Skip to content
Mark Jessop edited this page Oct 20, 2018 · 21 revisions

Project Horus Ground Station & Chase Car Utilities

This repository contains various libraries & utilities used for:

In the context of this repository, the term 'telemetry' generally refers to position (latitude/longitude/altitude) data from a high-altitude balloon payload, but can also include command & control messages, for example those send to/from the mission control payload.

In essence, these utilities provide the 'glue' that connects the telemetry sources (LoRa receivers, fldigi, radiosonde receivers) with the mapping applications (OziPlotter, Habitat).

The main use-cases for these utilities are:

  • Management of telemetry on a High Altitude Balloon Chase-Car PC
  • Headless reception of Mission Control Payload telemetry using a Raspberry Pi.

All the applications mentioned within this documentation are provided as Python scripts (within the apps directory), which are (mostly) cross-platform.

Related repositories include radiosonde_auto_rx (a source of payload telemetry data, in this case from radiosondes), and OziPlotter (for offline mapping of payload positions).

Data Flow Overview

Data Flows between Horus Utilities

The above figure shows the interactions between the various Horus Utilities, and other applications. Dashed arrows represent broadcast UDP messages, available to any application on the local network, and continuous lines represent 'targeted' inter-process messages, either via TCP or UDP.

At a high level, data flow is from a 'Data (telemetry) Source' (i.e. dl-fldigi, radiosonde_auto_rx, or LoRaUDPServer), through a 'Data Processing' application, and finally to data selection & mapping (OziPlotter).

Telemetry from multiple data sources can be fed into OziMux (OziPlotter Multiplexer), and a data source selected by the operator for mapping. There are also a number of 'sidecar' applications which allow display and use of the telemetry data in other ways (i.e. to point an az/el rotator).

The various applications shown in the above diagram are often split between multiple computers, usually a result of hardware interface limitations. For example the LoRaUDPServer application runs on a Raspberry Pi, and communicates with a LoRa Modem via a SPI bus. The data processing and mapping applications are generally run on a Laptop, or some kind of Car PC.

The next few sections will discuss the various data sources, data processing, and sidecar applications.

Data Sources

Data Source applications collect payload telemetry data, usually via a radio receiver, and pass it on to a processing application.

dl-fldigi

dl-fldigi is the UKHAS fork of the fldigi 'fast light digital modem', which supports many common amateur radio data modes. In the context of high-altitude ballooning, it is used to receive 'UKHAS Standard' format telemetry from balloon payloads, usually using 50 or 100-baud RTTY modulation. Refer to the UKHAS Tracking Guide for detailed information on how to configure dl-fldigi

dl-fldigi provides a TCP interface on port 7322 where all demodulated data can be accessed for further processing. FldigiBridge (see below) performs this function.

Habitat Bridge

Habitat Bridge GUI

The 'Habitat Bridge' application allows gathering of data from the Habitat/Habhub online tracker. This acts as a useful backup to local receivers, and allows leverage of the 'distributed listener' receiver network.

To use this application, click the 'Update' button to refresh the list of currently active payloads. Select the payload, and the application will start polling Habitat for position data. Once you see position updates, tick the 'Enable' checkbox to push data into OziMux (see below).

radiosonde_auto_rx

radiosonde_auto_rx provides software which automatically scans for radio signals, and decodes telemetry from Meteorological Radiosondes. These are essentially 'free' balloon launches, which provide great practice for a hobbyist high altitude balloon launch.

This software is intended to be run on a Raspberry Pi, and so must be connected to the same local network as the other Horus utilities to be able to supply telemetry.

Refer to the radiosonde_auto_rx documentation for information on use and configuration of this software. Take particular note of the 'Sending payload data to OziPlotter / OziMux' section of the Configuration Settings documentation page.

LoRaUDPServer

LoRaUDPServer is used to communicate with the Project Horus Mission Control payload, and provides an interface between a HopeRF RFM98W LoRa Module and the local network. This is intended to be run on a Raspberry Pi, with an UpuTronics LoRa Expansion Board. Communication to/from LoRaUDPServer is via broadcast UDP packets on port 55672, with the packet formats detailed here. Further processing & display of traffic from LoRaUDPServer is performed by HorusGroundStation (see below).

The TelemetryUploader script is a counterpart to LoRaUDPServer, and uploads payload telemetry data to the Habitat Tracker.

Data Processing

Telemetry information from some of the above data sources can require additional processing before it is in a format for passing onwards for selection & display.

FldigiBridge (processing of data from dl-fldigi)

Fldigi Bridge Screenshot

FldigiBridge is a GUI application which connects to dl-fldigi or fldigi (see above), and listens for telemetry in the UKHAS standard format.

The telemetry string must use a CRC16 checksum, and have the following first format:

  • $$CALLSIGN,sentence_id,time,latitude,longitude,altitude,other_data_here*CRC16\n

FldigiBridge cares not what modulation scheme (RTTY, or otherwise) your payload is using - it just reads the decoded data out of dl-fldigi via a TCP connection. Time/latitude/longitude/altitude are extracted and passed on if the checksum is valid. By default, FldigiBridge outputs data to UDP:localhost:55683, which is one of the default settings within OziMux. This can be changed using the --output_host and --output_port command-line options. Refer to the command-line help (python FldigiBridge.py --help) for more information.

Optionally, FldigiBridge can also upload telemetry sentences to the Habitat database. This is useful if you are using 'mainline' Fldigi, instead of dl-fldigi. Just set the user callsign (either in the text box, or in defaults.cfg), and tick the 'enable' checkbox.

HorusGroundStation (Processing of data from LoRaUDPServer)

HorusGroundStation Screenshot

HorusGroundStation is the 'control centre' for the Project Horus Mission Control payload. It displays telemetry data, and allows transmission of command & control packets to the payload, via LoRaUDPServer.

Data Selection - OziMux

OziMux Screenshot

The OziMux application allows observation and selection of telemetry from the data sources mentioned above. The telemetry data, and age of that data, is displayed on a GUI (shown above). Based on the operators determination of the quality of the provided data (i.e. regularity, non-glitchy position info), a source can be selected. The telemetry data is then passed onwards to OziPlotter for display on a map.

OziMux also produces a 'Payload Summary' message, sent into the local network via UDP broadcast. This message is a JSON blob providing the basic telemetry information, and is intended to be used by the various Side-Car applications mentioned below.

OziMux requires a configuration file to setup the input and output UDP ports. Refer to the Configuration page for further information.

Mapping/GIS

ChaseMapper

ChaseMapper is a new browser-based mapping application designed to be a cross-platform replacement for OziExplorer / OziPlotter (see below). It can accept the same data inputs as OziPlotter.

OziPlotter

OziPlotter is an interface between Project Horus's Ground Station receiver utilities and the OziExplorer mapping software. Refer to the OziPlotter documentation for further information.

SideCar Applications

These applications operate alongside the source->processing->mapping data flow mentioned above, and perform other useful functions.

SummaryGUI

Summary GUI Screenshot

SummaryGUI provides a 'quick-look' of the basic payload telemetry (altitude, speed, ascent rate), and if chase-car GPS data is available (see ChaseTracker below), will show the payload's position relative to the chase car. This application acts upon and requires 'Payload Summary' broadcast UDP messages, as emitted by OziMux.

During high-altitude balloon chases, I usually have this open and at the bottom-right of the chase-car screen, as can be seen in this screenshot.

ChaseTracker / ChaseCar_NoGUI

ChaseTracker Screenshot

ChaseTracker is used to upload the position of a balloon chase-car to the Habitat Tracker, so it appears on the map. It also sends a 'GPS' broadcast UDP message into the local network on port 55672, which is used by SummaryGUI and RotatorGUI.

It requires a serial (or USB-Serial) connected GPS unit, which must be configured in defaults.cfg.

There is also a no-GUI version (ChaseTracker_NoGUI), suitable for running headless on a Raspberry Pi.

RotatorGUI

Rotator GUI Screenshot

RotatorGUI uses the 'Payload Summary' and 'GPS' messages emitted by OziMux and ChaseTracker (see above) to determine the azimuth and elevation to a balloon payload, which can then be sent on to an azimuth/elevation rotator controller. Refer to the Rotator Settings documentation on how to configure this.

You can’t perform that action at this time.