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.
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.
> even the secret way to turn on 30-sec skip on the TiVo
Select-Play-Select-3-0-Select ;-)
Also can't forget the ,#401 dialing prefix to enable the device to call home over the Internet using a USB Ethernet adapter instead of the phone in the early days.
TiVo's whole approach to commercials in recordings was largely informed by ReplayTV though. ReplayTV took a lot of heat and lawsuits for their automatic commercial skip functionality, which is why TiVo never implemented it and buried 30 second skip behind the code.
ESPN is already partly doing this with "SC For You" [1]. It gives you a personalized feed of sports clips, generated and narrated by AI that uses the voices of ESPN on-air talent.
For anyone interested, ESPN has a HAM Radio club - WE1SPN[1] - and they are live streaming some of their Field Day operations on YouTube[2]. They're not operating overnight, but should be back in the morning eastern US time. If you'd like to make contact the operators are actively monitoring the chat.
I'd like to play devil's advocate for a minute and ask a question:
Does anyone know exactly what the Bosch service sends the dishwasher?
While I agree that connecting a dishwasher to the Internet should not be necessary, it does open the door to an interesting scenario if what gets sent to the dishwasher is not a command to run a mode but an actual program to control the dishwasher. In theory that would mean that Bosch could alter the programs that get sent to improve the dishwasher over time.
On a dishwasher with no connectivity the modes simply are what they are from the factory. But on a connected dishwasher if the Bosch engineers figure out that when in ECO mode using every third sprayer saves water while not altering the cleaning performance expected of that mode, they can update the payload and make the dishwasher you already have even more efficient. They could also in theory create a whole library of modes for specific use cases or scenarios (All glass, hard water, etc.)
Of course, this has potential drawbacks as well. They could change a mode and alter behavior you expect, and it could potentially be a hacker's playground, but if done well it could be a net positive.
The idea of a manufacturer updating my appliance to be "more efficient" is fine, but updates should only be applied at my discretion and we already have several mechanisms for this that don't involve an always-on internet connection.
If they really want firmware updates for their dishwasher, they should give it Bluetooth or a USB port enabled by a special button combination and call it a day.
The system I'd love to have a better understanding of is the one TiVo deployed for the transmission of data to their boxes in the early 2000s.
They would buy a 30 minute paid programming in the early hours on cable TV networks under the name "Teleworld Paid Programming". The box would tune the channel, record the show, and then decode the data from the recording.
I always thought there was something interesting there, as the process would need to survive the MPEG encode/decode process on the TiVo itself in addition to whatever they needed to do the broadcast.
Back in 2022 libtorrent implemented memory mapped IO as part of v2 [1]. Unfortunately, it didn't go so well. Memory usage went through the sky, leading to performance degradation and crashing [2]. The issue is still open in the project to this day, and many programs have stuck with the v1.2 library instead.
It looks like they are headed to a multi-threaded pread implementation now [3] and someone has created a patch to tweak the current mmap fallback that uses pread to perform better in the meantime [4].
The more interesting thing to consider is that Trump has said Elon will have an active role in his administration. How is he going to do that on top of everything else? How are Tesla investors going to feel about this?
I think for most of his business he already have other peiple he trust in charge of them. Its impossible to manage so many companies and he seens to spend more effort in Space X than Tesla, starking, etc...
The CEO of a company being one of most powerful people in government is excellent for Tesla investors. Much less so for the general population, as the conflict of interests is obvious.
Especially outside US - if next government will ignore world or start doing some serious harm (ie by being too friendly with putin), tesla drivers will be frowned upon universally and very few new sales can be expected, more like a lot of vandalism on cars.
I guess China is a gone market for tesla at this point.
If you meant PC-based mesh networking, I'll leave someone more knowledgeable to speak about that :).
[1] - https://meshtastic.org/
[2] - https://meshcore.co.uk/