Hello everyone, I am use DWM1000 modules with STM32L4 microprocessor in custom board.
I have followed the examples 5a and 5b for DS_TWR.
My problem it was that the dwt_starttx(DWT_START_TX_DELAYED) returns error because my resp_tx_time, it is too long.
I have disabled the HPDWARN flag and the dwt_starttx returns SUCCESS but its very slow. It makes > 7s to send the response to the initiator and obviously the RXTIMEOUT disable the rx.
Here is my resp_tx_time = (poll_rx_ts + (POLL_RX_TO_RESP_TX_DLY_UUS * UUS_TO_DWT_TIME)) >> 8;
resp_tx_time:
Also, when i disable the dwt_setrxtimeout(RESP_RX_TIMEOUT_UUS); of initiator.
the message arrive but with a huge delay
chip shall stay in IDLE in between poll_rx & resp_tx, otherwise the R-Marker timestamp of poll would not make sense.
if you are getting HPDWARN, this is a signal that you are attempting to Tx too early in the future. for example if your spi is too slow, that would affect your ability on timings. so chip will transmit, but clock need to turn over ~17sec via 40-bit timer overflow.
would evaluate to a double value. Im am not completly sure what happens when you shift a double, but I guess you do not get the result you expect.
Maybe you should do a cast to uint64 before the shift operation:
I think you should investigate why you are getting HPDWARN flags, instead of disabling them. Because during normal operation they should not occure. Submitting an invalid tx time is most likely the reason for this and if you accidently are shifting a double value, this could be the reason for the error.
Best,
Thorbjoern
EDIT:
AndyA, you are correct. I changed the code snippet.
Thank you
If that is the case then it should be (poll_rx_ts + (uint64_t)(POLL_RX_TO_RESP_TX_DLY_UUS * UUS_TO_DWT_TIME)) >> 8
otherwise the poll_rx_ts would be converted to a double, added to the delay and then the result converted back to a uint64_t which could result in some rounding errors.
Thank you, for your responses.
AndyA, i am not using double in my code, just i print it as double in a temp variable from a ready script.
Otherwise how can i check why the flag HPDWARN is go on?
Do you get this every time or only some of the time?
The first thing I would do when you get the HPDWARN flag is to output all of the time values, the receive time, the time you are setting for the transmit and the current time value from the DW1000 registers.
On the receive side make sure you output both RX_STAMP and RX_RAWST. I have seen issues where the RAW RX time is correct but then due to errors in the edge detection the corrected time in RX_STAMP is junk. In that situation setting a TX time based on RX_STAMP can cause this sort of issue.
Enough that his processor could process things within the allowed time.
How much you need to increase the times is going to depend on your hardware. Similarly how fast you can run the SPI bus is going to depend on your hardware. I have no issues running it at 20 MHz but if you use breadboard or long wires then the maximum speed will be far lower.
Hey Andy I figured out after this that my problem was having long UART wires as I was printing out the data with dw_printf. I think this was causing the biggest delay, so I am switching to custom USB dongle with short traces for data output to computer. Thanks
