Setup of the RTLS system from scratch based on few constraints

So u cant couple a single anchor to 2 masters running in different machines ??? If it is so can you help me in finding antennas which could actually increase the range. It would be helpful if you could suggest available antennas adaptable to dwusb and also with a good range.

Unfortunately, you cannot couple a single anchor to 2 masters running on different machines. The master’s function is to keep track of the timing of the entire system. If you have 2 masters working completely independently of each other, they will try to compete for control of the timing of the network, which would ultimately result in preventing proper functioning of the network.

Also, there are not many antennas available in the market right now that are compatible with the DWUSB since it is such a new product. Unfortunately, your best option would be to look for a custom antenna manufacturer that could develop a new antenna meeting your specifications.

Do know that increasing the range of the system is high on our priority list, but developing a good method for improving our range will take time.

Can we use your GUI in ubuntu 12 04 ??? I’m not able to download libqtserialport5 it needs libc6 version of 2.17 or more. but 12 04 suports only version 2.15…

We have not tested with Ubuntu 12.04, and we do not expect it to work by default in 12.04. There are almost definitely ways you could go about compiling the libraries you need in a Ubuntu 12.04 environment, but as we have not looked into setting up our GUI on any Ubuntu system other than 14.04, we do not have much information to offer on the process of setting it up in Ubuntu 12.04 at this time.

Hello. can I have the data types of the other channels like the ANCHR, TAG, TOA.? It would be great if you could provide them …

Here is a brief description of each of the other data channels. We’ve redacted a lot of these from the uwbtalk libraries provided online to make things less complicated for end users who just want position reports from the system, as all the data in these reports is encapsulated in the position reports and the TWR reports.

ANCHR - These reports come from the anchors and contained timestamps for every packet they receive over the UWB network. It is these timestamps that are fed into our location engine and ultimately generate a position for where a given
transmission originated.

ANCMT - These are announcement reports. They are used for discovering devices within the network, assigning network ids, timing, etc.

TAG - These are infrequent packets that announce information about the tag. They are currently not used in the system.

TOA - Time of Arrival packets. These packets are generated by the host software for internal use. They contain time difference of arrival information between anchors. They are used in a TOA algorithm that exists in the code in order to generate positions.

Thank you for the info !!! I need to know the attributes of these channels. Can I get a class file for all of the above channels? I think I can work with it even if its complicated. It’l be useful to rectify the errors in my values.

Can u suggest the best anchor positions in order to reduce errors and instability in XYZ values. I’m tryin diff anchor positions and I feel that it makes a huge diff. And also can you suggest where to place the master node. Should it be in the same plane as in the case of the anchors or should it be in a diff plane ???

The LCM compatible messages that have been left undocumented are intended solely for internal use, and as a result, they do not have much practical application for general use. All of the useful information that can be gleaned from those internal messages is already included in the channels that have been documented, so it is our belief that including the internal messages in our documentation will only lead to unnecessary confusion. Instead of taking that approach, it would likely be more beneficial to specify what errors you are seeing so we can address the problem directly.

Without knowing any details about the environment you are working in, its hard to give too much specific device. However, the following are a few useful general tips for proper anchor and master placement:

The anchors, being at a level where they are obstructed by metal objects and people, will produce bad data. The UWB signal simply doesn’t penetrate metal objects or people. Thus the first path is so attenuated that all you get are multipath signals, and the first multipath signal is what gets timed. A future version of the demo code will attempt to detect when this occurs from signal properties and then deweight the anchor data in the results. Elevate the anchors to the ceiling level if you can. Higher is better as that avoids obstructions.

Master node needs to have good radio visibility to all nodes for configuration. It also needs to be in a surveyed and stable location or the results will be off. Plugging it into a laptop directly is usually not adequate, and typically orients the antenna flat. A USB extender cable to where the master is located in a more fixed location would help. Much like with anchors, having the master up high where there is less opportunity for obstructions to interfere with line-of-sight communications is better, but as the master has to be in range of all the anchors and all the tags, it is usually better to keep it a little lower than the anchors to ensure that there are no blind spots on the ground where the tags will be unable to communicate with the master.

Having only four anchors is marginal. If any one is compromised, it affects the results badly. Having more will be good.

Also, if your survey is off, then your accuracy suffers but it also causes jitter in displayed positions when a particular anchor varies. A bad survey means the solution is “fighting” between the data from the anchors to locate the best position and when an anchor leaves the fight, the position jostles a lot.

With anchors all on ceiling, make use of the bounding for the tags. If you bound the tags to be below the ceiling (say ceiling is 3 meters Z, bound tags to be 2.5 meters or less), then you will get reasonable Z axis data.

So, in short:

  1. Fix master node higher, on cable, and with its antenna upward (not lying flat). Must be in surveyed location, must see all anchors as directly as possible, must see all possible tag positions.

  2. Elevate anchors onto the ceiling.

  3. Get more anchors.

  4. Have an accurate survey.

  5. Bound tags below ceiling.

I just need to know the timestamps from each anchor… The errors increase if one of the anchors loses line of sight. It would be really helpful If I’m able to read the timestamps from each anchor…

[quote=“ajith92, post:21, topic:63, full:true”]
I just need to know the timestamps from each anchor…[/quote]


You are going beyond what we provide in the DWUSB demo system. It was designed to provide you with locations and we document that output. The internal messaging is complex and not as simple as you might expect and we don’t intend to publicly document that.

I suggest that you contact me directly to discuss what we can do from here beyond what the DWUSB demo allows. After I know more about what you are trying to accomplish, then we can come up with a strategy to get that to you in the most reasonable way.

Mike C.

thank you for the info!!!

In the dwusb-gui the Smoothing factor works really well. Is there a way to get the xyz values through the lcm ports after it is smoothened ???

Currently, we do not have any way of sending the smoothed positions over LCM. If this becomes a highly desired feature, then we can incorporate it into the DWUSB GUI. In the meantime, we can give you the smoothing algorithm we use so you can compute those same positions.

As of the 0.5.0.X releases, our smoothing algorithm is just a simple average calculation. Whenever we compute a position, we record the time at which we computed that position. Then, we display the average of all the positions we have heard in the last x milliseconds, where x is 10 times the smoothing factor. That’s the entirety of our smoothing algorithm right now. In your case, the only change you’d need to make is to record the time at which you receive each position over LCM, but the rest of the algorithm should remain the same.

for example if my x value is 10 then do you store 10 values of position consecutively and compute the average of it ?? If that is the case then the rate of update is reduced rite ?? It doesn’t happen in your case…

Here is an example to help explain how the smoothing factor in the DWUSB GUI works:

By default the smoothing factor is set to 10, and when the smoothing factor is 10, the DWUSB GUI will average all the positions it has heard over the last 100 milliseconds. Just to clarify, the default smoothing factor of 10 does NOT cause the system to average the last 10 positions, but rather, it will average all the positions it has heard in the last 10 * 10 = 100 milliseconds.

In other words, the smoothing factor sets the number of centiseconds over which we will average before plotting a position.

ok i get it. Thank you !!!

Single anchor cannot be ran with two different mater node running on different machines. The master’s function is to keep track of the timing of the entire system.
Is this same rule true for TAG element configured to work within two RTLS networks running simultaneously ???

My goal is to track the same TAG element by two or more RTLS networks placed next to each other. It is possible due to system timing capabilities?

Unfortunately, a tag cannot be moved between two different networks for the same reasons that an anchor can’t simultaneously run on two separate networks. The current demo system is not capable of having any interoperability across multiple adjacent networks, so using multiple adjacent networks will likely only cause conflicts as any two networks will compete for utilization of the air time if they get too close together.