Hammerhead/Protocol

From Openmoko

(Difference between revisions)
Jump to: navigation, search
m (→‎Analysis: typo)
m (→‎Analysis: Add packet minimum and maximum sizes.)
Line 47: Line 47:
  
 
Packet types:
 
Packet types:
−
  count type
+
{|
−
    263 05
+
| Frequency || Type || Max length || Min length
−
    168 9d
+
|-
−
    128 18
+
| 9 || 16 || 73 || 11
−
    117 00
+
|-
−
    89 23
+
| 86 || 08 || 19 || 11
−
    86 08  
+
|-
−
    75 10
+
| 8 || e2 || 15 || 15
−
    63 9f
+
|-
−
    63 0a  
+
| 7 || 23 || 133 || 101
−
    52 0b  
+
|-
−
    48 0e
+
| 63 || 0a || 15 || 15
−
    31 9e
+
|-
−
    16 e0  
+
| 6 || 24 || 71 || 39
−
    13 20  
+
|-
−
    12 0c  
+
| 52 || 0b || 11 || 11
−
    10 16
+
|-
−
      8 e2
+
| 4 || 01 || 11 || 11
−
      6 24
+
|-
−
      4 01
+
| 263 || 05 || 19 || 15
−
      2 06
+
|-
−
      1 e5  
+
| 24 || 9d || 315 || 19
−
      1 13  
+
|-
−
      1 04  
+
| 2 || 06 || 25 || 19
−
      1 02
+
|-
 +
| 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
 +
|-
 +
|}

Revision as of 12:03, 28 April 2007

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:

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
Retrieved from "http://openmoko.org/index.php?title=Hammerhead/Protocol&oldid=8092"
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