Hammerhead/Protocol

From Openmoko

(Difference between revisions)
Jump to: navigation, search
m (→‎Analysis: add comment about 0x80 at starrt)
m (Replacing 'Freerunner' with 'FreeRunner')
 
(75 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):
+
−
* 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:
+
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.
−
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
+
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].
−
would be an appropriate response.
+
Other interesting papers. [http://gauss.gge.unb.ca/papers.pdf/iongpsgnss2003.beran.pdf] [http://topo.epfl.ch/documents/EuroSDR/beran05.pdf]
  
−
Packet types:
+
=== Packet format & comm protocol ===
−
  count type
+
 
−
    263 05
+
See sphyrna project for up-to-date decoding info.
−
    168 9d
+
 
−
    128 18
+
[[Category:GPS]]
−
    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
+

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://wiki.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: 

 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