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
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')
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:
(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