[Ground-station] pop quiz! (SPOILERS!)

[Zach Leffke]

Thanks for the feedback (partial credit...woot!) and explanation about 
the valves!  I'll do more squinting at the document later when I get a 
chance and see if I can sync up your feedback with my guess and correct 
my line of thinking (being vague here on purpose for spoiler avoidance 
reasons).

FYI, one of our PhD Computer Engineering students (Seth, on this list) 
and I were talking about this earlier today, and his question was 'why 
not do it in software.....?' kind of in sync with your thoughts there 
Phil.........


Thanks again to all, this was a fun one...........I'm also thinking 
about posting a hard copy of the document at our Space at VT group and 
re-issuing the 'find the flaw' challenge to the Spacecraft engineering 
minded students there.  Good lessons here about the value of 
documentation, testing, procedures, troubleshooting, etc.


-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/15/2018 6:44 PM, Phil Karn wrote:
> Hi Zach,
>
> You're pretty close.
>
> You are correct that the LIU consists of an 8-bit count-down timer
> (U2/U3) fed by a 8-bit serial-to-parallel converter (U4), but  I think
> the schematic is correct as drawn. There was a PC layout error that
> reversed the four bits in the high nybble of the commanded burn interval
> between U4 and U3. The low nybble connections from U4 to U2 are correct.
>
> That is, U4 pins 5, 4, 3 and 10 should go to U3 pins 4, 12, 13, and 3 as
> shown in the schematic. Instead they went in to U3 reverse order, i.e.,
> to pins 3, 13, 12 and 4.
>
> So the commanded bit sequence
>
> 76543210
>
> got loaded as
>
> 45673210
>
> i.e., 0x2f became 0x4f. I calculated 1.68 myself from those two values;
> good work on re-deriving them!
>
>> 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.
> The motor has separate 'start' and 'stop' commands. The fuel and
> oxidizer valves are pneumatically actuated by pressurized helium that is
> in turn controlled by a single latching-type solenoid. A 200 ms wide
> negative pulse on the coil opens it, and it remains open until a
> positive pulse on the coil closes it. Q10 and Q11 form a DC-DC converter
> to produce the negative voltage to open the helium valve.
>
> Latching type solenoids are often used in aerospace relays to save
> power, but I can't imagine that would be much of a consideration here. I
> presume it was done to avoid a mechanical spring that could fail.
>
> I think the same or very similar engine was flown on AO-40, and you may
> remember its failure due to a red vent cap that should have been removed
> before flight. If I recall correctly, the capped port vented the helium
> control manifold to vacuum when the control solenoid was closed. When
> the solenoid closed, the helium pressure was not properly relieved and
> at least one of the propellant valves stayed open.
>
>> 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.
> There's no need to test electronics with actual propellant, or even to
> try all 256 possible durations. Just do a walking-bit test: command the
> eight values 0x80, 0x40, 0x20...0x01 and see that they all work
> correctly. Also, the burn timing counter was telemetered where it could
> also have been checked in software.
>
> Personally, I would have put most of this in software. The only hardware
> you really need, aside from power supplies to pulse the solenoid, would
> be a safe-arm circuit to keep an insane computer from firing the motor
> unintentionally. I'd use just one PN sequence detector. Send it the arm
> sequence and it would turn on the solenoid power supplies just long
> enough for the software to conduct a maximal-length burn.
>
> Of course all of this is obvious in hindsight.
>
> The helium pyro valves were single-shot. They were fired before the
> first burn and remained open thereafter. The helium expanded
> adiabatically from the high pressure cylinder, which meant it cooled
> quite a bit. Since the first burn was unexpectedly long, the thinking is
> that the fittings on the helium tank got so cold that differential
> contraction allowed them to leak and lose pressure. So there wasn't
> enough to perform another burn.
>
> 73, Phil