Random and very high values of distance between DMW3000 using STM32G4 nucleo

Hello everyone,

I’m using examples: ds_twr_initiator_sts and ds_twr_responder_sts, but values of distance between DWM3000 modules, are random and high values. Where I can try to find a problem? In attachment you can see a values which I get form examples.

distance

Best regard
Mateusz

I want to add that I turned off every WiFi and Bluetooth devices and results are still the same :confused: .

1 Like

That looks more like a random number generator than ranges.

I’d start by outputting the Rx and Tx time values at each end and checking whether they make sense.

Thank you AndyA for response!

TS_Values


There’s are values of time stamps, as you can see variable tof_dtu has negative values, because (Ra * Rb) is smaller, some times tof_dtu has positive values.
But still I don’t know where is the problem :confused:

Something is wrong with your timestamps that you are reading out of the final message.

Poll_rx to Resp_tx works out as about 34 million or around 530us, that seems like a reasonable value. The final_rx value also looks sensible given poll_rx and resp_tx.
But Poll_tx to Resp_rx are 418 million apart or about 6.5 ms, far too long. Similarly the gap from resp_rx to final_tx is completely wrong.

Poll_tx to final_tx also looks a little high, I’d expect it to be almost the same as poll_rx to final_rx and it’s quite a lot more.

If I had to make a guess I’d say at least 2 of the timestamps you are reading from the remote device are wrong which makes all 3 suspect. I’d start by putting some debug code or break points on the other end and check whether the values you are receiving are the ones you think you are sending.

Thank you for the tip,
I checked a frames sending from initiator to responder on the last round and here what I got:
Here is a TX final message which is prepared by initiator:
initiator_live_expre
And here is a message which responder got:
responder_rx_buff

Using red color I marked bytes which have a timestamps from initiator. I checked that initiator include good bytes to msg and this is ok. But responder read from RX_BUFFER bad bytes of timestamps :confused: . I also see that first byte of timestamp form initiator have always 0x01.
Some similar problem got c0-hunterz in this topic:

P.S. I debug all process and read the timestamps by STMCubeIDE and put them to the formula. Calculated distance was good. The problem is probably in sending/receiving or reading from RX_BUFFER in responder or some little configuration. But still don’t know where search a problem :confused:

If you look at the Rx buffer the first 6 bytes of timestamp data ([10] to [15]) match every other byte in the tx buffer ([10],[12],[14] etc…)

To me that implies some sort of array indexing issue or possibly a unit16_t * being used instead of a uint8_t* when transferring the data from the buffer to the DW1000. But it’s odd that the first half of the message doesn’t show this issue.

mmm…

rx[10] byte - 1 ---- tx[10] byte - 1
rx[11] byte - 116 – tx[11] byte - 150
rx[12] byte - 55 — tx[12] byte - 116
rx[13] byte - 127 – tx[13] byte - 204

I see that at the beginning every byte is wrong

But I made some test that put all ‘E’ in the tx_final_msg and disabled code where stm put timestamps to the array:


and here is what responder got:

rx[10] byte - 1 ---- tx[10] byte - 1
rx[11] byte - 116 – tx[12] byte - 116
rx[12] byte - 55 — tx[14] byte - 55
rx[13] byte - 127 – tx[16] byte - 127

The chance of this happening due to random data corruption is tiny. It’s almost certainly due to a firmware bug. Probably on the Tx side.

1 Like

Rather than putting E into every byte put A,B,C,D,E,F,G…
I bet you get A,C,E,G,H,J in the Rx buffer.

What is your code that copies the final Tx message from the processor into the DW1000 Tx buffer?

There are a functions:


There is a body of function “final_msg_set_ts”:

There is a body of function: “dwt_writetxdata”:

There is a body of function: “dwt_writetxfctrl”:

dwt_writetodevice:

do you need also dwt_xfer3000?

Yes you are right:

It is possible that at the beginning of the frame are bytes that indicates:
“- byte 0/1: frame control (0x8841 to indicate a data frame using 16-bit addressing).”


and after byte 9 higher bytes are reading by 16bit?

Maybe. I don’t use that API so I can’t say what it may be doing to the data.
The values in your Tx buffer in memory are correct, your write to the chip doesn’t distinguish between the header and the data and the header is coming out correct but the data isn’t. So that’s as good a theory as any.
How are you reading the data? Is it some function that attempts to parse the received data or is it a straight read from the chip into a memory buffer? The chip itself doesn’t do anything based on the packet data contents so any assumptions as to 8/16 bit data would have to be in the driver layer.

It’s a simple read using non-double rxbuffer mode.


body:

OK, I’m at a loss to explain this.
You have the correct data in a memory buffer.
You copy that data to the DW in a single transfer.
You receive the data.
You copy the data from the DW in a single transfer.
The data in the rx buffer is correct for the first 10 bytes and then missing every other byte.

I’m assuming that when you’re showing the buffer contents that’s from a debugger reading the processor memory so there is no chance that what you are showing is wrong.

I would say to read the data back out of the Tx buffer to see what’s there but the manual indicates that it is write only. :frowning:

How many bytes do you think you are receiving? Does the Rx size match the expected value or is it short by the number of bytes missing? That would only tell you how many bytes were sent/received, not whether they were the correct bytes so I’m not sure if it tells you much but if it’s incorrect then that’s a clue.

This is really grasping at straws but any chance it’s a hardware related issue? Your SPI bus read or write goes wrong for transmissions over a certain length? Either putting a scope on it or splitting the transfers into two blocks with appropriate offsets into the rx/tx buffers would allow you to test this.

1 Like

Ok I understood, you helped mi a lot :muscle: :+1:!
The frame length is ok,
Yes unfortunately the TX buffer is not supported to read :confused:
Maybe now I must try to find some bugs in the SPI just like you said :frowning:
If I find something i will post this.

Thanks!

Ahhhh I found the problem…
Problem was in function readfromspi where receive function was wrote in LL(Low Layer) [If I will have time, will try debug LL], in comment above was wrote that HAL function had problem with reading bytes (but this API was wrote a few years ago). Now I backed to HAL_SPI_Receive function and everything is ok (thank God).
Here is a body function:

and here are good results about distance!:
obraz

@AndyA thank you very much that you devoted your time to help find problems and gave tips how to search bugs!

Best regards
Pianista

1 Like