User:Mmontour/HHNotes

From Openmoko

< User:Mmontour(Difference between revisions)
Jump to: navigation, search
(My notes about exploring the Hammerhead protocol)
 
m
Line 5: Line 5:
 
* 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).  
  
* Shortly after powering up the device, registers 0x22 and 0x23 on channels 1-8 return a value of 0. A few seconds later, 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 (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.

Revision as of 06:50, 19 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.

  • 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.
Personal tools