Dave Akerman

Although the current Pi In The Sky boards include an FM transmitter for use with RTTY, there are some reasons for wanting to transmit RTTY through a LoRa module:

• You can use 1 aerial for RTTY and LoRa, instead of 2, which makes payload design a lot easier
• Extra RTTY bandwidth
• You’re making your own tracker and want to avoid the expense of 2 radio transmitters

This article is about using the latest Pi In The Sky software to achieve this.

Methods

To transmit RTTY we need to be able to frequency modulate the carrier at a specific rate (e.g. every 20ms for 50 baud).  This timing needs to be accurate.  We could …

1. Switch the LoRa chip into a mode where it just generates a carrier, and use the RTTY bit stream to set the frequency to one of 2 values every 20ms.
2. Switch the LoRa chip into a mode where it transmits one of 2 frequencies, with the selection controlled by a DIO pin, and then send the RTTY stream to this pin.
3. Switch the LoRa chip into FSK (Frequency Shift Keying) mode, with preamble and checksum etc. disabled, and have it send data from a buffer where that data is the RTTY bitstream.

(1) requires accurate timing, which is not so easy with a non-real-time operating system.  I did try this option with a small test program written in Python, and it worked tolerably well at 50 baud, but really isn’t a good option as the timing varies depending on the processor’s workload.

(2) requires an accurately timed bitstream applied to the DIO pin.  This is possible on the Pi using the serial port, but we use that anyway for the standard RTTY radio.  It’s also possible using a software serial port and the Pigpio driver which uses the DMA hardware for timing, but this increases our reliance on a particular external driver and besides, on our LoRa boards the appropriate DIO pin is not connected.

Which leaves us with (3).  There is a difficulty here, which is that the buffer used for FSK is small (64 bytes) and we need to oversample (store the same bit several times) to get the lower baud rates needed for decent range on HAB, but these are just coding challenges.  So this is the option I chose.

Essentially, the code does the following:

1. Puts the LoRa chip in FSK mode at the desired frequency
2. Sets the bit rate to a suitable value for the desired baud rate (50 and 300 supported currently).  “Suitable” means a low bit rate (reduces CPU workload refilling the buffer) for which 1 bit in the data results in 1 or more bytes in the FSK buffer (so we don’t need to mess around with individual bits in the buffer, which complicates the code).
3. Set a buffer warning level so we can quickly sense when to refill the FSK buffer
4. Tell the chip to transmit
5. Fill the FSK buffer
6. Monitor the buffer level and refill as necessary
7. At the end of the RTTY sentence/packet, allow the buffer to empty

I am indebted to Matt Brejza for the idea, and for providing the code he used to implement this in his tracker, which I then incorporated/mangled to work with the existing PITS software.

Configuration

First, you need the new version of the Pi In The Sky software (released 26th September 2018), or later versions.

To understand the settings, first take note that PITS has a concept of “radio channels” where a channel is a particular radio transmitter not mode (RTTY or LoRa).  We are using one of the LoRa devices (channels) to transmit RTTY.  So our settings are associated with the particular LoRa module (in CE0 or CE1 position).  Essentially we are overriding the normal LoRa functionality by telling the software to transmitt RTTY as well as or instead of the LoRa packets.

These are the new settings (shown for channel 0)

• LORA_RTTY_Frequency_0=<RTTY Frequency>.  Without this, RTTY will use the same frequency as LoRa.  I recommend that you keep the frequencies apart so that your RTTY receiving software does not try to track the LoRa trransmissions.
• LORA_RTTY_Baud_0=<baud rate>.  Choose 50 (better range) or 300 (faster, allows for SSDV, easier for dl-fldigi to lock to).
• LORA_RTTY_Shift_0=<carrier shift in Hz>.  The carrier shift must be numerically greater than the baud rate.  Note that the LoRa chip steps in multiples of 30.5Hz.
• LORA_RTTY_Count_0=<count>.  This is how many RTTY packets are sent one after the other before transmitting any LoRa packets.  2 is recommended in case the RTTY decoder misses the start of the first packet.
• LORA_RTTY_Every_0=<count>.  This is how many LoRa packets are sent one after the other before transmitting any RTTY packets.  Set to zero to disable LoRa (and only send RTTY).
• LORA_RTTY_Preamble_0=<bits>.  Sets the length of preamble (constant carrier) before sending RTTY data.  Default is 8 and seems to be plenty.

Example:

LORA_RTTY_Frequency_0=434.350
LORA_RTTY_Baud_0=300
LORA_RTTY_Shift_0=610
LORA_RTTY_Count_0=2
LORA_RTTY_Every_0=12
LORA_RTTY_Preamble_0=8

 

Limitations

• Only 50 baud and 300 baud are currently supported.  This may change in future releases.
• If you choose to interleave RTTY and LoRa, then any SSDV packets are only sent out over LoRa.
• If you want to transmit SSDV over RTTY, then you need to disable LoRa transmissions on that module, and use 300 baud.
• You cannot have separate payload IDs for RTTY and LoRa on the same module.