CUWB Product Launch

Ciholas has been involved in UWB since the very early days of Decawave, being a founding member of the Decawave partner program. We have put all of our experience into a new general purpose UWB RTLS system called CUWB™ (https://cuwb.io) which we just launched this week.

The goal of the CUWB system is to establish game changing performance and usability as indicated in our feature list:

  • Tags up to 100 Hz beacon rate
  • High battery life, for example 20 days at 10 Hz from 150 mAH cell
  • Supports mixed and dynamic tag rates in one system
  • Very low latency beacon to location report, under 20 ms
  • High location precision, well under 10 cm achievable
  • Super high capacity of 3300 locates per second
  • Channel 5 and 9 operation, configurable over the air
  • Two modes, MultiTime™ (TDoA like) or MultiRange™ (TWR like)
  • Long radio range, 100 m channel 5, 70 m channel 9
  • ChainPoE™ allows 12 anchors per PoE+ port, 90% less wiring
  • Ambidextrous PoE ports, no in or out port to confuse
  • Redundant PoE option, no anchors lost with cable fault
  • Versatile mounting options for anchors
  • Sealed tags and sealable anchors for harsh environments
  • Scalable from a single room to the largest buildings
  • Wake on shake capability for improved battery life

We have clear, up front pricing with no recurring costs, including providing the CUWB software suite for free. There is no cloud or Internet connectivity requirement so your data stays under your control.

We are field proven. Our largest install is 650 anchors seamlessly covering 140,000 m^2 (1.4 million SF) at a fulfillment warehouse. This might be the largest unitary UWB system in the world.

Beyond the CUWB equipment we sell, we also offer extensive customization and engineering capabilities. Since we designed the entire system from whole cloth, from antenna to algorithms, we can customize the system to any degree. If UWB can do it, we can do it.

Our webstore is now open and we are shipping. At present, we have FCC (USA) approval, but CE (Europe), ISED (Canada), and MIC (Japan) are expected shortly. Other regulatory regions will be added as customer demand warrants.

We welcome your feedback and questions!

Mike C.

Nice looking solution.

Is the 20 ms latency achievable with the <10 cm accuracy? Generally accuracy requires some averaging which then gets in the way of low latency positions. Or does the accuracy require a higher anchor density to average things in that way?

You’re aiming for a very different market to us but we ended up defaulting to a 60 ms output latency in order to keep the noise down. We can dial it all the way down to ~5 ms if needed but the position and velocity noise goes up signifcantly at that point.

Nice looking solution.

Thanks. You’ve asked a really good question.

Is the 20 ms latency achievable with the <10 cm accuracy? Generally accuracy requires some averaging which then gets in the way of low latency positions. Or does the accuracy require a higher anchor density to average things in that way?

We can easily achieve sub 20 ms latency and sub 10 cm precision on a single tag beacon at the same time. Our advertised numbers are actually quite conservative.

For precision, in our test lab, with 12 anchors, we saw a position std dev of 1.6, 1.7, 1.8 cm in the 3 axis on a recent test. This is with no smoothing, each beacon treated as a new position. That means +/- 3 std devs (99% of all hits) is about 5 cm precision, so about half our claim.

The lab is roughly 10 x 20 meters, so not huge and that is a moderately high anchor density. This was done on channel 5 and the channel 9 numbers were similar. This was also done with the LNA turned on, the numbers get slightly better with it turned off. The tag was on a tripod near the center of the array, things get worse at the edge of the array. The lab is an open area, so every anchor had good LOS conditions. This was using a total station for anchor and tag survey (the most accurate survey method). It is, as they say, “lab conditions”.

Our location engine uses all anchors that hear any given beacon so you can increase the anchor density arbitrarily high. The highest density site we’ve done was a basketball arena with 54 anchors. The std dev on the position was around 6 mm for each single beacon.

Additionally, you can improve the precision by smoothing. You reduce the std dev by about the square root of the samples. If you take a 100 Hz tag and smooth it to 1 Hz output in the 12 anchor test above, the std dev will be around 2 mm, or 10 times better. Build a site with 100 anchors, using 100 Hz tags, smoothed to 0.1 Hz output, and the std dev will be crazy small, like 500 microns. Essentially, precision is limited by your budget and not the technology.

Our accuracy error for the test was -5.8, -4.2, -8.9 cm in the 3 axis. Accuracy accounts for the systemic errors in the system you can not remove with smoothing, like antenna group delay variation versus arrival direction. All were under 10 cm. Z axis is always worse since the anchors are only above the tag where as XY is better due to anchors being on both sides of the tag. This is analogous to GPS where altitude is always worse than lateral position. If you put anchors on the floor and ceiling, you can get Z axis to improve, and we do have some special sites that do this.

As for latency, the anchors normally operate in a mode where every tag beacon immediately generates an Ethernet UDP/IP packet to the location engine. That latency is well under 1 ms. Once the location engine gets the first report from an anchor for a particular tag hit, it then waits 5 ms more to let the other anchor hits flow in, and then it performs the location computation on the data it has collected. The computation takes generally under 1 ms (depends on the computer power you use) and the answer is output via UDP/IP which may go out Ethernet, Wifi, or internally routed to an application on the CUWB Engine PC itself (localhost). In general, this whole process takes less than 10 ms, so half our claim. Network congestion, PC tasking and load, and other factors can affect this, of course.

We do have an aggregation mode where anchors do not send an Ethernet packet for every beacon they hear. They aggregate into a larger packet and send that packet when it is full or when the the age of the oldest beacon has exceeded a time out. Aggregation increases latency, obviously, but it also reduces the load on the CUWB Engine PC since it handles fewer packets. Thus users can choose lower latency or lower CPU load.

We plan to put together a more detailed discussion of accuracy, precision, anchor density, and smoothing since those things are interrelated. When someone asks me how precise the system can be, I ask them how much money they have since you can achieve arbitrarily high precision by how you provision it. You can also make an imprecise system by very low anchor density and no smoothing. That may be just fine for some applications.

Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com