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
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.
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.
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.
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.
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.
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.
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.
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'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'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.
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.
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"
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.
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.
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’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.
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.
Nth for MeshCore, which the Boston Mesh has found to be a much more scalable solution for building an emplaced mesh network with hundreds of clients: https://analyzer.letsmesh.net/map?lat=42.00963&long=-70.9639...
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
From what I understand, Meshcore doesn't support the IOT/sensor types of use cases that Meshtastic does, right?
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.
Unfortunate recent news, Reticulum is kinda done (at least the main dev is). https://github.com/markqvist/Reticulum/discussions/1069
Yeahh, just saw that today :( it's a shame
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.
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.
Honestly .. MC is very successful in terms reliability doing it their way. Ignoring that will with full force doesn't make MT better.
Hopefully MT catches up. Their GPLv3 license is much more attractive to me than the MC MIT.
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.
That's true. Toxic people destroy projects and their communities.
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.
Write me if you are willing to experiment :)
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.
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.
Is encryption allowed over this network? I know it’s not allowed over HAM. Also is triangulation / message source identification possible?
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.
Ham isn't an acronym. Just saying!
Did you grab lunch at Smitty's?
I live 5 miles west of the maker space in the last photo, and I've been thinking about getting some Meshtastic nodes...
(The two amazon links for the antenna upgrade and pair of radios is swapped, if you're looking for the one, click the other)
Whoops. Thanks I will fix that later today.
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'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.
Also Meshtastic codebase is the awful mess - one of the many examples when Arduinoslop became something bigger than quick prototype.
You seemed to have made an account just for this reply. Care to explain the cynicism? I’m out of the loop with the toxicity.
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.
Here's an example of a good criticism: https://www.zeroretries.org/p/zero-retries-0215
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).
So you mean other than these sections right?
"Thought experiments about mesh networking"
"Hard Lessons Learned -- What not to do"
"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.
All the information you seek is found in the article you stubbornly refuse to read.
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.
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"
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.
[0] https://mtlynch.io/first-impressions-of-meshcore/
[1] https://partyon.xyz/@nullagent/113861754522594610
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.
Thanks! I appreciate your more accessible explanation.
How cute that you’re “puzzled”. Cool story bro.
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.
It's much easier to call some protocol "bad design", after the fact, than to develop something yourself.
And presumably rely on discord despite MQTT?
Are meshtastic nodes still spamming their battery status over the network?
Have they figured out that flood routing is a terrible routing mechanism?
Is it imperfect in an unusuable way? Do you have links to alternatives?
Meshcore is the obvious quick answer to alternatives to flood routing
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’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.
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.
MQTT is used for map reporting, and sometimes as a "fallback" or to connect distant meshes.
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.