User:Mmontour/HHNotes

From Openmoko

< User:Mmontour
Revision as of 15:59, 29 August 2007 by Mmontour (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This page contains some of my notes about the Hammerhead GPS protocol.

Based on my observations as well as other people's comments (including the "sphyrna" documentation), I treat the "0xFF" packet as a request to read registers from the device. These registers are potentially addressed from 0x00 to 0xFF (the 5th byte of the packet) and are specific to each "channel" (0x00 to 0x08, the lower 4 bits of the 4th byte of the packet). I will use this terminology on this page, as well as "0-16" to refer to channel 0 register 16.

- The upper half of 0x11 on the data channels appears to indicate received signal strength (noise around 0x0500, full-scale 0x0FFF). When receiving a strong signal, the value in the lower half of 0x11 counts up or down on subsequent observations of the same satellite (possibly counting phase differences of that satellite's signal with respect to a local reference?). This lower half rolls around from 0 to 0x07FF.

- (Aug 25) The value written to bank 2 reg 0x07 controls the unsolicited bank 2 reg 9d-9e packet that is returned. Some bits from 0x07 are mirrored in 0x9e of the response. Bits 0x03e00000 (possibly 0x07e00000) in register 0x07 specify the length (in words) of the response packet. E.g. if these bits have a value of 21 the response packet will go from registers 0x9f to 0xb3.


- It looks like the last byte of a packet from the GPS may be 0x00 rather than 0xFC in some error conditions. This is not confirmed and may just be a bug in my software, but I saw this when I was sending data to the device too quickly (before receiving its full response).

- The first time after the device is powered up, reading registers 0x22 and 0x23 on channels 1-8 returns a value of 0. On subsequent reads, these registers return values of 0x00000005 and 0x80000000 respectively.

- After performing the above reads (two dumps of all register values), any channel 0 register can be re-written (0xFE command) with its current value, and this will not change the value of any other registers in the device. Note - this applies if there is a 0.5s delay after the 0xFE, before the next 0xFF. With no delay, some changes are observed when writing register 1 (and others) and the device may return invalid packets.

- Channel 0 register 08: Bit 0x0004 (counter reset) stays set if it's turned on with the counter stopped. It is automatically cleared once the counter is started (bit 0x2000).

- The 0-16 counter will also increment if bit 0x00400000 in register 0-04 is set. It increments approx. 25176 counts in 10s with this bit pattern, but 12588 counts in 10s (1/2 the rate) if bit 0x80000000 is also set in register 0-04. Setting bit 0x80000000 by itself does nothing.

- After power-on, the first time that the 0-16 counter is started (whether triggered by register 0-04 or 0-08), register 0-0A goes from 0x00000000 to 0x00000002.

- The rate at which the 0-16 counter increments is determined by at least the following factors:

  • The value of register 0-07. This seems to be a 32-bit unsigned register whose value is linearly proportional to the number of counts per second.
  • Bit 0x80000000 of register 0-04 - if set, the counting rate is divided by two.
  • Whether the counter was started by setting bit 0x00400000 in register 0-04 or bit 0x00002000 in register 0-08. In the former case (with 0-07 = 0xFFFFFFFF and bit 0x80000000 of 0-04 clear) the rate is approximately 16918 counts/s, while in the latter case it's approximately 127783 counts/s.

- The value of register 0-05 doesn't seem to have any direct effect on the rate of the 0-16 counter. However, in at least one of the traces the same value (0x238E397B) is written to 0-05 and to 0-07.

- Writing 0x01FFA170 to register 0-08 will start the 0-16 timer, but will also cause a lot of activity on channels 1-8.

- The lower 2 bits of the "flags" packet field seem to act like a "bank select". 00 = normal usage (channel 0 = control, 1-8 = data), 01 seems to be unused (all registers return 0x100971F2), 10 and 11 give registers that are mostly filled with 0 but have a few non-zero entries.

Personal tools

This page contains some of my notes about the Hammerhead GPS protocol.

Based on my observations as well as other people's comments (including the "sphyrna" documentation), I treat the "0xFF" packet as a request to read registers from the device. These registers are potentially addressed from 0x00 to 0xFF (the 5th byte of the packet) and are specific to each "channel" (0x00 to 0x08, the lower 4 bits of the 4th byte of the packet). I will use this terminology on this page, as well as "0-16" to refer to channel 0 register 16.

- The upper half of 0x11 on the data channels appears to indicate received signal strength (noise around 0x0500, full-scale 0x0FFF). When receiving a strong signal, the value in the lower half of 0x11 counts up or down on subsequent observations of the same satellite (possibly counting phase differences of that satellite's signal with respect to a local reference?). This lower half rolls around from 0 to 0x07FF.

- (Aug 25) The value written to bank 2 reg 0x07 controls the unsolicited bank 2 reg 9d-9e packet that is returned. Some bits from 0x07 are mirrored in 0x9e of the response. Bits 0x03e00000 (possibly 0x07e00000) in register 0x07 specify the length (in words) of the response packet. E.g. if these bits have a value of 21 the response packet will go from registers 0x9f to 0xb3.


- It looks like the last byte of a packet from the GPS may be 0x00 rather than 0xFC in some error conditions. This is not confirmed and may just be a bug in my software, but I saw this when I was sending data to the device too quickly (before receiving its full response).

- The first time after the device is powered up, reading registers 0x22 and 0x23 on channels 1-8 returns a value of 0. On subsequent reads, these registers return values of 0x00000005 and 0x80000000 respectively.

- After performing the above reads (two dumps of all register values), any channel 0 register can be re-written (0xFE command) with its current value, and this will not change the value of any other registers in the device. Note - this applies if there is a 0.5s delay after the 0xFE, before the next 0xFF. With no delay, some changes are observed when writing register 1 (and others) and the device may return invalid packets.

- Channel 0 register 08: Bit 0x0004 (counter reset) stays set if it's turned on with the counter stopped. It is automatically cleared once the counter is started (bit 0x2000).

- The 0-16 counter will also increment if bit 0x00400000 in register 0-04 is set. It increments approx. 25176 counts in 10s with this bit pattern, but 12588 counts in 10s (1/2 the rate) if bit 0x80000000 is also set in register 0-04. Setting bit 0x80000000 by itself does nothing.

- After power-on, the first time that the 0-16 counter is started (whether triggered by register 0-04 or 0-08), register 0-0A goes from 0x00000000 to 0x00000002.

- The rate at which the 0-16 counter increments is determined by at least the following factors:

  • The value of register 0-07. This seems to be a 32-bit unsigned register whose value is linearly proportional to the number of counts per second.
  • Bit 0x80000000 of register 0-04 - if set, the counting rate is divided by two.
  • Whether the counter was started by setting bit 0x00400000 in register 0-04 or bit 0x00002000 in register 0-08. In the former case (with 0-07 = 0xFFFFFFFF and bit 0x80000000 of 0-04 clear) the rate is approximately 16918 counts/s, while in the latter case it's approximately 127783 counts/s.

- The value of register 0-05 doesn't seem to have any direct effect on the rate of the 0-16 counter. However, in at least one of the traces the same value (0x238E397B) is written to 0-05 and to 0-07.

- Writing 0x01FFA170 to register 0-08 will start the 0-16 timer, but will also cause a lot of activity on channels 1-8.

- The lower 2 bits of the "flags" packet field seem to act like a "bank select". 00 = normal usage (channel 0 = control, 1-8 = data), 01 seems to be unused (all registers return 0x100971F2), 10 and 11 give registers that are mostly filled with 0 but have a few non-zero entries.