I've never seen a bigger network with Reticulum in the wild. And I'm deep into Mesh stuff with several local communities.
One of the main reasons of the communities not jumping onto the ship was that it's mostly a one-man-project and most of its Git changes are "Update" "Better Version" "Update" "Cleanup" which makes it basically impossible to track changes.
And, as of 3 weeks ago, the one man is "stepping back from all public-facing interaction with this project".[1]
Further, "Occasional updates may appear at unpredictable intervals, but there will be no support, no responses to issues, no discussions, and no community management in this or any other public venue."
Nothing salacious here - just another one man open source project with a burnt out maintainer :(.
The reticulum dev have been trying to quit for years and have been quite open about his own personal struggles.
More recently:
- v1.0.0 was supposed to be the time his involvement is over [0]
- 6 months later [1]
> This is not a temporary break. It's not "see you after some rest", but a recognition that the current model is fundamentally incompatible with my life, my health, and my reality.
- But he pushed 3 releases since his last message [2]
It is like he is trying to quit somking.
I am not sure what the problem is exactly but it seems someone need to take over and honor the fantastic work he has done over the years.
> To the small group of people who has actually been here, and understood what this work was and what it cost - you already know where to find me if it actually matters.
>To everyone else: This is where we part ways. No hard feelings. It's just time.
In the LoRA/radio device sense, Meshtastic[1] is probably the easiest to get started with. It's the biggest player in the space, has devices that come pre-installed and configured, the most likely chance of making contact with someone else, etc. MeshCore[2] is the other major player. It's newer and tends to have been adopted by communities that have run into issues with large Meshtastic networks.
If you meant PC-based mesh networking, I'll leave someone more knowledgeable to speak about that :).
I've had some experience with both Meshtastic and Reticulum, and Meshtastic software was mostly unusable for me even with 3-node networks. E.g. a node sends a message and gets a successful delivery notification from the receiver but the receiver fails to display the message to the user. Reticulum was mostly working fine. Haven't tried MeshCore yet.
Meshtastic also doesn't really... work. Let me qualify that. You can get a couple of nodes for cheap, and you can (with a bit of work) get messages to go between them. The problem is coordination between nodes is required for the network as a whole to work. Specifically, user adjustable node -local settings can overwhelm the network for everyone else around you. Defcon "solves" this by providing firmware to flash with preconfigured settings tuned for the event. But hopefully this makes the problem obvious - in some other scenario that you might hope to use them - and TBC, my goals for a long range, non-cellular network mesh network are for connectivity during a hurricane/flood/firestorm/earthquake/tornado/etc.
An open implementation is preferred, because it drives down the cost of hardware and lets users purchase the grade of hardware they want. But if it doesn't work, an imperfect proprietary solution(s) available now > hypothetical perfect future solution.
Lora, especially on regulated bands that are the most used ones, is designed for very small, very infrequent messages. It isn't suited for real-time chat (nevermind secure) and so I think you can't really make it work while respecting transmission regulations.
There are lora modules that work on the 2.4GHz ISM band but then you probably need to consider whether Bluetooth is not a simpler choice if range is not the no. 1 concern.
>It isn't suited for real-time chat (nevermind secure)
It is encrypted on private channels and direct messages.
>and so I think you can't really make it work while respecting transmission regulations.
I don't know from where your information's are from, but for sure not from reality. Voice encryption/scramble on Amateur-Band's is not allowed, everything else is ok.
> Voice encryption/scramble on Amateur-Band's is not allowed, everything else is ok.
It seems like you're saying voice encryption is not permitted, but data encryption is? This is not true in the US. Any encoding used for the purpose of "obscuring meaning" is not permitted on amateur frequencies. Even using code phrases like "the eagle has landed" is arguably not allowed. There are some narrow exceptions for things like satellite control codes, but nothing that applies to hobby mesh nets.
> No amateur station shall transmit: [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein; obscene or indecent words or language; or false or deceptive messages, signals or identification.
No, numbers stations are not permitted on amateur frequencies in the US. There are some notable cases of foreign governments setting these up and interfering with amateur allocations [1], but there's not much the FCC can do about that.
I know what features it claims to have. The question is how well this can work on bands (US915, EU868) that very strictly limit the amount of time a device may transmit. IMHO you can't really have interactive chat on a mesh network over lora in those bands.
>IMHO you can't really have interactive chat on a mesh network over lora in those bands.
Devices allow 10% Airtime on ISM here (EU) that's about 300 messages (with 255 characters) per hour, and yes interactive chat is possible with around 20 seconds of lag.
EDIT: I stop here, so much half knowledge that sounds educated but is in fact just wrong and TBH not even sure if i talk to a selfhosted AI.
Yes, in the EU one subband allows 10%, the rest is 1%. I believe that Meshtastic uses the whole 250kHz of that subband by default. This is by far the most relaxed constraints of what is available in the EU and US. That's about 180 max. size messages per hour (at longfast) per device but you need to take into account retransmissions, acks, mesh management and routing of third party messages. So it may work, barely, for this specific config and very small number of people or 1-to-1, but that's it.
I am not picking on Meshtastic specifically, it's just that Lora and, especially the regs on those bands are such that some applications are never going to work well beyond extremely small meshes, if at all.
>I believe that Meshtastic uses the whole 250kHz of that subband by default. This is by far the most relaxed constraints of what is available in the EU and US.
My dream would be to have something like Yggdrasil[0] over some kind of mesh-based transport. Yggdrasil already does a good job with routing, it just needs a mesh-based transport IMO.
Big fan of MeshCore; been using it recently and it Just Works. Especially where I am in the USA Pacific Northwest, the mesh is always hopping with conversation. I have run into delivery issues a single digit number of times over hundreds of messages.
While I mostly agree, I have some small quibbles which I think will present a more complete picture.
I've had a good developer experience with 74LS00-family SSI chips (like the quad-NAND-gate 74LS00 and the hex-inverter 74LS04), so your mileage may vary.
Just to clarify, the Padauk and Nyquest chips I linked above are one-time programmable (PROM), not mask ROM, except the PFS122 (3.53¢), which is reprogrammable Flash. (It's advisable to debug your code with a Flash chip or an ICE before you start consuming PROM chips, unless you really like to desolder.) Padauk doesn't seem to make mask-ROM chips at all, and I haven't seen any from Nyquest.
I'm not sure what you mean by "highly specialized". They're tiny, slow 8-bit microcontrollers, so you will certainly be disappointed if you go in hoping for STM32-like capabilities. But they're programmable, and their peripherals don't include things like LiDAR pulse timing circuits or AES encryption hardware or anything like that. It's just very general-purpose stuff like watchdog timers and PWM generators.
> Europe's size may not lead you to comprehending the US' size.
Why not?
Europe seems to be about 10 million km2 in land size, and the USA 9 million km2. Are you trying to say that because Europe has bigger land size, it's hard for Europeans to imagine individual states' sizes?
Here's some quick facts comparing population and area
- There are 17 European countries >100km2 but 37 US states are
- 13 states (only one of those is <100km2) has a population density <= Norway.
- The most population dense state is Jersey, at 488 people/km2. 5 European countries are more dense than that.
- 10 US states have >100 people/km2 but 25 European countries do (I'm rounding Albania up)
- California, the most populous state, is smaller than Sweeden, but larger than Germany in area. It has half the population of Germany. 90% of CA's population lives in 5% of the area (near SF and LA)
- Driving North-South through California takes a bit over 13hrs but if you add 30 minutes you'll only hit one of those areas.
- Driving East-West across Texas takes 12 hrs and you'll only go through 2 major cities. You are likely to see more tornadoes than cities and definitely more cows than people (I know from experience)
Most of the US population is in the East and West coasts. With far more in the east. Most of the US is just empty, but also the land is not nearly as nice as in Europe.
I don't think it is hard for Europeans to imagine individual state sizes, but likely won't imagine how empty it is. Hell, even Americans aren't good at that
By everyone thinking you can get 100% coverage across the Great Basin Desert? Yes. Yes I do think that the population density of Europe leads them to think everything is closer and easier than it is.
That one desert, of many, is about 190,000 miles in size. That's half the size of the whole of France.
Are you really saying covering that, with 100% coverage, with no dead spots at all, is a reasonable task to undertake?
If you want to challenge the myth of coverage in Europe forget about size comparisons and look to some of the hard walking trails in remote areas; Via Dinarica Kosovo is known for it's beauty and harsh terrain, not for it's cell reception.
Elsewhere in the Balkans, Romania, et al you'll find blind spots.
The signal in the Kimberley's is shithouse, mate. Last time I was there, I went three days with zero signal, because I was in some more remote communities. That's not really an argument against what I was suggesting, is it?
> That's not really an argument against what I was suggesting, is it?
No, that's pretty much just a tangential straw interpretation of your own design as the signal quality in Kimberley, or lack thereof, has got three tenths of f'all to do with the issue being population distribution rather than size.
Both Europe and the US have low population regions with poor signal.
Upthread I suspect the anecdata about good quality signal in Europe came from somebody who had more exposure to the well trod higher population density parts of Europe and hadn't encounter less covered corners.
> I'm running LTE-only with zero problems for 2 years now without a single coverage gap. Even in the rural parts.
The anecdote, was suggesting that our vast and empty lands are trivial to cover. But as you know, that has nothing to do with reality. I'm so sorry I tried to convey it with a tinch of kindness to them. Next time I'll tell them to pull their fucking head in.
> Are you really saying covering that, with 100% coverage, with no dead spots at all, is a reasonable task to undertake?
Well, do people live in this desert? If not, then I wouldn't say that's reasonable.
But then I don't feel like your replies here are reasonable either and pretty disingenuous overall, so maybe lets just leave it at that, and you can continue believe your country is much bigger than it is.
> Well, do people live in this desert? If not, then I wouldn't say that's reasonable.
It stretches from Reno Nevada to Salt Lake City Utah. It also includes Las Vegas, Ogden Utah, and Provo Utah. But there are plenty of small cities in between. If you drove on the I-80 from Reno to SLC you'd pass through Fernley (23k people), Lovelock (2k), Imlay (200), Winnemucca (8.5k), Carlin (2.4k), Elko (21k), Wells (1.3k), Oasis (34), West Wendover (4.5k), and a few dozen more cities comparable to Imlay or Oasis as well as just as many ghost towns. That drive would take over 7hrs and is over 800km long.
This is not an uncommon setting in the US either. I'm sure there's a few unique paths like this in Europe, but honestly, are there that many? I once drove the majority of the US (I started in The South, so think 24 -> 70 -> 29 -> 80 -> 29 -> 90) and despite driving across almost all of America the biggest city I drove through was St Louis, which doesn't even have 300k people. I think if you counted all the people that were <5km distance from me over the subsequent several days and several thousand kilometers I doubt the number would add up to my stop in St Louis and would only have happened because I went through Sioux Falls (~200k at the time).
I think the comparison here would probably be the Greek archipelago. Or indeed Greece, or even more broadly the Balkans, given how the settlements are mostly in valleys and there's a lot of mountains, but I wrote the next paragraph before thinking of that:
You can go into the absolute wilderness of the states/the waters of the Mediterranean with suitable gear, and there's some dotted isolated communities within the uninhabited territory/EEZ of the greater region.
I don't know if either has good cell coverage. I presume not, given I managed to lose cell coverage even just crossing the English Channel by ferry a few years back.
But no, I don't live in America. I live in the much, much, much less dense country of Australia. Where tourists frequently die, because they believe that they'll have cell signal everywhere.
When I see this, I suspect the vendor is operating under conditions that approach absolute chaos: dumping whatever junk someone imagines might be necessary into the stack with zero resistance, for years on end. Zero effort spent on any factoring that might threaten redundancy.
I'm not saying the tools aren't bloated, but I believe that a lot of the size (sorry, can't quantify right now) are the datasets for each and every FPGA model that the tool supports. This includes, among other things, timing information for every wire in the chip. You really only need the files for the device that you are targeting and you do have the option to install only that, or you can install larger groups (e.g. same family, same generation), all the way up to installing every device that ever existed that the tool supports. That's how you get to hundreds of GB.
Are you sure about that, or is it just a guess? If that is the case, how will the open source toolchains avoid the same problem when they eventually become the industry standard? (I can imagine something like a software repository for serving device-specific information on demand.) Are they planning anything right now?
Xilinx toolchain installations used to include a file which was just the concatenation of the license files of every single open source library they were using somewhere inside any of their own software. Now if you installed two or more components of their toolchain (for example, Vivado, Vitis, and PetaLinux) into the shared installation directory, this same file was installed several times as well. Together, they made up something like 1.5 GiB alone.
Welcome to modern development lol. Try to refactor it and get an answer of "no money for testing".
On top of that, the "agile" mindset all too often also means there is no coherent vision where the project should go, which can and does lead to bad fundamental architecture decisions that need extensive and expensive workarounds later on.
And yes, there have been people describing exactly that in ASML [1], although the situation seems to have improved [2].
One of the main reasons of the communities not jumping onto the ship was that it's mostly a one-man-project and most of its Git changes are "Update" "Better Version" "Update" "Cleanup" which makes it basically impossible to track changes.
reply