This page considers the potential format for a new binary protocol. A varicode encoding method for any characters (eg callsign) will need to be also considered

• Current telemetry is inefficient due to ASCII coding and start/stop bits
• Sending positions requires a new string for each position
• Sending more than one position at once would allow for compression between position
• The current format does not support error correction
• Improved efficiency would help situations when a flight log is being sent, telemetry is being interlaced with other data such as SSDV, or the transmitter is using a low duty cycle to save power

• Flexible to support various potential uses
• Be simple with low overhead for the most simple use case
• Allow differential positions with a wide range of time difference between each point
• GPS and telemetry may not be sampled the same for multi-point messages
• Use FEC (option for R=1 - ie no FEC)
• Make sure framing is well thought out
• Support sending delayed data (by several hours or days) well

use https://github.com/msgpack/msgpack/blob/master/spec.md#array-format-family

The protocol will need to define the total length of the message, as well as some sort of callsign, and a sync sequence to mark the start of the message. Also a sentence type/version for future expansion.

Potentially a 16 bit payload ID could be used, but this will probably not be popular. The callsign will either have to be fixed length (unlikely) or variable length with a 'length' field. The order of 'callsign', 'sync' and 'sentence header' will need some thought.

The sync field will need to be some bits long, and not repeating. The message length could be a 7-8 bit long field, for which there will be predefined lengths. (This protocol will support error correction, and so will need to support an interleaver. If the LTE interleaver is used there are 188 valid interleaving lengths, but this could be pruned to 128 allowing a 7 bit length field)

Msgpack handles different variable types itself, so will not need to worry about how to convey datatypes or delimit fields.

The protocol is designed to allow multiple GPS positions per string, either to allow faster updates, less transmit duty cycle, sending back a log of data etc. It is proposed that a sentence will have one absolute GPS position, with numerous other positions given relative to each other. This will require fields to signal how many GPS positions there are, the precision and integer length used in each lat/long/alt, as well as the time spacing between fields, each discussed below in more detail

(with msgpack will still need resolution and time intervals, but int lengths and number of fields is no longer an issue. In msgpack will be implemented using the ext type with an ID to mean 'GPS deltas')

• Lat/Long resolution (2 bits) - 4 different resolutions possible - 10^-7 → 10^-4 of a degree (cm → 10m level)
• Altitude resolution (2 bits) - 4 different resolutions possible - cm,10cm,1m
• Lat/Long integer length (2 bits) - 4 different lengths, 8 bit signed int (+- 13m @ 10cm resolution) to 18 bit signed int (+-136km @ 1m resolution) (handled by msgpack)
• Altitude integer length (2 bits) - 4 different lengths, 8 - 20 bit signed int (burst can cause high descent rates) (handled by msgpack)
• Number of positions - potentially 8 bit (255 max positions). 0 indicates no GPS position. 1 indicates that only a single absolute position will be sent, so there will be less fields sent (handled by msgpack)
• Start date - only needed when the interval between GPS positions is large. The presence of this field could be indicated purely by the interval between positions. Could be implemented with 16 bits, with a sequence that repeats every 5 years. (eg 11203 - yr: 1, 3rd dec; 50229 - yr: 5, 29th feb) (now combined with GPS time)
• Interval between positions - potentially 8 bit. 256 different intervals defined in on a log scale
• Initial GPS position - 32 bit lat/long, 24 bit altitude. At least 17 bits for time. A value < 20000 could indicate a time is being sent, a value >20000 could indicate a datetime

At the equator, one degree of latitude or longitude is given by 2*pi*R/360 = 104km (R=6371km). This will be useful when considering the wanted precision and range of numbers needed.

The precision of lat/long is as follows:

• 10^-7 degrees gives 1cm level
• 10^-6 degrees gives 10cm level
• 10^-5 degrees gives 1m level

(The ublox outputs 10^-7 precision for lat/long, which is a 32bit signed integer)

Note that these values decrease for longitude at higher latitudes

This has not yet been considered, multiple GPS positions can be sent at once, but how this will extend to sensor reading is for debate. Potential uses are for the sensors to be sampled at the same frequency as the GPS, or for one set of sensor readings per sentence. If multiple sensor readings are undertaken, they could use the same settings as the GPS to save repeating this information. Could also be two blocks of telemetry for different sample rates.

Single sensor readings will be sent in a similar manner to previously, but deltas will also be supported. The delta fields will be placed at the end of the string, and will have a field to link to a single sensor reading (The absolute value which the deltas will be based from). Will also be implemented with a msgpack ext field with an ID that means 'sensor deltas'

sync, length, checksum, [callsign, packetID, (date)time, lat, long, alt, sensor1, … ,sensorN, [intervals, resolution, [GPS_delta1, …, N]], [relates_to_sensorN, intervals, resolution, [sensor_delta1, …, N]], … ]

[…] means msgpack arrays

(sync, length, checksum are included for the example but not part of the source code specification - they depend on the line coding used - rtty will have $$ as sync, no length and checksum at the end for example)

The protocol should be designed such that a receiver can plot GPS data without needing a payload document. As far as sensors go, the receiver should be able to interpret a series of values, but will not necessarily know what these values physically represent, or whether some scaling is required