[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: Special Bulletin ANS-063.02 BOD Meeting




OUCH!

At 01:20 PM 3/16/01 -0800, karn@ka9q.net wrote:
> >> There was the minor matter of a LIU wiring error.
>
> >I keep hearing hints about this, but it semms conspicuously absent from
> >the history of the project. Anybody wanna share the story?
>
>A CD4015 8-bit serial-to-parallel converter listens to the engineering
>beacon generated by the IHU.  When the IHU sends the proper firing
>code prefix (think of the CRM-114 device in "Dr. Strangelove"), the
>converter captures a subsequent 8-bit fire duration value, loads it
>into two CD4029 4-bit counters that form an 8-bit counter, and begins
>firing the motor.
>
>The counters are clocked by the 400 Hz beacon clock divided by 1024 in
>a CD4040. This results in one count every 2.56 seconds. When the
>counter reaches zero, the motor valve is closed. The actual valve
>control pulses are generated by a pair of 555 timers (one to open, one
>to close).
>
>The problem? The PC traces carrying bits 5 and 6 from the
>serial-to-parallel converter to the down-counter were crossed.  So
>when the desired burn duration of 29 (hex) was sent to specify a burn
>duration of 105 sec, the counter was actually loaded with 49 (hex),
>giving a burn duration of 186.88 seconds. [Most of this information
>comes from my copy of the AO-10 LIU schematics and PC images. I didn't
>have the actual burn counts, so I regenerated them from the 2.56sec
>clock rate and the planned and actual durations given in Peter's
>message.]
>
>One thing to note about this bug is that there was no good reason to
>do the burn timing in dedicated hardware in the first place, as it
>could have easily been done in IHU software. Ariane safety
>requirements did reasonably dictate a hardware "lock" on the motor to
>make it impossible for an "insane" IHU to fire it until the
>appropriate keys were uplinked after launch. But this need only have
>taken the form of a simple interlock that, when enabled, allowed the
>IHU to fire the motor under direct software control. This would have
>avoided quite a few parts and, as it turned out, an opportunity to
>make a wiring mistake.
>
>Phil
>
>
>----
>Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
>To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org

----
Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org



AMSAT Top AMSAT Home