Hello everyone, I want to use dwm1001 to do many to many ranging. If there are 100 nodes, any two nodes with a distance less than 2m will give an alarm. Use c-api, what’s your good plan?
100 nodes means 99+98+97+…+2+1 = 500 ranges to measure.
So if you use a TWR protocol you should be able to an update rate of at least 1 Hz on each range. You will however need a robust method to ensure that each node knows when it’s their turn to transmit or collisions will ruin the system.
And doing this all in a power efficient way gets tricky.
Also keep in mind that anything body mounted is going to give incorrect measurements if there is a body between the two antennas.
So if you mount it on the top of a hat it’ll work well. If you mount it on a belt then you will have somewhere between 180 and 270 degree coverage. With 270 degree coverage you have a 44% chance that the direct path will be blocked and your measurement will come out too high. With 180 degree coverage that increases to 75%.
If you look on this board there are lots of discussions on how to implement this sort of system. By limiting it to 100 nodes you’ve avoided one of the big theoretical problems of how to scale it but that still leaves some tricky engineering and design issues.
It’s the sort of thing it’s easy to build a proof of concept of but tricky to make a system that actually works well in the real world.
100 nodes have 4,950 possible pair ranges to measure.
r = (1/2)n(n-1)
r = number of pair ranges
n = number of nodes
Not possible, even with time slotting to a global time reference. You either have to reduce the number of nodes, or increase the measurement interval.
An extremely difficult problem if you don’t allow for an outside reference or infrastructure. A time slotted self organizing mesh where the nodes have incomplete and sometimes disjoint connectivity is basically impossible otherwise. PhD thesis are written about this sort of problem.
Extremely so. The fundamental issue is that nodes have to listen all the time to hear other nodes given no time slotting. That kills battery life.
At 100 nodes, you are deep into the problems of scalability and battery life. Limiting it to 10 to 20 nodes would help a lot, but the system is pretty crippled at that point, and you still have to issues of power and body occlusions.
Very much so. This is an extremely complex problem that appears simple at the start, leading to a large number of enthusiastic people attempting it.
The only two viable systems are either very limited small scale systems, or systems with infrastructure. Scalable no infrastructure systems are simply not practical.
Meanwhile, a system with infrastructure solves all three problems of scalability, battery life, and body occlusion but introduces the major hurdle of installation and cost.
This is not an easy problem. If it was easy to do, it would have been done already.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408
1 Like
My bad. Clearly a lack of coffee moment. The sum I wrote out is going to come out around 5000 not 500.
Agreed, with 10 times more ranges to measure you’re going to need 10 times longer. So around a 10 s update rate. Which is low enough that you’ll miss people walking past each other unless they are moving slowly even if you didn’t have to worry about blocked signals.
It would be possible to go a bit faster but that’s a reasonable ballpark number.
I suggest a combined solution - UWB + BLE.
BLE is used for discovering neighbors and rough distance estimation, then for BLE distances say less than 4m use UWB to measure the distance more precisely.
If I got correctly that this is a social distancing application - even 10s update rate is not an issue. Battery lifetime indeed is very critical.
Still a lot of R&D work to do.
Any code example that can help me? Im also working in a social distancing application.