Hammerhead/Protocol

From Openmoko

Revision as of 00:50, 29 April 2007 by Pavel (Talk | contribs)

Jump to: navigation, search

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

Analysis

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):

  • The start of a packet is marked by FF or FE.
    • FF in packets that do not carry data, but rather explicitly request a response. (This isn't used very often. More often we receive data without explicitly requesting it.) The response will be an FE-packet with the same length and type as the FF-packet. The GPS does not send any FF packets, only gltt does.
    • FE in packets that carry data sections.
  • The first word (32 bits) following the start-of-packet marker is the header.
    • The first byte (if it's indeed little-endian, the least significant byte) gives the data length, measured as the number of data words minus 1. For FE-packets, this is the length of the data section of this packet. For FF-packets, it's the length of the data section in the expected response.
    • The second byte of the header is always FD.
    • MS nibble of the third byte might be flags for the packet.
    • LS nibble of the third byte might be an identifying number which is echoed in responses to this packet.
    • The fourth byte is the packet type.
  • In FE-packets only, the data section (n 32-bit words) follows.
  • Finally, FC is sent to mark the end of the packet.
  • After the FC in an FF-packet, gltt sends a bunch of zeroes. In some cases it sends a number of zeroes equal to the number of bytes in the response packet; in some cases it sends more. I would guess that these have no effect.

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:

Frequency Type Max length Min length
9 16 73 11
86 08 19 11
8 e2 15 15
7 23 133 101
63 0a 15 15
6 24 71 39
52 0b 11 11
4 01 11 11
263 05 19 15
24 9d 315 19
2 06 25 19
16 e0 11 11
13 20 15 15
13 10 577 59
128 18 11 11
12 9e 303 15
117 00 65 39
11 0c 33 11
10 9f 477 61
10 0e 541 31
1 e5 11 11
1 80 17 17
1 13 11 11
1 04 23 23
1 02 11 11

NMEA

It is possible to translate NMEA messages into something readable using script like this:

  1. !/bin/bash

grep -v gettimeofday | \ sed 's/read.3/read(GPS/' | \ sed 's/write.3/write(GPS/' | \ sed 's/write.5/write(NMEA/' | \ sed 's/\\/\\\\/g' | \ while read LINE; do if echo $LINE | grep write.NMEA; then echo -e $LINE else echo "$LINE" fi done


NMEA description is available at http://www.gpsinformation.org/dale/nmea.htm .

At this point:

256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10 256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10 256 write(NMEA, "\x24\x47\x50\x47\x47\x41\x2c\x31\x35\x34\x31\x30\x34\x2e\x39\x35\x2c\x34\x39\x34\x38\x2e\x39\x35\x30\x33\x33\x39\x2c\x4e\x2c\x30\x30\x39\x35\x37\x2e\x39\x35\x35\x39\x37\x39\x2c\x45\x2c\x31\x2c\x30\x36\x2c\x35\x2e\x30\x2c\x32\x32\x30\x2e\x30\x2c\x4d\x2c\x2d\x30\x2e\x35\x38\x31\x30\x31\x34\x2c\x4d\x2c\x2d\x30\x2e\x31\x39\x30\x30\x31\x39\x30\x2c\x2a\x34\x30\x0d\x0a", 91) = 91 256 write(NMEA, "$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40 ", 91) = 91

...6 satelitte GPS fix was obtained. (And yes, there's big read few lines before that in the log). As far as I can tell, only 5-6 sattelite were _used_ till the end of log.

GSA sentence looks interesting, too. It tells us satellites #02, #04, #08, #10, #13 and #27 were used at this point.

256 write(NMEA, "\x24\x47\x50\x47\x53\x41\x2c\x41\x2c\x33\x2c\x30\x32\x2c\x30\x34\x2c\x30\x38\x2c\x31\x30\x2c\x31\x33\x2c\x32\x37\x2c\x2c\x2c\x2c\x2c\x2c\x2c\x36\x2e\x37\x2c\x33\x2e\x30\x2c\x36\x2e\x30\x2a\x33\x45\x0d\x0a", 51) = 51 256 write(NMEA, "$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E

Retrieved from "http://wiki.openmoko.org/index.php?title=Hammerhead/Protocol&oldid=8110"
Personal tools

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

Analysis

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):

  • The start of a packet is marked by FF or FE.
    • FF in packets that do not carry data, but rather explicitly request a response. (This isn't used very often. More often we receive data without explicitly requesting it.) The response will be an FE-packet with the same length and type as the FF-packet. The GPS does not send any FF packets, only gltt does.
    • FE in packets that carry data sections.
  • The first word (32 bits) following the start-of-packet marker is the header.
    • The first byte (if it's indeed little-endian, the least significant byte) gives the data length, measured as the number of data words minus 1. For FE-packets, this is the length of the data section of this packet. For FF-packets, it's the length of the data section in the expected response.
    • The second byte of the header is always FD.
    • MS nibble of the third byte might be flags for the packet.
    • LS nibble of the third byte might be an identifying number which is echoed in responses to this packet.
    • The fourth byte is the packet type.
  • In FE-packets only, the data section (n 32-bit words) follows.
  • Finally, FC is sent to mark the end of the packet.
  • After the FC in an FF-packet, gltt sends a bunch of zeroes. In some cases it sends a number of zeroes equal to the number of bytes in the response packet; in some cases it sends more. I would guess that these have no effect.

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:

Frequency Type Max length Min length
9 16 73 11
86 08 19 11
8 e2 15 15
7 23 133 101
63 0a 15 15
6 24 71 39
52 0b 11 11
4 01 11 11
263 05 19 15
24 9d 315 19
2 06 25 19
16 e0 11 11
13 20 15 15
13 10 577 59
128 18 11 11
12 9e 303 15
117 00 65 39
11 0c 33 11
10 9f 477 61
10 0e 541 31
1 e5 11 11
1 80 17 17
1 13 11 11
1 04 23 23
1 02 11 11

NMEA

It is possible to translate NMEA messages into something readable using script like this:

  1. !/bin/bash

grep -v gettimeofday | \ sed 's/read.3/read(GPS/' | \ sed 's/write.3/write(GPS/' | \ sed 's/write.5/write(NMEA/' | \ sed 's/\\/\\\\/g' | \ while read LINE; do if echo $LINE | grep write.NMEA; then echo -e $LINE else echo "$LINE" fi done


NMEA description is available at http://www.gpsinformation.org/dale/nmea.htm .

At this point:

256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10 256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10 256 write(NMEA, "\x24\x47\x50\x47\x47\x41\x2c\x31\x35\x34\x31\x30\x34\x2e\x39\x35\x2c\x34\x39\x34\x38\x2e\x39\x35\x30\x33\x33\x39\x2c\x4e\x2c\x30\x30\x39\x35\x37\x2e\x39\x35\x35\x39\x37\x39\x2c\x45\x2c\x31\x2c\x30\x36\x2c\x35\x2e\x30\x2c\x32\x32\x30\x2e\x30\x2c\x4d\x2c\x2d\x30\x2e\x35\x38\x31\x30\x31\x34\x2c\x4d\x2c\x2d\x30\x2e\x31\x39\x30\x30\x31\x39\x30\x2c\x2a\x34\x30\x0d\x0a", 91) = 91 256 write(NMEA, "$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40 ", 91) = 91

...6 satelitte GPS fix was obtained. (And yes, there's big read few lines before that in the log). As far as I can tell, only 5-6 sattelite were _used_ till the end of log.

GSA sentence looks interesting, too. It tells us satellites #02, #04, #08, #10, #13 and #27 were used at this point.

256 write(NMEA, "\x24\x47\x50\x47\x53\x41\x2c\x41\x2c\x33\x2c\x30\x32\x2c\x30\x34\x2c\x30\x38\x2c\x31\x30\x2c\x31\x33\x2c\x32\x37\x2c\x2c\x2c\x2c\x2c\x2c\x2c\x36\x2e\x37\x2c\x33\x2e\x30\x2c\x36\x2e\x30\x2a\x33\x45\x0d\x0a", 51) = 51 256 write(NMEA, "$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E