Hash: SHA1

On 11/16/07, mark gross <[EMAIL PROTECTED]> wrote:
> are the a2d samples 2 or one byte each?  (I'm assuming you where using
> a 10bit cheap A2D to take the measurements)

Two bytes, yes; the ADCs were 12-bit. I expect they *were* cheap,
though, as you say. :-)

> The x,y acceleration data is very noisy. ... Given that the Z data is
> reasonable its likely the data is just too noisy all buy itself.

The X/Y accelerometer pair are on a different scale than the Z/Q pair.
Is the noise still significantly different after you convert to common

> Some one should run the x/y acceleration data through and FFT to see
> if there are any acoustical effects getting sampled.

Please do! :-)

> On Thu, Nov 15, 2007 at 10:11:02AM -0800, Jamey Sharp wrote:
> > You can reasonably assume that the IMU had a good clock, so
> > reconstructing higher-precision timestamps isn't that hard. You
> > could similarly reconstruct the timestamps of messages that
> > originated in the flight computer or on the ground, if desired.
> Umm, no. I cant.

Yes, you can. ;-) The timestamps were computed by the flight computer;
explanation of those issues is below. But the IMU can be expected to
have done the actual sampling at a very regular interval. It was just a
micro-controller, and had low latencies in its timer interrupt handler.
I believe Andrew tested that with a good oscilloscope.

You do have to account for dropped packets though. Since the flash disk
on the rocket was destroyed, this log comes from what we captured over
wi-fi, and while that's incredibly good, it isn't perfect.

> Looking at the time stamp data it seems to change in the number
> samples taken per jiffy a lot.  I see data with between 1 and 69
> IMU_ACCELL_DATA records per jiffies.  (look at time stamps 1931.90,
> 1931.91 for example)
> Attached is a plot of the count of  IMU_ACCELL_DATA records per unique
> time stamp in the file.  It doesn't look good (but hay there are some
> interesting periodicities in it, could point to where some of the
> problems are).

I can't tell from your graph, but once the spikes become periodic,
they're about 5.3 seconds apart, right? And that starts about 38 seconds
after the data rate kicks up to full speed?

We measured this before the flight, but weren't able to implement a fix
in time. Our hypothesis is that whenever the flash disk we were logging
to flushed its write buffers, the kernel would hang until it was done.
It wasn't even handling interrupts during that interval, which lasted
about a quarter of a second, as I recall. We had to apply the ADEOS
patch to collect raw data packets from the CAN controller before its
buffers overflowed. We could have used ADEOS to make the timer interrupt
reliable too, and perhaps higher-frequency, but didn't get to it.

Ignoring those spikes, the spread of messages-per-jiffy is still a
little larger than I'd have expected. I'm not sure what explains that,
off-hand, if you really did only plot IMU_ACCEL_DATA messages.

Version: GnuPG v1.4.6 (GNU/Linux)


psas-software mailing list

Reply via email to