User:Mmontour/HHNotes

From Openmoko

< User:Mmontour(Difference between revisions)
Jump to: navigation, search
m
(Some more Hammerhead observations)
Line 1: Line 1:
 
This page contains some of my notes about the Hammerhead GPS protocol.  
 
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.  
+
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.  
  
* 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).  
+
- 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 (note - may be endian-flipped).  
+
- 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.
+
- 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).
+
- 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.
 +
 
 +
- Writing 0x01FFA170 to register 0-08 will start the 0-16 timer, but will also cause a lot of activity on channels 1-8.

Revision as of 05:10, 21 August 2007

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.

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

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

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.

  • 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 (note - may be endian-flipped).
  • 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).