Hi everybody
We’re using a MDEK1001 to test UWB viability for a project. At this moment we’ve set up 6 anchors almost simetrically positioned to cover a rectangular(ish) 26x17m space in which every anchor has at least LoS to 4 of the others. Everyone of them has been configured with reasonable precision in X,Y positions at 2 m height and the initiator is the one placed at (0,0,2). All this configuration has been made in the DRTLS app.
To retrieve position data we are using 1 or 2 tags at 10Hz frequency and a listener connected to a RaspberryPi 4B running a Python script. The script succesfully retrieves, prints and sends to a DB every received line.
The problem we’re facing a the moment comes when we check the received registers (both in log and DB, there is no loss here) and find that sometimes we receive the expected 10 records per second and sometimes there are some blank spaces between 1 to up to 15 seconds. Ploting theese positions means it gets stuck and then makes huge jumps. Meanwhile, checking app’s Grid at recording time, plots seamless movement and representation.
We’ve found that this issue is lessen in the script by the position of the tag, being over the head the one that offers the best results. In the app the representation is allways good enoguh regardless of the position of the tag or the speed at which the user is moving.
Is there any reason why this performance should be that different between the Decawave app and the listener script?
Thanks in advance
Hi @jelexpuru
thanks for a complex situation description. The decawawe app is using Bluetooth to connect to the TN or it connects to the listener and collect the data from the listener. Do you know which approach do you use in your observation with DRTLS app?
I have no experience with Python but you can do a simple test to observe listener via shell and see if there glitches or not 1-15sec should be easily visible. Or you can log the listener with timestamps and then evaluate the log and see if there are glitches or not.
Where is the listener located in your network? The listener collects data directly from the TN via UWB so you might be facing signal loss.
Cheers
JK
Hi @leapslabs .
Thank you for your reply. We’ve found that, indeed, the main issue was the positioning of the Listener, as changing it from the shorter side of the rectangle to an almost centered position of the longer side did, in fact, enhance the ratio at which data was being received. There were also issues such as guaranteeing tag orientation to be considered.
In any case we’ve found in our tests an average signal loss of a 26% and a maximun no-signal period of 1.6 seconds with the 10hz profile.
So in order to try to further improve this we’ve thinking: is there a way to deploy more than one listener connected to the same device? Could deploying gateways (I’ve seen mentions to it but no further details) a better solution instead? Is there any kind of doc about this deployings?
Thanks again
Hi @jelexpuru
please see my answers below
Is there a way to deploy more than one listener connected to the same device?
Yes you can have as many listeners as you want - listeners are passive devices.
Could deploying gateways (I’ve seen mentions to it but no further details) a better solution instead?
In your case I dont think that gateways will help you - and the RPI 3B is hard to buy these days.
Is there any kind of doc about this deployings?
Unfortunately there is no docs about it.
Cheers
JK