The long-held dream of wireless network hackers everywhere is to dispense with centralised network infrastructure, and instead rely on a distributed network in which the clients perform the role of distribution and routing of traffic. These so-called mesh networks promise scalability and simplicity on paper, but are in practice never as easy to implement as the theory might suggest. Much venture capital has been burned over the years by startups chasing that particular dream, yet most of our wireless connectivity still follows a hub topology.
An exciting development in our sphere concerning mesh networking came in early 2018, when Particle, the purveyors of wireless-equipped dev boards, launched their third generation of products. These offered mesh networking alongside their other features, but this week they have announced that they’ll no longer be developing that particular side of their offering. The Wi-Fi-equipped Argon and Cellular-equipped Boron will remain on sale, but they will henceforth discontinue the mesh-only Xenon. Existing owners of the now orphaned board will be compensated with store credit.
Their rationale for discontinuing mesh networking is interesting, and reflects on the sentiment in our first paragraph. Mesh networking is hard, and in particular their attempt to make it work with zero configuration was simply not successful. But then they talk about the realisation that maybe mesh networking was not the right solution for the IoT applications the boards were being used in, and perhaps another technology such as LoRa would be more appropriate.
So the mesh experiment from Particle is over, but the company and its connected dev boards are very much still with us. We salute them for being bold enough to try it, and we wonder when we’ll next find a piece of similar mesh networking hardware.
Store-and-forward on steroids.
sad news,
I have worked on the development of theory and practice of mesh networks in US, Europe, Dubai in pre 3G 4G 5G times, so not being aware any interest in zero configuration mesh networks is still not satisfied by 345G connectivity.
Let me know your zero configuration mesh network problem to discuss a nice solution.
You need at least 3-layer case by case modified protocols to match your logistic challenges.
Its to bad it didn’t work. 2.4G just doesn’t have the range to make Mesh a viable option. The other issue I had when using the Xenon was the dependance on an another Particle board for setup and OTA. If they would have wrote the firmware as a Microcontroller with bluetooth that supported Mesh. The board would have had a longer life. When they sold them there was very little said about the requirements of a Boron or another board to use it.
Well not in unlicensed form. Some mesh nets have been workable in ham radio licence holders hands, where they’ve boosted output and put better antennas on wrt-54g routers etc. Then they only need a few people running them per city, mounted high, getting 5 mile coverage or something like that.
It took me probably half and hour of trying to set up a Particle mesh network to realise it wasn’t really going to work for me. Honestly I think they could have marketed the Xenon as a Bluetooth enabled microcontroller, I found the BLE API easy to use. But that would probably does not support their “connectivity as a service” business model, and the hardware profit margins isn’t exactly high
On a somewhat related note I would love to see some sub GHZ wifi products (802.11af/ah), but I haven’t managed to find much of anything, seems to be little more than a published spec. Something similar to an ESP8266/32 that could greatly benefit from the increased range in many applications would be awesome.
Ubiquiti has some long range wireless devices that work on 900MHz, but that’s really more of a proprietary version of LTE-U as opposed to Wifi.
Goodbye mesh, we hardly knew you
One solution for a zero configuration static mesh network might be to include a GPS module on every router and route traffic via something similar to a Maidenhead Grid Locator(aka IARU Locator, aka QTH Locator).
So each device only needs to know how to route traffic to all global field locations:
field – base 18 – AA to RR – 18×18 – 324 locations
Their own local square:
square – base 10 – 00 to 99 – 10×10 – 100 locations
Their own local subsquare:
subsquare – base 24 – aa of xx – 24×24 – 576 locations
And finally their own local extended square:
extended square – base 10 – 00 to 99 10×10 – 100 locations
So a total size for the routing table on each device would only need to have 324+100+576+100 entries (1100). And most of those would be null unless new devices were added.
Actually I just ran the numbers and that would only get you to about a 16.5 metre (~54 foot) by 16.5 metre (54 foot) location on earth, maybe add another grid for finer granularity and possibly even add an elevation above or below sea level for skyscrapers or apartment blocks.
BL11bh16 would be ~16.5m x 16.5m square ( ~54′ x 54′ )
BL11bh16ex would be ~ 700 mm x 700 mm square ( ~2′ 3″ x 2′ 3″ )
Maybe change the Maidenhead Grid Locator from a pair of values (Latitude, Longitude) to a triplet value (Latitude, Longitude, Altitude) e.g. BLR113bhx169exa
mesh are alvays good!
I have yet to see the “Store Credit” for the Xenon’s I purchased from Particle.
Hey Jon – Meghan here from Particle – please send the team a note to the link below, likely just an oversight in our email communications: https://docs.particle.io/support/shipping-and-returns/mesh-deprecation/
Mesh was announced as the killer app and is getting killed before full release. Some of us would prefer a refund on our now worthless and discontinued Xenon’s rather than being trapped with a store credit
I becoming increasingly interested in how we can use existing technology to create meshed networks in emergency situations. I’m interested in exploring getting device manufacturers to natively build in and allow use of radios that are already there to be used for this purpose. I’d love to learn more about what the blockers are to allow this to happen as I’m working on a policy project to address this. If you are savvy in this area and willing to help me out please send me a message so we can chat further. Meshed@protonmail.com
Limited LoRa/915 available spectrum is a big one.
Preparedness tech might need to be usable for more everyday stuff, or else consumers won’t really care(How many people do you know that don’t even own a first aid kit?).
Ideally, we’d have a protocol that could seamlessly switch between radio and WiFi/Ethernet, and when using LoRa, will use the minimum possible transmit power.
More importantly, we need software that is usable without central servers. That kind of thing is almost nonexistant. Almost every attempt in recent years has some bandwidth wasting blockchain built in, or some crazy DAG based thing, or is just a really simple proof of concept.
Mesh needs software people actually want to use.
There’s been an open ticket for Google to allow ad hoc WiFi for years, they keep inventing all kinds of similar things that aren’t quite as good for mesh.
You might like
https://github.com/sudomesh/disaster-radio/wiki/Layered-Model
Developed for https://disaster.radio/
That’s pretty cool but I’m not entirely sold on the idea of LoRa based mesh. The datarate is really low, and every hop is more bandwidth.
Direct point to point LoRa might be ideal for disaster communications, but I think 2.4GHz and 5Ghz is the way to go for mesh, because of directional antennas and tons of available spectrum.
I’ve been thinking about how to efficiently allow public repeaters to forward E2E encrypted messages, and I think a basic publish-subscribe scheme with gateways linked via MQTT would probably work.
It would be interesting to see a good write-up of exactly what emergency communication involves, and what kinds of disaster people are trying to prepare for.
Is the goal mostly to get information back to a few central places where the real pros are? And do we expect the location of the disaster itself to be fairly small? If so, maybe mesh isn’t needed at all and sattelites need to be involved.
Or maybe this is for the one guy stuck in the woods and we need cheap wide area coverage with almost no data, and LoRa mesh is perfect?
Check out http://www.rajant.com. The most extreme example of totally decentralised wireless mesh networking. Used in heavy industry for high throughput IoT and mobile ethernet.
We totally understand why Particle decided to move away from their mesh offering, but it’s important to remember that Thread was the backbone of it and the challenges associated with the specific hardware, and protocol, are not necessarily representative of “mesh networks” as a technology.
The Amatis Controls wrote this blog post to try to get the conversation opened up a bit:
https://www.amatiscontrols.com/2020/01/30/a-case-for-mesh-networks/
And we launched this forum to create a place to talk about:
https://www.amatiscontrols.com/forums/forum/mesh-networking/
We won’t be a good fit for everyone, but we think our experience with 802.15.4 networks in real commercial applications sets us up to possibly help some of the companies that are feeling the pain from this decision.
For what it’s worth, we have a module that is also based on the NRF52840 and are putting hundreds of devices on our networks with an advertised range (conservative) of 200ft.
I really want consumer mesh to be a thing, but I think WiFi based meshes like Yggdrasil and CJDNS are the way to go, with LoRa comms for the actual nodes.
LoRa has better range than you even need or want for any kind of consumery thing, and so one LoRa to IP gateway can serve a huge area.
Also LoRa mesh is a thing now: https://github.com/sudomesh/LoRaLayer2/blob/master/README.md
The store “credit” of 20$ is also 100% bullshit since they just upped the shipping costs to 31$, when it was free previously. This is nothing more than a greedy money grab combined with trying to look apologetic.
We moved to xbee controllers, a true mesh network that worked out of the box. Particle mesh was a scam.