I am trying to build a system where I attempt multiple consecutive ranging events, using the ss_twr_int_init and ss_twr_resp examples in GitHub, but I am running into a peculiar problem. Here’s the psuedocode of what I’m doing at the initiator side (the responder side is pretty much the same with ss_twr_resp):
I am sending poll messages for different responders (destination IDs are different) and waiting for responses. However, after the rx for the resp1, I get a timeout while waiting for the rx from resp2 if I don’t put the device to sleep for at least 70 ms (using deca_sleep()). The less the amount of the sleep, the more rx messages I miss.
I have read that the Decawave PANS is able to perform ranging with 4 devices in 3 ms. I don’t really need such precision but it would be better if I did not have to wait for 70 ms between every ranging. Can anybody point me in the right direction to decrease the time I need to wait for? Or is it something like the SS-TWR examples in GitHub are somehow not precise enough for waiting less?
There is certainly no need for a wait that long.
There shouldn’t be any need for any wait, once the radio transmission and reception process is complete you should be able to start the next one immediately.
After your rx process completes are you sure there are no further events, packets from the responders or other processes or timeouts that could be happening later on?
To get it’s update rate PANS uses a trick where one poll from the initiator results in all 4 responders replying in sequence, this gives a 75% reduction in the number of transmissions from the initiator and so gives you a speed improvement assuming you want to range to 4 devices, it works out slower for ranging to a single device. I’ve used a similar system and some other tricks to get an effective rate of 12 ranges every 5 ms. The fastest I’ve managed to get a single unit double sided two way range is 1 ms.
I have attempted this as well and it did not work. I sent a single broadcast message from the initiator and made one responder wait 1-3 ms for the other one to transmit its answer (by hard-coded sleeps) and set up the initiator to wait for consecutive rx events (enabling rx etc.). Initiator receives the first message but goes into timeout for all the others, which led me to think that it is a problem with consecutive rx events instead of consecutive tx/rx events.
If it is not confidential or anything, could you please share which system you achieved this with or what tools did you use (which RTOS, which library etc.)?
The system is using custom driver written based on the user manual and optimised for speed for our specific application (mainly minimising SPI transactions since the SPI bus is slow in comparison to the processor). No RTOS, it’s running as a bare metal interrupt driven system on a 100MHz M4 (An NXP LPC family part). Some of the NXP libraries are used for device setup and peripheral drivers but other than that it’s fully custom code.
We have two hardware variants, the anchor is just a DW1000 and the NXP processor and a tag version that adds an STM32 (380MHz M7 with DP floating point). The NXP runs the radio, on the anchor it’s constantly listening and only transmits as needed to reply to received messages. On the tag the NXP constantly initiates ranges, calculates the results and passes these on to the STM. The STM does some filtering and smoothing on the measured ranges and then uses a least squares system to calculate position. It then optionally runs a Kalman filter to combine the UWB position with inertial measurements. It then outputs the final position at 100Hz. We use an off the shelf least squares library and the basic device drivers for the processor but again the rest is custom code running bare metal.
The radio protocol is (you guessed it) custom. It’s a similar system to PANS where each initiation triggers a series of replies from anchors, only with groups of 8 or 12 rather than the PAN groups of 4. Each anchor gets a window of 330us to reply in.