Hammerhead/Protocol
From Openmoko
(→NMEA) |
m (→NMEA: add formatting) |
||
Line 105: | Line 105: | ||
It is possible to translate NMEA messages into something readable using script like this: | It is possible to translate NMEA messages into something readable using script like this: | ||
− | + | <pre> | |
#!/bin/bash | #!/bin/bash | ||
grep -v gettimeofday | \ | grep -v gettimeofday | \ | ||
Line 119: | Line 119: | ||
fi | fi | ||
done | done | ||
− | + | </pre> | |
NMEA description is available at http://www.gpsinformation.org/dale/nmea.htm . | NMEA description is available at http://www.gpsinformation.org/dale/nmea.htm . |
Revision as of 10:31, 29 April 2007
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:
#!/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