Differences

This shows you the differences between two versions of the page.

--- communication:binary_protocol [2013/09/09 23:58] – [GPS Requirements] mbrejza
+++ communication:binary_protocol [2013/09/10 19:07] (current) – [Example Telemetry] mbrejza
@@ Line 29: / Line 29: @@
 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.
 ===== GPS Requirements =====
 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)
+(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)
+   * <del>Lat/Long integer length (2 bits) - 4 different lengths, 8 bit signed int (+- 13m @ 10cm resolution) to 18 bit signed int (+-136km @ 1m resolution)</del> (handled by msgpack)
-   * Altitude integer length (2 bits) - 4 different lengths, 8 - 20 bit signed int (burst can cause high descent rates)
+   * <del>Altitude integer length (2 bits) - 4 different lengths, 8 - 20 bit signed int (burst can cause high descent rates)</del> (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
+   * <del>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</del> (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)
+   * 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
+   * 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
@@ Line 61: / Line 62: @@
 ===== Other Telemetry =====
-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.
+<del>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.</del>
+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'
+===== Example Telemetry =====
+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
-===== Requirement of a Flight Document =====
+(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)
+===== Requirement of a Payload Document =====
 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