Hammerhead/Protocol

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(→‎NMEA)
m (Replacing 'Freerunner' with 'FreeRunner')
 
(71 intermediate revisions by 12 users not shown)
Line 1: Line 1:
−
Christian did some stracing on TomTom device, and result is great logs at http://www.maintech.de/download/hammerhead-strace.log .
+
Hammerhead is the GPS receiver chip used in the Neo 1973. The only way currently to use it is via a closed-source binary program. This page describes efforts to write an open source driver. (Mostly abandoned since the release of the Neo FreeRunner which uses a different chipset)
  
−
GPS seems to communicate in packets.
+
== Repository ==
  
−
Direction GPS -> machine
+
We have set up a SCM repository for experimental code and documentation at http://projects.linuxtogo.org/projects/sphyrna.
  
−
read(3, "\xfe\x00\xfd\x80\x16\x19\x0b\x00\x00\xfc", 2048) = 10
+
[[User:mmontour]] has created a quick and dirty gtk program called 'satscan' which performs the first steps of a cold-start acquisition. It scans through the satellite numbers 8 at a time in several different frequency bands, and displays a symbol on the screen indicating the strength of each signal. The program (which includes portions of 'hhtest.c') is available here: [http://members.shaw.ca/mmontour/satscan/]. Description/screenshots are 
  
−
\xfe: begining of packet
+
[http://openmoko.togaware.com/survivor/SatScan.html]
−
\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
+
== Background resources ==
  
−
=== Analysis ===
+
Christian did some stracing on TomTom device, and result is great logs at http://www.maintech.de/download/hammerhead-strace.log . 'pH5' on IRC has put up some traces at http://linuxtogo.org/~ph5/tmp/gllin (a cold start, a hot start and a somewhat longer trace). He even has a software that can init and send command to phase-1 openmoko device in http://linuxtogo.org/~ph5/tmp/hhtest.c . (Please use strace -s9999 -x to produce traces).  http://folks.o-hand.com/andrew/strace-schwartz-oabi is a log of all library calls (i.e. a superset of system calls) made by gllin during a hot start and acquiring the time (but no fix), except acos() because printing all acos() calls would fill gigabytes per second.
  
−
Were there by any chance 8 satellites overhead at the time that log was made?
+
A file giving doppler information on the above longtrace NMEA is on [http://www.mauve.plus.com/gps].
  
−
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.
+
[http://en.wikipedia.org/wiki/GPS_signals GPS signals at wikipedia] seems to be required reading for very basics, along with  [http://www.colorado.edu/geography/gcraft/notes/gps/gps.html this page from University of Colorado] for more in depth stuff.
  
−
The 80 80 80 stuff is probably just to force resynchronizing after an error, or wake the device up, or something like that.
+
http://home.earthlink.net/~cwkelley/ has sources for open-source GPS receiver, and
 +
http://home.earthlink.net/~cwkelley/documentation.htm is its documentation.
  
−
It is - we have this information from another source. It's to train the UART in the hammerhead to the correct speed. --[[User:Speedevil|Speedevil]] 11:39, 28 April 2007 (CEST)
+
https://okeefesrv.geomatics.ucalgary.ca/essentials/index.html provides a library of useful GPS-related algorithms under a 3-clause BSD license.
  
−
Packet format (same format in both directions):
+
GP2021 is "dumb" GPS receiver, similar to hammerhead. (But I think it communicates over ISA bus, not over serial). However, its data sheets are freely available. Well, hammerhead marketing tells us that their GPS chip is something special, http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=3053 . It seems to differ from "dumb" receivers by doing code phase search in hardware, directly.
−
* 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:
+
There is an interesting paper on increasing accuracy of commercial GPSs that may be applicable. [http://www.ion.org/search/view_abstract.cfm?jp=j&idno=2439].
−
ff 04fdc00c fc
+
Other interesting papers. [http://gauss.gge.unb.ca/papers.pdf/iongpsgnss2003.beran.pdf] [http://topo.epfl.ch/documents/EuroSDR/beran05.pdf]
−
(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
+
=== Packet format & comm protocol ===
−
would be an appropriate response.
+
  
−
Packet types:
+
See sphyrna project for up-to-date decoding info.
−
{|
+
−
| 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 ===
+
[[Category:GPS]]
−
 
+
−
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
+

Latest revision as of 14:39, 31 August 2008

Hammerhead is the GPS receiver chip used in the Neo 1973. The only way currently to use it is via a closed-source binary program. This page describes efforts to write an open source driver. (Mostly abandoned since the release of the Neo FreeRunner which uses a different chipset)

[edit] Repository

We have set up a SCM repository for experimental code and documentation at http://projects.linuxtogo.org/projects/sphyrna.

User:mmontour has created a quick and dirty gtk program called 'satscan' which performs the first steps of a cold-start acquisition. It scans through the satellite numbers 8 at a time in several different frequency bands, and displays a symbol on the screen indicating the strength of each signal. The program (which includes portions of 'hhtest.c') is available here: [1]. Description/screenshots are

[2]

[edit] Background resources

Christian did some stracing on TomTom device, and result is great logs at http://www.maintech.de/download/hammerhead-strace.log . 'pH5' on IRC has put up some traces at http://linuxtogo.org/~ph5/tmp/gllin (a cold start, a hot start and a somewhat longer trace). He even has a software that can init and send command to phase-1 openmoko device in http://linuxtogo.org/~ph5/tmp/hhtest.c . (Please use strace -s9999 -x to produce traces). http://folks.o-hand.com/andrew/strace-schwartz-oabi is a log of all library calls (i.e. a superset of system calls) made by gllin during a hot start and acquiring the time (but no fix), except acos() because printing all acos() calls would fill gigabytes per second.

A file giving doppler information on the above longtrace NMEA is on [3].

GPS signals at wikipedia seems to be required reading for very basics, along with this page from University of Colorado for more in depth stuff.

http://home.earthlink.net/~cwkelley/ has sources for open-source GPS receiver, and http://home.earthlink.net/~cwkelley/documentation.htm is its documentation.

https://okeefesrv.geomatics.ucalgary.ca/essentials/index.html provides a library of useful GPS-related algorithms under a 3-clause BSD license.

GP2021 is "dumb" GPS receiver, similar to hammerhead. (But I think it communicates over ISA bus, not over serial). However, its data sheets are freely available. Well, hammerhead marketing tells us that their GPS chip is something special, http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=3053 . It seems to differ from "dumb" receivers by doing code phase search in hardware, directly.

There is an interesting paper on increasing accuracy of commercial GPSs that may be applicable. [4]. Other interesting papers. [5] [6]

[edit] Packet format & comm protocol

See sphyrna project for up-to-date decoding info.

Retrieved from "http://openmoko.org/index.php?title=Hammerhead/Protocol&oldid=51131"
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