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]
Ajith,
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!!!
Hello,
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 !!!
Hi.
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.