[Ground-station] pop quiz!

Zach Leffke zleffke at vt.edu
Fri Jun 15 10:57:06 PDT 2018


I know its not a priority, so no worries, but wondering if anyone that 
has the 'answer key' to the pop quiz has had a chance to review my 
answer?  I anxiously refresh my email on my phone twenty+ times a day in 
anticipation of the 'you sir.....are crazy wrong' email.


-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/12/2018 2:27 AM, Zach Leffke via Ground-Station wrote:
>
> 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
>
>
>
> _______________________________________________
> Ground-Station mailing list
> 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/20180615/1ad25bf9/attachment.html>


More information about the Ground-Station mailing list