2 Modem Details - projecthorus/horusbinary GitHub Wiki

The horus_demod modem used by Horus Binary supports the following signal types:

Horus Binary packets take the form:

<preamble><unique word><payload>
where
<preamble> = 0x1B1B1B1B
<unique word> = 0x2424

The payload consists of a 22-byte long binary packet, encoded with a Golay (23,12) code, and then interleaved and scrambled, for a total encoded length of 43 bytes. The binary packet format is available here, and the golay-encoding/interleaving/scrambling is performed by horus_l2_encode_packet.

At the start of a packet is a Payload ID (one byte). A lookup table for payload IDs is located here. If you are going to fly your own payload using this mode, you must get a payload ID allocated for your use. This can be done by submitting an issue or a pull request to this repository, or e-mailing me at vk5qi (at) rfhead.net

Packets are then transmitted using 4FSK modulation, at 100 baud. Symbols are encoded 'naturally', not grey-coded, i.e. symbol 0 = 00, 1 = 01, 2 = 10, 3 = 11. The spacing of the four tones is not critical - as long as they are fully contained within the receiver passband the modem will find and demodulate the signal.

A worked example for generating and encoding these packets is available in the RS41HUP repository.

UKHAS-standard telemetry sentences sent via RTTY can also be decoded by this modem, which slightly better performance than fldigi. This telemetry take the general form:

$$$$$CALLSIGN,other,fields,here*CRC16\n

Note the use of five (5) '$' symbols at the start of the sentence. This is used as a 'unique word' for packet detection, and must be present. Other quantities of '$'s will result in the packet not being detected.

Only RTTY telemetry with the following parameters are supported:

• Baud Rate: 100
• Tone Spacing: 150 to ~1 kHz will work
• Encoding: ASCII 7N2 (7-bit ASCII, no parity, 2 stop bits)
• CRC: CRC16-CCITT

To enable RTTY demodulation, you will need to replace -m binary with -m rtty in the supplied startup scripts.

The horus_demod binary accepts 48khz 16-bit signed-integer samples via stdin, and can decode either RTTY or the MFSK (binary) packets. Successfuly decoded packets are output via stdout, and debug information is provided via stderr. Refer to the GQRX RX Guide for dependency and compilation instructions.

Suitable audio inputs could be from a sound card input, or from a SDR receiver application such as GQRX.

The horusbinary.py python script will accept decoded packets from horus_demod, and upload them to the HabHub tracker, for display on a map. Uploading to Habitat can be inhibited using the --noupload option. The --stdin option tells horusbinary.py to listen for data via stdin, instead of from UDP packets as are emitted by FreeDV.

We can string these applications together in the command shell using 'pipes', as follows:

$ sox -d -r 48k -c 1 -t s16 - | ./horus_demod -m binary - - | python horusbinary.py --stdin

The above command records from the default sound device.

This assumes you want to use an rtl-sdr dongle on a headless Linux machine.

rtl_fm -M raw -F9 -s 48000 -p 0 -f 434645000 | ./horus_demod -q -m binary --fsk_lower=1000 --fsk_upper=10000 - - | python horusbinary.py --stdin

Tune 5 kHz below the expected centre frequency (i.e. 434.650 MHz - 5000 Hz = 434.645000 MHz = 434645000 Hz, as above), and make sure your dongle has a known PPM adjustment.

Note the use of the --fsk_lower and --fsk_upper options. These set the limits of the FSK demodulators internal frequency estimator, and has an effect similar to a band-pass filter. The modem will only detect signals within this range. These options take frequencies in Hz, and these must be positive frequencies.

Note that there is a start_rtlfm.sh script provided which does the calculations for the above.