Long Range IoT Networks - Chapter 2 | Particle + LoRa Better together

Alright… in today’s adventures in LoRa, I learned you can only have ~2 (maybe 3) LoRa mesh nodes all within range of each other. As soon as I added the 3rd and especially the 4th LoRa mesh node (i.e. a node that services mesh messages by routing them), when I add a “end node” the route discovery message for it fails. I am pretty sure what’s going on is if 3 or more LoRa mesh nodes all hear the same mesh discovery message at the same time, then all 3+ will retransmit the route discovery message at nearly identical times and thus the message gets clobbered and nothing makes it through and the new node never self discovers a route.

Thankfully, in my use case, it’s not too big of a deal as 2 repeats (3 hops total) should easily cover the rural use case I’m after. I was tempted to enable CAD (channel activity detection) or possibly try adding a random delay when processing a LoRa mesh route discovery message to prevent the LoRa traffic from colliding but it seems things will get out of hand quick if say 10+ nodes all within range of each other wanted to service a route discovery message even with CAD and random delays. So avoiding that complexity for now.

So short of some new technique, it’s clear guidance for me to only have 2 LoRa Mesh repeaters per “LoRa network” or at least only have 2 that are within range of each other and no more. Currently I configure this using a DIP switch on the PCB anyhow.

As of now, I set it up to have 6 nodes total for more testing of robustness.
Node 1 <–> Gateway
Node 2 <–> Node 1 <–> gateway
Node 3 <–> Node 2 <–> Node 1 <–> Gateway
Node 4 <–> Node 2 <–> Node 1 <–> Gateway
Node 5 <–> Node 2 <–> Node 1 <–> Gateway
Node 6 <–> Node 2 <–> Node 1 <–> Gateway

2 Likes

I’d bet the Protocol contains some kind of measure to prevent this.
Large-Scale High-Density Networks is a core function for LoRa, I thought.
It’s marketed for Smart Cities with 1,000’s of devices.

I don’t know what the answer is, but maybe stepping through the SF’s, random delays, etc.
Or possibly a limitation w/ the Library that you’re using ?

Unfortunately, the only thing that I have to offer is Encouragement :slight_smile:

1 Like

Yeah, to be a bit more clear… I fully expect to be able to accommodate 50-100+ LoRa nodes if it ever becomes necessary in a single deployment. It’s the fact that all 50 can not be configured to be a LoRa Mesh repeater. I’d plan to do more of a 1-2 nodes be configured as a mesh node and the remaining 48 are end nodes (i.e. do not attempt to re-route messages from neighboring nodes). They just send data (possibly through the 2 mesh repeaters) and then go back to sleep.

As for the smart cities with 1,000s of devices, yeah, that’s all LoRaWAN protocol which does not support mesh and therefore doesn’t do any type of “route discovery”. Nodes don’t have to repeat a broadcast it receives. I read a recent article that LoRaWAN is beginning to support repeaters but that’s a simple channel activity detection wake up and re-transmit whatever you heard and does not a “route”.

That said, I’m sure there are ways to provision it somehow to make many more nodes be a mesh, and this is likely a limitation of the current Radio Head library. I studied the RadioHead library in detail and already made several changes to it and I’m pretty sure there is no provision in it to account for this today. I know there are other sub Ghz mesh networks out there that must do route discovery, just not sure how they handle the route discovery component when many nodes try to re-broadcast at the same time. Maybe each repeater node has it’s own “re-broadcast” window so instead of re-broadcasting a route discovery right away, it waits for it’s specific turn to re-broadcast it. That would probably work… but it would be a significant development item.

Nearly all of my use cases won’t require more than 1-2 hops anyhow. It’s more about strategically locating 1 LoRa Mesh node at the highest spot on a property/hill to reach up/over a hill than trying to mesh many together and go miles. If someone is trying to cover miles, then I’d just put in another Particle + LoRa gateway on a different channel.

Thanks for the explanation… that all makes sense.

True, My guess is that LoRa’s built around it’s Fair Use Policy, and that’s a big factor.

For instance, with a XBee mesh you can routinely perform a “Find Neighbor” Command and receive replies back from dozens of nodes (used for Indoor Localization, like an indoor “GPS”).
The big difference is this would be a Private Network with much higher bandwidth, verses LoRa that’s much better for a “Community Wide” approach with it’s Fair Use Policy.

I’ll go ahead an appoligize for the dumb questions below:
In your deployment, I visualize several STAR networks that are centered around your Repeaters. The repeaters then provide the backhaul between each other to the final destination.
I assume your concern occurs in the Overlap of these STAR’s footprint ( a new node being commissioned will be heard by too many repeaters, clogging up the channel) ?

Can you simply adjust the SF during the commissioning process to limit the range (if required) for the route discovery ?

So does each neighbor have an offset to when it sends a reply in XBee or does somehow XBee handle multiple devices on air at the same time for these replies? Maybe the higher bandwidth is such a short on air time that avoids conflicts. I believe a route discovery message is 70ms including the pre-amble for LoRa RadioHead library default radio settings.

Yeah basically, once the node discovers a route, it works nearly flawless from that point forward since it has a prescribed route for the message. Even of repeater nodes hear an application message as long as it’s not participating in the route, it won’t re-transmit it. It’s only route discovery message that get hosed. Anytime multiple repeaters hear a route discovery message itself gets flooded and nothing gets through. Having many repeaters in a system is just fine, they just can all be within range of each other.

Per the RadioHead Library documentation:

When a RHMesh mesh node is initialised, it doe not know any routes to any other nodes (see RHRouter for details on route and the routing table). When you attempt to send a message with sendtoWait, will first check to see if there is a route to the destinastion node in the routing tabl;e. If not, it wil initialite ‘Route Discovery’. When a node needs to discover a route to another node, it broadcasts MeshRouteDiscoveryMessage with a message type of RH_MESH_MESSAGE_TYPE_ROUTE_DISCOVERY_REQUEST. Any node that receives such a request checks to see if it is a request for a route to itself (in which case it makes a unicast reply to the originating node with a MeshRouteDiscoveryMessage with a message type of RH_MESH_MESSAGE_TYPE_ROUTE_DISCOVERY_RESPONSE) otherwise it rebroadcasts the request, after adding itself to the list of nodes visited so far by the request.

It’s the fact that all repeaters who heard the original message “rebroadcast” it at the same time that causes the issue. I may try to just add a short random delay to see if that helps at all.

Possibly… I am already using SF7 to keep the on air time low. I could reduce power during route discovery, but then it’s artificially reducing range since the route discovery message won’t travel as far.

Yeah, this is basically what I’m after. I think the 1-3 star networks covers most of the use cases I’m after as that should cover 100+ acres depending on terrain. Even if it’s hilly, generally speaking you have the top of 1 hill to strategically locate a LoRa mesh node to service most of the area. The consequence in all of this is the customer/user will have to “pick” which node/s are repeaters, open the cover to flip a switch and then strategically locate that node. Was initially hoping all could be configured to be repeaters and the system would still “be happy” but that is not the case short of a lot more development.

1 Like

It’s been awhile since I posted here… It’s been a busy month or two building, shipping devices as well as making other necessary updates in my backend/web app to accommodate this LoRa Sensor node configuration. Happy to report that several systems are now coming “online” and fully installed/commissioned by a non-tech savvy end user. Several of these are also making 1 or more hops to get back to the Particle LoRa Gateway. The few that’s been installed and operating to date has been 2-3 weeks and the nodes haven’t missed a beat yet reporting either every 5 minutes or 20 minutes. Or if they missed a beat it was only 1 beat and fell back inline the next 5 minute interval.

I also was able to bench test 50 nodes all communicating to 1 Particle LoRa Gateway. This was more of an extreme use case and I thought of it more of a smoke test to see if this method is scalable to larger installations and so far so good. Should be an interesting few months for me as more and more systems come online.

3 Likes