communication:protocol
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
communication:protocol [2010/05/06 15:59] – danielrichman | communication:protocol [2015/04/03 09:49] (current) – removed eroneous , at the end of the example mfa298 | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Communications Protocol ====== | ====== Communications Protocol ====== | ||
- | This is the typical protocol used by UKHAS members to transmit GPS data balloon to ground on the unlicensed bands, although any custom data may be tacked onto the end of the string. | + | This is the typical protocol used by UKHAS members to transmit GPS data balloon to ground on the unlicensed bands. Parsing is handled by [[http:// |
- | This doesn' | + | < |
- | + | ||
- | $$<CALL SIGN>,<COUNTER D>,<TIME HH: | + | |
- | + | ||
- | * <CALL SIGN> simply identifies your balloon - doesn' | + | |
- | * < | + | |
- | * The checksum is optional, but not for much longer! :). It must either be the NMEA XOR format or the CRC16_CITT | + | |
- | * After "< | + | |
- | * The newline at the end IS required. It does make the protocol much more easier to human-read, and dl-fldigi looks for that character to terminate the string. | + | |
+ | * The individual fields can be of variable length, the minimum and maximum can be set in the payloads XML file. | ||
+ | * CALLSIGN simply identifies your balloon - doesn' | ||
+ | * sentence_id (sometimes known as count, sequence, incremental counter...) also helps people receiving many transmissions at once. This should go up for each new transmission. It can go up 1, 2, 3, or be the milliseconds since power on, or whatever you want. It just has to increase each time a new string is sent. | ||
+ | * latitude and longitude can either be in decimal degrees (DD.dddd) or the NMEA format (DDMM.mmmm). If using decimal degrees take care that your conversion code does not break if it crosses the meridian. While the NMEA format is accepted you will still need to parse whether it its NSEW and use +/- appropriately. | ||
+ | * The checksum is very strongly recommended. We support CRC16_CCITT, | ||
+ | * The newline at the end IS required. It does make the protocol much more easier to human-read, and dl-fldigi looks for that character to terminate the string. Although both will work, please use ' | ||
* Here are example strings: | * Here are example strings: | ||
- | | + | XOR Checksum' |
$$A1, | $$A1, | ||
Line 22: | Line 20: | ||
Demonstration of the fact that the custom data can be anything: | Demonstration of the fact that the custom data can be anything: | ||
- | $$icarus, | + | $$icarus, |
**Usage example for the below two functions** | **Usage example for the below two functions** | ||
Line 53: | Line 51: | ||
**Useful code to calculate NMEA xor checksum** | **Useful code to calculate NMEA xor checksum** | ||
+ | |||
+ | Please note: The use of xor checksum for payload telemetry is not advised, this code is useful for checking sentences sent by the GPS. The CCITT checksum below has much better performance and is preferred for payload telemetry | ||
<code c># | <code c># | ||
Line 77: | Line 77: | ||
**Useful code to calculate CRC16_CCITT checksum on the AVR** | **Useful code to calculate CRC16_CCITT checksum on the AVR** | ||
+ | |||
+ | (Refer to [[http:// | ||
<code c># | <code c># | ||
Line 100: | Line 102: | ||
return crc; | return crc; | ||
}</ | }</ | ||
+ | ====== Getting Your Payload On the Tracker ====== | ||
+ | You will need to fill out a flight document so the server can parse your telemetry strings and update the map.\\ | ||
+ | Fill out the form here : |
communication/protocol.1273161595.txt.gz · Last modified: 2010/05/06 15:59 by danielrichman