First the good.
The core tech of LoRa remains amazing.
The hardware has gotten DIRT CHEAP.
The idea that anyone can go buy a $10 circuit board, 3d print a case and have a radio that can talk privately to satellites or across town IS ground breaking!
The biggest break through lately is that the hardware IS good AND cheap at long last!
Some LoRa history.
First off a company called Semtech developed & patented the silicon to make LoRa radios back in 2014.
In the EU a corporate outfit, "The Things Network"(TTN), was the earliest adopter and created an open specification for a centralized LoRa network(LoRaWAN).
TTN feels a lot like a cellular network and isn't a mesh network. Suffers from the typical coporate conflicts but has a nice enough free tier and a fair bit of open source code behind it.
A wireless communication method between a plurality of end-points by a plurality of base stations, based on frames that have a CSS-modulated preamble followed by a data body modulated at a narrower bandwidth, either by CSS or by a UNB modulation. The system permit to avoid or mitigate collision between packets and to increase the network capacity, maintaining the simplicity of detection inherent of CSS modulation.
So the problems with the TTN is basically is a SaaS capitalist play. You buy a gateway, connect it to TTN then TTN sells access back to you and your community for your own hardware 馃ゴ
They do give a free tier and act open but your hardware and data is THEIR profit center. Lame.
It's got a lot of network coverage in the EU, but never really took off in the US.
In practice the network in the EU is viable, the one in the US isn't.
In the end TTN/LoRaWAN make a ton of sense for corporate customers or people selling IoT gear to corporate buyers.
It works well where you have coverage. It's well designed and there's tons of quality hardware, though much of it not fully open.
LoRaWAN's claim to fame is that device data connections can be as cheap as $1/year and some of the gear like soil sensors can last for 10yrs on a single coincell battery.
But TTN's LoRaWAN was always plagued with limited adoption in the US especially.
Enter the crypto bros....
A crypto startup used the basic business plan from TTN, multiplied the cost to deploy a device by like 5-10x and put an allbeit secure, but confusing AF layer of cryptocurrency around the whole thing and promised to share profits with routers err I mean "miners"
Naturally they hit the adoption jackpot but cost structure is f'd so its a non-starter馃檮
Me, watching this chaos from like 2017 to 2020 things seemed hopeful. Like... I've been playing with mesh radios since 2006. So this felt like a lot of progress and a TON of potential.
I've just been dying to see someone take the same gear and use it in a mesh instead.
Enter meshtastic . . .
I first found #Meshtastic in 2020. It was early, had aloha broadcast (aka floodfill routing) as the core routing protocol.
I thought it was a cute LoRa mesh demo but it was super buggy and the hardware wasn't good then.
Back to that flood fill tho... friends, THIS IS NOT HOW TO MESH. I've been playing with wifi, bluetooth, zigbee meshes since 2006. Friends, you can't scale flood fill.
So I made a note to check in on meshtastic when they did real routing.
2024 rolls around, the cryptobro hype has died off, the corporate hold is doing its thing on TTN and well... all other types of public comms are getting spied on like no ones business.
Time to go catch up on the LoRa mesh going ons.
I noticed meshtastic was close to FINALLY merging their public/private key system in the fall last year and decided it finally hit my first min. bar for re-review.
Mind you they were kinda making misleading encryption claims up to this point.
I found it pretty quick and easy to throw together nodes and repeaters.
Even got some permanent installs in some high places. Built piles of nodes for frens.
Which my friends went wild and threw up more nodes, built chat bots and mesh bots.
And it's chattering away.
Meshtastic postives:
- code works
- there's DM level pub/priv crypto
- community is slinging a lot of code
- there's docs now
- it's popular so you will see some nodes in many places including the US.
So from my previous LoRa experiments with TTN in the same area, Seattle, I was familair with the propagation properies of LoRa.
LoRa is great at line of sight, If you can see it, they can probably hear you.
I could -easily- with TTN make connections to my home router along the Burke Gillman trail in U District and all the way up to any visible part of Capital Hill from the TTN gateway in U District.
Meshtastic performs similarly rangewise, but datarate is almost non-existant vs TTN.
Part of why LoRaWAN (like TTN & Helium) have better RF performance than meshtastic (and other lowcost LoRa meshes) is that LoRaWAN makes use of actual gateway chips which enable them to listen to 8 channels at once while meshtastic only uses one static channel at a time.
LoRaWAN gateways can then use intelligent scheduling modes (they call it device classes) to make super efficient use of the 8 channels and possible hop around noise channels too.
https://www.semtech.com/products/wireless-rf/lora-core/sx1303
I personally -really- want to be able to use LoRaWAN gateways as part of a mesh so it can serve 8x the users and frequency hop around noise.
I've also been pretty up to date with mesh and lora stuff so I just feel its a lil lame none of the meshes use gateways.
It's not the worse problem and in the case of meshtastic having more channels will only make their problems worse.
Floodfill can't scale.
That's the core issue with meshtastic.
All the nodes repeat what they hear, kinda like "the people's mic" at a protest. This strategy is great if we all want to hear ONE person's speech across a whole crowd.
But try the people's mic with 10's hundreds or thousands of different bi-directional conversations and things get messy.
We're all shouting to hear and expecting the person next to us to repeat. But all they hear is noise and very rarely a few words here & there
So doing what LoRaWAN does(optionally using better router hardware), could help maybe 8x the ability of this chaotic shouting fest but it'd never improve things.
The ONLY routing approach meshtastic has seriously considered is this broadcast system. They keep futzzing around with how long people pause before shouting but they don't introduce anything more than this.
This is why the datarate sucks. Messages collisions. "router_late" etc won't fix this.
https://meshtastic.org/docs/overview/mesh-algo/#layer-3-managed-flooding-for-multi-hop-messaging
Aside from playing with timers, the meshtastic core team encourages people to use very low hop counts.
Now IMO "hop limit" shouldn't even be a thing a user needs to know about or set 馃毃
The system, must use a routing algo that can adapt.
If I'm in Tacoma and the mesh has a route to nodes in Seattle and I want to chat with my friend in Seattle idgaf how many hops it takes.
We -actually- have a mesh that far already.
Meshtastic refuses to hop far enough.
Worse, its a 3bit hop limit!
In practice I've been able to make meshtastic connections all over Seattle, gotten line of sight links from North Gate to West Seattle and everything in between.
With meshtastic's mesh I can even make a ton of those long shots without line of sight by hoping over and around the hills and buildings.
But its clear, I -frequently- run out of hops NOT network!
The broadcast algo eats up all the hops in the core downtown and rarely makes it out the otherside with low hop limit or even with the max
Now to the kicker with meshtastic.
The project is run in the usual tech-bro seeming ways and are rude ass fuck to new comers with less experience / platform than I who've made the -same- observations about floodfill's limits.
The core team is dying on the hill of the shitiest routing algo possible because they I guess don't want to read anything about routing research.
Bruh... I worked in a networking research lab in the early 2000's, almost every excuse this team has made is bullshit.
So when I have spent time and money learning an open source project, encouraged friends to also go learn and spend money.... and then the core team is rude as fuck to them when they have polite and honest feedback.... yea fuck that noise.
Meshtastic is gonna fail on the same dumb hill as many tech-bro led projects, fighting their community over dumbshit.
It's a perfectly fine toy of a project to learn LoRa but please know better is possible and we don't have to deal with these assholes.
Normally I'd recommend forking once a project is getting well known for bad leadership.... but IMO meshtastic isn't worth forking.
It needs so much work to be good, like it -might- be an ok starting code base but so much needs changing so it may be easier to start the fuck over.
I really need to refute their core teams constant insistance that routing algos other than floodfill are too complex to implement and are too heavy weight.
I point to the project RadioHead... which now a decade ago implemented a better LoRa mesh routing algo a DECADE before meshtastic.
Someone please inform the meshtastic crew that for literally 10-20yrs makers have been making more complex mesh algos run on low end processors ffs.
https://airspayce.com/mikem/arduino/RadioHead/classRHMesh.html
Now back to the positive.
All is not lost, meshtastic is the biggest LoRa mesh and it sucks BUT its not the only one and the same mobile nodes and repeaters you'd use for meshtastic can be used on any other LoRa mesh.
I think the most exciting meshtastic alternative is Reticulum. It exists already, has a routing and security approach for the real world but might be too opinionated in some ways for some users. It's a bit of a grander vision
Lately a youtuber whose been doing a lot of videos about meshtastic just announced he's launching his own meshtastic replacement targeting the same hardware.
I watched a lot of Andy Kirby's videos and he seems to have an eye for the same sorts of problems I've mentioned with meshtastic so I'm very curious to see how his project goes.
They haven't released their code yet so we'll have to wait and see.
I wish I had less complaints for meshtastic, comments reminded me of others.
0. Has routing table, doesn't use it
1. Static MAC is used and expected over lora
2. The static MAC is the same or similar to the device ble/wifi mac
3. Location data leaks in unexpected ways
4. MQTT arch is messy af
5. Their simulator is buggy & bad. But is how they make technical decisions
6. Security is an after thought (and finally ok-ish)
7. History of non-sane defaults + many users are slow or never upgrade = bad
11. Limited protocol privacy behavior by default responds to certain protocol events unless in specific mode (client_hidden). But they still leak data sometimes, possibly bugs???
12. Lack of strategy on #11 means once you know a node's ID you can track it trivially both via MQTT or physically or even via BLE or Wifi.
And if you've seen my defcon talk.... you probably can figure out what I can do with #1, #2 #11 and #12 馃
#13 No conversation privacy in default scalable configuration. Anyone can see your to/from fields and bc #1 it's great metadata.
Need to verify how bad #13 is, I think you can mitigate but most people use a public channel. The header I think its technically encrypted BUT with a known public key so everyone can see whose talking to whom. I think you can get encrypted headers on the public channel but docs aren't clear and probably limits your hops.
Finally I suspect that IF meshtastic ever does fix their routing algo they will suffer from MITM exploits due to issues around #1, #6, #8, and #9.
Bc when you have MAC as the root of trust I can respond to your MAC and poison the routing table.
There might even by a solid security downgrade attack here too bc they have backwards compatibility for insecure DMs. So once I clone your MAC I can also downgrade security and ppl are trained to accept downgrades.
MeshCore has released their code today.
I've read most of the code and this is fairly early, limited docs, no mobile app and limited hardware testing.
That being said the over the air protocol+routing looks excellent. The code is well designed and fairly slim. The security posture is good and designed in from the start.
They get so much right in so little code. I even think I could make this messtastic compatible faster than they can improve.
Rapidly moving my meshtastic nodes over to meshcore 馃馃徔
Going very smoothly so far. Meshcore is notably very fast at message delivery and delivery confirmations back to the sender.
Thinking I'll leave my primary meshtastic infrastructure nodes up and build meshcore nodes to deploy next to them so as the network matures I can do head to head comparisons.
#lora #meshtastic #meshcore #lilygo #tdeck #wisblock #seeedstudio #esp32
Writing my first meshcore PR 馃馃徔
It's still a work-in progress, but having a lot of fun learning this code base!
https://github.com/ripplebiz/MeshCore/pull/96
#lora #meshcore #meshtastic #privacy #networking #esp32 #offgrid
Idea for this PR is to add a network bridge mode for repeaters.
This will let you take multiple LoRa radios, setup meshcore repeater firmware and listen on any number of channels or with different antenna setups and bridge the routing across those different channels with a shared Wifi link(the two dotted white boxes).
I've tested it for a few days and it's pretty amazing to see meshcore automatically finding bridged routes.
Wrote a little parser for meshcore packets tonight. It's still messy and a lot more to implement. But, it reads the container format so I'm happy for now.
I have meshcore packets flowing from multiple repeaters(on different frequencies) talking on wifi using udp broadcasts.
The repeaters automatically discover each other on the network and now I'm able to watch their chatter with a quick nodejs server.
#lora #meshcore #networking #radio #nodejs #container #incus
Working on a meshcore testbed.
I want to have several radios on the roof so I can develop in production
Cleaning up the wiring and checking antenna SWR with a NanoVNA.
Was curious if these cheap antennas were similar to their name brand look alikes. And no, no they are not comparable lol. Stick to the name brand I guess for this style of antennas, the cheaper ones are not worth it this time.
Trying out a safer route to the roof and sorting out how we'll deliver PoE to our radio mast projects.
Really hope the hacker space can get some proper folding stairs for attic access at some point.
Some results from a week of there being a meshcore repeater on Cougar mountain.
A lot of us can now hear around 80 radios throughout the Seattle / Tacoma region.
The public chat channel is extremely busy at various times throughout the day.
I've been able to DM people in Tacoma and connect to their chat servers all the way from Seattle.
Some routes are extremely stable, meanwhile others are more flaky. It's super exciting!
Testing routes from central Seattle down to Tacoma is shockingly stable.
Meshcore is working well enough in Seattle that now adoption is the largest issue to having a more robust LoRa mesh network.
So if you're in the PNW area and want to build a solid handheld LoRa radio to try out meshcore I've made a bill of materials for my go to portable build LoRa plans.
https://git.devhack.net/nullagent/lora-builds/src/branch/main/rak
#meshcore #seattle #pnw #tacoma #openhardware #arduino #lora #radio
Without wifi, how do you use it? USB otg?
It can be connected to via USB or BLE.
In the case of repeaters and room servers neither BLE or USB is needed as it works purely over LoRa and can be managed remotely over LoRa as well.
nullagent
Niedliche Nacktschnecke