Feasibility of Channel Sounding for Large Scale Indoor Asset Tracking

[SoldOutYungLean]

Hello,

I am considering the prospect of using channel sounding as opposed to UWB for indoor asset tracking.

I can understand, that the main limitation with that would be, that channel sounding is connection-oriented, meaning that each anchor/beacon would need an active connection with each of the tags in its vicinity. Which, if you scale the system to 500 tags per beacon, is not at all possible.

My question is; Are there any actively implemented workarounds around this?

If not, do you have any thoughts as to the viability of this plan:

Instead of keeping the connection with every tag, the beacon connects with a tag, calculates distances and then it removes the connection. Maybe it can keep 300 or so of the tags in its contact book as a sort of cache, but essentially the idea is to just drop the connection every time it has connected with a tag.

My main concern with this would be the power usage of the tags. Are there any other factors I should consider?

[Elfving]

Hi Benjamin, 

I have to mention that direction finding is also a typical protocol for indoor locationing, which you can also do connectionless which means that it is also very scalable. Though perfecting an angle algorithm can be time-consuming. 

My question is; Are there any actively implemented workarounds around this?

There aren't any that I have heard of myself, though what you are thinking of does sound like a plan. You could for instance use a PAwR network for the communication, which is low power (no pun intended). And if a certain node is being polled to provide another distance estimation, or if it is being moved (which can be measured by an accelerometer), it can enter a connection in order to get a new distance estimation. 

I'm just trying to be creative here, but I think variations of something like this could work. One question is the scale though, what do you mean by Large scale exactly?

Regards,

Elfving

[SoldOutYungLean]

Hello Elfving,

Thank you very much for your quick reply!

If by direction finding you're referring to stuff like AoA, then the issue is, the cost of and - as you mentioned - complexity of developing a beacon, which can convert the angles into distance.

As for what I mean by "large scale," I mean the potential for 1000 tags for the same beacon, with a typical use case being in the 100's per beacon.a

Finally, I forgot to ask, do you have any clue on the accuracy of positioning with channel sounding? I can see that the accuracy in ranging is in cm, but what kinds of positioning accuracies does that lend itself to? I get that the positioning is an extra layer/algorithm added on top of the ranging, and so if UWB and BLE channel sounding have the same ranging accuracies they should have the same positioning accuracies, but is there anything else I need to consider that might alter this assumption?

[Elfving]

SoldOutYungLean said:

As for what I mean by "large scale," I mean the potential for 1000 tags for the same beacon, with a typical use case being in the 100's per beacon.a

I see. So not in "physical scale" then, which I was more afraid of. 

SoldOutYungLean said:

Finally, I forgot to ask, do you have any clue on the accuracy of positioning with channel sounding?

It is hard to say, because it also depends a bit on what you want to do with the algorithm. You can simply try the samples yourself, though the accuracy you get from those are not that good (like the documentation of the samples also almost urgently seem to mention: "The accuracy is not representative for Channel Sounding and should be replaced if accuracy is important.").

The technology used in channel sounding is a bit similar to what we used in the proprietary "nordic distance toolbox" though, you might be able to get a certain ballpark figure/understanding of the accuracy from this presentation about that.

SoldOutYungLean said:

and so if UWB and BLE channel sounding have the same ranging accuracies

They definitely do not, BLE is unfortunately worse when it comes to accuracy for ranging. But it's cheaper. If high accuracy is important, and cost is not, then I can't really recommend BLE for this. You could use an nRF alongside a chip for UWB though.

Regards,

Elfving

[SoldOutYungLean]

Elfving said:

I see. So not in "physical scale" then, which I was more afraid of. 

Well, it would also be in a physical sense.

The original idea was to have a UWB module with an nrf54 as the host processor (H series for the beacons, L series for the tags), which will use BLE channel sounding exactly, when the tags are out of range with UWB, but in range with BLE. And possibly also as a kind of sensor fusion thing between the UWB and the BLE.

Also thanks for the suggestions and honesty. We already plan on using an nRF54 (possibly 52 if channel sounding serves no purpose) as the host processor and an UWB module for the actual ranging. We just wanted to investigate the possibility of completely cutting out the UWB in order to cut costs.

[Elfving]

SoldOutYungLean said:

The original idea was to have a UWB module with an nrf54 as the host processor (H series for the beacons, L series for the tags), which will use BLE channel sounding exactly, when the tags are out of range with UWB, but in range with BLE. And possibly also as a kind of sensor fusion thing between the UWB and the BLE.

That sounds promising. 

SoldOutYungLean said:

Well, it would also be in a physical sense.

I was just concerned about the BLE range. With low power also being need, there aren't that many options. I guess this also depends on data throughput etc.

SoldOutYungLean said:

Also thanks for the suggestions and honesty. We already plan on using an nRF54 (possibly 52 if channel sounding serves no purpose) as the host processor and an UWB module for the actual ranging. We just wanted to investigate the possibility of completely cutting out the UWB in order to cut costs.

Understood. If UWB does everything else you need it to regarding range etc, then I agree that it sounds like the best option.

Regards,

Elfving