APD001 - CUWB Operational Modes

The Ciholas Ultra-Wideband (CUWB) Real-Time Location System (RTLS) can operate in two fundamentally different operational modes: MultiRange™, and MultiTime™. Each mode provides users with low-latency location data output and can be used for large scale deployments. This document describes the pros and cons that a user should consider when selecting each mode.

This document references a variety of components and tools within the CUWB RTLS. An overview of those features, along with diagrams detailing how individual components connect together, can be found in the CUWB System Architecture document.

Feature Overview

MultiRange:

MultiRange utilizes ranging beacons between each tag and multiple anchors to produce location data. CUWBNets configured for MultiRange have the following characteristics:

• Work with fewer anchors
• Tolerant to survey error
• 150 Locations Per Second (LPS) in single coverage area
• Spatially diverse tags can beacon at the same time increasing overall LPS
• CUWB Engine uses Two-Way Ranging (TWR) between tags and anchors
• Scalable to large installations
• Requires less survey accuracy, good for lower accuracy installations
• Anchors do not need to be in range of other anchors. UWB coverage areas can be ‘disconnected’

Recommended Use Cases:

• Quick setup/teardown where time is limited for survey
• Small deployments with limited tags and anchors
• Disconnected areas where anchors can not be in UWB range of each other

MultiTime:

MultiTime utilizes timing beacons between each tag and an anchor array to produce location data. CUWBNets configured for MultiTime have the following characteristics:

• Higher LPS rates, up to 3300, in single coverage area
• Scalable to large installations with high beacon rate tags
• CUWB Engine uses tag Time-of-Arrival (ToA) data recorded by the anchors
• Requires anchors to be in range of other anchors for time synchronization
• Tolerant to Line-of-Sight (LoS) occlusions between tag and anchors
• Added anchors improve CUWB System location precision and accuracy

Recommended Use Cases:

• High performance systems; high accuracy, low-latency, high LPS
• Large scale, large coverage area, applications
• Fast beacon rate installations >50Hz per tag
• Enterprise or commercial installations

MultiRange™ vs MultiTime™

Timing and Schedule

A primary difference between CUWBNets configured for MultiTime and MultiRange operation is the handling of UWB airtime. UWB transmissions, like any RF transmission, experience lost or dropped data due to air-time interference, e.g., two devices transmitting at the same time. It is important to understand how tag beacons are scheduled and how much air-time each beacon occupies. When using MultiTime, beacons are fixed to a schedule that is provided to the tags by the CUWB Engine. Conversely, MultiRange tags are NOT given a schedule and are allowed to beacon freely.

Timing and Schedule - MultiTime

The following image shows a simplified version of a typical MultiTime schedule based on a nominal 10Hz tag beacon rate¹.

To join a MultiTime system, a tag first listens over UWB to discover if any CUWBNets are active in the area. Once the tag detects UWB activity from a CUWBNet configured for MultiTime, it will send a UWB packet to announce its presence. Having announced, the tag will then listen for a UWB command message defining the tags beacon schedule.

Timing in a MultiTime system is fully scheduled. This avoids UWB airtime conflicts and enables extremely high LPS Rates.

In the diagram below, all of the anchors are within UWB range of at least four other anchors. Any anchor that cannot hear UWB packets from other anchors will be unable to synchronize and thus unable to be used for scheduling or location calculations.

The timing and schedule requirements for MultiTime systems require anchors to be synchronized. The synchronization process is handled by the CUWB Engine which keeps a time model for all anchors in the anchor array. Anchor time models are synchronized into a unified model representing time across the array. This careful process of scheduling and time synchronization necessitates that all anchors must be within UWB communication range of at least one other anchor in the Anchor Array. Anchors with more LoS connections to neighboring anchors will have more stable and accurate time synchronization.

MultiTime anchors MUST be within range of at least one other synchronized anchor.

The process for a tag joining the CUWBNet above requires that anchors advertise network time via repeated UWB packets containing the current network time. This repeated transmission allows the tags to both announce and beacon at the proper scheduled time.

Timing and Schedule - MultiRange

In a CUWBNet configured for MultiRange, each tag maintains its own beacon schedule, hitting the desired beacon rate and jittering transmissions to avoid UWB airtime conflicts. The following image shows a simplified version of a typical MultiRange schedule based on a nominal 10Hz tag beacon rate¹.

There is no central scheduling in a MultiRange system; timing is governed by the tags.

To join a MultiRange system, a tag first listens over UWB to discover if any CUWBNets are active in the area. Once the tag detects an active CUWBNet configured for MultiRange, the tag recognizes that it may beacon at any time. The tag sends a packet over UWB to announce its presence and waits a predetermined time for a response containing CUWBNet parameters such as its nominal beacon rate. The tag is now free to beacon at any time matching the desired rate.

As tags beacon, there is potential for the transmissions to collide with other tags. Collisions result in lost or dropped packets and reduce the overall system capacity.

The method described above for MultiRange beacon scheduling is often called Aloha. Studies have shown that typical throughput for an aloha based system is roughly 1/3 of the available airtime.

MultiRange systems have lower LPS due to aloha beaconing and longer beacon periods. However, because MultiRange CUWBNets are unscheduled, it becomes possible for anchors to be placed outside of UWB range of one another and continue to work. The diagram below shows groupings of anchors that are outside of UWB range of one another.

Tag Beacons

In both operational modes, MultiTime and MultiRange, tags transmit beacons that are timestamped by anchors and sent to the CUWB Engine for determination of the tag position. Beacons between the two operational modes look quite different and are used differently by the CUWB Engine.

Ranging Beacon - MultiRange

The diagram below shows a timing breakdown for a well-known algorithm Two-Way Ranging (TWR) typically used to measure distances between two UWB devices:

Ciholas MultiRange uses an algorithm similar to TWR to calculate the distance between the tag and a selection of anchors. However, unlike TWR, the Ciholas Ranging algorithm implements a proprietary Asymmetric TWR (ATWR) enabling multiple anchors to respond during a single beacon, shown in the following diagram:

Asymmetric TWR removes the requirement for the delays between transmissions to be equal.

This algorithm improvement allows for multiple anchors to respond to the initial beacon start packet. In a typical Symmetric TWR system, each range measured between an anchor and tag requires 3 packets. Ranging to 8 anchors would take 24 transmissions and waste a lot of UWB airtime. ATWR can range to 8 anchors using only 10 transmissions. The algorithm collects the following timestamps from each beacon, as shown in the diagram above:

1. Tag UWB Transmit Timestamp (START_TX)
2. Anchor[1..N] UWB Receive Timestamps (START_RX)
3. Anchor[1..N] UWB Transmit Timestamps (STAMP_TX)
4. Tag UWB Receive Timestamps [1..N] for each anchor (STAMP_RX)
5. Tag UWB Transmit Timestamp (END_TX)²
6. Anchor[1..N] UWB Receive Timestamps (END_RX)

Each beacon in a MultiRange system requires multiple transmissions and thus takes up more UWB airtime. This, in addition to the aloha collision rate limitations, limits the number of LPS available with using MultiRange mode.

Timing Beacon - MultiTime

In a MultiTime setup, the tag beacon is a single transmission from the tag that is received by the anchors. The tag joins the CUWBNet and understands its nominal scheduled beacon time based on the scheme laid out in Tag Timing and Schedule above.

Anchors in the vicinity of a tag will hear each UWB beacon and forward the received timestamp information to the CUWB Engine. The data collected at the anchors from a single beacon generates enough timestamp data to locate the tag. The length of the beacon is limited only by the time it takes to send a single transmission.

MultiTime inherently has a high LPS because a large number of tag beacon transmissions can fit within a single second.

Location Calculation

Above, we discuss ranging beacons used in MultiRange and timing beacons used in MultiTime. Each beacon style comes with its own pros and cons with regard to the timing discussed above, and the same is true with regard to the location calculation done by the CUWB Engine.

Time-of-Arrival Location Data - MultiTime

The MultiTime timing beacon data consists of UWB receive Time-of-Arrival (ToA) timestamps collected by a large number of anchors. In traditional UWB systems used by competitors, the ToA data is compared for each anchor pair, generating Time-Difference-of-Arrival (TDoA) data that is fed through a Multilateration algorithm. The traditional multilateration approach requires exactly four sets of TDoA data (five ToA timestamps). If there are fewer than four TDOA pairs, then no output location can be computed. If there are more than four pairs, the equations are over-determined. Systems that use multilateration must either throw away data or have a secondary process to handle overdetermined output with multiple potential output locations.

The CUWB Engine generates a best-fit answer by taking into account all of the ToA data from a MultiTime beacon. Whether there are 4 anchors or 100 anchors, the CUWB Engine will use all of the data and generate the best possible answer to fit the data. In situations where users require more precision, it becomes possible to add anchors and improve the overall location performance.

Time-of-Arrival Location Data - MultiRange

MultiRange beacons are used slightly differently by the CUWB Engine. The first step the CUWB Engine takes with MultiRange beacon data is to run the ATWR algorithm described in the Ranging Beacon section above. The output result is a set of ranges, or distances, between the tag and the anchors that responded to the beacon START_TX. Traditional systems that use TWR between the tag and the anchors will use trilateration to generate an output location relative to the anchors. The traditional trilateration approach requires exactly three sets of range data. If there are fewer than three range measurements, then no location can be computed. If there are more than three range measurements, the equations are over-determined.

The CUWB Engine generates a best-fit answer taking into account all of the range data from a MultiRange ranging beacon. Whether there are 3 anchors or 12, the CUWB Engine will use all of the data. The number of responding anchors can be configured in the CUWB Manager and is limited based on timing requirements.

The MultiRange limit to the number of anchors responding necessarily limits the benefit of adding anchors in a single area to improve location performance.

Regardless of MultiTime or MultiRange setup, the CUWB Engine always generates a best-fit answer using ALL of the data provided. More anchor data results in better location performance.

Incorporating Receive Signal Quality Information

MultiRange and MultiTime beacon data include receive signal strength indication (RSSI) for each transmission. The RSSI data for each beacon is forwarded along with the timestamp information to the CUWB Engine. The CUWB Engine uses the RSSI data to weight each beacon, resulting in a more accurate output location. For example, a MultiTime beacon may result in 50 ToA timestamps where the RSSI information indicates that 20 of those timestamps have a 90% probability of being LoS and 30 of the timestamps have 50% or less. In this scenario, the weak beacon data is de-weighted by the CUWB Engine and the ‘best-fit’ answer is biased toward the good LoS data.

The CUWB Engine weights beacon data based on RSSI for each timestamp, resulting in a more accurate output location.

Survey Considerations

MultiTime CUWBNet configurations require a more careful survey than MultiRange configurations. A MultiRange setup with a large baseline for the anchors will provide reasonably precise output with survey error ±0.2 meters. The same setup in MultiTime might require a survey error of less than ±0.05 meters in order to synchronize and operate properly.

These differences are due to the inherent nature of using range data versus ToA. Small errors in ToA can result in large changes in the potential output solutions computed by the CUWB Engine. Users should always strive for the best survey accuracy possible, the CUWB Engine output cannot correct for survey error. CUWBNets that operate with survey error will provide distorted results consistent with the input error.

Always strive for accuracy when surveying anchors. Bad data input will result in bad data output.

Spatial Reuse

“Spatial Reuse” is defined as the ability for two devices to transmit over UWB at the same time based on their location in space. Two tags that are located far apart from one another will not interfere with each other if they are outside of each other’s UWB range. The CUWB System takes advantage of this by default when configured to use MultiRange mode.

In MultiRange, the tags inherently realize spatial reuse. Tags maintain their own schedule, beaconing using an aloha style algorithm. Any tags that are separated by distances greater than their maximum UWB range will not interfere with one another when they happen to transmit at the same time.

MultiRange configurations inherently realize spatial reuse because there is no global schedule. Two tags in disparate areas will not interfere with each other when they transmit at the same time.

Practically, this means that when considering maximum LPS rates for MultiRange systems, users should consider the maximum number of tags they can have ‘per area’. If a user has determined that they can have 50 tags before they hit the nominal maximum LPS threshold in MultiRange, it means they can have 50 tags in a given region or area. If they have a large, spread out, tracking area, then they will realize LPS rates greater than the aerial maximum.

Battery Considerations

The CUWB 300 series tag hardware has low-power usage and long battery life. When configuring both MultiTime and MultiRange systems, user settings can impact overall battery performance. For example, any tag configured to beacon at 100Hz will use significantly more power than a tag configured for 10Hz.

It is important to balance location output performance with tag beacon rate. Excess location data doesn’t help if tags lose power too quickly.

CUWBNets configured for MultiRange should also carefully consider the number of anchors that are configured as responders to the tag START_TX packet. After each tag beacon, the tag must stay awake listening for all of the anchor responses, regardless of whether or not the anchors transmit. More response slots configured in the system will result in higher average tag power usage.

A user with only 6 anchors in their system should consider reducing the number of anchor response slots from the default of 8, down to 6. Doing so will save tag power and increase overall battery life.

Capacity Calculations

The following sections describe two capacity related calculations that users will find helpful when planning and setting up CUWB Systems: Locations Per Second, and maximum tag count per role.

Locations Per Second, or LPS, is a measure of the total CUWBNets maximum beacon capacity after taking into account airtime lost to non-beacon transmissions like commands and anchor synchronization packets. The LPS Calculations below are close approximations³ based on parameters provided by the user.

Tag Count is a measure of the maximum number of tags that can be assigned to a given tag role. The equation requires a few parameters from the user, and does not take into account other tag roles. The output is a close approximation³ of the total tags that could be assigned to a given role configuration if it is the only role used. The Max Tag Calculator in the CUWB Manager will provide a max tag count for the requested role taking into consideration all currently assigned tags and schedule time.

The equations provided in the section below use a variety of parameters that are configured, and can be found, in the CUWB Manager. This table provides a brief description of those parameters:

Mode	Parameter	Description
MultiRange, MultiTime	$NTags_{role}$	Number of Tags Configured for a given role
MultiRange, MultiTime	$rate_{role}$	Beacon Rate Configured for a given role
MultiRange, MultiTime	$bytes_{userdata}$	Overhead bytes configured to allow UWB airtime for extra data
MultiRange	$anchor_{count}$	Total number of anchors configured to respond to a ranging beacon. Default is 8
MultiTime	$Nanchors$	Total number of anchors in the CUWB Configuration
MultiTime	$rate_{seeder}$	Rate at which seeders are configured to transmit timing beacons
MultiTime	$command_{rate}$	Rate at which UWB commands packets are scheduled within the CUWBNet
MultiTime	$announce_{rate}$	Rate at which announce window are scheduled within the CUWBNet
MultiTime	$seeder_{count}$	Total number of anchors configured as seeders

LPS - MultiRange

To approximate the LPS for a MultiRange configuration, use the following formula:

$$LPS_{MultiRange} \approx \sum_{role} (Ntags_{role} \cdot rate_{role})$$ $$LPS_{MultiRange} \le 150$$

This LPS calculation provides a good estimate³ for users to determine if their system settings meet the requirements of the operational mode.

Given the aloha nature of MultiRange configurations, users should expect periodic collisions even when below the nominal maximum number of tags. The CUWB Engine output location performance will degrade when the recommended LPS is exceeded in an area. However, the output location data will continue to be delivered. As collisions rise RTLS data is delivered more slowly with less accuracy. It is possible to greatly exceed the LPS rating in an area by adding more tags and still maintain usable location data.

System performance in MultiRange degrades gracefully when the LPS in an area is exceeded.

LPS - MultiTime

To approximate the LPS for a MultiTime configuration, use the following formula:

$$LPS_{MultiTime} \approx (Nanchors \cdot rate_{seeder}) + \sum_{role} (Ntags_{role} \cdot rate_{role})$$ $$LPS_{MultiTime} \le 3300$$

This LPS calculation provides a good estimate³ for users to determine if their system settings meet the requirements of the operational mode. The $LPS_{MultiTime}$ approximation factors in anchor airtime, removing it from the overall airtime available for timing beacons.

Max Tags Per Count Role - MultiRange

To approximate³ the maximum number of tags that can be configured for a given role, use the following formula:

$$Tag_{count} \approx \left\lfloor \frac{150}{tag_{rolerate} \times (1+(0.01 \times bytes_{userdata})) \times \frac{anchor_{count}}{8}} \right\rfloor$$

To determine exact maximum available tag counts users should create CUWB Configurations in the CUWB Manager, then use the Max Tag Calculator utility.

Max Tags Count Per Role - MultiTime

To approximate the maximum number of tags that can be configured for a given role, use the following formula:

$$Tag_{count} \approx \left\lfloor \frac {3300-(2 \times command_{rate})-(2 \times announce_{rate})-(10 \times seeder_{count})}{ (1+(0.01 \times bytes_{userdata}))} \right\rfloor$$

To determine exact maximum available tag counts users should create CUWB Configurations in the CUWB Manager, then use the Max Tag Calculator utility.

Capacity Examples

The following tables demonstrate a few possible configurations along with the theoretical maximum number of tags that could participate in the given configuration.

MultiRange Configurations

Anchors Per TX	Tag Rate	User Data (Bytes)	Maximum Tags
8	1	0	150
8	5	0	30
8	10	0	15
8	20	0	7

MultiTime Configurations

Calculated for a CUWBNet with one tag role configured for 10Hz beacon rate, and default 10Hz Seeder, Command, and Announce Rates

Number of Seeders	User Data Bytes	Maximum Tags
6	0	330
25	0	311
100	0	236

Calculated for a CUWBNet with one tag role configured for 100Hz beacon rate, default 10Hz Seeder, Command, and Announce Rates

Number of Seeders	User Data Bytes	Maximum Tags
6	0	33
100	0	23

Revision

Version	Date	Change Description
5.0.0	2025-09-15	Initial Preliminary Release