I am working on custom boards with DWM1000 modules and STM32L4 microprocessor. I have already check my communication and everything about the SPI, it works well.
Also my project works very welll with SS-TWR but i want to optimized it with DS-TWR because i have some error. (From Decawave Software 5a-5b-6a-6b)
It’s look like the Initiator work well.
It send the POLL, receive the RESP and send the FINAL msg include the timestamps.
On the other side, the Responder receives the POLL, send the RESP and wait for the FINAL msg. After debugging, I understand that the Responder receives the FINAL msg from the Initiator but at wrong point. It receives the Final msg at the point that the Responder looking for the POLL msg.
I assume that something goes wrong with my Delays from the one Tx to the other Rx.
Here, are my Delays : (initiator)
POLL_TX_TO_RESP_RX_DLY_UUS = 300
RESP_RX_TO_FINAL_TX_DLY_UUS = 3500
RESP_RX_TIMEOUT_UUS = 3300
Am I missing something, you have FINAL_RX_TIMEOUT_UUS set to 3300 us but RESP_RX_TO_FINAL_TX_DLY_UUS set to 3500.
Doesn’t that mean that you’re going to time out 200 us before the final message is sent? Surely FINAL_RX_TIMEOUT_UUS should be at least the message duration longer than RESP_RX_TO_FINAL_TX_DLY_UUS.
I fixed it now, but the final message is not received yet.
There is a case to blame, for the configuration channel and the distance between the two boards (<5m) ?
It being short range shouldn’t matter. You were getting the final message before, just not at the time you were expecting it. Is that still the case? If so can you measure how late the message is in comparison to when you timed out?
(Updated)
Here are my resp_tx_ts and final_rx_ts:
In my rx_buffer now i have the final_msg but at wrong point.
just increased the FINAL_RX_TIMEOUT_UUS to 3800, the other delays are the same as before.
(the whole code is the same as examples 5a and 5b)
It must be calculated somewhere.
Since it is timing out you could always read the time and print it out when it expires. It won’t be perfect but it should be close enough.
When your code times out read the 40 bit time register from the DW1000 to give you a timestamp value that is in the same format as the packet rx and tx timestamps.
You can’t compare times if they are measured on different clocks.
Or if you can’t measure things work it out experimentally. Set FINAL_RX_TIMEOUT_UUS to some absurdly large value like 8000. See if it then works. If it then works decrease it until it starts to fail and then increase but 100 to 200 from that point.
