Overview

This reference manual provides users with detailed feature descriptions and in-depth settings guidance for the CUWB Manager. For detail on individual settings, page descriptions, and general CUWB Manager information see the CUWB Manager Manual

This CUWB Manager Reference Guide is only for v5.0 CUWB Manager Version. The v5.0 CUWB Manager Version and Reference Guide is compatible with 300 series devices and is not compatible with older databases or legacy Ciholas hardware. Legacy documentation is available in our legacy area.

Background

Successful operation and tuning of any CUWB system takes careful setup and planning. This document dives into detail regarding a few common top level features. It may be helpful to have these other documents available:

Persistent Properties

Persistent property modification is for expert users only. These properties will override device default settings and can lead to adverse RTLS behavior.

Persistent properties are settings that are stored, and persist, locally on the tag and anchor hardware. Persistent properties allow users to change device behavior that is specific to the hardware. Many of the available persistent properties impact behaviors that cannot be controlled by a CUWBNet, like off-network search, because no CUWBNet is running.

Firmware updates do not overwrite persistent properties.

Setting a Persistent Property

Persistent properties are set in the Device Manager tab. See Persistent Property Configuration for instructions.

Devices must be hard reset for persistent property changes to take effect.

CUWBNets must be running to set a persistent property. Devices need to be participating in the CUWBNet or devices need to use a wired connection.

RF Agility & Search Expert Settings

Expert users can configure devices to use one custom search / RF agility channel via persistent properties. The custom channel setting replaces the Default Channel settings.

When persistent properties are used, devices search for CUWBNets using the persistent property configuration and the recovery channel when not participating in a CUWBNet.

To modify the persistent property, use the Device Manager. See 0x0064 Search Buckets in the Persistent Properties Appendix for details on setting options.

Wake-on-Shake Search Expert Settings

The Search Motion threshold and Timeout for Wake-on-Shake CUWBNet Search can be configured via persistent properties. This feature can also be disabled via persistent property updates. The persistent property is described in 0x40b0 Wake-On-Shake in the Persistent Properties Appendix.

LED Intensity Settings

The LED Intensity persistent property allows the LED intensity state to be retained while a device is not participating in a CUWBNet. The Intensity can be set to either On (100%) or Off (0%). The persistent property is described in 0x4083 LED Intensity in the Persistent Properties Appendix.

Turning off the LEDs may cause confusion about devices being functional. Use with caution.

Settings Keys

Settings keys are special expert user keys for the CUWB Manager that enable unique features or specialized settings. These can be added to any configuration when using expert mode. The three key types are: Device, Role, and System.

• Device - Settings keys that are added on a per device basis.
• Role - Settings keys that are added on a per role basis.
• System - Settings keys that are added at the system configuration basis.

Some Role and System Settings Keys duplicate functionality of the CUWB Manager UI. These are marked in each relevant entry in the Settings Key Appendix.

Priority

When a device is participating in a CUWBNet:

The devices will follow this priority order for settings, where lower numbers indicate priority:

1. Device Settings Keys
2. Role Settings Keys
3. System Settings Keys
4. Persistent Properties
5. Firmware

When a device is not participating in a CUWBNet:

The devices will follow this priority order for settings:

1. Persistent Properties
2. Firmware

LED Control

The LEDs on CUWB devices can be configured in a variety of ways. There are two main parameters of the LEDs: LED Pattern and LED Brightness.

LED Pattern

LED Pattern settings are only available in MultiTime mode.

The LED Pattern dropdown in the Configuration -> General tab of the CUWB Manager sets the device LED pattern when participating in that particular CUWBNet. This can be set to Role or Device. This setting is also available as a system setting key: led_mode.

• When set to Role, all devices will follow the defined LED pattern for their assigned role.
• When set to Device, all devices will follow the pre-defined firmware behaviors listed in the respective device datasheets.

Pattern Priorities

The LED Pattern will follow this priority order:

1. Error Codes
2. LED Identification
3. Charging Behaviors (if applicable)
4. Role Mode
5. Device Mode (Firmware)

This priority list is independent from the Brightness priorities.

LED Brightness

The LED Brightness sets the intensity of the LEDs. This is based on an intensity percentage, with 0% being Off and 100% being On. This can be set on a per role basis in the CUWB Configuration on the Configuration -> Schedules tab or by the LED Intensity persistent property.

Device firmware defaults the LED Brightness to On or 100% intensity.

Brightness Priorities

The LED Brightness will follow this priority order:

1. CUWB Configuration Setting
2. Persistent Property
3. Device Firmware

This priority list is independent from the Pattern priorities.

Pattern & Brightness Interaction

Error Codes and LED Identification will always be at 100% intensity (or On) regardless of the Brightness setting. These two LED functions cannot be disabled.

If a device is using role mode, it will flash the role pattern at the LED Brightness setting. By default, that would be at 100% intensity. However, if a user additionally configures devices to use 0% intensity (aka Off), the role pattern will flash at 0% intensity and not be visible.

LED Functions

• Error Codes: Device errors codes will vary. Each datasheet contains an LED error code table that outlines the various applicable codes. Datasheets for devices can be found under the Products sidebar.
• LED Identification: The CUWB Manager can send out special identification commands to help identify devices in the environment. Options include setting a solid color, a flashing color, or using serial number flash. Additional details can be found in the LED Identification section of the CUWB Manager.
• Device Charging: If devices support battery charging, the LED is able to provide the user with battery charge state while charging. See datasheets for specific charging LED patterns and timing.
• Role Indication: Devices that are using Role mode will flash their LEDs in the Role Mode Pattern.
• Device Indication: Devices that are using Device mode will enable their LEDs in their respective device modes. These modes can be found in their datasheets.

Radio Frequency (RF) Agility

Tags and Anchors support Radio Frequency (RF) Agility, which allows them to switch between predefined RF settings. RF Agility allows users to operate multiple overlapping UWB networks or change UWB frequency to avoid interference with other systems.

RF settings consist of three components: UWB Channel, Pulse Repetition Frequency (PRF) and Preamble Code.

The following combinations are supported on Series 300 hardware:

Not all RF settings are available to all users. Countries have varying regulations and requirements for use. Verify local regulatory requirements prior to use.

RF Agility Enabled Behavior

By default, this feature is enabled on devices and is configured as follows:

• Default Channel A: Channel 5 PRF64 Preamble Code 11¹
• Default Channel B: Channel 9 PRF64 Preamble Code 11
• Recovery Channel: Channel 9 PRF64 Preamble Code 11

^{1. Available only in select regulatory jurisdictions.}

RF agility uses the timing patterns defined in CUWBNet Search.

When a CUWBNet is running:

Devices will discover and attempt to participate in the first CUWBNet they hear from on their default channels or the recovery channel.

• If a Tag is configured for multiple CUWBNets, then it will join whichever CUWBNet is heard first.
• If a Tag is only configured for one CUWBNet but is in range of multiple CUWBNets, then the Tag will get pushed to the CUWBNet that it is configured for, even if the Tag hears the CUWBNet that it does not belong to first.

Anchors can only be configured for one running CUWBNet at a time. When Anchors are participating in a CUWBNet, they will use the RF settings defined in the CUWB Configuration under RF Settings.

Large systems with multiple Host PCs to run multiple CUWBNets require all Host PCs to be on the same Anchor Network. See Networking Guide for additional information on Network Configuration.

When a CUWBNet isn’t running:

The Recovery Channel provides the ability to recover devices if the RF settings are modified in the device’s persistent properties. Devices periodically (once every 640 seconds) listen on the Recovery Channel. Devices will either attempt to join a new CUWBNet or continue to search for a CUWBNet if there are no active CUWBNets in the area.

Devices search RF setting sets in this order: Default A ->Default B -> Recovery.

Additionally, devices that support Wake-on-Shake Search will follow the CUWBNet search behavior described in Wake-on-Shake. Wake-on-Shake Search is enabled by default for supported devices.

If Wake-on-Shake Search is disabled, the Tags will revert to the CUWBNet Search Default Behavior.

RF Agility Disabled Behavior

RF Agility cannot be disabled, the Recovery Channel search settings are always present and cannot be removed.

Adjusting Settings for RF Agility

RF Agility parameters for Anchors are modified via the RF settings the CUWB Configuration is the drop down menu on the Configuration -> General tab.

By Default, Tags will only be able to join the CUWBNet if the CUWBNet’s RF Setting matches one of the RF agility default channels or recovery channel. Tag’s RF Settings can be modified by Persistent Properties, described in 0x0064 Search Buckets of the Persistent Properties Appendix.

CUWBNets must be stopped before the CUWBNet RF settings can be modified.

Expert users can configure devices to use one custom search / RF agility channel via persistent properties if the Default Channel settings are not desired. The custom channel setting will replace the Default A and Default B channel settings.

CUWBNets must be running to set a persistent property or the device needs to use a wired connection.

CUWBNet Search

Devices discover available CUWBNets to join via a feature called CUWBNet Search. Devices will scan several RF setting sets to find CUWBNets. Tags can participate in more than one CUWBNet on different RF settings. However, tags cannot simultaneously participate in multiple CUWBNets. This feature is only used when a device is not actively participating in a CUWBNet.

CUWBNet Search impacts battery life when not participating in a running CUWBNet. Additional RF search settings require more power, reducing battery life.

CUWBNet Search Default Behavior

This feature takes advantage of RF agility to search for CUWBNets. By default, tags have the following RF search setting sets:

• Default Channel A: Channel 5 PRF64 Preamble Code 11¹
• Default Channel B: Channel 9 PRF64 Preamble Code 11
• Recovery Channel: Channel 9 PRF64 Preamble Code 11

^{1. Only available in select regulatory jurisdictions.}

For every programmed default or additional RF setting set, the tag will use the following pattern to search for CUWBNets:

Once a device hits the 640 second period, the device will remain in that state until it finds a CUWBNet that it can join or battery power runs low. This provides a balance between conserving battery life and being able to quickly rejoin CUWBNets.

Recovery Channel

The Recovery Channel is unique and devices will search every 640 seconds on the Recovery Channel Settings. This occurs regardless of whether the device is using the default behavior or the wake-on-shake feature.

CUWBNet Search & Wake-on-Shake Search Behavior

The above default behavior is impacted by using the Wake-on-Shake feature:

See the Wake-on-Shake CUWBNet Search feature for additional details.

CUWBNet Search Disabled Behavior

This feature cannot be disabled. The tags and anchors will search for a CUWBNet.

Devices that are in ship mode will not search for CUWBNets.

Adjusting Settings for CUWBNet Search

These default settings are pre-programmed and not user adjustable via the CUWB Manager.

Wake-on-Shake

Wake-on-Shake (WoS), for CUWB devices, is a combination of two different settings: Wake-on-Shake CUWBNet Search and Wake-on-Shake CUWBNet Leave. Below is a flow chart outlining the various state interactions.

Search Pattern Table for N¹:

_{1. This search pattern is the same pattern that devices use when searching for a CUWBNet without WoS features enabled. See CUWBNet Search Default Behavior for non-WoS search behaviors}

Wake-on-Shake CUWBNet Search

Tags support Wake-on-Shake CUWBNet Search. This feature allows a tag to sleep between searches for CUWBNets, and allows tags to quickly rejoin a CUWBNet when no longer participating in a CUWBNet. After a tag is motionless for a preconfigured amount of time, the tag will enter a sleep mode and periodically wake to search for a CUWBNet.

Wake-on-Shake CUWBNet Search Enabled Behavior

By default, this feature is enabled on tags with the following settings:

Motion & Timeout Threshold

_{1. Motion is given in milligravities.}

Devices are preconfigured to wake from a reasonable movement. They will then search for CUWBNets until there are 30 consecutive seconds of no movement.

Search Timing

Wake-on-Shake CUWBNet Search Disabled Behavior

Wake-on-Shake CUWBNet Search may be disabled, by setting either the Search Threshold or Search Timeout to zero. If disabled, the tag will utilize the default CUWBNet Search behavior.

Powered Devices & Wake-on-Shake Search

This feature can be used while a tag is powered via USB. The following are the powered settings:

The Tags use a faster search pattern while powered. This is due to not needing to conserve as much power while being charged.

Adjusting Settings for Wake-on-Shake CUWBNet Search

Only the motion threshold and stationary timeout can be configured by a user. These are configured via persistent properties. This feature can also be disabled by setting the persistent property. The persistent property is described in 0x40b0 Wake-on-Shake Search in the Persistent Properties Appendix.

Wake-on-Shake CUWBNet Leave

This feature allows a tag to leave the CUWBNet immediately if the tag does not move for a set period of time. This allows tags to save battery life when stationary.

By default, this feature is disabled on the tags.

Wake-on-Shake Leave Enabled Behavior

If the tag does not experience movement greater than the motion threshold for a set period of time, the tag will immediately leave the CUWBNet.

Settings options:

Setting the timeout period or motion threshold to 0 will disable the feature.

The leave motion threshold and timeout period is set and sent to devices via the CUWB Manager.

Wake-on-Shake Leave Disabled Behavior

This feature is disabled by default. When the feature is disabled, the tag will not leave the CUWBNet due to a motion threshold or timeout period caused by lack of movement

Powered Devices & Wake-on-Shake Leave

This feature can be used while a tag is powered via USB, but the behavior is modified: The tag will timeout after the set timeout period, and announce every 5 seconds. It will not join the CUWBNet until it is in motion or given a tag role without Wake-on-Shake CUWBNet Leave parameters. Additionally, wake-on-shake search is disabled while on USB power while this feature is enabled.

Adjusting Settings for Wake-on-Shake CUWBNet Leave

Tags can be enabled with this feature via the CUWB Manager. To modify the settings, use the System Settings keys in the CUWB Manager.

The setting keys are described in wake_on_shake_timeout and wake_on_shake_threshold respectively in the Settings Key Appendix.

Filtering

Filtering is a mathematical process applied to the output position data that makes the data more precise, at the cost of latency.

The CUWB System allows for users to configure position data filtering. The filtering is applied to the position data on the User Stream.

Filtering can be configured in the CUWB Manager UI or via position_smoothing_mode in the System Setting Keys.

Users can set the Smoothing Factor which is the number of positions. The equivalent settings key is position_smoothing.

Supported Algorithms

Currently, the CUWB Manager supports three different filtering algorithms: a simple average, a weighted average, and a kalman filter.

Simple Average

The simple average is the moving average of the position data over the last number of positions determined by the smoothing factor. Dropped beacons, or positions that are unable to be calculated are not included in the output. The simple average filter is sufficient for most users to increase system precision and eliminate outliers.

The simple average filter is a windowed average and will continue to deliver output location data at the nominal tag beacon rate.

Weighted Average

The weighted average is an average of the last number of positions determined by the smoothing factor, weighing each position based on its quality. Dropped beacons, or positions that are unable to be calculated are not included in the output.

The weighted average filter is a windowed average and will continue to deliver output location data at the nominal tag beacon rate.

Simple Kalman Filter [Expert Only]

The kalman filter is recommended for expert users only. Contact Ciholas for support on Kalman filter configuration.

Logging

Available Logs

Logs are located on the Host PC at /var/log/cuwb/network. These are also referred to as text logs to differentiate them from “CDP Logs”.

The following logs are available from the CUWB Manager in the Log tab:

• cuwb-manager.log - logs UI related errors and issues
• cuwb-websocket.log - logs errors and issues between the backend and CUWB Engine
• <name_of_CUWBNet>.log - logs errors and issues for the CUWBNet.

When requesting support, logs are helpful to send for debugging if available.

Additional CDP logs can be captured using CDP Logging. Users can use CDP logs to record and replay CUWB activities as if it was from a live system.

Log Summary Tab

The log summary tab in the CUWB Manager, provides a shortened list of log messages to the user. The log tab utilizes de-spamming to reduce the amount of repeated messages to the user. See the Log Tab for additional details.

Common Log Messages

In the examples below, all serial numbers would be replaced with serial numbers from the running CUWBNet.

Planar Anchors

The anchors are all bound to a single plane, and that plane intersects the position bounding zone, 
which can lead to poor tracking.

This message indicates that there is a problem with the Bounding Box, which can be configured on the Configuration -> General tab of the CUWB Manager. This indicates that the anchors are on a single plane and that plane is within the bounding box limits.

If all anchors are installed directly on a flat ceiling, then they are all on the same plane.

When this occurs, the anchors cannot resolve which side of the plane any given tag is on. This can lead to odd behaviors when tracking.

There are two methods to resolve this issue:

1. Adjust the bounding box setting so the plane of the anchors is not included within the boundaries of the bounding box. This can be done by manually adjusting the bounding box values or the Use Anchor Bounds button in the Bounding Box section.

   If the anchors are on the ceiling at a height of 3.5 meters, then set the bounding box Z to 3 meters.

2. Install additional anchors that are not on the same plane as the original set.

   If all the anchors are on the ceiling, anchors could be added along the floor or at an additional ceiling height.

Device Joining CUWBNet

Sent commands to 01:0B:00B7 for it to join the CUWBNet

This message occurs when a device first announces its presence to the CUWBNet. This indicates that the CUWB Engine heard the announce packet from the device and is sending commands to the device so it can participate in the CUWBNet.

No Unconfigured Slots

No available slots to assign unconfigured tags (0 total slots): 01:12:0001 01:12:0002 01:12:0003

This message only appears when using MultiTime mode.

This message indicates that there are CUWB devices within UWB range that are not configured to participate in the current CUWBNet, but there are not enough Unconfigured Tag slots in the CUWBNet for those devices to participate as Unconfigured Tags.

The amount of Unconfigured Tags can be increased or decreased in the Configuration -> Schedules tab of the CUWB Manager under Tag Count.

Ignoring CUWB Engine

Telling nodes to ignore this CUWB Engine: 01:12:0001 01:12:0002 01:12:0003

This message indicates that there are CUWB devices within UWB range that are unable to participate in the CUWBNet. These devices are being sent Ignore Commands from this CUWBNet so the devices will search for other CUWBNets in the area instead of continuing to try to join this particular CUWBNet.

Host Control

Initializing

Initializing the host...

This is one of the first message printed in the log when a CUWBNet is started. This message indicates that a CUWBNet is in the initialization process prior to the beginning of UWB activity.

Shutting Down

Host shutting down... 

This is one of the last messages printed in the log when a CUWBNet is stopped. This message indicates the CUWB Engine is in the process of removing CUWB devices from the CUWBNet so the CUWB Engine can be safely terminated.

Alien Nodes

Marking the following devices belonging to CUWB Engine FE:00:0002 as 
Alien Nodes: 01:1200A, 01:12:000B, 01:12:000C

This message occurs when a second CUWBNet is started on the same LAN that an existing CUWBNet is using for the Anchor CDP Stream. This message indicates that the two CUWBNets are aware of each other. This allows them to coordinate CUWB devices, so any CUWB devices in range will join the proper CUWBNet.

MultiTime Seeder Messages

These messages only appear when using MultiTime mode.

Unable to find initial seeder

This message occurs when the CUWBNet is not able to communicate over Ethernet with any Anchors configured to the Initial Seeder role.

Verify the following:

• That the initial seeder is powered
• That the initial seeder is plugged into the same LAN as the CUWB Manager
• That the CUWB Manager interface is configured properly for the Anchor Stream

No initial seeder was configured. Promoting all seeders to initial seeder now

This message occurs when the CUWBNet is configured for MultiTime mode without any anchors configured for the Initial Seeder role. At least one Initial Seeder is required for MultiTime mode. The CUWBNet will automatically promote all anchors configured as Seeders to the Initial Seeder role. This ultimately means that any of the Seeder anchors can be selected as the Initial Seeder.

Tag Rate Too High

WARNING: Tag 01:12:0074 is configured to transmit at 10Hz, 
but that tag is only capable of transmitting at 1 Hz

This message indicates that the specified tag is configured for a faster Role than the Tag’s Max Tag Rate will allow. The Tag will still participate in the CUWBNet, and it will take up one slot for its configured Role, but the tag will only transmit as fast as it is capable of transmitting.

For the message above, the Tag would only be able to transmit at 1Hz, but it consumes one 10Hz slot in the CUWBNet.

Firmware Updates

Tags

Tags support firmware updates via one of two possible bootloading methods: Over-the-Air (OTA) and Wired.

OTA Bootloading

OTA bootloading utilizes the CUWB Manager and UWB communications to send packets to tags for bootloading. OTA bootloading is the default method for bootloading tags.

OTA is the default bootloading method, but if a device is plugged into a powered USB hub, the bootloader will swap to the CUWB USB Driver instead of using OTA.

Setting Up OTA Bootloading

The CUWB Manager should be used for OTA bootloading and devices will need to be part of a CUWBNet.

1. Setup CUWB Configuration with devices that need to be updated. Devices must be participating in the associated CUWBNet to be updated.
2. Install and Confirm firmware images for devices are installed on the machine. See Software Downloads for firmware installation location.
3. Enable Automatic updates via the CUWB Manager Configuration -> General tab.
4. Start the CUWBNet.
5. Wait for devices to start and finish updating, by monitoring the Status -> Devices tab.
6. Stop the CUWBNet.
7. Disable Automatic updates via the CUWB Manager Configuration -> General tab once all devices are updated. This helps prevent unwanted updates if using a mix of firmware on devices.

For customers using a set production CUWBNet, an additional isolated (via RF or physically) CUWBNet can be set up just for bootloading.

OTA Success

When the OTA is successful, the tag will automatically reboot, rejoin the CUWBNet, and the reported version string will update.

OTA Failure

Should the OTA process fail, check the following:

• The devices have sufficient battery life
• The Image being sent is compatible with the devices
• The Image being sent isn’t corrupted

If none of those items resolve the issue, plug the device in and use the CUWB USB Driver to recover the device.

Wired Bootloading

Wired bootloading utilizes the CUWB USB Driver and serial communications to send packets to the tags for bootloading.

Setting up Wired Bootloading

1. Setup CUWB USB Driver on the Host PC running the CUWB Manager.
2. Plug devices in either via single USB-C cable or via a powered USB-C hub
3. Run the command sudo cuwb-usb-interface-daemon lo on the command line
4. Follow the steps in the Setting Up OTA Bootloading section above

Wired Bootloading Success

When wired bootloading is successful, the tag will automatically reboot and join the CUWBNet. The reported version string will update.

Wired bootloading does not need to be done in the same space as the active CUWBNet.

Wired Bootloading Failure

Should the wired process fail, check the following:

• The Image being sent is compatible with the devices
• The Image being sent isn’t corrupted

If none of those items resolve the issue, plug the device in and use the CUWB USB Driver to recover the device.

Contact Ciholas and provide a copy of the image being loaded onto devices.

Anchors

Anchors firmware update is similar to the tags. Anchor bootloading is strictly over the wire via Ethernet.

Setting up Wired Bootloading

The CUWB Manager should be used for anchor wired bootloading and devices will need to be part of a CUWBNet.

1. Setup CUWB Configuration with devices that need to be updated. Devices must be participating in the associated CUWBNet.
2. Install and Confirm firmware images for devices are installed on the machine. See Software Downloads for firmware installation location.
3. Enable Automatic updates via the CUWB Manager Configuration -> General tab.
4. Start the CUWBNet.
5. Wait for devices to start and finish updating, by monitoring the Status -> Devices tab.
6. Stop the CUWBNet.
7. Disable Automatic updates via the CUWB Manager Configuration -> General tab once all devices are updated. This helps prevent unwanted updates if using a mix of firmware on devices.

For customers using a set production CUWBNet, an additional isolated (via RF or physically) CUWBNet can be set up just for bootloading

Anchor Bootloading Success

When bootloading is successful, the anchor will reboot and automatically rejoin the CUWBNet. If using chained power, downstream power and communications to anchors are maintained. The reported version string will update.

Anchor Bootloading Failure

Should the wired process fail, check the following:

• The Image being sent is compatible with the devices
• The Image being sent isn’t corrupted

Contact Ciholas and provide a copy of the image being loaded onto devices.

API Control

The CUWB Manager includes a comprehensive Application Program Interface (API) that enables user programs to interact directly with CUWB Configurations and CUWBNets. Developers can build custom tools and automation for tasks such as adding or removing Tags, adjusting beacon rates, or monitoring system performance.

For details, see API and API commands.

Troubleshooting

Common Issues

The following sections outline common issues that users may run into while using the CUWB RTLS.

Interface mismatches

If all anchors have Ethernet connectivity but only the initial seeder has UWB connectivity, this could be an Interface mismatch or a cable connection issue with the initial seeder.

This could be due to:

• Initial seeder having a loose cable connection
• Anchor Stream’s Network Interface isn’t configured properly

Verify the following:

• That the initial seeder is properly installed and connected.
• The Interface for the Anchor Stream is properly specified in the Ethernet settings.

PoE+ Switch Overloading

If anchors intermittently lose power (LEDs shut off or Anchor resets) and the CUWB Manager status is inconsistently showing green and red status for anchors, the PoE+ switch port may be overloaded.

Verify the following:

• PoE+ Switch is configured properly for power delivery and link budget
• Anchor chains are no longer than 12 units

Invalid UDP Interface Specified

If the CUWB Manager prints an error message about invalid UDP interfaces, verify that the network interfaces specified are all valid interfaces on the Host PC. See Interface Example for instructions on checking Host PC interfaces.

CUWB Viewer Connectivity

If the CUWB Manager shows device connectivity but the CUWB Viewer does not display any devices, the issue is likely an Ethernet configuration mismatch between the User Stream and CUWB Viewer.

Verify the CUWB Viewer is on the same subnet as the CUWB Manager’s User Stream Interface and the Viewer is connected to the correct CUWBNet.

Tag Unable to Join CUWBNet

If a Tag is unable to join the CUWBNet, but the Tag RF settings match the CUWBNet RF settings, verify:

• The assigned Role for the Tag has the Tag Count set.

• The Tag Count is large enough to support all units using that Role. The following text log message will be displayed in the log:

    Unable to schedule {SERIAL_NUMBER} (Role = {ROLE_NAME}). 
    Check that the Tag Count is high enough to make room for this device in this Role.
  

Finding Devices

Accurate recording of serial numbers during the installation process is strongly encouraged, but can be error prone. Common errors include: mistyping serial number, writing down serial number improperly during installation, and failing to write down serial number.

In case of serial number errors, Ciholas recommends the following during debugging:

1. Run the CUWBNet in ‘Role’ mode for LED patterns and walk around the tracking area. Any anchor that isn’t configured for the CUWBNet will use the UNCONFIGURED LED pattern.
2. Use Colors to check location and serial numbers. Using the LED identification, set a couple devices to different colors (solid or flashing). Verify color matches expected serial / installation location.
3. Use Serial number flash. Using the LED identification, set devices to flash their serial numbers via color.

Hz Rounding Causing Schedule issues

The basic unit of the CUWB schedule is the Tick. There are 975,000 Ticks per second. The different device rates of the CUWB schedule can be configured in Hz or Ticks. The formula for converting between the two options is as follows: T = 975000 / H, where T is the period in Ticks and H is the repeat rate in Hz.

The Hz option is provided for the user as a convenience, and for the majority of situations, specifying the rates in Hz is sufficient. However in some more advanced configurations, using Hz can lead to rounding issues which causes significant fragmentation of the schedule. This can result in either significantly diminished capacity or a completely invalid schedule.

Example:

In a configuration where the Seeder Rate is 8.00 Hz and Tag Rate of 16.00 Hz, configuring these rates in Hz will lead to schedule fragmentation. This is because 16.00 Hz = 975000 / 16 = 60937.5 Ticks. Fractional Ticks are not supported, so the value will be rounded to 60938 Ticks. Likewise, 8.00 Hz = 975000 / 8 = 121875 Ticks. 121875 is not evenly divisible by 60938, so using these 2 rates in the same configuration will result in an invalid schedule.

To resolve this, the CUWB Configuration can be set with a Seeder Rate of 121876 Ticks and a Tag Rate of 60938 Ticks. These rates still round to 8.00 Hz and 16.00 Hz respectively, but now they are evenly divisible, and will produce a valid schedule.

Revision

APPENDIX A : Persistent Properties

This appendix outlines the currently available persistent properties that can be set through the CUWB Manager UI.

0x0064 Search Buckets

The Search Bucket persistent property is available via dropdown menu in the Device Manager. The following options are available:

Available channel settings vary depending on regulatory jurisdiction.

Search Bucket UI Messages

Property Not Set

For devices that do not contain the search bucket persistent property, the following message will be posted to the Device Manager UI:

Device 12:34:5678 does not have a Search Bucket set.

This means that the device will use the default channel search and RF agility settings.

Property Set

For devices that do have the search bucket persistent property, the following message will be posted to the Device Manager UI:

Device 12:34:5678’s Search Bucket is set for Channel 5, PRF16, and Preamble Code 4.

0x4083 LED Intensity

The LED Intensity persistent property is available via dropdown menu in the Device Manager. The dropdown menu provides On or Off options, which correlate to the following intensities:

If manually entering setting, the property value must be given in intensity percentage: 100 or 0.

LED UI Messages

Property Not Set

For devices that do not contain the LED Intensity persistent property, the following message will be posted to the Device Manager UI:

Device 12:34:5678 does not have a custom LED set.

This means the device will follow default firmware LED settings when not participating in a CUWBNet and follow the CUWB Configuration setting when participating in a CUWBNet.

Property Set

For devices that do have the LED intensity persistent property, one of the following messages will be posted to the Device Manager UI:

Device 12:34:5678’s LED is ON.

Device 12:34:5678’s LED is OFF.

0x40b0 Wake-On-Shake CUWBNet Search Configuration

The Wake-on-Shake CUWBNet Search persistent property is available via dropdown menu in the Device Manager. The following options are available:

Wake-on-Shake Search Threshold

_{1. Motion is given in milligravities.}

Wake-on-Shake Search Timeout

It is recommended to keep the stationary timeout to less than 300 seconds.

Wake-on-Shake Search UI Messages

Property Not Set

For devices that do not have the Wake-on-Shake CUWBNet Search Configuration persistent property, the following message will be posted to the Device Manager UI:

Device 12:34:5678 does not have a custom Wake On Shake set.

This means the device will follow the default Wake-on-Shake CUWBNet Search Settings. The recommended values in the tables above match the default Wake-on-Shake CUWBNet Search Settings.

Property Set

For devices that do have the property set but not disabled, the following message will be posted to the Device Manager UI:

Device 12:34:5678 is configured to timeout 30 seconds with wake threshold of 200 mg.

For devices that do have the property set and disabled, the following message will be posted to the Device Manager UI:

Device 12:34:5678’s Wake on Shake is disabled.

APPENDIX B : License Terms and Conditions