On Tue, Nov 20, 2007 at 09:00:07AM -0800, Jamey Sharp wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11/20/07, mark gross <[EMAIL PROTECTED]> wrote:
> > On Thu, Nov 15, 2007 at 10:11:02AM -0800, Jamey Sharp wrote:
> > > 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.
> 
> You meant 16, surely.
> 
yeah 16.

> > I'm not seeing the above record format ...
> 
> `hexdump -v 20050820.log` shows me one sensible-looking message per
> line, though AFAICT it treats the input as native-endian and can't be
> forced to big-endian.

Help me interprit the following:
00001490   00 00 73 01  00 00 1E B4  34 00 04 A5  07 31 07 75 ..s.....4....1.u
000014A0   00 00 0B 50  00 00 00 00  00 00 00 30  00 00 00 00 ...P.......0....
000014B0   00 00 09 41  00 00 1E B7  30 00 04 A5  07 31 07 75 ...A....0....1.u
000014C0   00 00 2B 90  00 00 00 00  00 00 00 30  00 00 00 00 ..+........0....
000014D0   00 00 2B 81  00 00 1E BB  01 00 04 A5  07 31 07 75 ..+..........1.u
000014E0   00 00 2B B0  00 00 00 00  00 00 00 00  00 00 00 00 ..+.............
000014F0   00 00 2B A1  00 00 1E BF  00 00 04 A5  07 31 07 75 ..+..........1.u
                 id id  ts ts ts ts  dd dd dd dd  dd dd dd dd

Whats with the wacky ordering of the id bytes?
I was expecting that I could use the can id's to infer time stamp.

What are there lines with no time stamps?

00020160   00 00 01 A8  00 00 00 00  FF FF 7F E1  07 00 00 00 ................
00020170   00 00 01 E4  00 00 00 00  00 01 59 74  20 92 09 0A ..........Yt ...
00020180   FF FF F0 28  00 00 00 00  76 07 0D 2D  00 02 1F 85 ...(....v..-....
00020190   FF FF F8 04  00 00 00 00  00 02 00 04  E0 FB 3F BF ..............?.
000201A0   FF FF F8 A1  00 00 00 00  07 02 00 04  E0 FB 3F BF ..............?.
000201B0   FF FF F8 27  00 00 00 00  14 08 07 D5  13 34 06 BF ...'.........4..
000201C0   FF FF F8 48  00 00 00 00  04 8E CD 4E  F3 73 07 53 ...H.......N.s.S
000201D0   FF FF F8 64  00 00 00 00  00 03 44 01  F3 73 07 53 ...d......D..s.S
000201E0   00 00 53 08  00 02 3D AF  EB 03 2D 00  00 00 E9 79 ..S...=...-....y

how do I interprate the data from 0x00020180?

> 
> > > 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?
> 
> The amount of valid data varies.
> 
> By the way: If you're going to insist on reading the raw data yourself,
Its shaping up that way.

> you may find useful this list, of record numbers where the flight
> computer rebooted and the value of 'jiffies' goes back to near zero. I
> used it with csplit.
> 
> 92407
> 93785
> 225588
> 745298
> 757639
> 
> Jamey
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFHQxKOp1aplQ4I9mURAv6AAJ98XE/4aYj2EVCxqYhRH5rjJnTU5QCfTf+C
> uiVTAP4XgAvKk4Kepxbbjco=
> =C7IC
> -----END PGP SIGNATURE-----

Attachment: signature.asc
Description: Digital signature

_______________________________________________
psas-software mailing list
psas-software@lists.psas.pdx.edu
http://lists.psas.pdx.edu/mailman/listinfo/psas-software

Reply via email to