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.


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.


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.





  • 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.


4 Replies to “RTTY Through LoRa Module”

  1. Hello,

    Could you tell me how to find those settings? I’m new to all this and cant figure out how to turn on RTTY over LoRA, I assume the software is already in the PiInTheSky that I just downloaded, and all I have to to is change the settings as you describe above?

    Thank you

  2. I think you add the lines to the /boot/pisky.txt
    I’ve just tried this and on an SDR waterfall I can see the device is transmitting on two frequencies. It does a longish transmission on the LoRa frequency then a short burst on the RTTY frequency. The only change I made to Dave’s code was to change the last 0 to a 1 as my device has the LoRa module using channel 1.
    I’m new to all this and I haven’t configured my Fldigi to decode the RTTY transmission yet so I don’t know if it is sending garbage – but it is certainly sending something on the RTTY frequency.

  3. A quick update to the above. I’ve managed to get the Fldigi to display something but it is just garbage. I’ve set the baud and shift correctly in the RTTY configuration but there are other controls such as parity and stop bits. I’ve tried every combination but nothing seems to make sense. The beacon is transmitting the LoRa packets correctly as the “balloon” appears on the Habhub tracker map.

  4. Further update: I’ve now got the dl-fldigi decoding the transmissions received from an SDR running on my PC. The message is being correctly uploaded to the Habhub tracker map and a balloon has appeared over my house!
    Setting for the Modem are 600 custom shift, 7 (asci) bits, 0 parity and 2 stop bits. I am currently running at 50 baud rate but I have also tried 300.
    If trying to set this up I suggest disabling the camera as in between the lat and long etc packets it transmits the image which appears as garbage and makes you think it isn’t working. Many thanks to Dave for this facility.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.