A gentle FYI for casuals interested in Meshtastic / MeshCore in the the USA: the default radio settings promoted by both these services are actually outside the parameters permitted by the FCC for unlicensed spread-spectrum operation, which require that such signals be spread over at least 500 kHz of spectrum [1]. Meshtastic "LongFast" spreads over only 250 kHz, and MeshCore "USA Recommended" over only 125 kHz.
(500 kHz bandwidth is indeed a valid setting for the underlying LoRa protocol, and is used when the radios get certified.)
Unfortunately the community meshes in most/all US metros have coalesced around these settings, meaning one is forced to choose between linking with "the" mesh, or operating legally.
I've seen several bigger Meshtastic networks in Europe that suffer from a dramatic unreliability.
Everything beyond 1 Hop is often unusable. The public chat room only sees fragments of discussions. This causes big frustration within the community.
MT clients are just too chatty. That most Roles can act as a (delayed) Router was IMHO a bad design decision.
Also that they blocked the term "Meshcore" on their Reddit Sub leaves a bad taste. Both projects share similar problems - they should cooperate instead of fight each other.
> Also that they blocked the term "Meshcore" on their Reddit Sub leaves a bad taste. Both projects share similar problems - they should cooperate instead of fight each other.
Oh yeah I saw that behaviour on the lineageos irc too. Mentioning microG gets you instabanned there. Micro G is an excellent Google Play Services alternative which is open source. But the lineage guys hate it because they're afraid of pissing Google off.
In slovenia and neigboring countries there's a huge mesh of probably hundreds of nodes, some connected via radio, some via mqtt with people only working on expending the mesh and nothing else....
the result is predictable... a few "test? can anyone see this?" every few days and most of the radio channel is used up by signalization between the nodes. Then somone adds a new node in some area further away (parents' place, work, whatever), sets up mqtt, connects two such meshes together, and we get the same 'test?' but now in italian.
Making it smaller (city-wide) and have people actually talk there would be much better, but for now, everyone just wants to make it bigger.
This is a big point; in the nyc Meshtastic network there are well over 1000 nodes now (up 10x in the last year) but in the public channels nobody has much interesting to say beyond testing
It’s great amateur radio. Which I’ve learned is not about reliable communication. It is the sport of “can you here me now?”. Lots of tinkering and testing. The fun of Seeing the network open up when someone attaches a node to an airplane. Or occasional conversations that pop up. Set expectations low and get into appreciating direct EM wave communication.
Blocking a "rival" standard isn't necessarily petty censorship, it can also be spam control. I check the sub once in a while and I definitely do not want to see the same "but meshcore" whining over and over and over again.
The subreddit isn't the place where MT development happens - it's where users discuss stuff they do. If there was the occasional discussion of MC vs MT, that would be very healthy and helpful for both projects. But this is not what happens. The sub drowns in toxic flamewars. There's nothing to be learned from that in terms of development, and the subreddit just becomes noise i.e. spam.
Re: licensing, last thing I read was the MC was... at least awkward: a "core" being "open", and then some "modules" that you need to pay for (to run on your device). I don't really care for a project like this, even if they backpaddled from this scenario. I'd rather wait for yet another third option, that is free open source and would have the supposed protocol improvements.
The good thing is, after all, that the same LoRa radio devices can be flashed with one or the other, if I understood correctly.
I think both the Meshcore and Meshtastic communities have a problem with people being passive aggressive instead of being direct and upfront about the different tradeoffs chosen by those projects, and their consequences for various use cases. Unless those attitudes improve, keeping the forums separated is unfortunately one of the more straightforward ways to avoid flamewars and repetitive, circular arguments.
There are significant downsides to the changes Meshcore made to achieve more reliability in some use cases; it's absolutely not an all-around improvement that Meshtastic necessarily needs to "catch up" to, and downplaying or hiding the downsides doesn't help anyone. At the same time, Meshtastic proponents should be more honest about the scalability limitations of their approach.
There's only so much bandwidth available so pick and choose what the firmware is good at. MeshCore went all in on messaging and tracing. Meshtastic is a more noisy protocol which is perfect for camping and hiking in small groups.
I was just about to ask this: a non partisan honest comparison between Meshtastic and Meshcore for different use cases such as long/short range, congestion resistance with nodes growth, resilience against adverse condition, ease of integration with different software, etc. without fanboyism/hatred/shilling etc involved to form an opinion before starting buying hardware and diving into one of the technologies.
The good news is that almost all Meshtastic hardware can be flashed with the MeshCore firmware (and vice versa). This makes it straightforward to dive into both relatively easily.
I wanted to fix this with my FreakWAN but I was never able to find a user base willing to validate the ideas of the routing I implemented. All the code is open source and easy to modify.
LoRa diverges too strongly when applied in the real world. There are quirks in the chip (Semtech in the latest revision did a few strange things), and in the way chirp modulation works (the one used by LoRa), that makes it a lot better to test in the field.
Separately: while it's cool to chat human-style over these networks, lately I've been thinking that the real value add is last-mile automations. Stuff that won't clog the network like remote-starting your car once or twice a day, and is normally built on top of LTE.
Thats what helium and some iot manufacturers tried like Ring. A mesh that only routes out the least utilized egress node.
This is also convenient for backpackers and campers to request help, or get alerts, with their exact location
Meshtastic is actually good though. Helium is just another crypto pyramid scheme that pollutes the airwaves. The things network is a much better alternative from people that actually care about making a great network and not about getting rich fast.
It has some functionality of this type (you can see in the overall map a small number of "sensor" nodes), but it's not super well fleshed out or documented ATM.
What I think you can do for sure today is poll a sensor over the mesh, unlike the meshtastic way where you generally automatically broadcast telemetry.
Reticulum (https://reticulum.network/) seems to have quite a community with global chatrooms and local communities (saw at least US, Germany, Italy), seems like a more scalable solution than meshtastic imo.
there’s still quite a lot of chat in the element group, active github projects, the “official” stack hit v1.0.0 this summer, and it works.
him stepping away might slow things a little but there’s already enough functional stuff and actively maintained nomadnet pages that i’m frankly surprised at how few people have heard of this project.
Yay! Now you can enjoy the 8543 device roles Meshtastic has to offer, and see the static position and battery level eating away at airtime utilization.
How exciting!
Meshtastic is a bad protocol developed by toxic people in way over their heads.
Beware of using their trademark! They’ll send you a cease and desist letter.
I'm not OP, but there's a lot of criticism of meshtastic from people knowledgable about mesh networks. I also have been critical of meshtastic on this site.
I have no experience with the community, but if they couldn't have been bothered with understanding AlohaNet from several decades previous, than maybe it's not surprising.
I myself have been fairly critical of meshtastic, you can probably search for bb88 and meshtastic to find more criticisms.
To save you some time, I live in a fairly populous city with a bunch of meshtastic nodes, and can't get a message accross from me to my friend who lives one hop away.
It's not clear to me which portions of that very long newsletter are responding specifically to Meshtastic, but it seems like the most relevant section starts by listing some challenges but offers nothing in the way of solutions except to digress into talking about a wildly different class of radio hardware (SDRs that can monitor many channels at once).
"Meshtastic Is Rediscovering Lessons (Already Learned) of Amateur Radio Data Networking"
Instead of actually trying to understand the arguments these days, it's easier to inject noise into the argument, proclaiming it's too "hard to find" or "too hard to understand."
Mesh networking is a hard topic. Expect to expend some brain cells to understand it. I'm not here to spoon feed you tech that was well understood 3 decades ago.
How about you make an actual argument here in this thread, instead of vaguely gesturing at an excessively long newsletter and claiming there's relevant substance in there somewhere? Or at least tell me if I've incorrectly interpreted the "Meshtastic Is Rediscovering Lessons (Already Learned) of Amateur Radio Data Networking" section as listing problems but no solutions aside from buying a radically different (more expensive and power-hungry) type of radio?
Try making some specific suggestions for what Meshtastic is doing wrong that could be done differently. That way, we can tell whether your beef is with the Meshtastic software and protocol, or with their choice of LoRa radio hardware, or if you're just trying to preach about your ideal mesh network design with unstated assumptions about the priorities and constraints of such a network.
FWIW I have some background in this area and got curious how Meshtastic works so I read some of the docs and code. It seems like they are unaware of existing work even 20+ years ago, a specific suggestion is to study the state of single radio CSMA meshes in say 2005 and make a list of subjects to read on, then do that. There's a lot of stuff that happened later but in the early 2000s many people tried to make meshes out of 802.11b IBSS and a lot got written about those efforts.
having read that meshtastic section: I mostly agree with their requests tbh. the only suggestions in there seem to be "use full duplex" (with approximately one reason why, though it's a good one) and "solve frequency discovery with SDR" which they've already addressed as somewhat ridiculous - because it is, for someone interested in a low power and low cost network.
particularly the SDR stuff, which is the VAST majority of that section. this is not at all the same target audience as meshtastic:
>A computer with “sufficient” compute power and RAM, to run the ka9q-radio software. KA9Q has stated that a Raspberry Pi 4 is sufficient, and now we have the Raspberry Pi 5 with up to 16 GB of RAM, for only $120.
that's like suggesting the way to fix a wireless problem is to use a wire. otherwise the criticism seems to summarize as "it's slow and bad" and well. okay? that's hardly constructive, whether or not it's accurate.
the whole thing reads like "the solution is left as an exercise to the reader ;)" because it sounds like it's written by and for people who are already experts and just want to read a cathartic list of flaws they already know. and/or "buy better hardware lol". it's not at all the logical slam-dunk that you seem to think it is.
Meshtastic can only use one frequency at a time. So, say, a battery status update can stomp on a message trying to get to a meshtastic router. (He's got the link to the hidden node problem with a great wikipedia article about it).
The more popular the network, the more frequent these message stomps happen. Flood routing makes these stomps more frequent.
There is also no end to end packet acknowledgement system like tcp, so at hop 3 (e.g.) if the message got stomped on, who would know?
Let's say someone made a dual band lora transceiver. Well that would help, but it wouldn't solve anything else, because there's still core routing/reliability/topology issues.
So if you had 20 channels to talk over, well that would be even better. The chance of having your message stomped on would go down significantly making the network much more reliable. That's the SDR part (the listening of 20 channels at once) vs the Lora chip which can only listen/transmit on 1 channel at once.
Edited to add:
"But that's super expensive hardware/engineering to do that!" you might say. Well, it's being done today.
The point is that if you can fit 20 1khz channels in a 20khz RF space. The 20khz RF can be converted into audio and fed into a soundcard and processed. This exists today with FT-8, though FT-8 uses 150hz bandwidth per stream in 2.8khz sections per band.
You can see some FT-8 activity by looking at some websdrs.
Maybe go here and tune to 14.074Mhz Upper Side Band (USB)
I still don't see how your suggestions amount to anything other than telling people to spend a lot more money on completely different hardware and use it in a completely different manner.
FT-8 doesn't seem usefully relevant here. The fact that the bandwidth is so low that it can be sampled with a sound card isn't at all helpful when Meshtastic doesn't require a PC. And FT-8 carries minimal payload (typically amounting to no more than the automated status updates you dislike Meshtastic wasting airtime on), and I've never heard of anyone doing routing over FT-8. You're just making noise about a completely unrelated niche radio hobby.
If the constraints of LoRa and Meshtastic don't make it possible to implement the kind of radio system you want to play with, that doesn't prove that Meshtastic has made any wrong decisions. It just says you would get a more fulfilling experience from getting into a different radio hobby, and stop getting in the way of potentially productive discussions about how Meshtastic could be improved within the constraints of the currently-existing commodity hardware.
> FT-8 doesn't seem usefully relevant here. The fact that the bandwidth is so low that it can be sampled with a sound card isn't at all helpful when Meshtastic doesn't require a PC.
This is what I meant about adding noise to the argument. This isn't a useful argument. FT8 could be decoded with a microcontroller. But you wouldn't know that. And it only shows your ignorance of the subject.
Meshtastic maximalists are the true believers, throwing away the decades of experience and knowledge because they drank the kool-aid of the leaders that think they are smarter than the folks who have been doing this for the last 40 years.
Why does this pattern come up so often? Something is promoted ignoring the lessons of the past and claiming not to have those problems, then it's discovered that it does have those problems and that ostriching didn't solve them (surprise) and that ostriching made it even worse than if they'd left a TODO placeholder
There is some issues with "boomers" and "toxic culture". Ham radio can be pretty toxic -- but you have to find the groups that have the knowledge but don't have the toxicity. There is a stigma to being a Ham these days -- often well deserved I think. You can find lots of youtube videos of toxic hams on the air. Or you know facebook forums.
But those people aren't the experts typically. The experts have their own community, friendships, etc. They'll be super nice, and they might speak up, but they expect to have polite conversation. And if the forum is a shit show, they'll take their expertise elsewhere.
The message would be 20 times longer (in time), increasing its chance of collision by 20 times and exactly cancelling the 20 times reduction that it gets from randomly selecting one of 20 channels.
But that's also true on 1 channel. Doesn't solve the hidden node problem. You have 1/20 as much risk of starting to transmit at the same time on the same channel as someone else, after you both determined the channel was clear, since that's a race condition with a fixed time window per transmission, but is that the main cause of collisions?
Here's a thought experiment. Remember, there's only one channel.
Let's say you have 100 meshtastic nodes in a residential valley. And you have 1 meshtastic repeater up on a mountain overlooking the valley (or it could be on a radio tower or water tower, say).
So it's clear that most of these nodes won't see each other because terrain, housing, trees, etc.
But it is possible that the repeater may have clear line of sight to most of them. And that's where the hidden node problem lies.
And adding more nodes and more repeaters is not going to help. The problem is either solved by increasing the number of channels (hence the sdr angle) or by time division multiplexing the single channel and coordinating who can talk at what time. The first is easy. The second is much harder.
yeah, that's exactly what I was referring to as "use full duplex" (use at least 2 frequencies, I agree this sounds like pretty solid critique (particularly with meshcore's network setup) and wouldn't make hardware dramatically more expensive) and "buy better hardware lol" (use 20+ frequencies and make it a completely different product at a MASSIVE price increase. why not just suggest wires then).
so there's one bit of probably-usable advice (slightly raise cost for significant benefits) and one that completely misses the point (charge at least 5-10x more for wildly different hardware, use hundreds of times more power, etc). the article spends several times more text on the latter.
flood routing and lack of end to end ack I also agree with, I sincerely doubt those are the best options and if user complaints are any sign then I think it's an existence proof that it doesn't scale, exactly as predicted. neither are part of that article, though it is in a linked also-large mastodon thread, which has basically just one constructive suggestion (8x the channels, though they don't think it'll work either) and many "this sucks" examples (flood fill, hop limit, etc. it amounts to "do better", not "X is better, learn from it").
> charge at least 5-10x more for wildly different hardware, use hundreds of times more power, etc
So I think what's super interesting is that it not necessarily need to be 5-10x more, nor needs hundreds of times more power.
I'll start with the power argument first.
WSPR (pronounced "whisper") often uses 100mW transmissions and can be heard across the globe in the HF spectrum. The techniques for reception can pull the signal out of the noise. It's common for weather balloons to send telemetry this way. People use it to monitor band conditions as well.
The trick is that WSPR puts all the power into one signal approximately 6hz wide. That's why it's so efficient, and one reason why it can be heard across the globe with such low power. Now you're probably not going to get that distance in the 900Mhz ISM band, but you will be heard further if you so choose (or need to be).
As per cost?
100mW assuming a 75ohm antenna (dipole) is 36mA of current. For 1W (which is roughly the ISM limit) it's 115mA of current, so the components won't need to be high power, probably jelly bean parts.
The RTLSDR is $25 bucks with 2.4Mhz bandwidth which is way overkill for this.
Lots of microcontrollers are cheap.
There's engineering cost and time, sure, but Meshtastic did show that a need for reliable mesh low power messaging exists even if it's not the final form.
I've been spending a lot of time experimenting with and learning about Meshtastic and MeshCore recently,[0] and I'm also puzzled by the criticism of Meshtastic.
In the article you linked, there are three paragraphs about Meshtastic in a 150-paragraph newsletter about several topics. The criticism seems to be that they they use digipeating, and then it refers to a Fedi thread[1] which is more coherent but still fairly vague. The upshot seems to be that flood routing doesn't scale, which is a fair criticism but feels disproportionate to the level of vitriol against the project.
The Fedi thread also adds that the Meshtastic founders were rude or unprofessional to him but doesn't cite any specifics or evidence.
I see this a lot with Meshtastic. People keep saying the founders are toxic and disrespectful of the community but it's always in these vague terms so I don't know what's driving it.
But specifically in this thread, I agree with sibling poster that you're being disrespectful and arguing ineffectively by pointing to such poor resources and then blaming other people for being unconvinced or confused.
As I understand it, the section on "what not to do" features many things that Meshtastic does, though it does not say that explicitly. Perhaps the linked post wasn't clear to non hams (it is a newsletter targeted at hams), but the biggest issue is not flood routing, but using the same channel for networking and user access. It, by definition, cannot scale meaningfully. Many commercial networks solve this with either FDMA or TDMA.
Elsewhere in the newsletter, the author advocates for a form of FDMA, where users operate on different, dynamically allocated frequencies and all of them are received at once. P25 trunked radios used by almost all law enforcement in the US operate on a system like this.
I think the vitriol from those who are in the space either professionally or as an amateur comes from the fact Meshtastic is repeating mistakes we knew about in the 80s at the latest, for which reams if literature freely exists.
That's a reasonable take to an extent, but underlying all of that is the assumption that Meshtastic should be trying to scale up to support hundreds or thousands of active nodes on a single mesh. Since that's clearly almost impossible to achieve with an ad-hoc network of low-power LoRa radios, it's not entirely fair to criticize Meshtastic for not inventing a revolutionary solution to a very hard problem.
It would be more fair to criticize Meshtastic for not being clear enough about the tradeoffs and limitations inherent in a low-speed ad-hoc mesh network, and for not actively encouraging people to seek other hardware and software if their use cases are not well-matched to what Meshtastic hardware is capable of. A one size fits all solution simply isn't possible, and Meshtastic can't be the right answer for everyone.
This is also a fair response, however I'd argue that the current architecture, far from supporting hundreds or thousands, won't even support dozens in a small area with meaningful traffic being exchanged (e.g., not just heartbeats and routing data). The solutions exist and no revolutionary approach is needed. That's the crux of the complaints.
Now, for the hobbyist these solutions are harder to implement and that's not nothing, but I don't even see a movement to switch over to something more robust.
> Now, for the hobbyist these solutions are harder to implement and that's not nothing,
I'd argue it's everything. A network architecture that requires serious fixed infrastructure should probably be an entirely separate project from the ad-hoc mesh formed solely by cheap battery-powered portable/handheld gadgets. And everyone should be realistic about what "meaningful traffic" is for a network with a default data rate of ~1kbps; it's not reasonable to expect that to support the kind of chatter a busy IRC server would see.
Have YOU ever tried interacting with the developers? No?
* They made incredibly poorly designed software — the firmware and the mobile apps — and then yell at you for “using it wrong”
* The refuse to admit they made a mistake with the 7 hop limit and call you an idiot for not believing in their garbage “simulator”
* They write nasty responses to app reviews and GitHub issues because they’re petulant children. Just go read the responses, and look at the hissyfit the of the primary app developer in discord.
* They’ve taken down multiple community groups because they decided they needed to be a business rather than an open-source project. Seriously just go look at the history in their discord #trademark channel. They’re on the verge of evil.
All this stuff is available and just because YOU choose to put your head in the sand doesn’t mean it didn’t happen.
While it looks like Meshtastic devs probably made at least some mistakes relating to that underlying complaint, I think that thread provides thorough evidence that banning that particular user was a reasonable choice.
He went off the rails as a reactionary move is how I see it. He got mad because his issue was deleted. I'm banned from the discord for a disagreement with one of the developers; but I've done code contributions to the project as well.
Even without toxicity, as a domain expert, I'm cynical about community experiments in this space in general.
Hobbyist "mesh networking" communities readily adopt suboptimal modulation, frame specification, packet format, encoding, ineffective mesh arrangements, flood-prone routing mechanisms, poor reference hardware, and bloated user interfaces, while often ignoring basic practices like forward error correction, collision detection/multiplexing, trust mechanisms. Community solutions tend to be opinionated in the worst ways ("we assumed you'd use an arduino" or "here's a mandatory packet header field to indicate whether you're currently in a hot air balloon") and under-constrained in areas where opinion would be helpful "our client UI has 75 configurable options -- get one wrong and you won't be able to communicate."
By the time there is a "community" it's too late to address these issues: network effects have already locked in the worst design decisions.
I've also found meshtastic to be totally unusable in practice. Tried it, really really hard. It barely worked in a city i live in. Did not work at all when i took the node for 500km ride. Bad protocol, yes, it is.
I’ve done extensive mesh network testing in nyc and compared with notes from other big cities, and the number one thing you can do to dramatically improve mesh reliability is moving off of the default frequency. Staying on Longfast is fine, but find an alt freq and everything will suddenly work 10x better.
Yes, it is enabled by default (in fact this caused problems earlier on). Licensed hams (in the US) can increase transmit power (and theoretically use additional spectrum outside of ISM) but even the default "public" channel was encrypted with a known, publicized key. There was some debate whether this ran afoul of amateur radio rules against encryption, even if the key is known, since it cannot be disabled. I believe there was some progress in fixing this and allowing truly unencrypted channels for licensed operators, but I haven't checked back recently.
I am pretty sure (though have not vetted) that triangulation of LoRa is possible even at very low SNR.
The trick is understanding LoRa's trick, which is simply to "skew" the signal across time (via chirps), modulo a window of the configured bandwidth around the center frequency. The key is that the skew rate is purely a function of the spreading factor, bandwidth, and IQ polarity (= pol × BW² / 2^SF), so there's a small-ish finite number of skew rates. So you can just modulate raw IQ data with carriers at each of these skew rates to find one which gives you a bunch of carrier waves that hop around discretely at about twice the symbol rate, looking like an FSK signal. You can then bin this at a factor of, say 2^(SF-2) to correlate the signal and raise it up above the noise floor, on which you can apply any standard triangulation technique.
I'll try vetting this soon and reply to this post with results.
Sounds like you know what you’re talking about. I’d be very interested in learning more. I’m not a radio or even software expert. I’m a data scientist with a math background. Interested in communicating across mesh networks anonymously.
I know only basics about mesh networks per se. I'm speaking here from a background in signal theory / amateur radio / research on the LoRa protocol. If you have specific questions on those aspects feel free to contact me, my e-mail is in my profile.
Is your goal nondetection? If so, know that triangulating a radio signal is fairly straightforward, even in a dragnet fashion. The exception I think is something like cryptographic DSSS (found in military use) wherein not only is the signal far below the noise floor, but the spreading function is not predictable by an adversary (LoRa being very much predictable). Even then, you're limited by physics to only be able to transmit so far without the signal being detectable near the transmitter.
Has anyone come across a good semi-technical description of "how your node knows that its message got sent and reached its destination and can stop sending"? I'm interested in how this logic is executed when you can't be sure (I assume) that knowledge of the result will get back to you in a certain amount of time.
In short, all messages are sent within windows, which include waiting periods within which the broadcasting node listens for any other node to rebroadcast the same message. Upon seeing the message be rebroadcast, it stops attempting to send.
The Meshtastic list of networks is nice, but it is missing several. For example, the lack of listings in North Carolina led me to find https://ncmesh.net/.
I'm ignorant of mesh technologies, but can somebody explain to me why they are using MQTT in their stack? Topics and pub-sub over TCP doesn't sound like a mesh-y kind of thing. Does it work well in this context?
The mesh isn't doing MQTT or TCP. They're using MQTT to bridge between meshes, with mesh nodes that have an internet connection or are paired to a smartphone with an internet connection relaying mesh traffic with an MQTT server.
Also very good way to instantly spend all your air time. Remember, legally you can only transmit at something like 10% of time. In some bands even less, afaik.
Would you be interested in a small commercial application of your node?
I need a few messages transmitted to as many peers as possible once in a while.
Nothing illegal, just a small contribution to the economy.
We're selling pure herbal organic medicine which helps males perform better, and our product announcement will fit perfectly in you 200 characters limit.
(500 kHz bandwidth is indeed a valid setting for the underlying LoRa protocol, and is used when the radios get certified.)
Unfortunately the community meshes in most/all US metros have coalesced around these settings, meaning one is forced to choose between linking with "the" mesh, or operating legally.
[1] https://www.ecfr.gov/current/title-47/part-15/section-15.247...
reply