Τoo Long timestamps

[kostas_deca]

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

Does anyone know what is going wrong?

Thank you,
Kostas

[alliv]

1. are you sure your arithmetic is uint64?
2. chip shall stay in IDLE in between poll_rx & resp_tx, otherwise the R-Marker timestamp of poll would not make sense.
3. 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.

[kostas_deca]

Hello, thanks for reply .

1. Yes it’s uint64, just i print it in double variable.
2. I noticed that my SPI it was too fast (72Mhz) and i reduced it, in 1 Mhz. But i don’t see any difference. dwt_starttx(Tx_delayed) returns ERROR

[ThoMumme]

Hi kostas_deca
Is it possible that UUS_TO_DWT_TIME is a double or float value?
If so, the whole statement:

(poll_rx_ts + (POLL_RX_TO_RESP_TX_DLY_UUS * UUS_TO_DWT_TIME))

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:

(poll_rx_ts + (uint64_t)(POLL_RX_TO_RESP_TX_DLY_UUS * UUS_TO_DWT_TIME) ) >> 8

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

[AndyA]

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.

[ThoMumme]

AndyA, you are correct. I changed the code snippet.
Thank you

[kostas_deca]

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?

[AndyA]

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.

[kostas_deca]

Yeah i am getting that values every time.
This is for resp_tx_time.

[AndyA]

And when setting those TX times what are the RX time, the raw rx time and the decawave internal clock times?

[kostas_deca]

Hello anyone.

After from a lot searching and reading. I solved it.
So firstly i reduced the spi rate at 2 MHz and i increased the Delays:

RESP_RX_TO_FINAL_TX_DLY_UUS
RESP_RX_TIMEOUT_UUS

POLL_RX_TO_RESP_TX_DLY_UUS
RESP_TX_TO_FINAL_RX_DLY_UUS

Thank you for your support and your time.