The Wenet imagery downlink encapsulates Slow-Scan-Digital-Video (SSDV) packets within a layer of LDPC forward error correction and some light framing.
Packet Framing
Packet framing is as follows:
- Preamble: 16 repeats of 0x55. May not be required, but helps with timing estimation on the demod.
- Unique Word: 0xABCDEF01 Used for packet detection in the demodulator.
- Payload: 256 bytes of arbitrary binary data. Refer below for details.
- Checksum: CRC16-CCITT checksum ('crc-ccitt-false' in crcmod) of the payload, sent little-endian.
- Parity bits: 516 bits (zero-padded to 65 bytes) of LDPC parity bits, using a r=0.8 Repeat-accumulate code, developed by Bill Cowley, VK5DSP. See ldpc_enc.c for more details.
No scrambling or interleaving is used in the transmission. It was decided this was un-necessary due to the very short on-air time of each packet. Robustness to 'swing-fading' (fading from the balloon payload swinging or spinning) would require very long interleaving durations, which were deemed impractical for this system.
Modulation
- Modulation: 2-FSK
- Baud Rate: Ideally 115.2k, however thanks to the RPi's UART module it's actually 115177 baud.
As we are using the RPi's UART to modulate the radio IC in direct-asynchronous mode, this means we are unfortunately transmitting each byte described below with RS232 framing. This means our byte is actually encoded as: 0 LSB ... MSB 1, and we have a 20% overhead. This is certainly non-ideal, but did provide a very easy way of building a functional high-speed FSK transmitter.
The theoretical user data rate through the Wenet link (after packet framing and FEC) ends up being approximately 9kB/s.
The demodulator code (drs232_ldpc) handles the 'de-RS232-ing' and performs LDPC decoding.
Future work should investigate making use of the radio IC's packet FIFO to send packets without the RS232 framing.
Payload Formats
Wenet packet payloads start with a single byte identifier, followed by 255 bytes of data. If the content to be transmitted is less than 255 bytes, it must be padded out to 255 bytes.
The following packet payload identifiers are used:
- 0x00 - Text Message
- 0x01 - GPS Telemetry
- 0x02 - Orientation Telemetry
- 0x03 - Secondary Payload Telemetry
- 0x04 - Image Telemetry
- 0x55 - SSDV Image Packet, format defined here: https://ukhas.org.uk/guides:ssdv
- 0x56 - Idle packet. Sent when there is nothing in the queue to be downlinked. Contains 255 repeats of 0x56.
The content of the each payload is described in the following sections:
0x00 - Text Message Packet
These packets are used for general purpose message downlinks from the airborne payload. In practice, they are used for the sending of arbitrary debug information, for example the current state of the main loop. The PacketTX Class provides a transmit_text_message function, which encapsulates an arbitrary string (up to 252 bytes in length) and transmits it.
All multi-byte fields are sent big-endian.
| Offset | Length | Data Type | Description |
|---|---|---|---|
| 0 | 1 | uint8 | Packet Type (0x00) |
| 1 | 1 | uint8 | Message Length (length of message content field) |
| 2 | 2 | uint16 | Message ID, incremented with each message sent. |
| 4 | 252 | String | Message content, zero padded to fill out 256 byte payload. |
0x01 - GPS Telemetry
This packet is used to transmit a snapshot of GNSS data. It is expected that these packets will be sent on a regular basis, at least once per second.
All multi-byte fields are sent big-endian.
| Offset | Length | Data Type | Description |
|---|---|---|---|
| 0 | 1 | uint8 | Packet Type (0x01) |
| n | 2 | uint16 | GPS Week Number |
| n | 4 | uint32 | GPS Time-of-Week in milliseconds |
| n | 1 | uint8 | GPS Leap Seconds |
| n | 4 | float32 | Latitude (degrees) |
| n | 4 | float32 | Longitude (degrees) |
| n | 4 | float32 | Altitude (metres) |
| n | 4 | float32 | Ground Speed (kph) |
| n | 4 | float32 | Ascent/Descent rate (m/s) |
| n | 1 | uint8 | Number of SVs used in solution |
| n | 1 | uint8 | GPS Fix State (0 - No fix, 3 = 3D Fix) |
| n | 1 | uint8 | Dynamic model used in solution (0 = 'Portable', 6 = 'Airborne 1G') |
0x02 - Orientation Telemetry
SHSSP flight specific packet, refer here for details. Provided live orientation information from a BNO055 orientation sensor.
0x03 - Secondary Payload Telemetry
Used to allow downlink of telemetry from other payloads in the main downlink telemetry stream. The Wenet transmitter process listens for secondary payload packets on UDP port 55674, and inserts them into the downlink queue. The source of these packets does not necessarily have to be on the same RPi as the transmitter - one flight had a second payload communicating with the Wenet payload via WiFi to relay packets to the ground.
Some example code to generate and emit secondary payload packets can be found here.
All multi-byte fields are sent big-endian.
| Offset | Length | Data Type | Description |
|---|---|---|---|
| 0 | 1 | uint8 | Packet Type (0x03) |
| 1 | 1 | uint8 | Secondary Payload ID (0-255) |
| 2 | 254 | uint8* | Message content, zero padded to fill out 256 byte payload. |
0x04 - Imagery Telemetry
SHSSP flight specific packet, refer here for details. Was used to provide a snapshot of payload position and orientation when an image was captured, to assist with geo-referencing of imagery.