Day: October 24, 2012

So there I was, riding along Thornwood Drive in Poughkeepsie, minding my own business, when I teleported into Vassar Farm… and back!

The aprs.fi database shows these packets around that glitch:

2012-10-21 15:43:55 EDT: KE4ZNU-9>T1TP3T,WA2YSM-15,WIDE1*,WIDE2-1,qAR,WB2ZII-15:`eSllA=b/"4Q}
2012-10-21 15:48:41 EDT: KE4ZNU-9>T1TP4U,WA2YSM-15,WIDE1,W2VER-15,WIDE2*,qAR,WB2ZII-15:`eS0mAQb/"4X}
2012-10-21 15:49:53 EDT: KE4ZNU-9>T1TP5W,WA2YSM-15,WIDE1*,WIDE2,qAR,WB2ZII-15:`eS$l{1b"4U}
2012-10-21 15:50:20 EDT: KE4ZNU-9>T1TP5V,WA2YSM-15,WIDE1,K2PUT-15*,WIDE2,qAR,WB2ZII-15:`eR lzlb/"4V}
2012-10-21 15:50:20 EDT: KE4ZNU-9>T1TP5V,WA2YSM-15,WIDE1,K2PUT-15*,WIDE2,qAR,KC2DHU:`eR<0x7f>lzlb/"4V} [Rate limited (< 5 sec)]
2012-10-21 15:52:31 EDT: KE4ZNU-9>T1TP8T,W2LW-15,W2LV,WIDE2*,qAR,W2GSA:`eR|lz:b/"4T}
2012-10-21 15:52:53 EDT: KE4ZNU-9>T1TP8S,WA2YSM-15,WIDE1*,WIDE2,qAR,N2MH-12:`eRsm*ub/"4S}
2012-10-21 15:59:52 EDT: KE4ZNU-9>T1TQ3X,WA2YSM-15,WIDE1*,WIDE2,qAR,K2DLS:`eQ}lz\b/"4N}

The two packets at 15:50:20 represent two different paths from the WA2YSM-15 digipeater to the APRS database: one through WB2ZII-15 and the other through KC2DHU. The “Rate limited” message indicates that the database regarded the two as different packets, which they are: the position data differs by one character. The database discards identical packets without comment, because the network must handle all the packets generated by a single RF transmission from one GPS tracker to multiple receivers, but rejects what it sees as deliberate (or inadvertent) attempts to overwhelm it.

Decoding the packets provides a bit more information:

2012-10-21 15:49:53 EDT: KE4ZNU-9>T1TP5W,WA2YSM-15,WIDE1*,WIDE2,qAR,WB2ZII-15:`eS$l{1b/"4U}
   type: location
   format: mice
   srccallsign: KE4ZNU-9
   dstcallsign: T1TP5W
   latitude: 41.67616666666667 °
   longitude: -73.91800000000001 °
   course: 121 °
   speed: 16.668 km/h
   altitude: 62 m
   symboltable: /
   symbolcode: b
   mbits: 101
   posresolution: 18.52 m
   posambiguity: 0

2012-10-21 15:50:20 EDT: KE4ZNU-9>T1TP5V,WA2YSM-15,WIDE1,K2PUT-15*,WIDE2,qAR,WB2ZII-15:`eR lzlb/"4V}
   type: location
   format: mice
   srccallsign: KE4ZNU-9
   dstcallsign: T1TP5V
   latitude: 41.676 °
   longitude: -73.90066666666667 °
   course: 80 °
   speed: 16.668 km/h
   altitude: 63 m
   symboltable: /
   symbolcode: b
   mbits: 101
   posresolution: 18.52 m
   posambiguity: 0

2012-10-21 15:50:20 EDT: KE4ZNU-9>T1TP5V,WA2YSM-15,WIDE1,K2PUT-15*,WIDE2,qAR,KC2DHU:`eR<0x7f>lzlb/"4V} [Rate limited (< 5 sec)]
   type: location
   format: mice
   srccallsign: KE4ZNU-9
   dstcallsign: T1TP5V
   latitude: 41.676 °
   longitude: -73.9165 °
   course: 80 °
   speed: 16.668 km/h
   altitude: 63 m
   symboltable: /
   symbolcode: b
   mbits: 101
   posresolution: 18.52 m
   posambiguity: 0

2012-10-21 15:52:31 EDT: KE4ZNU-9>T1TP8T,W2LW-15,W2LV,WIDE2*,qAR,W2GSA:`eR|lz:b/<4T}
   type: location
   format: mice
   srccallsign: KE4ZNU-9
   dstcallsign: T1TP8T
   latitude: 41.68066666666667 °
   longitude: -73.916 °
   course: 30 °
   speed: 16.668 km/h
   altitude: 61 m
   symboltable: /
   symbolcode: b
   mbits: 101
   posresolution: 18.52 m
   posambiguity: 0

Feeding the coordinates into Google Maps shows that the first packet (to WB2ZII-15) at 15:50:20 carries the damaged data. The second (to KC2DHU) has the correct position, but was rejected because it arrived just after the first and wasn’t an exact duplicate.

AX.25 packets carry a checksum and it’s a convolutional code, not a simple XOR, so I think it’s safe to say the packets were received as transmitted; you’ll find an intro to that whole topic, with further references, in the N1VG OpenTracker project. The database doesn’t store complete AX.25 packets, so we can’t run their headers and data through the checksum algorithm to see if they both produce good results. Here’s the raw packet payload:

2012-10-21 15:50:20 EDT KE4ZNU-9: 75 bytes
0x00 K E 4 Z N U - 9 > T 1 T P 5 V , W A 2 Y S M - 1 5 , W I D E 1 ,
     4b45345a4e552d393e5431545035562c57413259534d2d31352c57494445312c
0x20 K 2 P U T - 1 5 * , W I D E 2 , q A R , W B 2 Z I I - 1 5 : ` e
     4b325055542d31352a2c57494445322c7141522c5742325a49492d31353a6065
0x40 R   l z l b / " 4 V }
     52206c7a6c622f2234567d

2012-10-21 15:50:20 EDT KE4ZNU-9: 72 bytes [Rate limited (< 5 sec)]
0x00 K E 4 Z N U - 9 > T 1 T P 5 V , W A 2 Y S M - 1 5 , W I D E 1 ,
     4b45345a4e552d393e5431545035562c57413259534d2d31352c57494445312c
0x20 K 2 P U T - 1 5 * , W I D E 2 , q A R , K C 2 D H U : ` e R 7fl
     4b325055542d31352a2c57494445322c7141522c4b43324448553a6065527f6c
0x40 z l b / " 4 V }
     7a6c622f2234567d

So it seems the TinyTrak3+ sent out a packet containing bad position data, wrapped with a correct checksum.

The NMEA-format 4800 baud 8N1 serial data from the GPS receiver puck to the TT3+ has no parity error detection, so I suspect a character or two got clobbered (by RFI?) and produced a bad position. NMEA messages have a simple XOR checksum that’s susceptible to that kind of error. Note that the Mic-E encoded message shown above is not passed from the GPS receiver to the TT3+; we never see the raw GPS data.

Our TinyTraks use SmartBeaconing to transmit only on significant course changes, so the sequence of events probably went like this:

• The TT3+ decodes a damaged NMEA message from the GPS receiver
• It notices an abrupt position change and sends that incorrect position
• The next NMEA message arrives correctly
• The TT3+ sees another abrupt jump and sends that position
• The aprs.fi database rejects the message due to rate limiting
• The TT3+ remains silent until the next turn

The map doesn’t show all the turns, because that’s a hilly area and not all RF packets make their way from my bike to an APRS receiver.

For what it’s worth, although we were riding at a fairly steady pace, I don’t believe the five-significant-figure accuracy of those speeds, either.