What Should Be the Default LoRa APRS Settings?

By Jon Adams N7UV

A really great thing about sub-GHz LoRa is that there are 9 different bandwidths and 8 different spreading factors from which to choose, each set giving a link unique characteristics. 

A really challenging thing about LoRa is that there are 9 different bandwidth and 8 different spreading factors from which to choose, each being non-interoperable with the other. 

And that's not including all the different center frequencies one could select to operate on!  

Coming up with a common set of LoRa settings that everyone should use seems to make sense at first. For the ham traveling across the USA or Canada with their mobile LoRa terminal, there's not much of a LoRa APRS network presence and where there is, the settings probably are different. But, at the same time, LoRa is exceedingly flexible and depending on one's RF skills, LoRa can fly. 

Long long ago in a country far far away from me (Austria), some hams selected 433.775 MHz as a good operating frequency for their LoRa experiments. I don't know the backstory, maybe someone can illuminate us on why that happened. They also liked a LoRa bandwidth of 125 kHz. I don't know why. The good thing is that at least in the US (and maybe Canada?), those settings are completely consistent with the regulatory rules. 

Firmware developers (notably Ricardo CA2RXU and Damian SQ2CPA, but likely others) out there writing code for the LoRa radio devices have been migrating from the original Austrian experimental settings of years ago to allow the LoRa user to experiment with most LoRa settings. This is terrific as LoRa technology is incredibly flexible, and capable of speeds from about 11 bps to 62.5 kbps. As I've said before, at the 11 bps settings it might be possible to do moon-bounce with the right antennas! At 62.5 kbps, one could imagine over-the-air firmware upgrade! 

When I first started experimenting with LoRa APRS back in December 2024, the CA2RXU firmware at that time only allowed 5 settings between 293 bps (BW125 SF12 CR4:5) and 1288 bps (BW125 SF9 CR4:7). Very quickly I learned that these settings weren't the most efficient at optimizing channel capacity. An SF12 APRS message or position packet consumed around 2 seconds of channel time, and use of a digipeater doubled that, so digipeaters at SF12 aren't the best idea, unless there's only a very few operators on a channel. In a previous post, I calculated that a SF12 channel could handle just a few packets per minute before becoming saturated. 

First, learned how to use Visual Studio Code (VSC) and platformio and hacked the firmware to allow faster over-the-air rates. Within a few months, we had the beginnings of the Arizona network running at 4557 bps (BW125 SF7 CR4:6), increased the digipeater output power to 1 watt (+30 dBm), and used good antennas at good locations. Why not faster? Good question. Needed a place to start and roll out a stable network. The network performance right now seems to be ok for barefoot (using +20 or +22 dBm tx) user terminals and excellent for +30 dBm user terminals. Visitors driving through the state have demonstrated that. 

The network now spans much of the lower half of Arizona (home to 85% of the population) and someday soon we might actually be able to connect to Southern California's growing network using the same settings. We've proven decisively that high speed LoRa works fine. 

PROPOSED DEFAULT LoRa APRS SETTINGS  

• STANDARD: BW125 SF9 CR4:7 1288 bps. Why? It's the same as 2 m AFSK APRS, it can easily handle the same level of traffic. One could port all 2 m APRS traffic onto the channel using aprx and it would go smoothly. (Actually, it's probably 2x the performance, given that LoRa has forward error correction (FEC) while AFSK ax.25 APRS does not, so loss of a few bits during a transmission isn't generally a problem for LoRa, while for AFSK AX.25 it's a total packet loss and waste of channel time.) 
• FAST: BW125 SF8 CR4:6 2604 bps. Why? It's double the speed of the above setting, and really shows off the performance of LoRa. If operators want to make their local network shine, this is a great place to be, without having to do a lot of RF engineering. 

You might ask why I don't suggest a "SUPER-FAST" version reflecting the Arizona (and now Southern California) 4557 bps speeds? Our network is fortunate to have a good mix of actual communications radio sites with friendly site managers, full-size antennas, and 1 watt output power. While I'd love to see the rest of the country work to attain what we have here in Arizona, one step at a time! Stay tuned to our Arizona and Southern California activities - big things are in process. 

Last request to the DEVs: DON'T USE AX.25 for LoRa and any new modulation modes. Use TNC2 format. AX.25 is a hack on a wireline protocol, radio isn't a wire, there's a bunch of unnecessary parsing, bit stuffing, bit shifting, the awful 4 bit SSID field, and worst of all, HDLC! 

--Cheers and 73 - Jon N7UV