On Fri, Nov 16, 2007 at 08:46:07AM -0800, Jamey Sharp wrote:
> 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. :-)

did you find out how fast you could get away with sampling the various
devices?  I have some robot applications where I found that if I sample
the data too fast I get different result than if I give things a chance
to settle.  Its a function of the device you are measuring.

> > 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
> units?
> > Some one should run the x/y acceleration data through and FFT to see
> > if there are any acoustical effects getting sampled.
> Please do! :-)

This weekend.

> > 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.

I'm sure it did, at one point, but once everything was integrated and
additional data was put on the CAN bus I'm thinking things where

So before lift off the data seems to come once a jiffie, after launch I
get 25ish samples per jiffie (most times) with spikes of 70 and lows of
1.  How do I infer a uniform time per sample?

> 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.

form just the data I can see I can't say its good even if I assume the
time stamp is bogus and use sample index as a type of clock.  I'll look
at the data again from this point of view this weekend to see if I can
see something different.
> > 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?

I'll get this information this weekend.

> 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.
> Jamey
> Version: GnuPG v1.4.6 (GNU/Linux)
> iD8DBQFHPclJp1aplQ4I9mURAjitAJ40iGFwfdSkE+7nLKV1lC5n38jxwQCeKjro
> YmUGg2Lu2IWQs85iYL8qgKA=
> =yU03

Attachment: signature.asc
Description: Digital signature

psas-software mailing list

Reply via email to