Although everyone has their own reasons for exploring a new hobby, one of the driving factors behind the popularity of Meshtastic and MeshCore has been the incredible accessibility offered by off-grid LoRa mesh networks. You don’t need any expensive hardware or a license to get on the air — armed with a $20 microcontroller dev board and open source software, you could be on the mesh in minutes. Then came the really exciting part, seeing who else was out there. The low barrier of entry and ad-hoc nature of these projects meant there was a good chance you’d soon find yourself exchanging messages with other like-minded folks in the area.
Or at least, that’s how it used to be. With the recent revelation that their default radio configurations have potentially been in violation of the Federal Communications Commission’s (FCC) regulations governing amateur usage of the 900 MHz industrial, scientific and medical (ISM) band, the users and developers of both Meshtastic and MeshCore have been sent scrambling. Getting in compliance isn’t necessarily a technical challenge. In fact, Meshtastic has already introduced changes aimed to address the issue and anyone running the latest alpha release can be sure that their initial radio configuration will meet FCC standards.
But unfortunately, this introduces a new problem. While it’s easy enough to get new installations of Meshtastic and MeshCore operating in a mode that keeps the FCC happy, doing so breaks compatibility with everything that’s already been deployed. The community will be fractured into distinct strata depending on when they first configured their hardware, with an added dash of confusion from the more rebellious users who will undoubtedly refuse to migrate over to the new settings.
What was once easy and accessible has just gotten a whole lot more complicated.
Wait, Are They Talking About Us?
So how is it that both projects could have gotten as far as they have without realizing that they may be in violation of regulations that date back to the 1980s? It’s actually a bit tricky to nail down the timeline. Nothing has changed recently in the rules, and while it’s possible there were some back-channel discussions, the FCC has made no public acknowledgement of Meshtastic, MeshCore, or the general handling of LoRa mesh networks.
But if we go back to October of last year, we can see the first signs of potential trouble. Issue #945 in the MeshCore GitHub repository points out that the default radio settings in the US for both it and Meshtastic would appear to run afoul of FCC regulation 15.247. Specifically the second paragraph of subsection (a), which dictates the minimum allowed bandwidth. Out of the box MeshCore operates at 62.5 kHz and Meshtastic uses 250 kHz, but the FCC says it needs to be 500 kHz or higher.
The resulting discussion, which spans several hundred messages and is still seeing activity as recently as this week, paints a fascinating picture and illustrates one of the reasons it’s taken so long for the issue to gain traction. Although the text of 15.247 may seem straightforward enough at first glance, there’s always room for interpretation with documents like this.
Some pointed out that subsection (a) states that it is “limited to frequency hopping and digitally modulated intentional radiators,” as evidence that it doesn’t apply as neither project utilizes frequency hopping. Others felt that the rules were only intended for devices with higher output power, and some even expressed a disbelief that the manufacturers would allow the modules to operate in a non-compliant mode in the first place.
Put simply they couldn’t decide if 15.247 was something they really had to worry about, and without any official word coming down from the FCC, were reluctant to throw the community into turmoil over it.
Philly Does Their Homework
While MeshCore users debated if they should switch over to 500 kHz, many Meshtastic users started exploring alternate radio configurations for a very different reason. Its default 250 kHz mode, known as Long Fast, was never designed for networks with hundreds of radios in an urban environment. Taking advice provided by the developers themselves, operators of large networks such as the one in Philadelphia started testing other modes to see if they would fare any better.
As it so happens, one of the modes tested by the operators of Philly Mesh this summer happened to be Long Turbo, one of the two available modes that utilizes a bandwidth of 500 kHz. Their findings, which have since been widely cited online, were underwhelming to say the least. Part of the problem seems to have been due to bugs which went undiscovered up until that point due to the relatively limited testing of Long Turbo mode. Unfortunately, even after the bugs were addressed upstream, they noted some of the hardware they tested seemed unable to operate properly when switched into 500 kHz mode.
But the biggest problem they encountered was interference from other devices on the ISM band. In a dense urban environment like Philadelphia such interference is essentially unavoidable, but they found that Meshtastic operating at 500 kHz was especially susceptible to the electromagnetic din of the city. From their investigations, they theorize that the narrower bandwidth used by Meshtastic’s default mode was better able to slip through some of the interference, while the wider 500 kHz mode was more likely to collide with other transmissions.
Welcome to the Wild Wild Mesh
Given its poor performance at 250 kHz in an urban environment and the growing concern that anything less than 500 kHz could draw the ire of the Federal Communications Commission, Philly Mesh caused a considerable wave in the community earlier this month when they announced they would be switching to MeshCore.
While MeshCore was also impacted by interference at the FCC-compliant 500 kHz, during their testing Philly Mesh found that its protocol seemed to handle the situation more gracefully. The announcement also explained that they hadn’t given up on Meshtastic entirely, and that future installations may run both. But at least for the time being, it was determined that MeshCore offered them the best chance of creating a reliable mesh network in Philadelphia — a goal which superseded any loyalty they may have felt to one particular project.
This decision completely shifts the balance of the mesh community in Philadelphia and the surrounding area. Not only will users running older Meshtastic radios set to 250 kHz be unable to communicate with newer installations operating at 500 kHz, but both groups would also be separated from radios that were being switched over to MeshCore — which themselves may also be operating at various bandwidths depending on how they were configured.
One large network which could be accessed by anyone using Meshtastic’s default configuration has now been broken into several factions. In theory everyone could simply start over from scratch and move over to the same configuration, but the potent combination of tribalism and apathy is all but guaranteed to keep many users in their respective niche, kicking off what’s essentially a LoRa turf war.
It’s too early to tell what will become of Philadelphia’s mesh aspirations. There’s little reason to question their analysis of the situation on the ground, and it could very well be that using a custom MeshCore configuration is the best way for them to achieve their stated goals. But it’s still a painful transition, and you can be sure that other large mesh networks in the Northeast and beyond will be keeping an eye on the situation as they consider their own futures.
Featured image: “Meshtastic T-Beam” by [Chiffre01]