[psas-software] near-complete success with Adeos
Tue Jun 28 00:15:49 PDT 2005
Let me say first that I want to discuss alternatives for dealing with
these quarter-second events, but for a July 9th launch I'm not willing
to consider much new code unless there's a really serious need for it.
As a result I expect we'll be flying with a way bigger in-kernel buffer
and no other major changes.
On Mon, 2005-06-27 at 08:27 -0700, Carl Worth wrote:
> On Sat, 25 Jun 2005 13:18:06 -0700, Jamey Sharp wrote:
> > Give me a harder problem! That's about 1.6MB of data. We've already
> > dedicated 32MB of RAM to buffering in user-land. Heck, we have 37
> > seconds from going high-rate to dropping stuff, though unfortunately we
> > currently go high-rate before the beginning of the countdown, so those
> > 37 seconds are eaten up pre-launch.
> But pre-launch data needn't consume any precious resources, right?
> Can't we just stream that off or something to verify that things are
> working and save it if off-rocket where storage is cheap?
Well... That's true, I guess. Trying to take advantage of it makes me
nervous in case we fail to detect launch, or in case there turns out to
be something wrong with the flash that we don't notice until the motor
is burning. I'm also wary of trusting the network with our pre-launch
IMU data, because I think we want as much of that as we can get to
calibrate the sensor biases post-flight.
Some of my concerns would be addressed by turning on flash logging when
we enter Armed state at T-7 seconds or so, and trying to test that flash
writes are successful as part of the transition from there to
> > I don't think that's useful: the point is to write to something that we
> > hope will survive the rocket crashing, right?
> Since we (hopefully) have a lot more in-air time post-apogee than
> pre-apogee, can't we use that to get the skip-free data from ram to
I should have been more explicit: I had both senses of "crashing" in
mind. One of the failure modes we've thought about (we really should
track these better) is a flight computer reboot pre-apogee, maybe
because a connector comes loose under the high acceleration while the
motor is burning, or for whatever reason. (Of course, because of this
I'm especially unhappy about having a 2MB RAM buffer that we can't
control inside the flash card.)
There's also always the possibility of the rocket going to pieces
mid-air, for any number of reasons. We might have no usable time
post-apogee, but still be able to pull the flash card intact out of the
wreckage. (Did you hear that our avionics module is massively
We don't actually believe any of that will happen; as Bart pointed out
when we discussed the possibility of reboots, if we believed something
that awful had any real chance of happening, we wouldn't launch. But we
want to handle worst cases as gracefully as we can.
More information about the psas-avionics