[Michael Lynch] recently decided to delve into the world of off-grid, decentralized communications with MeshCore, because being able to communicate wirelessly with others in a way that does not depend on traditional communication infrastructure is pretty compelling. After getting his hands on a variety of hardware and trying things out, he wrote up his thoughts from the perspective of a hardware-curious software developer.
He ends up testing a variety of things: MeshCore firmware installed on a Heltec V3 board (used via an app over Bluetooth), a similar standalone device with antenna and battery built in (SenseCAP T-1000e, left in the header image), and a Lilygo T-Deck+ (right in the header image above). These all use MeshCore, which is built on and reportedly compatible with Meshtastic, a framework we have featured in the past.
The first two devices are essentially MeshCore gateways, to which the user connects over Bluetooth. The T-Deck is a standalone device that resembles a Blackberry, complete with screen and keypad. [Michael] dove into what it was like to get them up and running.
Probably his most significant takeaway was that the whole process of onboarding seemed a lot more difficult and much less clear than it could be. This is an experience many of us can relate to: the fragmented documentation that exists seems written both by and for people who are already intimately familiar with the project in its entirety.
Another thing he learned was that while LoRa is a fantastic technology capable of communicating wirelessly over great distances with low power, those results require good antennas and line of sight. In a typical urban-ish environment, range is going to be much more limited. [Michael] was able to get a maximum range of about five blocks between two devices. Range could be improved by purchasing and installing repeaters or by having more devices online and in range of one another, but that’s where [Michael] drew the line. He felt he had gotten a pretty good idea of the state of things by then, and not being a radio expert, he declined to purchase repeater hardware without any real sense of where he should put them, or what performance gains he could expect by doing so.
Probably the most surprising discovery was that MeshCore is not entirely open source, which seems odd for an off-grid decentralized communications framework. Some parts are open, but the official clients (the mobile apps, web app, and T-Deck firmware) are not. [Michael] found this out when, being primarily a software developer, he took a look at the code to see if there was anything he could do to improve the poor user experience on the T-Deck and found that the firmware was proprietary.
[Michael]’s big takeaway as a hardware-curious software developer is that the concept is great and accessible (hardware is not expensive and there is no licensing requirement for LoRa), but it’s not really there yet in terms of whether it’s practical for someone to buy a few to distribute among friends for use in an emergency. Not without getting into setting up enough repeaters to ensure connectivity, anyway.
Meshcore clients being closed sources is a deal killer for me personally, still an interesting project & stack to keep an eye on.
To me this is really interesting. I honestly don’t know exactly all the terminology but it was a staring pkace for me to learn.
The service firmware and protocol specification are open though, so anyone who can and is willing to is free to create a fully open source client (phone app).
Some clients are closed some are open. Developers are free to build compatible apps or clients any way they wish.
I think them calling Meshtastic “casual” and closing their client source says everything I need to know about this project. The fact that HaD would even promote this abomination…
How exactly are you to create “decentralized, resilient” networks if your software is closed and proprietary? It’s “decentralized” and “resilient” insofar as they are willing to support, document and expand it, and you’re beholden to them for binary distribution. That also means no audits, so now the chain of trust includes another actor, and you can’t really know for sure whether or not your “decentralized” “private” network is private at all.
No thanks.
This comment is a bit heartbreaking. The foundation of MeshCore is developed primarily by a single developer who is incredibly hardworking, dedicated and idealistic about keeping everything he does fully open. The firmware and protocol specification are completely open, allowing anyone to create a client app or perform security audits on the device firmware implementation. Just hop over to the meshcore-dev github repo and have a look. There are also open source command line, python and javascript client libraries, free for anyone to audit and build their application with. I’m not a meshcore dev myself, but I have downloaded the firmware sources a few months ago to make a tweaked firmware for my devices. No problems building and uploading the binaries I built myself.
The only native client phone app that currently exists is developed by another dev, and they chose to not make the app open source. You are free to have an opinion on that, but calling the entire project and “abomination” is a bit unfair I think.
I totally agree with you.. I have multiple devices on Meshcore and it’s only the lily go t-deck that if you want to unlock the full features you pay a small donation. Updating or programming your first companion is super easy through the web flasher , so I don’t understand how (Michael) managed to mess it up!. This whole article is hear say and should not be relied on.
+1
Cool. Let me know when you’ve made that, and I’ll beta test it for you.
@Elliot just wrote an article about several times per week finding articles on Hackaday relevant to his current projects. Just a few days ago, I picked up a Heltec v3 for just a few bucks from an auction, thinking “I’ll throw it in the parts bin and do something with it someday”. And along comes this article shortly thereafter!
I’ve ended up doing the same last year. Luckily, the financial damage was minimal.
Both of these devices work well with Meshtastic, if you don’t like the Meshcore tos.
Yes they do work well for Meshtastic, but in dense environments, the “everybody’s a repeater” model is a liability that essentially makes Meshtastic all but useless. As in, Los Angeles. Meshcore works alright though. Now, if everyone on Meshtastic set their units to “Client Mute” by default, the story would be different.
Playing around with meshtastic after a few years I was supprised of the node density as well over her ein Germany – now easily 300km range of the mesh to the south of Frankfurt.
It might be a better default option to implement a “client-auto”, that starts muting itself after seeing messages echoing around and/or too many nodes in client-mode. A forced “client-repeat” as a new option then maybe as well. I bet, there is already an issue on github for that.
The part you are missing with regards to Meshtastic is that while everyone is a repeater, if you have created a private channel with a private encryption key, those repeaters can’t decrypt your message.
Yes, but that’s not the problem. The problem is that while “everybody is a repeater” has some advantages when the network is very sparse, it has massive disadvantages when the network becomes even a little denser. Meshtastic has pretty poor message delivery reliability as a result.
Everybody being a repeater is not the recommended way to setup a new Meshtastic node.
There’s plenty of guidance https://meshtastic.org/docs/configuration/radio/device/
I don’t wanna near any project with proprietary license, it will trap you
I made my own with the power of AI and attention deficit. I call it citadel and I’m not sharing :)
Meshcore protocol and node device firmware are all open source. Also nobody is going to sue if you use Meshcore as name – unlike Meshtastic does. The developers and community are quite aggressive.
Mobile apps for Meshcore are free but not open source, but feel free to write your own apps. However the mobile app works so well (compared to meshtastic mess) that there is no need for new ones..
Meshcore is generally more robust by design than Meshtastic for example in larger cities. Try both and see yourself.
And if there is no repeaters around, setup one and be patient. This is not commercial network – dont expect ”service”. Make your own service if needed!
I’ve never heard of any actual lawsuits being filed, so this seems pretty inlfammatory. Meshtastic has a trademark, which has to be upheld (or it is possible to lose). So far they’ve only enforced with unauthorized businesses using the trademark to sell devices and merchandise as well as groups using it in a way that is confusing for individuals who perceive it as official ala “Meshtastic UK”.
https://hackaday.com/2020/12/12/irc-over-lora-for-when-things-really-go-south/ We’re still working on this and welcome contributors, eh!
That is interesting; thanks for sharing. I wound up handling communications protocol myself for testing but found I couldn’t get more than a half-mile on 915MHz with spread factor low enough that short messages felt instant (largely due to having the antenna laying on its side inside my house and the other in a car). This project might be what gets me to retry properly.
idk about wireless generally for SHTF emergency comms, tho; GPS/similar jamming is a big problem in Russia/Ukraine war, and I imagine in others (I think they’ve had trouble recently in Caribbean with US operations against Venezuela) — with strong jamming equipment, overwhelming relatively weak consumer LoRa/WiFi seems pretty plausible if they become aware of frequencies being used to organize resistance — but maybe you make a hardware switch to violate FCC/similar rules in emergency to make jamming more difficult. Not actually sure if militaries have jamming equipment tuned to these lower frequencies, though. If I’m going full tinfoil, I’d probably want physical, buried, shielded lines running to my neighbors. A thousand feet (305m) of direct-bury-rated cat6 cable on a spool goes for $150-200 and gets you what’d feel like a hurricane of data compared to a mouse sneezing.
-or if it’s really an emergency, it might be worth considering hijacking existing coax and fiber utility lines. if the city’s on fire and the Internet’s out anyway, who’s going to enforce against a neighborhood cutting the coax line for their own uses? that technology is wholly unfamiliar to me, though. … this is why I shouldn’t think about these things too much :joy:
That’s what I was thinking, why use a unit of measurement that 95% of other countries would have no idea what that actually is.
Heck I wouldn’t have minded if they said feet or yards, that I can convert, but is one cuties block size the same as anothers? I don’t know, I’ve never (and have no desire to) go to the US, the only country, to my knowledge, that uses the “block” as a unit of measurement.
Every language has their equivalent of “a block”.
For example, in Swedish “kvarter”, which is usually considered to be 100 meters, but that should not be confused with kvarter as in volume, which is a quarter of a stop, or an eighth of a canister.
Not sure what the equivalent would be in Dutch, to be honest :). We sometimes say something like “3 straten verder” (“3 streets further”), but that doesn’t really correspond to an absolute distance, but rather indicates you need to pass 2 intersections or side streets to get to whatever is there.
Nobody refers to “blocks” as an absolute distance either
In at least some US cities, blocks might be around 400 by 700 feet or 125×215 meters. Without someone having specified which direction, we could say that’s 1746-2000 feet minimum and a maximum of 2828-3500 feet. It would be fair, given line of sight, to assume paths straight paths had lower loss than diagonal paths, with significant hot spots where reflectors off of planar surfaces like garage doors boosting signal. In the past, I had an 900 mhz direct sequence spread spectrum phone that could manage around 1750 feet and presumably a roughly 60 kbps full duplex data stream. Assuming a repeater is an elevated, it would have greater line of sight than you do from the ground.
I’d assume, based on experience that 1746 feet is a fair number. If a repeater were halfway between it would double range. I’d estimate something like 3.92 repeaters per square mile or 2.11 repeaters per square kilometer would be in the range of useful as a starting point. (Assume, pessimistically that you’re in a relatively empty area where it’s all repeaters and you’re the only node means adding 1 to the total).
What’s really needed is some really cheap, really repeatable repeater nodes with an integral solar panel charge controller, Lithium ferrophosphate battery pack using 18650 size cells and a weatherproof housing and a vertical antenna with some gain. A repeater option with capability for 4 radios (3 with directional antennas, plus an omnidirectional for local access) would be good at vastly reducing number of hops to get between cities.
I live an hour outside of a metro area, and to blanket the city I call home it’s probably take about 25 or so repeaters. If some were strategically located on hilltops, I wouldn’t be surprised to get more than a mile per hop.
I haven’t looked that deeply at the protocol, but assuming you light up significant areas, means of congestion mitigation, finding efficient paths and having the right level of redundant are a huge problem. The one thing that would help would be a strategy of dynamic path adjustment, but it’s hard to see how you can do that while preserving privacy.
It’s using language to avoid giving precise measurements, since the range of a radio device at such distances depends more on the amount of stuff in between blocking the signal rather than the actual distance. It also depends on the number of walls giving off multi-path reflections that eventually distort the signal.
So you can consider five city blocks more as “five clusters of buildings” rather than any specific distance, but if you like you can give it a range between 50 – 250 meters per block, which means you can expect a range of 250 – 1250 meters in densely built urban areas.
In general “under a kilometer”, but that is no promise because it depends very much on where you are within that distance. You might be standing just one street away and get no reception because you’re in a bad spot.
This is the measure you use when your buddy got the wrong door and you want to tell him, that the leather club’s two blocks down.
Even in the US, “blocks” are the measure in the inner cities only. US miles is more like it.
I prefer yards, tho, because one yard is somewhere close enough to a meter, and I can see 100 yards next to be (nearest parking lot happen to be nearly 100 yards long – I measure it using google maps, then re-measured with GPS walking, yep, decidedly close to 100 meters).
So, to put it in usable terms, how many 100-yard measures would give one a better ballpark that would cast reasonably well into both metric and imperial. Hence, I propose “Hectometers”, which are both walk-able and see-able.
“already intimately familiar with the project in its entirety”
Not sure how you could think Meshcore is more complicated than Meshtastic????
After using both I stayed with Meshcore(more reliable)
I found MC MUCH easier to set up.
“feel free to write your own apps”
Yep….Meshcore is open…it’s just the app that is not. Write your own.
Because he’s right. The app is comparitively obtuse. To get started in Meshtastic, you only need to pair to the node and set a lora region. It doesn’t get much simpler than that.
“The fact that HaD would even promote this abomination…”
Wow…….1st time on this site???
I dislike all the “SHTF” scenarios and the invented reasons where these devices become useful. Especially for a small group of scientists in an off-grid scenario like low elevation hillscape you can do better with cheap multi-channel PMR radios from a supermarket. The reaction of the wife is absolutely reasonable, as much as I love the idea of encrypted messaging with random people.
My real power fantasy is a simple jeep with an antenna mast and boom, an LTE modem in the trunk, parked at the spot with the last signal bar connecting me to society. The clients can only do so little work, it’s the repeaters we need portable, in the field and at a strategic location.
Municipal LORA stations, well they work a few clicks in an area where you usually have more modern alternatives. Make no mistake, I would be the first person in a zombie scenario to get “whacked” by scavengers.
Yeah, everyone thinks it’s pointless until they need it. Regarding your power fantasy, though… will your LTE modem still work when (not if, it has been happening with increasing frequency) the infrastructure goes down… or when an AWS/cloudflare bug takes out three quarters of the Internet? Will you be able to coordinate with the people you care about — for whatever purpose — when the lights go out?
Further, just as soon as you get a few miles from “society”, LTE (and even satellite phones in many cases) are unreliable at best, a liability at worst. For a practical, real-world example, LTE barely worked (if at all) during North Carolina’s recent hurricane/flood/mudslide disaster. Guess what fire, EMS, rescuers and even volunteers used to coordinate search/rescue and relief efforts? Meshtastic + ATAK. It’s even used for fire watch, wildfire evacuation and mountain rescue where other mechanisms are unreliable or impractical. And, you know… farming and industrial applications. They don’t use PMR446, unsurprisingly… especially in the case of sensitive/confidential use or emergency coordination.
Just because you don’t have a use for it doesn’t mean the reasons for its use and development are “invented”.
I have an off-grid Adirondack cabin that has cellphone access itself because it is atop a mountain. But I needed to track my crazy dogs on their adventures in the lowlands near the two lakes on either side. So I went with Meshtastic, which seems designed to infuriate anyone who actually tries to use it. Every subversion breaks compatibility with previous subversions (nodes running version 2.6 pretty much refuse to communicate with those running 2.7) and ChatGPT is hopelessly confused when you’re trying to vibecode something that works. Still, I got it working well enough to track my dogs, and it works so well I only need the receiver at my cabin to track the dogs a half mile away in all directions. I integrated it into my whole ESP8266-based homebrewed cabin control system, which is on Github here:
https://github.com/judasgutenberg/Esp8266_RemoteControl
Anything that touches LoRa has the habbit of having “open-source” in the branding but is actually closed. Started 8 years ago with “open source lora wan”, seems to iterate trough every single incarnation using LoRa in the bottom.
I have an off-grid Adirondack cabin that has cellphone access itself because it is atop a mountain. But I needed to track my crazy dogs on their adventures in the lowlands near the two lakes on either side. So I went with Meshtastic, which seems designed to infuriate anyone who actually tries to use it. Every subversion breaks compatibility with previous subversions (nodes running version 2.6 pretty much refuse to communicate with those running 2.7) and ChatGPT is hopelessly confused when you’re trying to vibecode something that works. Still, I got it working well enough to track my dogs, and it works so well I only need the receiver at my cabin to track the dogs a half mile away in all directions. I integrated it into my whole ESP8266-based homebrewed cabin control system, which is on Github here:
https://github.com/judasgutenberg/Esp8266_RemoteControl
Meshcore uses many of the same devices as Meshtastic, but is not compatible with it.
The majority of it is open source and is rapidly being developed. This includes reimplementations of the protocol in python, and software to run the radios as a LoRa KISS TNC
(Self plug)
https://github.com/brianwiddas/meshcore-pi
https://github.com/rightup/pyMC_Repeater
https://github.com/datapartyjs/MeshTNC
This mesh stuff is nothing but a toy to me.
I’m sure the search and rescue, fire, emergency coordinators and volunteers saving lives following North Carolina’s hurricane disaster thought the same thing.
So then the logical (for me) question would be “would there be some kind of mid-way OPEN SOURCE technology, so to speak, that would be as robust and as relatively simple as ham/cb radio, but utilizing mesh”. Some kind hybrid of the two that would NOT pit one against the other (as it seem to be common in the US), but complement one with the other.
I mean, ideally it would be the best of both world, and if one picks one side (cb radio, prime example of very, very well-known and quite usable tech,) he/she can augment that with the mesh networking, and vice-versa? I’ve already seen examples of sending simple chat messages over the air and forwarding through the gateways, both wireless and wired, just I remain skeptical that those still will be working in the case of true emergency, when it is largely unclear what still works and where (and the usual channels, cell towers, etc get easily overwhelmed with the frantic calls – most probably serving no real purpose and blocking REAL calls to emergency trying to get through).
As far as maintenance goes, military knows how to do that – any system that can suddenly become mission-critical HAS to go through regular maintenance no matter what. It is also expected that the backup systems, too, will be unmothballed, installed, replacing the main systems, and put through proper paces as if it was the only main one, thus, making sure it still works when it needs to work. In this sense having only one Plan A is a lousy way of approaching anything that should be robust, there HAVE to be Plans B and C, all valid and working. If anything fails, then, short of Pony Express, Morse code should still work no matter what.
Something like that.
One of the developers of Meshcore was initially building its own system (ripple which then became R2) where repeater functionality had to be unlocked by donation for a key/code.
Meshcore on the other hand is only locking some clients, in terms of transport and encryption it seems to have copied for the most part reticulum which makes me think future wise there won’t be much progress unless the surrounding frameworks evolve.
People using it, ran from Meshtastic because of the broad packet types covered by Meshtastic and their broadcasts but from what ive been seeing Meshtastic is evolving into allowing to select more and more what types of packets we want to deal with so i cant really see a benefit of switching to Meshcore.
Theres a problem a lot of people mention on Meshtastic due to nodes spamming telemetry, location, nodeinfo packets constantly clogging the network and this is down to bad players on the network. In Spain most people use the nodes with 7 hops and a daily dose of 1000 packets of nodeinfo, telemetry, GPS how can they not expect network problems of most people dont care about the community at all?
Reticulum Network may be a better answer for lora networks. https://share.google/R01ZrkDnUU0j3pFoY
He already had repeater hardware. The V3 just needed repeater firmware. Which is free.
The protocol and examples are open and free for anyone to develop their own software or firmware.
As far as distance, etc yes you cannot get away from physics. The real world limits range. Height is might. Less obstacles the better the range. Many places are not covered but MeshCore is growing fast. Other places like England, Boston, PNW have great networks and can reliably pass messages over many hops. Once thing nice is a good, friendly community and a few open source projects. There is a CLI project for those who like that.