richonguzman
Propose to change LoRa configurations from Country Abbreviation to "MODE"
I apologize up front: this is not an issue. However, it's something that I think needs updating in the code for the tracker and I'm not familiar enough with "pull" requests to work this through that method. Hopefully I figure that out soon!
Overview:
Change the tracker "configuration" names "EU", "UK", "PL" to "M1", "M2", "M3".
- The current names not only are confusing for operators who live in other than these three countries/regions.
- Some new to this firmware have asked me whether the radio configuration is somehow configured to meet the indicated country's regulatory environment. AFAIK there is no correlation.
- Having a specific configuration for a local network should not require the operator to remember it as "the Poland one", "the UK one", or the "European Union one".
As an example, my T-Deck Plus is currently set up with three "modes"
- M1: 433.775MHz, BW125, SF7, CR4:6 (operational APRS network deployed across 2500 sq km of the greater Phoenix area)
- M2: 433.775MHz, BW62.5, SF7, CR4:6 (experimental APRS network I've just set up here in Phoenix)
- M3: 433.775MHz, BW125, SF9, CR4:7 (when I visit San Diego and want to use their LoRa APRS network)
While I enjoy visiting the EU, UK, or PL, these are arbitrary names for a tracker's three available configuration sets each of which contains:
- Operating center frequency
- LoRa bandwidth
- LoRa spreading factor
- LoRa code rate
I have long familiarity with Motorola two-way radios and their enduring use of the term "MODE" to represent a container that holds a set of parameters that configure the radio for a given situation:
- Operating frequency (RX)
- Operating frequency (TX)
- CTCSS TX
- CTCSS RX
- CTCSS TX/RX
- Alphanumeric for display
- Conventional/Trunking and many other radio configuration parameters specific to a situation or area.
My proposal requires only some text editing tweaks in three files: lora_utils.cpp; menu_utils.cpp, display.cpp
lora_utils.cpp Change lines 87-89 to: case 0: loraCountryFreq = "M1"; break; case 1: loraCountryFreq = "M2"; break; case 2: loraCountryFreq = "M3"; break;
menu_utils.cpp Change lines 381-383 to: case 0: freqChangeWarning = " M1 --> M2"; break; case 1: freqChangeWarning = " M2 --> M3"; break; case 2: freqChangeWarning = " M3 --> M1"; break;
display.cpp Change lines 557-559 to: case 0: workingFreq += "M1]"; break; case 1: workingFreq += "M2]"; break; case 2: workingFreq += "M3]"; break;
I haven't found any other dependencies as of yet.
What do y'all think?
Cheers and 73 - Jon N7UV
I disagree with this proposal.
The world is mostly well aligned in terms of LoRa modulation settings and frequencies. It is literally one setting (for historical reasons it is named EU) that works almost anywhere in the world, and two exceptional countries (UK and PL). The current designators are simple to understand and literally do what it says on the box, without any complications. Changing this to arbitrary "MODES" is a step backwards for the global community - we'd be going from intuitive descriptions to an abstract one that requires the user to look it up, making everything more complicated. To put it simply, suddenly we'd have a ton of users asking "which MODE should I select?" If anything, I would rename EU to Global, but that is more characters on screen.
I understand that there is no de facto standard for LoRa APRS settings in the USA, and since LoRa APRS appears to be relatively new to US, the US HAMs are experimenting with different flavours. Could the global mode work for US as well (honest question) ? Or alternatively, if it must be, could there be a standard US mode, so we'd have Global, UK, PL, US? Experimenting is always good and we have custom settings for that, but in telecommunicatons we should strive for simplification and standardization.
I agree that this request makes sense for the author's specific use case and perspective, but I believe it does not benefit the vast majority of the users around the world.
Could the global mode work for US as well (honest question) ?
That is a very good question.
In the US, the allowed frequency range for LoRa is 902-928 MHz. This is an unlicensed ISM band so there is all sorts of random stuff there. This range is also available for ham radio use, so some are using LoRa APRS here. It is easy to find LoRa devices with that frequency range, often preloaded with Meshtastic. It is difficult to find 433 MHz LoRa devices from domestic suppliers. I don't recall seeing a proposal for a standard frequency for this band.
Other US hams are using the global standard frequency. 433 MHz falls inside the 70cm ham band so using LoRa here, under ham rules (callsign identification, no encryption, higher power, higher duty cycle) should be OK. The problem is that digital data modes are limited to 100 kHz bandwidth, in the 70cm band, so the standard 125 should not be used.
The FCC (US government agency regulating radio transmissions) is considering changes to bandwidth regulations for the 70 cm amateur radio band, including relaxing the current 100 kHz limit. These efforts are part of a broader initiative to modernize outdated symbol rate restrictions across multiple bands.
73, John WB2OSZ
Good day @S57PNX and Ricardo -
I appreciate your point that up to now there have been some default settings for region-specific or country-specific ham radio use of LoRa. But times have changed in a good way - what was once a few pioneering hams has evolved into a vast community of like-minded hams around the world. Thinking of a specific set of LoRa and operational parameters as a "mode" is flexible, it means specific LoRa parameters that the local hams themselves have selected, and can be expanded indefinitely. Country is immediately problematic, especially now that there are hams all around the world in their own regulatory domains using LoRa and running Ricardo's firmware. Adding more countries to the list only makes the necessary list longer, and doesn't allow the firmware to be as inclusive as it could be. Perhaps allowing an alphanumeric name instead of displaying the callsign would help. I know my own call, I don't need to be reminded of it! %^) So I could program my mode 1 to have the name "Phoenix", my mode 2 PHX EXP", and Mode 3 "SDiego" or something like that. There's no need (except for display space constraints) for it to be limiting.
Just look at the global map at lora-aprs.live. There are users in IARU regions 1, 2, and 3. Countries (not including the US, UK, or PL) include: Brazil, Chile, Argentina, Uruguay, Columbia, Panama, Guatemala, Mexico, Canada, Georgia, Russia, Kazakhstan, China, Malaysia, Australia, at least. Perhaps there are more and they just don't use the syslog function.
While many countries listed may have adopted similar regulatory rules to EU/US/UK, many may not have, and rules change. Using country or region tags instead of the generic "mode" is immediately with issues with others who aren't in those countries or regions. From personal experience with multiple hams, they have questioned whether operating under "EU", UK, or "PL" is actually a regulatory issue. That's an unnecessary confusion and one that may have risks to users in other countries who don't understand the technology deeply enough to determine whether it meets their own regulatory requirements. The US FCC has some unusual (antiquated?) language about spread spectrum systems in ham bands, and that may or may not be reflected in other countries.
As far as a global standard, I disagree that one is necessary or even valuable at this early stage of the technology. Locally, I and other hams are running a 70 cm network at BW125 SF7 CR6, the group in San Diego is at BW125 SF9 CR7, the ones in Los Angeles are experimenting with their own approach.
LoRa technology is an amazing leap forward from the days of AFSK. If you look at the research that's being done using LoRa, there are some incredibly cool things like multi-SF adaptive networks and other things that boggle the mind. Lower SFs are now being pursued with far more interest since link margin isn't generally an issue with nodes that are higher up. 1200 bps or worse, 300 bps, is a terrible compromise of extended channel occupancy and higher power consumption.
While it's not necessarily ham radio, I'm sure you're all familiar with Meshtastic and more recently Meshcore. Here's a quote from the Meshcore wiki:
Recently, as of October 2025, many regions have moved to the "narrow" setting, aka using BW62.5 and a lower SF number (instead of the original SF11). For example, USA/Canada (Recommended) preset is 910.525MHz, SF7, BW62.5, CR5. After extensive testing, many regions have switched or about to switch over to BW62.5 and SF7, 8, or 9. Narrower bandwidth setting and lower SF setting allow MeshCore's radio signals to fit between interference in the ISM band, provide for a lower noise floor, better SNR, and faster transmissions.
Some of the local hams who have built out Meshtastic networks are in the midst of moving away from the slower over-the-air rates to significantly higher rates, both on "public" networks and private ones. Why? For one, throughput is generally more valuable than raw link margin, and a network with much less channel occupancy times supports hops much more easily. (Remember when people who were running HF packet tried to do digipeating? What a mess that was!)
What does all this have to do with hams and LoRa? We're seeing in real time a remarkable large number of groups all over the world experimenting with a really cool technology and moving on from what might have been once the "standard". APRS has different center frequencies around the world, and that hasn't stopped that from becoming a exceedingly mature (but mostly outdated) technology.
Why do any of us need to worry right now that we should be interoperable with the EU, PL (which I thought was part of the EU?), UK, US? Does it matter? What should hams in Malaysia use? How about China? Why should we be assigning a "standard" for them? Suggestions are one thing, so that someone can get a couple nodes up and running quickly, but the need for a country or regional standard is extremely premature at best.
"Mode" makes so much more sense than assigning arbitrary country/region names and forgoes the challenges that will come as more and more hams adopt this technology, and can save Ricardo a lot of pain %^)
Cheers and 73 - Jon N7UV
P.S. Perhaps the term
Thanks for weighing in John!
The bandwidth limitation is one of the reasons I have continued to encourage Ricardo to allow at least the 62.5 kHz setting... Now it's time to move the local network to that narrower BW.
Cheers and 73 - Jon N7UV
In the US, the allowed frequency range for LoRa is 902-928 MHz. This is an unlicensed ISM band so there is all sorts of random stuff there.
Ok, this is probably Too Much Information, but it's part of my living and and I generally need to know the rules. Here we go!
In the US, the Federal Communications Commission (FCC) is the US government regulatory body for civilian and non-federal government usage of anything that emits electromagnetic energy at any frequency in the radio spectrum from 9 kHz to 3 THz (3,000 GHz). The military and federal government have rules to follow as well, but they also often have priority over any other user. In the US, a lot of amateur radio spectrum is shared with us as secondary to the federal government, which has the side benefit of protecting that spectrum from commercial interests.
The FCC has multiple sets of regulations on how that 902-928 MHz radio spectrum may be used. There is FCC Part 15 Radio Frequency Devices (think low power cordless devices, old-school cordless phones, inexpensive consumer products that need wireless control or data/voice/video transfer, remote controls, etc.). Then there's FCC Part 18 Industrial, Scientific, and Medical (ISM) Equipment band, which allows for essentially unlimited power (many many kilowatts) so long as the leakage power measured at a specific distance is below certain limits. There's Part 90 Private Land Mobile Radio Services which is authorized to use specific segments of the 915 MHz spectrum for what's called location and monitoring services (LMS) at powers up to 30 watts. Then there's FCC Part 97 Amateur Radio Service which grants hams access to the 902-928 MHz radio spectrum. There may be a few others. The rules are different for everybody. The 902-928 MHz band (33 cm band) segment finds everything from high power industrial microwave ovens to wireless baby monitors. It's a mess, but a "happy" mess. So long as one stays within the rules, there's 26 MHz of spectrum to do it in! %^)
Attempting a national standard in that spectrum would have to accommodate all the potential interferers out there who are also within their particular rules. While hams have "priority" over Part 15 devices, there's billions of Part 15 devices vs less than a million hams.
Hams to date have generally stuck to the band edges (902-903, 927-928 MHz) because the majority of interferers tend to stay away from the band edges so as to not run the risk of spurious interference to the services that are below 902 MHz or above 928 MHz. However, that's changing as there are more and more uses of this extremely valuable sub-GHz spectrum.
It is difficult to find 433 MHz LoRa devices from domestic suppliers.
Now that suppliers are from everywhere, it's easy to purchase quality 70 cm LoRa transceivers, components, antennas, filters, you name it. Note that the Semtech (based in California USA, but with LoRa technology from France, I think) radio chips for the most part support everything from 150 to 960 MHz. Therefore most 868 MHz LoRa transceiver products will probably support 433 as well, except that there might be some LC filtering that gets in the way. I buy 70 cm igate/digipeaters from qrp-labs, which is in Turkey, but it's just as easy as buying from somewhere in the US. Soon RPC Electronics (near the US east coast) will be selling a very sophisticated LoRa transceiver. Between Amazon, eBay, and AliExpress, gear is readily available and hams are becoming far more aware of what LoRa is and what it can do.
Other US hams are using the global standard frequency. I take issue with this - there are few ham radio specific 33 cm networks consistently deployed, most hams who I know have taken up Meshtastic or Meshcore (either by using without encryption or by using a publicly documented common key, since the Amateur Service rules can allow that). These are both attractive to many hams since each has a pretty good ecosystem developed, but they're not interoperable. And neither of them are interoperable with LoRa APRS. How can there be a standard when we have so many to pick from? It may be LoRa under the bonnet, but everything else is by local choice, level of enthusiasm, and agreement. One significant issue for non-ham-radio 33 cm communications usage, under Part 15 rules that both Meshtastic and Meshcore use, is that the maximum channel occupancy time is 400 ms. The usual way to make that work is to do slow frequency hopping or limit themselves to packets that fit fully within 400 ms.
433 MHz falls inside the 70cm ham band so using LoRa here, under ham rules (callsign identification, no encryption, higher power, higher duty cycle) should be OK. In the US hams are required to identify their transmissions at least every 10 minutes. The rules are flexible enough that one can adopt a key so long as it is documented publicly. In other words, it's not that we're prevented from using encryption, that word is not used in Part 97, the actual language is "... data emissions using unspecified digital codes must not be transmitted for the purpose of obscuring the meaning of any communication". That's a significant difference, and one that allows us to use things like IEEE 802.11 under Part 97 rules.
Specific to any form of spread spectrum communications, US hams are limited to 10 watts peak envelope power. Specific to the 420-450 MHz Amateur Radio Service spectrum, US hams have limitations on spread spectrum comms (as John points out) of maximum occupied bandwidth of 100 kHz. We have some very antiquated rules - it would be good to renovate them %^)
Another interesting thing about 70 cm radio spectrum is that 433.5 - 434.5 MHz is specifically authorized under Part 15 rules for shipping container transponder usage where the transmit power may not exceed 11,000 microvolts per meter measured at a distance of 3 meters, and that operations must be limited to commercial and industrial areas such as ports, rail terminals and warehouses. This is another reason many hams avoid that spectrum altogether as those kinds of facilities are everywhere.
Rules are fun. Can't you tell? %^)
Cheers and 73 - Jon N7UV
Jon,
LoRa APRS has been around for many years, and I am afraid that the US HAMs are joining the game quite late. The first LoRa APRS networks started as early as 2014, soon after the Semtech chips came on the market. The so-called EU setting has evolved over the last 10 years as a global standard all over the world, in over 100 countries (including all those that you list above). It is not an Europe-specific config and has nothing to do with geopolitics, and it is not even a formal standard. The "EU" designator might be misleading in this sense, hence my suggestion to rename it to GLobal - or perhaps even WW for worldwide? But there are (in my very unscientific estimate) already over 10k LoRa APRS gates globally running this setting. People are of course still developing and experimenting with settings, but by and large, the technology has reached maturity and so did the deployed networks.
As of today, I know of 3 countries in the entire world that don't stick to the WW standard: UK (due to national rules), PL (design choice of the early adopters) and US (early deployment phase). If anybody knows of any other country anywhere in the world, please speak up, it would be interesting to know.
I understand that there are specifics of the US frequency rules and allocations, and as you and John explained, the worldwide default might not be legal there (yet?). It has happened before (e.g. GSM, UMTS, PMR/FMR, even ham radio bandplans) and that's fine. But let's not change a simple designation that works for 99,99% of users to a more complex scheme that benefits the early adopters in your area still trying to find the best common settting.
Experience shows that sooner or later, as the number of users grows, the LoRa APRS networks in your area will converge on a common setting that will be legal and will work for the majority of the users, simply because it is more convenient not having to switch settings on the tracker. This will then become a de facto (practical) national standard. If the FCC rules relax and the WW settings become doable for you, even better. Otherwise, it will be a US specific setting, acknowledging the specifics of the rules that you operate under.
Thus I still prefer to have "WW, UK, PL, US" (or perhaps even US1 and US2 if need be). There are still some remaining countries that haven't deployed LoRa APRS yet, and if one of them really has some specific national rules, let's add them to the list - it will be more intuitive for people from those countries. Rather than nondescriptive "MODE1, MODE2, MODE3,..., MODE n" where n could become a big number considering many possible combinations of central frequency, BW, SF, CR.
Finally, unlike Meshtastic, LoRa APRS is a HAM radio service and by definition follows the HAM rules (callsign, no encryption, duty cycles etc.). We must thus be careful to distinguish between LoRa as modulation (used for everything under the sky including home alarms and remote garage openers) and LoRa APRS as a HAM service (APRS using LoRa modulation as opposed to AFSK1200).
I would love not to mix LoRA APRS with Meshtastic, Meshcore and similar systems. Let's keep our beloved amateur radio frequencies clean and let's Meshtastic and Meshcore guys use their respective LoRA non-amateur radio frequency allocations.
I do play with both Meshtastic and Meshcore, but on 868 MHz EU non-amateur radio frequency allocation. It is like a CB radio. Fun, but many times completely un-controllable from human side of things. :)
Personally i do not mind "mode1, mode2, mode3" settings. But it would be good to keep extra text for end users not to "get lost" and still use correct settings.
Maybe a drop-down in web configurator for each mode: "EU", "UK", "PL", "Custom". And when user selects "Custom" he/she can enter custom settings for that LoRA mode.
This would still enable simplicity for settings and switching between different modes either for testing purposes and/or when roaming between geographical territories with different settings.
