This article is about using the latest Pi In The Sky software to achieve this.<\/p>\n
Methods<\/h2>\n
To transmit RTTY we need to be able to frequency modulate the carrier at a specific rate (e.g. every 20ms for 50 baud).\u00a0 This timing needs to be accurate.\u00a0 We could …<\/p>\n
- \n
- 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.<\/li>\n
- 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.<\/li>\n
- 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.<\/li>\n<\/ol>\n
(1) requires accurate timing, which is not so easy with a non-real-time operating system.\u00a0 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.<\/p>\n
(2) requires an accurately timed bitstream applied to the DIO pin.\u00a0 This is possible on the Pi using the serial port, but we use that anyway for the standard RTTY radio.\u00a0 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.<\/p>\n
Which leaves us with (3).\u00a0 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.\u00a0 So this is the option I chose.<\/p>\n
![\"\"](\"http:\/\/www.daveakerman.com\/wp-content\/uploads\/2018\/09\/rtty-1024x391.png\")
<\/p>\nEssentially, the code does the following:<\/p>\n
- \n
- Puts the LoRa chip in FSK mode at the desired frequency<\/li>\n
- Sets the bit rate to a suitable value for the desired baud rate (50 and 300 supported currently).\u00a0 “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).<\/li>\n
- Set a buffer warning level so we can quickly sense when to refill the FSK buffer<\/li>\n
- Tell the chip to transmit<\/li>\n
- Fill the FSK buffer<\/li>\n
- Monitor the buffer level and refill as necessary<\/li>\n
- At the end of the RTTY sentence\/packet, allow the buffer to empty<\/li>\n<\/ol>\n
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.<\/p>\n
Configuration<\/h2>\n
First, you need the new version of the Pi In The Sky software (released 26th September 2018), or later versions.<\/p>\n
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).\u00a0 We are using one of the LoRa devices (channels) to transmit RTTY.\u00a0 So our settings are associated with the particular LoRa module (in CE0 or CE1 position).\u00a0 Essentially we are overriding the normal LoRa functionality by telling the software to transmitt RTTY as well as or instead of the LoRa packets.<\/p>\n
These are the new settings (shown for channel 0)<\/p>\n
- \n
- LORA_RTTY_Frequency_0=<RTTY Frequency><\/strong>.\u00a0 Without this, RTTY will use the same frequency as LoRa.\u00a0 I recommend that you keep the frequencies apart so that your RTTY receiving software does not try to track the LoRa trransmissions.<\/li>\n
- LORA_RTTY_Baud_0=<baud rate><\/strong>.\u00a0 Choose 50 (better range) or 300 (faster, allows for SSDV, easier for dl-fldigi to lock to).<\/li>\n
- LORA_RTTY_Shift_0=<carrier shift in Hz><\/strong>.\u00a0 The carrier shift must be numerically greater than the baud rate.\u00a0 Note that the LoRa chip steps in multiples of 30.5Hz.<\/li>\n
- LORA_RTTY_Count_0=<count><\/strong>.\u00a0 This is how many RTTY packets are sent one after the other before transmitting any LoRa packets.\u00a0 2 is recommended in case the RTTY decoder misses the start of the first packet.<\/li>\n
- LORA_RTTY_Every_0=<count><\/strong>.\u00a0 This is how many LoRa packets are sent one after the other before transmitting any RTTY packets.\u00a0 Set to zero to disable LoRa (and only send RTTY).<\/li>\n
- LORA_RTTY_Preamble_0=<bits><\/strong>.\u00a0 Sets the length of preamble (constant carrier) before sending RTTY data.\u00a0 Default is 8 and seems to be plenty.<\/li>\n<\/ul>\n
Example:<\/p>\n
LORA_RTTY_Frequency_0=434.350\r\nLORA_RTTY_Baud_0=300\r\nLORA_RTTY_Shift_0=610\r\nLORA_RTTY_Count_0=2\r\nLORA_RTTY_Every_0=12\r\nLORA_RTTY_Preamble_0=8<\/pre>\n
<\/p>\n
Limitations<\/h2>\n
- \n
- Only 50 baud and 300 baud are currently supported.\u00a0 This may change in future releases.<\/li>\n
- If you choose to interleave RTTY and LoRa, then any SSDV packets are only sent out over LoRa.<\/li>\n
- If you want to transmit SSDV over RTTY, then you need to disable LoRa transmissions on that module, and use 300 baud.<\/li>\n
- You cannot have separate payload IDs for RTTY and LoRa on the same module.<\/li>\n<\/ul>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[4],"tags":[],"_links":{"self":[{"href":"http:\/\/www.daveakerman.com\/index.php?rest_route=\/wp\/v2\/posts\/2350"}],"collection":[{"href":"http:\/\/www.daveakerman.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.daveakerman.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.daveakerman.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.daveakerman.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2350"}],"version-history":[{"count":6,"href":"http:\/\/www.daveakerman.com\/index.php?rest_route=\/wp\/v2\/posts\/2350\/revisions"}],"predecessor-version":[{"id":2357,"href":"http:\/\/www.daveakerman.com\/index.php?rest_route=\/wp\/v2\/posts\/2350\/revisions\/2357"}],"wp:attachment":[{"href":"http:\/\/www.daveakerman.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2350"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.daveakerman.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2350"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.daveakerman.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2350"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- LORA_RTTY_Baud_0=<baud rate><\/strong>.\u00a0 Choose 50 (better range) or 300 (faster, allows for SSDV, easier for dl-fldigi to lock to).<\/li>\n
- LORA_RTTY_Frequency_0=<RTTY Frequency><\/strong>.\u00a0 Without this, RTTY will use the same frequency as LoRa.\u00a0 I recommend that you keep the frequencies apart so that your RTTY receiving software does not try to track the LoRa trransmissions.<\/li>\n