communication:binary_protocol
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| communication:binary_protocol [2013/09/10 18:53] – [Example Telemetry] mbrejza | communication:binary_protocol [2013/09/10 19:07] (current) – [Example Telemetry] mbrejza | ||
|---|---|---|---|
| Line 39: | Line 39: | ||
| * Lat/Long resolution (2 bits) - 4 different resolutions possible - 10^-7 -> 10^-4 of a degree (cm -> 10m level) | * 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 | * 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) | * 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 | * 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 | * 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 69: | Line 68: | ||
| ===== Example Telemetry ===== | ===== Example Telemetry ===== | ||
| - | sync, length, [callsign, packetID, checksum, (date)time, lat, long, alt, sensor1, ... ,sensorN, [intervals, resolution, [GPS_delta1, | + | sync, length, checksum, [callsign, packetID, (date)time, lat, long, alt, sensor1, ... ,sensorN, [intervals, resolution, [GPS_delta1, |
| [...] means msgpack arrays | [...] 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) | ||
| ===== Requirement of a Payload Document ===== | ===== 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 | 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 | ||
communication/binary_protocol.1378839194.txt.gz · Last modified: 2013/09/10 18:53 by mbrejza