UKHAS String Parser, and Payload Documents #7
Description
Currently Habitat has the concept of a 'Payload Document' - this describes the fields present in an uploaded line of UKHAS-format telemetry. Payload documents are generated in this interface (Link dead due to habhub shutdown), and can also include:
- Modulation information (mainly targeted at RTTY settings like baud rate, tone spacing, byte format e.g. 7N1).
- Payload frequency information.
These payload documents are then used to parse uploaded lines of UKHAS-format telemetry, and convert them into objects for storage into the Habitat database. While UKHAS-format telemetry has a few mostly constant starting fields (e.g. callsign,sequence_number,time,lat,lon,alt), anything after this can be customised, and so to extract these fields the payload document system is required.
There also 'Flight Documents', which specify a 'flight', containing:
- A time range during which the flight is going to occur
- Metadata on the flight location, who is performing the flight
- What payloads (specified by payload documents) are on the flight
The flight documents are used to:
- Put an entry in a google calendar visible on the habhub tracker, to announce flights.
- Allow dl-fldigi to 'auto-configure' settings to receive telemetry
- Allows exporting of telemetry in a time-bounded manner.
Suggest way forward:
- Currently Horus-GUI and the various LoRa decoders from Dave Akerman do basic extraction of the first few fields in UKHAS-format telemetry, and upload this to Sondehub-Amateur. This at least gets the payloads on the map.
- To maintain the current parser functionality, the payload document, flight document, and parser functions need to be extracted out of Habitat, or re-created. The parser could then be modified to submit telemetry into Sondehub-Amateur instead of Habitat.