We operate large indoor venues with high footfall and are exploring UWB as a solution for locating specific individuals within these spaces. The core problem is that staff need to find pre booked visitors who may have moved from their expected location, in environments where GPS is unreliable.
The approach I’m considering is a network of fixed UWB anchors at key sites, with two ranging methods. A small UWB tag (lanyard or card form factor) issued to visitors who don’t have a compatible device, and direct phone to anchor ranging via Apple’s NI framework for those who do.
I’m also interested in the broader platform potential once anchors are deployed. Asset tracking for frequently misplaced equipment, and eventually leveraging DL-TDoA for indoor navigation to majority of visitors.
A few questions:
Is this a well suited use case for UWB, or are there gotchas I should be aware of for large, open indoor spaces with metal structures and high crowd density?
For the dual mode approach (tags + phone-based NI ranging from the same anchor), are there known limitations in running both concurrently?
Indoor localization is certainly one of the main use cases for UWB technology. Some of the key considerations would be the density of anchor deployment, number of tags, their update rate, and required accuracy.
The recommendation would be to employ a TDoA architecture and we have great partners who can help enable this including @mciholas (see CUWB Product Launch) and @leapslabs
Help me out with what “high footfall” means. Do you mean lots of people or something else?
How big is “large”? Do you have a ceiling or is it open air, or some in-between?
A large site, say football arena, without a ceiling, may create range issues. Our anchors and tags are all equipped with excellent antennas and LNA (low noise amplifier) to increase range. We tell customers we can go 100 m on channel 5, 70 m on channel 9, but in testing under ideal conditions we often go 50% further than that. In rough terms, the minimalist system would be anchors spaced every 50 m or so, and that would be a pretty marginal system. The site particulars, desired accuracy, and desired occlusion tolerance will determine what anchor density is required.
If you have a ceiling and can put anchors overhead, then we can cover any size. Our largest install is 140,000 m^2 warehouse, for example.
This is similar to the counter ordered but served restaurant case. Customer orders at the counter and then the server needs to find which table they sat at. Panera Bread “solved” this problem with a bunch of RFID readers under tables with RFID tag equipped flags, but that proved to be too cumbersome to maintain. A system based on UWB in the order flag would be better.
I believe at present, all the UWB capabilities built into phones won’t allow tracking by infrastructure. They are all designed for the phone to track some tag relative to itself. This is considered a security issue.
(I would love to find out my understanding is wrong here, I haven’t dug into this for a couple of years).
UWB is not a ubiquitous technology in phones in any case, only being in a fairly small number of high end phones. Latest numbers I’ve seen is that 82% of phones out there right now are not UWB equipped. So any solution is going to require consideration for the non UWB users. In that case, it probably makes sense to just forgo the phone UWB and concentrate on the tagged UWB.
There is a middle ground, which is a UWB tag that plugs into a cell phone, thus would work with basically all cell phones, UWB equipped or not. Our tags have a USB-C connection and can be plugged into and communicate with a cell phone. The cell phone can have the app while the tag can provide location and communication with the UWB network. This still has the complication of needing to plug it in.
A perhaps better idea is to associate the tag (by QR code, serial number, etc) to the cell phone and the association is made without a physical connection. This avoids any sort of complexity with regards to USB OTG permissions, plug compatibility, etc. This also means the UWB tag can be placed more nicely on the person and not attached to the cell phone.
There are a lot of ways to do this potentially, each with various pros and cons.
Once you have RTLS infrastructure, there are a lot of uses both for the visitors and for the operator. Item tracking, heat maps, path maps, security, emergency response, etc.
As for DL-TDoA, or what we call “nav mode” since it works like GPS, we built such a system that was installed in a museum in 2017 (9 years ago, how time flies). The anchors transmitted time codes not unlike GPS, and then tags did the location. This has two big advantages, namely there can be an infinite number of tags since they consume no air time, and the tags are not located by the system but only by the user for personal security.
One of my hopes for UWB in cell phones is that the OS opens up access to the UWB subsystem to the extent someone could write a nav mode (DL-TDoA) driver to allow cell phones to be tracked in infrastructure. Surely this is coming at some point?
That all being said, the CUWB system has very high capacity in standard TDoA mode (what we call “Multitime” whcih is really more of a ToA mode). We can support 3400 tags at 1 Hz, or 7800 tags at 0.5 Hz, or 34,000 tags at 0.1 Hz. it is hard to imagine you need more capacity than this.
Large open spaces are IDEAL for UWB. Whether the metal structures will cause issues depends on where they are and what they are. If this is just building structure, not something that gets between anchors and tags, then it is no factor. Radio reflective surfaces really screw up BLE and Wifi location but have essentially no effect on UWB location since UWB measures only the FIRST signal it gets, not the multipath echoes.
In any case, placing additional anchors can almost always deal with occlusions. Our location engine has very specific occlusion mitigation features to reduce this issue, too.
The greatest issue with tracking lots of people will not the be structures or building, but where you put the tag on the person and how it is occluded by that person and the people around them. Worst place: pocket, where cell phones go. Best places: top of head, head band, bill of cap, but these are usually impractical in public use cases. Good places: top of shoulders, nape of neck, wrist. So-so places: lanyard, badge clipped to front. If this is something they place on a table, like an order flag, then it will work great since it is away from the body occlusions.
At present, I don’t think you can locate UWB equipped phones by infrastructure.
The most reasonable present day approach is to issue tags associated with each person.
If you want to dive into the details of your application, you can set up a meeting with us and we can give you the expert feasibility assessment so you know what UWB can do and what it can’t.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA mikec@ciholas.com
Woah! Great response, thank you for taking the time to write that.
Yes at peak times the main areas will be packed with hundreds of people, and a select few who need extra requirements will make themselves known by ‘checking in’.
I completely take your point on compatibility. However, my research into the UK landscape shows a higher concentration of UWB ready devices due to the density of newer iPhones, Pixels and Samsungs. I believe every iPhone (except the SE/e line) have had UWB in them for the past 6-7 years.
I think for staff devices & those with non UWB capable devices, this would certainly be the direction we look into.
This dropped around October I think as a developer preview, alongside I think an android equivalent going into beta in the past couple of weeks. Stuff seems to be moving really fast! I assume this is what you meant?
"While your app is in the foreground, it can freely use Nearby Interaction to perform ranging between UWB devices. When the app moves to the background, it can perform UWB ranging only with devices that are Bluetooth Low Energy (LE)-paired and connected.
In iOS 18.4 and later, your app can continue ranging in the background with any supported device if the app starts a Live Activity as it goes to the background."
If the phone calculates its own position via UWB, can it transmit those coordinates back to the anchor via a BLE connection? The anchor would then act as a relay to a central server, completely bypassing the need for WiFi. Assuming iOS 18.4’s Live Activities keep both the UWB ranging and BLE return path alive in the background, this seems technically possible.
You have plenty of capacity with normal TDoA, so you don’t need DL-TDoA for capacity reasons. In our CUWB system, at 5 Hz, you could support 680 tags.
Maybe, but UWB has yet to reach the ubiquity that BLE has, for example. So whatever strategy you go for, you either deny service to the non UWB equipped cell phone owner, or you have a tag mechanism for them.
Basically yes.
There are several issues, both technical and political, to settle before DL-TDoA becomes a reality for UWB equipped cell phones.
The most serious is political, Apple in particular is into controlling technology for its benefit and there is no assurance that DL-TDoA will be made available to developers in a way they can actually use it. For example, the infrastructure Apple decides on may be proprietary to them, and not operate with Android, and vice versa. This then creates an incompatibility that makes supporting both Android UWB and Apple infrastructure at the time a problem.
On the technical side, we don’t yet have full details on how this will work, what limitations it will have, and what control the app will get.
I hope things work out, but I feel like we are some distance away. from this being really usable.
Two major problems:
First, you have hundreds of potential phones trying to locate at the same time and that will clog up the airspace such that you will get poor results. I don’t think the ranging function on iOS or Android is particularly airspace efficient.
Second, the BLE pairing will cause the “anchors” to be “captured” by the phones and thus not generally useful for all phones in the area.
Honestly, Wifi (or even cell data) is the logical back haul means for a phone to share its position. Every cell phone owner will already be on the internet anyway, whether you provide Wifi or not.
Honestly, I don’t think so. We looked into this for a prospective client about 2 years ago, they wanted to track the location of about 100 iPhones (no Android support) in an infrastructure with about 5 Hz location and our research said this was basically infeasible. The barriers Apple puts up are implacable and OS support of UWB simply didn’t allow for locating in that way.
Maybe things have changed in recent times, but I suspect not once you look through all the things that have to be in place.
I think our anchor array would make an awesome infrastructure to support DL-TDoA (nav mode), but the access to that ability is blocked for non technical reasons. We built our tags with enough compute power to do DL-TDoA inside them, and will support that mode at some point, but you want to support the cell phone directly.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA mikec@ciholas.com