We're using Meshtastic quite extensively for communication on our boat. Each crew member carries a mobile waterproof node (Seeed T1000e), the boat itself has a node, and we also have a Meshtastic tracker for the dinghy.
We often sail in places where there's no communication infrastructure, or it is prohibitively expensive. With Meshtastic we can talk when somebody goes ashore, and the boat can send telemetry and alerts to the remote crew.
Some of our buddy boats also have Meshtastic on board so we can text chat with them instead of using VHF.
The only real problem I foresee with this use(fantastic use case btw) is if you travel across regions, does the kit currently get automatically switched to correct frequencies and power limits?
No, you need to switch the region manually. Not a big deal to do for a couple of nodes.
The trickier part is to figure out the correct preset for more exotic locations. I've had to ask a couple of times from the local Meshtastic community group.
I have a few LoRa radios running Meshtastic and they're fun to play with, but I wouldn't rely on them in a critical situation. It's too easy to accidentally configure a node incorrectly and cause problems for nearby nodes.
Perhaps someday the project will settle on a handful of sensible presets for different use cases. Even better would be if more of the options were managed dynamically by the software itself, things like adjusting timeouts and hops based on current network utilization and previous transmission success rate, or automatically tweaking the role based on the current mesh toplolgy, that sort of thing.
We need better radio silicon that can survey a wide swath of available spectrum (based on country limits) and pick channel(s) appropriate to the use optimized for battery life, distance, and/or bandwidth with a simplified interface. There's no sense wasting spectrum or having malfunctioning radio gear when it can be standardized and used more efficiently without an artificial, protectionist, hoarding monopoly (excluding particular essential, prioritized uses).
Proprietary mesh networks tend to become unusable garbage because they omit DoS, rate limits, and proper configuration for dense metropolitan uses, and tend to fail at investing in upkeep.
> better radio silicon that can survey a wide swath of available spectrum (based on country limits) and pick channel(s) appropriate to the use optimized for battery life, distance, and/or bandwidth
That would certainly be helpful, but even with current radios I can imagine a configuration process that sequentially scans different channels to achieve the same result, just a little slower.
Huge fan of Reticulum, fixes some of my biggest gripes with Meshtastic. Shame it hasn't got as much adoption yet. For those looking for Meshtastic-equivalent things in the Reticulum ecosystem:
Didn't got adoption because the code base is awful to work with and there is a trauma against bluetooth being used as a network path.
Plus: encryption is heavy when bandwidth is limited and over radio waves we aren't even permitted to encrypt data most of the times.
Please don't read my comment as bringing down the project. I'm a fan, used everything it was produced but ultimately is unusable for serious applications on the current state. I really tried hard to adopt it.
What are those gripes? If I don't have anyone else who would use it, but would hang out in a public chat room, it didn't seem like reticulum was the right choice for that? You need destinations on things?
Nomadnet it's really bad; it doesn't properly work with a 80x24 terminal and 16 colors.
Also, it uses tons of CPU on legacy machines. It needs some rework.
Not everyone it's a hipster with 256 or 32 bit colour terminals, shitty NerdFonts (nonstandards) and big displays.
And being written in Python3 makes it dog slow. Being rewritten in Go would get a few performance tweaks, (networking and GC there it's ideal), security and portability. But, please, no BubbleTea unless you can be sure it can work on a plain XTerm with 16 colors (I use Tango for readability, but 16 colors FFS). Keep 256 colours as an option.
One of the main differences with MeshCore is that client nodes don't repeat messages, only dedicated repeater nodes repeat with the idea that they should be placed in more ideal locations.
Just don't mention MeshCore anywhere around Meshtastic, or they'll kickban you.
Meshtastic: Text message mesh network using LoRa modems.
Reticulum: full network stack (alternative to IP), mesh, focus on low-speed, unreliable connections. Transport layer agnostic. Current 'Hardware drivers' are written for LoRa, Internet Tunnels, Wifi, Amateur radio.
Reticulum sounds great? It is, but still has 2 problems: 1. The only complete & stable implementation is written in Python and 2. The existing end-user applications have confusing and complex UIs (except for the command-line tools for remote shell and file copy).
First I've heard of this. My initial reaction is why oh god why this name. I liked Anathem, but seriously you're not going to using this as the Internet 3000 years from now.
Meshtastic at first glance seems silly. No routing, one spammer could mess up the whole thing. Hopefully this is better.
Meshtastic is reasonably good for unplanned and mobile use cases such as hiking, but for building an emplaced network, Meshcore has much better performance.
This has been our experience in the Greater Boston Mesh.
Is there a mesh network solution with very low bandwidth by design? "by design" meaning that participants of the network aren't able to increase their bandwidth beyond a defined upper limit. I'm thinking of a bandwidth of about 10kbps. The low bandwidth would practically eliminate problems around spamming and cp. The idea is a network that is only useful for exchanging texts/messages and accessing simple text based websites.
Meshtastic already fulfills that, except for the bit about accessing simple text-based websites, because Meshtastic isn't an IP network. The data rates only go up to 21.88 kbps for the fastest preset: https://meshtastic.org/docs/overview/radio-settings/#presets
the idea is that there would be no point in visiting anything else than text based web-sites or use text-based services. or do you mean that it can't be hooked up to the internet due to its lack of IP protocol?
How far can Meshtastic go, it seems using LoRA. How is it different from VHF/UHF based radio that can do 30+ miles using handheld where no cellular power exists(off-grid communication), or the 5-mile walkie-talkie. My assumption is that Meshtastic has the advantage of low-power that can sustain much longer time.
Another forthcoming alternative will be satellite-based chat using phones.
For a single hop you can expect close to similar ranges as a VHF set. We saw 30NM distances on open sea when leaving Curaçao. Could be a lot more with antenna situated high up.
Where the magic potentially kicks in is the mesh hops. With those you can reach much further by jumping from one node to another.
It's not even close to satellite comms in reach or reliability, but it also requires no infrastructure, no licensing, and no subscriptions.
Meshtastic is multi-hop, doesn’t require a license and is encrypted by default. It’s also a toy network, really. Reliability doesn’t seem to be high on the priority list.
Reliability carries serious costs in airtime usage and power consumption, and there's always going to be someone who demands that the network support an even higher level of reliability. "Toy network" is highly subjective and depends on your (unstated) assumption about what kind of use case you want Meshtastic to fulfill.
Readit News
We often sail in places where there's no communication infrastructure, or it is prohibitively expensive. With Meshtastic we can talk when somebody goes ashore, and the boat can send telemetry and alerts to the remote crew.
Some of our buddy boats also have Meshtastic on board so we can text chat with them instead of using VHF.
Here's a story describing this: https://blog.noforeignland.com/off-grid-boat-communications-...
The trickier part is to figure out the correct preset for more exotic locations. I've had to ask a couple of times from the local Meshtastic community group.
Lots of LoRa stations nearby.
Perhaps someday the project will settle on a handful of sensible presets for different use cases. Even better would be if more of the options were managed dynamically by the software itself, things like adjusting timeouts and hops based on current network utilization and previous transmission success rate, or automatically tweaking the role based on the current mesh toplolgy, that sort of thing.
Proprietary mesh networks tend to become unusable garbage because they omit DoS, rate limits, and proper configuration for dense metropolitan uses, and tend to fail at investing in upkeep.
That would certainly be helpful, but even with current radios I can imagine a configuration process that sequentially scans different channels to achieve the same result, just a little slower.
i installed a node week ago. honestly, it is somewhat underwhelming
I played a bit with them. There was one node anyway about 6 miles from me.
https://reticulum.network/
- Sideband: iOS/Android chat app (https://github.com/markqvist/Sideband)
- NomadNet: Desktop CLI chat app (https://github.com/markqvist/NomadNet)
- Rnode: Reference node hardware/firmware (https://unsigned.io/rnode/)
Plus: encryption is heavy when bandwidth is limited and over radio waves we aren't even permitted to encrypt data most of the times.
Please don't read my comment as bringing down the project. I'm a fan, used everything it was produced but ultimately is unusable for serious applications on the current state. I really tried hard to adopt it.
Also, it uses tons of CPU on legacy machines. It needs some rework. Not everyone it's a hipster with 256 or 32 bit colour terminals, shitty NerdFonts (nonstandards) and big displays.
And being written in Python3 makes it dog slow. Being rewritten in Go would get a few performance tweaks, (networking and GC there it's ideal), security and portability. But, please, no BubbleTea unless you can be sure it can work on a plain XTerm with 16 colors (I use Tango for readability, but 16 colors FFS). Keep 256 colours as an option.
Deleted Comment
https://meshcore.co.uk/
Just don't mention MeshCore anywhere around Meshtastic, or they'll kickban you.
Reticulum: full network stack (alternative to IP), mesh, focus on low-speed, unreliable connections. Transport layer agnostic. Current 'Hardware drivers' are written for LoRa, Internet Tunnels, Wifi, Amateur radio.
Reticulum sounds great? It is, but still has 2 problems: 1. The only complete & stable implementation is written in Python and 2. The existing end-user applications have confusing and complex UIs (except for the command-line tools for remote shell and file copy).
Meshtastic at first glance seems silly. No routing, one spammer could mess up the whole thing. Hopefully this is better.
2024 (335 points, 79 comments) https://news.ycombinator.com/item?id=38829448
2022 (249 points, 90 comments) https://news.ycombinator.com/item?id=32016142
2020 (620 points, 168 comments) https://news.ycombinator.com/item?id=22540066
Meshtastic's Opposition to Proposed Changes on 900 MHz Band - https://news.ycombinator.com/item?id=41242091 - Aug 2024 (16 comments)
Meshtastic: An open source, off-grid, decentralized, mesh network - https://news.ycombinator.com/item?id=38829448 - Jan 2024 (78 comments)
Meshtastic is an encrypted communications platform for the Lora RF protocol - https://news.ycombinator.com/item?id=32016142 - July 2022 (88 comments)
We're making an open-source $30 GPS/mesh radio, would like advice - https://news.ycombinator.com/item?id=22540066 - March 2020 (166 comments)
Here is part of the Berlin mesh https://potatomesh.net/
This has been our experience in the Greater Boston Mesh.
Another forthcoming alternative will be satellite-based chat using phones.
Where the magic potentially kicks in is the mesh hops. With those you can reach much further by jumping from one node to another.
It's not even close to satellite comms in reach or reliability, but it also requires no infrastructure, no licensing, and no subscriptions.