Background
I'm writing this post because the correct answer to a question I had didn't exist on the internet. This is one of those cases where you think "surely, this has to be able to work right?" And despite all desiring it to be so, it may not. But the reason given isn't the correct. The right reason is actually much more nuanced and interesting.
The question
First of all, I present to you the question:
Can you use a LoRaWAN Gateway Concentrator with MeshCore?
TLDR: The answer is "Maybe, but probably not, and it's complicated."
MeshCore and Meshtastic
Lately, I've been getting into MeshCore. It all started when a friend of mine asked if I knew anything about Meshtastic. I had, but I wasn't really that interested. See, I had a lot of experience with LoRaWAN, and I really appreciated the forethought and effort put into that protocol. What I learned about Meshtastic seemed to be a bit under-baked, so I mostly ignored it.
What I didn't know is that it was gaining a lot of mindshare, and that the network effects of people playing with it meant that a lot more people were playing with it. Also, the ease of getting into it (less than $50 to start playing) meant that it was a lot more accessible.
When my friend brought it up, he mentioned that he got several of the SeeedStudios T1000 modules and that he had no one to chat with using them so he'd give me one. I guess I was doing this thing :)
We quickly discovered that we couldn't actually hear each other using the modules, even though we live pretty close together. So, I joined a few local discord servers for doing mesh stuff. There, I learned more about MeshCore. It seemed like a lot of people were moving to it and leaving Meshtastic behind. Meanwhile, I read someone's reporting on the internals of MeshCore and they said it was more competently designed.
At any rate, we flashed our T1000's with the MeshCore firmware, and I setup a repeater on his roof (he's on a hill in town).
Due to my work with LoRaWAN, I have an absolute ton of LoRaWAN parts. When the Helium crypto currency collapsed, that stuff got really cheap on eBay and I picked up a lot of it.
I suppose I need to take a moment and explain what a LoRaWAN gateway concentrator does... LoRaWAN is designed to support a lot of nodes, and for the most part they all can transmit whenever they want. To help make that not a disaster, they support receiving on many channels at the same time. The edge nodes also randomize the channel they use to transmit on each time they do so. Additionally, LoRaWAN concentrators can receive more than one packet on the same frequency at the same time, as long as each transmission uses different spreading factors. This is detailed in Semtech's AN1200.86 application note:
With LoRa, packets using different spreading factors are orthogonal, meaning that they are invisible to each other: as mentioned earlier, they simply appear as noise to one another. Therefore, two packets that arrive at the same time on the same receive channel at different spreading factors will not collide and, both will be demodulated by the gateway modem chip. However, two packets with the same spreading factor arriving at the same time on the same channel might result in a collision. However if one of the two packets is stronger by six dB, it will survive.
Essentially all LoRaWAN Gateway Concentrators have the same architecture, based on Semtech's reference design. The SeeedStudio WM1302 is captured below:
On the right of the diagram is the antenna port. It's connected to a FEM (or Front-End-Module) which is a power amplifier, Low-noise amplifier, and a few other components. Then it's split into two signals and filtered by SAW (Surface Acoustical Wave) filters. After the filters, the pair of signals go into SX1250 transceivers. These transceivers are essentially software-defined radios. They each have their own frontend consisting of a PA and LNA, then mix the signal with a local oscillator to bring the desired frequency into the baseband. It's immediately sampled with an ADC and sent over SPI to the gateway concentrator chip.
Within the SX1302 Gateway Concentrator chip, it decimates the incoming baseband signals from the SX1250's and splits it out into a variety of demodulators. This chip employs a fascinating architecture that I could probably talk about for hours, and that's without even knowing the gritty details within. But, to keep it brief, there are three parts of the architecture that are the most important:
- LoRa Detector: The LoRa Detector is the most interesting part of the whole thing. The first most interesting part is that it's labelled as 8x8, implying that there are 64(!) packet detectors in this block! That's a lot of DSP! But, if we look into how LoRa modulation works we might be able to get some clues about how this works, and how to make it a tractable problem.
In the video linked above, pay special attention to the description of the preamble of the LoRa packet. That preamble is a very specific pattern that can be very easily identified using correlation. All each of those detectors needs to do is multiply the incoming signal with a reference preamble (element-wise) and sum the result. If there's a spike of sufficient size then there's high confidence that a preamble was detected and the packet should be demodulated. This information is passed down to the packet demodulators below.
-
125kHz LoRa x 16: This block is a set of 16 packet demodulators. They likely use a similar correlation method to identify symbols in the remaining period of the packet. They're assisted by the detector telling them exactly where to look.
-
LoRa High Speed: This block is the same, but it's only one demodulator, but it's capable of processing higher bandwidths
I'm ignoring the remaining blocks because they don't matter for this question.
This is a very clever system, and there are many tricks that can be employed to ensure that it's working efficiently.
Now that we've spent way too long understanding how the LoRa Gateway Concentrators work, I hope we can all agree that the tech is very compelling, and could support very sophisticated network architectures in the context of Meshtastic and MeshCore.
This all felt so obvious that I was sure someone had already done it, so I started searching...
Research
The first place I looked was the Meshtastic page for meshtasticd, which is their linux process that implements the meshtastic stack. In the required hardware section, it says explicitly:
UART HATs and SX1302/SX1303 chip-based HATs are not supported. Only hats that use a SPI radio can work with Meshtastic.
The confusing thing about this is that the SX1302 usually does connect with SPI. What I think they're getting at is that you can't use a Concentrator chip, which the SX1302 is.
Meanwhile, I was also wondering whether the ChirpStack platform (which is an open source platform for LoRaWAN) might be able to support people putting a meshtastic stack as a plugin into their architecture. You can already get access to "malformed" LoRaWAN packets, and what's a Meshtastic packet if not a malformed LoRaWAN packet (if you squint hard enough)??
So, I search on their forums for meshtastic and there are only two topics. The first asks "Is it possible to connect a Meshtastic node to Chirpstack?" That's more-or-less the question I'm asking, so I'm hopeful. Unfortunately, the primary reply is a long post where someone just copy-pasted a bunch of slop from ChatGPT.
(Ok, rant time... Please don't do this. If someone is asking a question on a forum it's almost certainly because they didn't find the information online already. That means that is't not easily findable online. That means that the OpenAI scraper didn't find it. That means that ChatGPT doesn't know. If someone wanted to use ChatGPT to answer their question, they would have just asked ChatGPT. You don't sound like the bestest and smartest most helpful boy by doing this. Silence is better.)
The response from ChatGPT completely misses the point of the question. The poser of the question isn't asking for a bulleted list of pros/cons of LoRaWAN or Meshtastic, they want them to work together.
There is one response that's interesting. The user ardlen had basically the same idea I did, but they never followed-up in several months, and I assume they lost interest. The basic notion of their idea (and mine) is to generalize the semtech packet forwarder to forward all LoRa packets, not just those for LoRaWAN.
Unsatisfying results
Ultimately, my searching leaves me unsatisfied, and I can't shake the feeling that a sufficiently motivated individual could almost certainly implement an architecture where the plentiful SX1302 Gateway Concentrators could be used with Meshtastic and MeshCore. It would allow repeaters to support 8 simultaneous frequencies and 8 simultaneous spreading factors, all at the same time, as we discussed in the previous section.
If the pace of increased interest in mesh networks continues for much longer, it is likely that we'll begin to see congestion issues. Assuming that's the case, it's going to be imperative that we plan now for that eventuality. I believe that the technology I've explained above will be a part of that evolution.
With all that in mind, I decided to take it upon myself and really figure out whether we can use these gateway modules with MeshCore.
So, can we do it or not? This is getting long.
If we revisit the datasheet for the SX1302 we get the bad news on page 1, in the Key Features section...
The takeaway from this list is that all the demodulators only work with bandwidths greater than or equal to 125khz.
This isn't a problem for Meshtastic (all the Meshtastic presets I know of are greater or equal to 125khz). But, for MeshCore, it is an issue. Virtually all MeshCore deployments in the US use 62.5kHz bandwidth. This renders the SX1302 unworkable.
Why are the presets this way, anyway?
But, why is it like this?
The presets used by Meshtastic and MeshCore aim to strike a balance between bandwidth, airtime, range, and energy use. Indeed, all radio communication is designed around these same constraints.
The Meshtastic page for presets has a nice table where they show pros and cons for various presets. But, of course, this table doesn't include the preset for MeshCore.
I've taken the liberty of double-checking their work using the Semtech LoRa Calculator to make sure I'm comparing apples-to-apples, and adding the MeshCore preset.
| Radio Preset | Alt Preset Name | Data-Rate | SF / Symbols | Coding Rate | BW | Link Budget | Est. Range |
|---|---|---|---|---|---|---|---|
| Short Range / Turbo | Short Turbo | 21.88 kbps | 7 / 128 | 4/5 | 500 kHz1 | 138dB | 1.72km |
| Short Range / Fast | Short Fast | 10.94 kbps | 7 / 128 | 4/5 | 250 kHz | 143dB | 2.38km |
| Short Range / Slow | Short Slow | 6.25 kbps | 8 / 256 | 4/5 | 250 kHz | 145.5dB | 2.8km |
| Medium Range / Fast | Medium Fast | 3.52 kbps | 9 / 512 | 4/5 | 250 kHz | 148dB | 3.3km |
| MeshCore | US Preset | 2.73 kbps | 7 / 128 | 4/5 | 62.5 kHz | 149.0dB | 3.53km |
| Medium Range / Slow | Medium Slow | 1.95 kbps | 10 / 1024 | 4/5 | 250 kHz | 150.5dB | 3.89km |
| Long Range / Fast | Long Fast | 1.07 kbps | 11 / 2048 | 4/5 | 250 kHz | 153dB | 4.58km |
| Long Range / Moderate | Long Moderate | 0.34 kbps | 11 / 2048 | 4/8 | 125 kHz | 156dB | 5.57lm |
| Long Range / Slow | Long Slow | 0.18 kbps | 12 / 4096 | 4/8 | 125 kHz | 158.5dB | 6.56km |
In this table, I've sorted it by effective data rate. Notice that MeshCore's US preset sits between the Meshtastic "Medium" presets (Medium Fast and Medium Slow). To me, the most interesting thing about this list is how the variables trade with each other around data rate and range.
The MeshCore preset achieves (nearly) the same effective data rate as the Medium Fast meshtastic preset, but using 1/4 of the bandwidth... How this is possible? The trick is that the LoRa spec defines the "Chirp rate" relative to the bandwidth. So, the 62.5khz bandwidth used with MeshCore has 1/4 the chirp rate (slower chirps), but the spreading factor (SF) is 7 which increases the bits per chirp by 4. This is how 62.5kHz bandwidth with a SF of 7 for MeshCore is very close to the same as Medium Fast's 250kHz bandwidth and SF of 9. (Each spreading factor doubles or halves the bits per chirp) For more information about Spreading Factor, The Things Network has a good primer on it.
Nothing is free in communication, so it's no surprise that Medium Fast has almost all the same specs (Link budget and expected range) as MeshCore given they use the same kind of modulation and achieve the same data rate.
I do have one remaining question, and maybe someone knows, but I'd have expected that the increased bandwidth with Medium Fast would improve range. I feel this way because the increase in bandwidth should improve noise resistance and therefore gain. The Semtech calculator says no, though, and I'm sure they're right, but it "feels" wrong to me. I think I need to brush up on Shannon Information Theory. My best guess about why my intuition is wrong about the bandwidth question is that we're "spreading" the same transmitter power over a greater bandwidth, so the gains you'd make from using more bandwidth are cancelled-out by integrating more noise power from the same increase, and they balance. Again, I'm excited to hear about how I'm wrong about this.
Does this idea have a future?
Perhaps. It's not obvious to me why MeshCore decided upon 62.5kHz for the US preset. I suspect it might be to reduce the spectrum occupied so it doesn't pick up as much interference from other users in the 915MHz ISM band. It may be so it doesn't occupy as much of the band? I wish I knew.
If MeshCore moved to the same modulation parameters as Medium Fast, I suspect the same range and performance could be achieved. If we were to decide, as a community, to do that, then I think the idea of using a LoRaWAN Concentrator as a "super repeater" actually has legs.
But, where network effects giveth, they also taketh away. The same network effects that are causing a boom in interest in these meshes also mean that we would need a similar groundswell to get people to adopt a new profile that's not compatible with existing settings. And, without a compelling reason, I don't see that happening.
The only possible silver lining is that mesh communities are extremely local. And, the decentralized nature of these communities mean that the changes can occur region-by-region according to the needs and desires of each. It would be quite easy to have a repeater that bridges across different presets at the interface between regions.
Conclusion
I wish I had a clearer idea of what to do moving forward. To be honest, I only wrote this post because someone was wrong on the internet, and I knew the only way to ensure that correct and complete information is available is if someone takes the time to write it.
I'm hoping this post is the start of the conversation about Meshing with LoRa in general. Let me know what you think. I'm planning on starting the work on the Packet Forwarder to support Meshtastic and MeshCore anyway.
I'm sorry this post is a little unfocused. I wrote it all in one evening after a lot of research, and I just wanted to get the information down somewhere. I hope it's useful to you! See you on the mesh!