View source for Hammerhead/Protocol

From Openmoko

Jump to: navigation, search

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Administrators.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page:

Return to Hammerhead/Protocol.

Personal tools

Christian did some stracing on TomTom device, and result is great logs at . 'pH5' on IRC has put up some traces at (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 . (Plesae use strace -s9999 -x to produce traces).

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. has sources for open-source GPS receiver, and is its documentation.

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, . It seems to differ from "dumb" receivers by doing code phase search in hardware, directly.

Possible lock scheme that it may use

From reading the published brief information sheets on global locates products, not the patents. The global locate chip has massively parallel correlators, and configurable integrators to integrate over a given time. I would expect it to do something like - in this case.

  • Load orbit data from file.
  • Look at time.
  • Compute which satellites are up.
  • Init the GPS.
  • Set the hardware to expect to receive from the set of visible satellites (the hardware is unlikely to be designed to receive them all at once, as you'll never see more than around 12 of the nominal 24).
  • Set the integration time at 10ms-20ms or so - around, or a bit under a data bit.
  • Now, read back the outputs of the integrators, to see if we've got possible data.
  • If we do have data, spend a bit of time working out where the data bits begin and end in the datastream per satellite.
    • it's possible this is done in hardware
  • Now that we've got all the satellites locked in the hardware, simply interrogate the hardware regularly, so that we can read out the 50bps datastream from each satellite.
    • It seems this step takes 19s or so. From the first timestamp in the file, to the first GPGSV line - satellites in view, and their actual signal strengths.
  • Read the navigation messages from each satellite, which cycles every 6 seconds.
  • Compute a position.
  • Output it to NMEA
    • It seems this takes 22 seconds.


To keep to the datasheet of 1s position times, it cannot read the whole navigation message, but significantly under 50 bits of it. It must.

  • Use 'AGPS' data to initialise the hardware to a condition where it can get a rapid lock - perhaps telling it the Doppler - then compute what the navigation message from each satellite may be, based on the internal clock.
  • Work out at what point in this navigation message the 20-30 bits that it's received come.
  • Compute the time that was in the navigation message, though it may not have picked it up (from the internal clock) and add it to the information on where the bit edges are from the hardware.
    • If the uncertainty in relative time - due to local clock drift and movement of the GPS device - is under 10ms, then you know immediately as you detect the satellite signal the current satellite time - you simply snap the time to the nearest bit-edge, letting you immediately compute a position, without waiting for more data.
      • With typical crystal accuracy, this implies you need to take a position every 3 minutes or so in order to keep the clock set correctly enough for this to work.
    • This gives you a psuedorange to the satellite to within several meters.
  • Compute a position.


Looks like there were 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.) LSB-first, as can be seen on negative numbers.

The first stream of 0x80's to the GPS is simply to synch up the UART in the GPS to the correct baudrate.

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 is an identifying number of the channel (1-8), 0 in case this is not channel-specific
    • 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 zeros. In some cases it sends a number of zeros 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 zeros), 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:

(Ugh, I do not understand this. Is it SEND or RECEIVED packets? Pavel 22:26, 6 May 2007 (CEST))

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

SEND Packet 00

Packet type 00 (with the exception of the very first FE-packet in the log) appears to specify a particular satellite to track. It also seems that this specifies the "ID" field (LS nibble of the third header byte) that will be used for future packets concerning this satellite. (Non-satellite-specific packets have ID=0.)

Bits 3-7 of the 11th byte of the packet -- third byte of the third data word -- are the satellite PRN number. In this log only 8 satellites appear to be tracked (2, 4, 8, 10, 13, 23, 27, 29). If I'm reading the GPGSV messages correctly, 24 should also be visible, but it doesn't appear gltt even attempts to track it.

As for the rest of the packet... There's a lot that gets repeated, information common to all the satellites, at least initially. When a batch of 8 of these packets gets sent, usually only the PRN and two other words differ among the 8. So those two words contain whatever satellite-specific info is needed, it seems. They both appear to be little-endian integers, one around -10^8 and one around 10^8.

(Info needed to search for sattelite... doppler frequency range and phase range is useful).

RECEIVED Packet 00

Last four bytes are little endian timestamp, in miliseconds. (Ok, it may actually be number of frames or something on that particular channel).

Packet length is constant.

RECEIVED Packet 03

It carries variable-length array of 12-bit integers... 6 to 32 entries were seen.

RECEIVED Packet 06, 08

short packets, 06 has varying length, and both are rare.

RECEIVED Packet 0c

Is global -- not about particular sattelite, probably fixed length and rare.

RECEIVED Packet 0d

Okay, so packets 0, 3 and d come in groups, for each sattelite, and they seem to contain enough info to compute position.

Packet d seems to contain 2 32-bit integers (second one is signed), then 3, 0, 0 and flags (?) -- so the packet length is constant.

RECEIVED Packet 0e

Comes in variants of differing lengths... data are similar at each length, but not accross whole command. Makes me wonder if we decoded commands right? Or does "flags" field play a role?

RECEIVED Packet 0f

Comes in variants of differing lengths..


It is possible to translate NMEA messages into something readable using script from , and using c decoder .

NMEA description is available at .

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

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

The whole log is