Secondary Telemetry Packet

Secondary Telemetry Packet

I've decided I want to report more data, though the additional data does not need to be transmitted with each transmit sequence. Instead, I'llo initially send it once per hour.

The second telemetry packet will follow the other two packets on an hourly basis. The encoding is described below. The encoding of the first two packets were blogged previously.


Third Packet

The third telemetry packet will encode data that is stashed in non-volatile memory on the tracker.  It will give performance metrics of the tracker itself.  It is distinguished from the normal telemetry packet in two ways.  First, it will begin 4 minutes after the primary (callsign) packet, rather than two. Second, it will use an value in the DBM field which is unused in a normal telemetry packet.  That will immediately flag that this is a secondary telemetry packet.

We'll illustrate the encoding scheme by decoding an example.

     QC1BAD FN12 60

The callsign consists of 6 positions with potential values as follows:

Position	Possible Values	Use in Scheme (number of values)	Number of Used Values / Number of Possible Values
Callsign 1	Q,0	Telemetry Channel (2)	2 / 2
Callsign 2	0-9,A-Z	Transmit cycles -modulo 36 (36)	36 / 36
Callsign 3	0-9	Telemetry Channel (10)	10 / 10
Callsign 4	A-Z	Boot Ups - modulo 26 (26)	26 / 26
Callsign 5	A-Z	Watchdog Resets - modulo 26 (26)	26 / 26
Callsign 6	A-Z, space	GPS Resets - modulo 27 (27)	27 / 27
Gridsquare 1	A-R	Same as Packet 1	n/a
Gridsquare 2	A-R	Same as Packet 1	n/a
Gridsquare 3	0-9	Same as Packet 1	n/a
Gridsquare 4	0-9	Same as Packet 1	n/a
DBM	0-18	18 (hard coded to 60 dbm)	19/19

Callsign Positions 1 & 3: Telemetry "Flight" or "Channel" number

Positions 1 & 3 allow for 2*10 = 20 possible values.  This allows for up to 20 pico flights to be in operation simultaneously without telemetry confusion, provided everyone cooperates and uses a unique pair of characters in those two positions.  In the example above, the two telemetry channel bytes are "Q" and "1". We can interpret a "Q" in position 1 as the 10's value, so this is "Flight Number 11" or "Channel 11".

Transmit Cycles

We count each time the tracker does a transmit sequence (2 or 3 per sequence).  This field wraps at 36.  Since we send the count hourly (6 cycles), we should wrap each 6 hours of daylight operations, but we should be able to tell that it happened from the hourly telemetry.  This will be helpful in the event of tracker reboots or lost packets.

Boot Ups

We count each time the tracker boots up, at power on.  Theoretically this happens once per day, but it appears the tracker browns out in the morning and at night.  The BootUps counter will help give a better picture of that scenario for consideration of future enhancements.  These are counted modulo 26.

Watchdog Resets

We count each time the tracker hangs, and the watchdog timer reboots it.  In an ideal world, this counter will never increment.  Uh huh.  It'll be nice to know, though!  These will be counted modulo 26.

GPS Resets

The GPS presently will go through a pretty hard reset if it is unable to get a lock for 5 minutes straight.  We'll count those here.  They are counted modulo 27.

Example

     QC1BAD FN12 60

Q = Telemetry Flight ID10's place
C = 12 transmit cycles
1 = Telemetry Flight ID 1's place  - Q,1 = Flight 11.
B = 1 boot up.
A = 0 watchdog resets
D = 3 GPS resets