Oct 9, 2018
CUWB 3.2
Bernoulli Update

Auto-discovery of devices and more

CUWB 3.2 brings usability and device management improvements to the Bernoulli revision of the Ciholas Ultra-Wideband (CUWB) system. Look below for new features available with this release.

Existing CUWB 3.x systems can be updated to 3.2 through the apt package manager. Copy the command below into a terminal to update the CUWB system.

Terminal - /home/cuwb

  • sudo apt update && sudo apt --with-new-pkgs upgrade
Please note the Upgraded Data Items section below. If you have custom applications relying on Position V2 or other deprecated data items, please consider updating your application to support the new data items before upgrading to CUWB 3.2.

Better Device Management

Device Discovery

As Ethernet devices are added to the LAN, the CUWB Manager device list will automatically populate with an unconfigured device listing. This makes it much easier to manage which serial numbers are installed at which location. Device Discovery also provides a quick way to verify the connection of newly installed devices.

Device Identification

Device Discovery helps during CUWB network setup; however, sometimes it is difficult to determine the location of a device after the CUWB network has been setup. With Device Identification, the CUWB Manager now helps users find devices already installed on the network. Device Identification turns on the device LEDs allowing it to be found in the real world.

Maintenance

CUWB Manager shows the Device Update Status in the status page making it easy to track when devices are being updated and when they are done.

CUWB 3.2 also adds the ability to reset devices directly from the CUWB Manager.

Improved User Experience

Log Improvements

The Log page now provides filtering allowing users to easily find what they are looking for. CUWB 3.2 also adds an improved scrolling interface and the ability to download the log as a text file.

Improved Device List

CUWB Manager now has a consolidated table for devices. Devices are now easier to find regardless of how they are configured (Anchor, Tag, or None).

CUWB 3.2 also improves device management with better pagination controls and required confirmation for device deletion.

Improved Network Information

New Data Items

The CUWB 3.2 release adds data items making it easier to monitor the activity of the network. Device Activity State V5 provides a quick overview of device connectivity, synchronization, and position. Device Hardware Status V2 contains information regarding device temperature, battery status, errors, and more.

The Device Names data item allows for names programmed in the CUWB Manager to be reflected in the CDP output stream. This feature makes it easy for external tools to display the names of devices instead of serial numbers.

The Synchronization and Role Report data items provide high level statistics regarding network operation. Synchronization tracks the quantity of synchronized anchors in the network. The Role Report tracks the number of devices currently on-line for a particular role.

Upgraded Data Items

A handful of the data items have been revamped to make it easier to support multiple networks in a single LAN and improved Ethernet throughput.

Position V3, Position’s Anchor Status V3, Accelerometer V2, Gyroscope V2, Magnetometer V2, Pressure V2, Quaternion V2, and Temperature V2 are upgraded formats. These data items will now be emitted with the CUWB Network serial number in the CDP header. These data items will also contain the device serial number directly in the data item.

These updates facilitate the ability to transmit multiple CDP data items in the same ethernet packet. When running more than one network, it is now easy to log which network a data item has come from.

Internal Items Made Public

The Internal stream on a CUWB Network contains three data items that are now documented in the public CDP documentation: Timed Reception V5, Tick V4, and Ping V5.

Timed Reception V5 encodes an anchor reception of another anchor's transmission. The information in this packet is useful in determining anchor to anchor connectivity and quality.

Tick V4 encodes the transmission time from a given anchor.

Ping V5 encodes an anchor reception of a tag's transmission (beacon). These packets can be utilized to determine the connectivity from tag to anchor.

Where do I go from here?