I am working with dwm3001cdk and have set up (for this issue) >1 initiator, each of which pings a responder synchronously. I do get correct ranging values for a majority of the pings, but at random instances, the value reported is (generally) much lower, or even negative.
Working off of the ss twr example for dwm3000, I found that for a given range (looking at 1 pair of initiator-responder, ~9m apart, LOS), the tof value varies, with the round trip delays of responder being relatively constant (resp_msg_get_ts()) but that of the initiator (dwt_readtxtimestamp()/dwt_readrxtimestamp()) varying drastically. Could anyone point me in a direction that I should revisit to find what could possibly cause this?
I would assume if some delay calibration constant was off, all values would be off, rather than random readings.
The received messages from the responder are filtered to check for matching Initiator and responder ID, as well as a frame sequence number.
Does not occur when each subsequent initiator waits 50 ms before starting its ranging.
Am I reading this correctly? You have multiple devices all sending packets at the same time and then use a filter to decide if it’s the correct packet?
If so that won’t ever work well. You need to ensure that only one device is transmitting at a given time.
Image above represents the temporal flow of the process.
Init1 sends a packet first that is addressed to Resp1 (only Resp alive), which then replies. There is then a wait for del_t ms.Now Init2 repeats the process, (very likely) gets a reply, followed by another del_t ms wait and so on.
I get the above issue when del_t = 0, but not when del_t >= 50 ms. DWM3000 RX Timestamp not updated on every packet, CIA processing does not complete remotely resembles my issue, but I get a wrong reading relatively scarcely (~ 1 in 100 readings per init-resp pair).
I haven’t seen this issue when running just 1 Initiator, but I do in some cases also get a situation where resp_rx_ts < poll_tx_ts. The latter can easily be caught but am not sure why it occurs. If it were a reflected signal from a previous iteration, the check for the incremental frame sequence should catch it. Moreover, the timestamp in this situation varies by a large factor, i.e., is sometimes ‘missing’ a digit.
And del_t is timed by I2 picking up the response from Resp1 replying to I1 and then waiting the given amount of time before transmitting?
Is the responder transmissions sent with the expect a reply flag set so that the receive is automatically armed as soon as the transmission is complete? And the timeouts are set so that it arms immediately rather than after a short period?
If it’s a rare issue then it does sound like a timestamp related problem. On the DW1000 I ended up performing a sanity check. In some situations I would get an invalid Rx time. It was so clearly invalid that the range results would be rejected as clearly junk but it messed up the transmission timing. I added a check that if the raw Rx time and the calculated Rx time after performing the leading edge detection were over a certain amount apart the I assumed things had gone wrong and threw the data away. You may want to look at the difference in the two values for your system and see if a similar check could help.
I am still in the process of building up a system where the initiators snoop in on each other to synchronize (Coordinating multiple initiators), but this is meanwhile handled by an external wait for del_t period once I1 has either received and processed a response or timed out.
Yes, but any pointers to adjusting the delays/timeouts? I currently try to use POLL_TX_TO_RESP_RX_DLY_UUS + Preamble_length + SFD + PHR + Payload_length < POLL_RX_TO_RESP_TX_DLY_UUS as a starting point.
I do receive at times an ‘invalid’ Rx timestamp, but wasn’t certain if I was messing up or was a wrong timestamp reading even a possibility. I will try figuring out if I can prepare a sanity check for it
