[Ground-station] pop quiz!

Mon Jun 11 23:27:11 PDT 2018

All,

OK, I'm going to give this a go! Spoiler alert and lots of whitespace 
before my attempts at answers (please be gentle if I'm in left field! hi 
hi).....................................

------------------------------------- POTENTIAL SPOILER 
ALERT--------------------------------------------------

-------------------------------------STOP READING IF YOU DON'T WANT TO 
SEE MY ANSWER 
ATTEMPTS-------------------------------------------------------

-----------------------OK, YOU'VE BEEN 
WARNED.....TWICE---------------------------------------------------------------------

------------------BEGIN ANSWER---------------------

So first off, this is a Motor Firing set of questions....which lead me 
to the LIU set of schematics (marked page 129b, PDF page number 158).  
The first question plus hints leads towards a hunt for a hardware timing 
error.  The golden nugget I believe is the indication of a 1.68 factor 
(longer burn time than expected).....which I'll get to in a second.

Bit of my logic/attempt at understanding the schematic:

I think I narrowed things down to the 4015 chip (U4, dual 4 bit serial 
to parallel shift registers, configured to be an 8 bit shift register) 
and the pair of 4029 chips (U2, U3) near the top center of the page 
(with the 'burn counter' lines coming out). Also relevant is the 4029 
chip (no 'U' label) below U2/U3 that I think is the 'kick' to start the 
firing sequence by setting the 'JAM' signals (aka preset enable) on 
U2/U3 to initialize the countdown values in U2/U3 that are loaded into 
U4.  The 'kick' signal out of the 4029 is tied to Q4, so 8 cycles of the 
undecimated clock passes before this bit is set (and stopped since its 
also tied to the inhibit), allowing the serial to parallel registers to 
be clocked in (from the pn sequence decoders) before the 'kick' that 
takes their values and maps them to the U2/U3 chips.  The 4040 Chip 
(U11) looks like its being used for clock decimation.  The 4022 chip 
(U5) looks like it is the valve sequencer that controls the order and 
repetition rate of the opening and closing of the helium, UDMH, and N2O4 
valves, ultimately controlling the rate at which fuel and oxidizer flows 
to the motor.

If I'm reading the schematic correctly, it looks like U2/U3 comprise an 
8 bit timer with 256 (0 - 255) possible countdown times.  U2 is the low 
nibble, U3 is the high nibble.  Every time U2 reaches the all zeros 
state, the U2 Carry Out toggles Low for one clock period, which allows 
U3 to decrement by one count.  U2 is fed by the 'B' side of U4 and U3 is 
fed by the 'A' side of U4. Via a sequence of NAND gates, it looks like 
the initial 'kick' signal triggers a Monostable multivibrator (aka a 
'one shot') on the U21 555 Timer that is the 'START' of the burn.  When 
the countdown finishes, it looks like another monostable multivibrator 
555 (U9) fires the 'STOP' command.  This is where my understanding 
begins to break down, because it could be that the 555s are astable 
multivibrator configurations (maybe some kind of charge pump for the 
ignition coils?, or maybe the ignition is being fired in sync with the 
valve sequencing?) that are being toggled on and off rather than actual 
one shots, and I'm not positive about how the valves are actually 
'actuated' by the control circuitry.  I am sure that I am missing lots 
of details, but I think I have a pretty good understanding of what the 
'regions' of the schematic are responsible for.

To the point......

Answer to Question 1:

I think there is a transposition of the high nibble and the low nibble 
when transferred from the 4015 to the respective 4029s for the 
countdown.  The bits are 'mirrored' about their 4 bit lanes when 
transferred.  More specifically, the 4015 clocks in the serial data on 
the 'B' side first, and then those bits are transferred to the 'A' side 
as four more bits are moved into the 'B' side.  I think the fundamental 
problem is that what becomes the least significant bit of each nibble in 
the 4015 becomes the most significant bit in the respective nibbles of 
the overall countdown timer.  Lets say that the intended 8 bit sequence 
that is clocked into the 4015 is the following:  0010 1111, where the 
0010 is the High Nibble, side A of the 4015 and 'jammed' into U3 on 
'kick' and 1111 is the Low Nibble, side B of the 4015, and 'jammed' into 
U2 on 'kick'.  When the 'kick' signal is applied, the 0010 of the 'A' 
side of the 4015 then becomes 0100 in U3.  A similar process happens on 
the Low Nibble, but since it is 1111, the transposed result is also 1111.

Why did I pick that bit sequence?...This is where the 1.68 factor comes 
in.  I'm not sure of the actual clock period, so lets assume for the 
moment that the clock frequency is 1 Hz, or a rate of 1 clock period per 
second.  For an intended countdown of 0010 1111, this would result in a 
47 second burn.  With the transposition of the high nibble, the actual 
countdown timer is then 0100 1111, which results in a 79 second burn.  
79/47 = 1.680851064.  Thus the motor burns longer than expected by a 
factor of 1.68.  I figured out the bit sequence using a giant excel 
spreadsheet and listing out all 256 combinations of 'expected' sequences 
and the resulting 'transposed' sequences, with the associated burn times 
for each, and thus the ratio of burn times and only one bit sequence 
shows a factor of 1.68 of Actual burn time over expected burn time 
(programmers reading this.....please don't throw any rotten tomatoes, 
copy and paste is quick in excel...hi hi).

Answer to Question 2:

IF a maximal length burn was tested on the ground, the transposition in 
the 'jamming' from the 4015 to the 4029s would not have been detected.  
1111 1111 with each of the nibbles transposed is 1111 1111.  Still 
works!  The most OCD test (and expensive if actual propellant was used 
during the test) would be to test all 256 potential burn periods (one of 
them would be '0' and thus the cheapest!).  Measuring the burn time of 
each burn and comparing against the expected burn times for the sequence 
loaded would have revealed the problem.

Answer to Question 3:

No idea really.  Zero experience with how these kinds of valves work.  
I'm guessing if the problem is 'electrical' in nature it maybe has 
something to do with the timing between the 4040 clock decimation chip 
('pyro speed' indicators here, without remote control of the selector, 
suggesting the developers were testing various rates, and then settled 
on a jumper for the fastest rate) and the 4022 valve sequencer that is 
'self inhibiting' (maybe another step of clock decimation?).  It looks 
like the Helium control valve is the first valve in the sequence at one 
of the lower bit values (bit '2') relative to the higher bit values.  So 
maybe the helium valve is getting 'toggled' more frequently, meaning 
less 'time open' and thus reduced helium pressure in the 
propellant/oxidizer tanks (like maybe it was getting 'stuck' and the 
toggle rate was too rapid to allow sufficient helium to make it into the 
tanks?).  Maybe this was less of a problem earlier before the big burn 
because the propellant/oxidizer tanks had sufficient pressure on their 
own when they were more full (requiring less helium to pressurize them 
sufficiently)?  Last shot in the dark.........The 4022 is tied back into 
the pn sequence decoder reset lines.....so maybe some kind of reset 
occuring relatively quicker than expected even when the right pn 
sequences are sent.  maybe the 4022 hits the reset condition, which 
clears the pn sequences from the registers, requiring some number of 
clock periods (8?) before they are 'reloaded' with the correct pn 
sequence, reenabling the process.....so sort of a 'stop and go' 
situation with the valve sequencing.....again, maybe not a big deal when 
the tanks were full and had their own pressure, but more of a concern 
later when more helium is needed to pressurize fully?

That's it.......again, I'm sure I screwed up a lot of the details, but 
that's my best guesses for the three questions.  Fun game!  I look 
forward to partial credit!

-Zach, KJ4QLP

Research Associate
Aerospace Systems Lab
Ted & Karyn Hume Center for National Security & Technology
Virginia Polytechnic Institute & State University
Work Phone: 540-231-4174
Cell Phone: 540-808-6305

On 6/11/2018 9:31 AM, Douglas Quagliana wrote:
> Friends,
>
> Even if you know the history, you might not have seen the actual 
> blueprints, and you still have to find it in the blueprints.
>
> Regards,
> Douglas
>
> On Jun 11, 2018, at 6:59 AM, Michelle Thompson via Ground-Station 
> <ground-station at lists.openresearch.institute 
> <mailto:ground-station at lists.openresearch.institute>> wrote:
>
>> Good question - post with a generous spoiler alert style header. Cc 
>> Phil for a faster reply.
>>
>> On Mon, Jun 11, 2018, 04:52 Zach Leffke via Ground-Station 
>> <ground-station at lists.openresearch.institute 
>> <mailto:ground-station at lists.openresearch.institute>> wrote:
>>
>>     Do you want answers (or attempts at answers) on the list or
>>     direct to you?
>>
>>
>>     -Zach, KJ4QLP
>>
>>     Research Associate
>>     Aerospace Systems Lab
>>     Ted & Karyn Hume Center for National Security & Technology
>>     Virginia Polytechnic Institute & State University
>>     Work Phone: 540-231-4174
>>     Cell Phone: 540-808-6305
>>
>>     On 6/8/2018 10:36 PM, Michelle Thompson via Ground-Station wrote:
>>>     Phil Karn KA9Q has been working on something fun for us. If you
>>>     enjoy this quiz, please feel free to share it and let him know!
>>>
>>>     Given the documents that you can find at:
>>>     https://github.com/phase4space/AO-10-blueprints
>>>
>>>     Quiz for fans of the AMSAT Phase IIIB/AO-10 blueprints
>>>     Phil Karn, KA9Q
>>>
>>>     Question 1: AO-10 carried a 400-newton kick (rocket) motor that
>>>     used hypergolic propellants. It was fired only once, but the
>>>     burn duration was 1.68 times longer than planned. Why? (Note:
>>>     the burn did *not* end because of propellant depletion.)
>>>
>>>     The cause can be discerned from the prints; i.e., it was a
>>>     hardware problem, not a software bug or operational mistake.
>>>
>>>     Optional hint 1: The burn was timed in hardware.
>>>
>>>     Question 2: The ground test of the hardware consisted of
>>>     successfully executing a maximal length burn. What tests could
>>>     have revealed it?
>>>
>>>     Question 3: Although the first burn did not deplete the
>>>     propellants, it was not possible to fire the engine again
>>>     because of insufficient helium pressure. Why? (Hint: the cause
>>>     was not insufficient helium loading before launch.)
>>>
>>>
>>>     _______________________________________________
>>>     Ground-Station mailing list
>>>     Ground-Station at lists.openresearch.institute
>>>     <mailto:Ground-Station at lists.openresearch.institute>
>>>     http://lists.openresearch.institute/mailman/listinfo/ground-station
>>
>>     _______________________________________________
>>     Ground-Station mailing list
>>     Ground-Station at lists.openresearch.institute
>>     <mailto:Ground-Station at lists.openresearch.institute>
>>     http://lists.openresearch.institute/mailman/listinfo/ground-station
>>
>> _______________________________________________
>> Ground-Station mailing list
>> Ground-Station at lists.openresearch.institute 
>> <mailto:Ground-Station at lists.openresearch.institute>
>> http://lists.openresearch.institute/mailman/listinfo/ground-station

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20180612/0e4e8134/attachment.html>