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://wiki.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:

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