-----BEGIN PGP SIGNED MESSAGE-----
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
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
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.
> 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)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
psas-software mailing list