On Thu, Nov 15, 2007 at 10:11:02AM -0800, Jamey Sharp wrote:
> Hash: SHA1
> On 11/15/07, mark gross <[EMAIL PROTECTED]> wrote:
> > Is there a format specification for the packed 16 byte array of data?  I
> > would like to check the text dumps.
> You don't trust me? ;-) The text dump I provided contains every bit of
> information that has a defined meaning in the binary telemetry, unless
> you want the timestamps of all the fragments of the big GPS messages, or
> you want stuff from before the last time we turned on the flight
> computer. I don't see any way that either of those are useful. It
> discards bytes that are uninitialized, but we're trying to do data
> analysis here, not fuzzing...
> But here's the format:
> 4-byte big-endian "ID"
> 4-byte big-endian timestamp
> 8 bytes of data

OK, so now looking at the Rocketview_20050820.log using hexedit which lists
out the data in 18 byte chunks.

I'm not seeing the above record format, is there some variable length
thing going on?

> The ID is a packed bitfield, with only the low 16 bits being
> significant. The least significant 4 bits are the "data length", the
> next bit is "RTR", and the remaining 11 bits are what CAN calls the
> message ID.
> Data length is limited to the range 0..8. If RTR is 1, there is no
> actual data, but the length field can still be in the range 0..8. If RTR
> is 0, the first "length" bytes of the data have valid data in them.

Does this mean the record length is variable or the valid data in the
fixed length record varies?

> > Also, the time stamp data in the acceleration is not high enough
> > resolution to be unique.
> Nope. We used the value of "jiffies" for each timestamp. We flew a 2.4
> kernel, so HZ was 100.
> 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.
> > ... the perl code git snapshot ... doesn't run to completion
> Hmmm, it Works For Me (tm). It does need to be able to seek on its
> input, so don't feed it a pipe.
> > I wrote a python program to average the acc values for the items with
> > the same time stamp and make a plot.  (see attached)
> Interesting, thanks!
> Jamey
> Version: GnuPG v1.4.6 (GNU/Linux)
> iD8DBQFHPIutp1aplQ4I9mURAhXoAJ9QD7mdvmjwppRft285TVSLgVlntQCaAzyk
> B8cqYXt7eiOOlQSKpmUr+7o=
> =+OoI

Attachment: signature.asc
Description: Digital signature

psas-software mailing list

Reply via email to