Hello,
I am currently using multiple DWM1001C modules as Anchors (~50–100) and Tags (~100–200). The firmware “DWM1001_PANS_R2.0.hex” is running on all the devices.
I have noticed that as the number of Tags increases, the number of “NaN” (unknown) location results also increases, particularly in a specific area. Additionally, whenever the location is valid, the accuracy is significantly worse in that zone.
This area contains many tall metallic structures, so my assumption is that multiple signal reflections are occurring there, making accurate Tag position acquisition almost impossible (at least with this firmware).
Besides that, although the documentation states that, with a Stationary/Normal Update Rate of 60 seconds, the network can support around 9000 Tags, we sometimes cannot visualize the position of the Tags in your mobile application.
Note that during these tests, the Tags had Bluetooth enabled, Responsive Mode turned on, and the LEDs were active, so the batteries were not depleted.
This leads me to suspect that the Initiator may be overloaded with data.
The reason I am contacting you is to ask: what do you recommend in this situation?
Is there a newer firmware version that I may not be aware of?
Thank you for your attention.
Hello @mnrDWM1001C
the PANS 2.0 is not maintained already for a few years.
Regarding your zones issue - the NaNs are returned when the internal location engine can not calculate the position. It could be because of some reflections, measurement loss, wrong position of the anchor. Can you make log of LES and post it here?
Regarding the 9000TN in the Android application. I would have strong doubts that the Android OS can handle so many connections. Having 9000 BLE devices at the same place makes the BLE practically impossible to use. The BLE is it no t designed to work this way. However have you tried the passive node as TN position scanner - this might work but we have never tested it with so many devices.
As this looks like a commercial project please leave us a message here: https://www.leapslabs.com/about (in the Get in touch form) we might have a better solution for you.
Cheers
JK
Hello @leapslabs,
Regarding the logs, that will be an issue since the Tags are already mounted and their results are being used for industrial purposes. However, I can check your theory about the Anchors.
Regarding Bluetooth, there was a misunderstanding. What I meant is that I have a few Tags that I use for testing, and on those I enabled the features I mentioned. On the production Tags, the LED, responsive mode, and Bluetooth are all turned off.
Speaking about the initiator, I had made a wrong assumption.
On page 27 of the Decawave System Overview document, it is stated that it is not the network initiator that calculates the Tags’ positions, it is the Tags themselves. In typical geolocation systems, it is indeed the network initiator that performs the calculation, which is why I was confused. However, I noticed in the application that the seat number of some Anchors is very high (~27–28), almost at the maximum (30). So, as good practice, I probably still need to add another network, which was my original plan in case the network initiator was being overloaded.
I will create a topic in the LEAPS forum as you suggested.
Thank you for your feedback.
Hi @mnrDWM1001C
regarding the location calculation: The location is calculating the TAG itself. There is no central position calculation for all tags.
Regarding the seat number)
- The system is designed to reuse the seat numbers if they are available. However it tries to search for the first highest number - it is likely that it will be unused. If not available then it overlaps and start searching from the begging again.
- You might not be reaching the limits as of the workflow in noted in point 1. There are networks with more than hundred of anchors.
- Adding new network (PAIND) wont help as they share the same air time
Regarding the BLE) The DRTLS manager is a quite old application/outdated which extensively use BLE interface on the Android devices. For proper functionality is recommended to use some branded Android devices as they tends to have good BLE drivers. Some noname/cheap android devices have really poor BLE drivers which can not handle the need of the DRTLS application.
Cheers JK