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.
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
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:
And here is a message which responder got:
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 . 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
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.
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).”
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.
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.
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.
Ok I understood, you helped mi a lot !
The frame length is ok,
Yes unfortunately the TX buffer is not supported to read
Maybe now I must try to find some bugs in the SPI just like you said
If I find something i will post this.
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: