View source for Hammerhead/Protocol
From Openmoko
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Return to Hammerhead/Protocol.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Return to Hammerhead/Protocol.
Christian did some stracing on TomTom device, and result is great logs at http://www.maintech.de/download/hammerhead-strace.log .
GPS seems to communicate in packets.
Direction GPS -> machine
read(3, "\xfe\x00\xfd\x80\x16\x19\x0b\x00\x00\xfc", 2048) = 10
\xfe: begining of packet \x00: type of packet? seems to determine length. \xfd: follows .... \xfc: packet end
GPS signals at wikipedia seems to be required reading: http://en.wikipedia.org/wiki/GPS_signals
Were there by any chance 8 satellites overhead at the time that log was made?
The protocol appears to be oriented around 32-bit words (the single-byte markers notwithstanding.) I'm not absolutely certain, but I strongly suspect the byte order is LSB-first.
The 80 80 80 stuff is probably just to force resynchronizing after an error, or wake the device up, or something like that.
It is - we have this information from another source. It's to train the UART in the hammerhead to the correct speed. --Speedevil 11:39, 28 April 2007 (CEST) Packet format (same format in both directions):
For example:
ff 04fdc00c fc
(possibly followed by zeroes), is a request for a packet of type 0C, with length 20d ((4 + 1) * 4), and flags C0.
fe 04fdc00c 0025102a 45dbdd4e 36030000 4b260000 16010000 fc
would be an appropriate response.
Packet types:
count type 263 05 168 9d 128 18 117 00 89 23 86 08 75 10 63 9f 63 0a 52 0b 48 0e 31 9e 16 e0 13 20 12 0c 10 16 8 e2 6 24 4 01 2 06 1 e5 1 13 1 04 1 02