Hi, I’m trying to implement this 1 side (so basically one round trip) ranging scheme.
The problem so far is that the responder can receive the ranging request from the initiator, but when responder send back the respond message, with delayed transmission, the initiator consistently fails to receive it.
Code snippet below:
uint32 resp_tx_time;
/* Retrieve poll reception timestamp. */
poll_rx_ts = get_rx_timestamp_u64();
/* Set send time for response. See NOTE 8 below. */
resp_tx_time = (poll_rx_ts + (POLL_RX_TO_RESP_TX_DLY_UUS * UUS_TO_DWT_TIME)) >> 8;
dwt_setdelayedtrxtime(resp_tx_time);
/* Set expected delay and timeout for final message reception. */
dwt_setrxaftertxdelay(RESP_TX_TO_FINAL_RX_DLY_UUS);
dwt_setrxtimeout(FINAL_RX_TIMEOUT_UUS);
/* Write and send the response message. See NOTE 9 below.*/
memcpy(&tx_resp_msg[11],&dist[TAG_ID],2);
tx_resp_msg[ALL_MSG_SN_IDX] = frame_seq_nb;
dwt_writetxdata(sizeof(tx_resp_msg), tx_resp_msg, 0);
dwt_writetxfctrl(sizeof(tx_resp_msg), 0);
dwt_starttx(DWT_START_TX_DELAYED | DWT_RESPONSE_EXPECTED);
If you interrupt one of the communications right in the middle and read the 0x2F register, you get a readout typically like this:
My questions are:
I get the feeling that my delayed sent is synchronized with the initiator’s delayed receive, in a really bad way, in other words, the send misses the receiving window every time. Is this likely?
Other than #1, can you please share some of the possibilities regarding where the problems might be?
Other than reading 0xF and 0x2F - any other ways that I can get more diagnose information regarding where the problem lies?
Is the algorithm for calculating delayed transmission time correct?
Please help! Thanks in advance. And if further details are needed, feel free to ask, and I will update this thread promptly.
From what I understand your transmitter sends a message and then waits a certain time before enabling its receive.
Your other device receives a message, waits a fixed time and then transmits its reply.
You have the Rx enable delay and the TX delay set to the same values. But the Tx delay is timed on one systems clock, the Rx enable delay is timed on a different systems clock. These clocks will be running at very slightly different speeds which means your Rx may be enabled a little late.
To be honest I wouldn’t have through this would matter much, it would cost you a small amount of preamble reception but that shouldn’t stop it working.
Have you tried disabling the Rx enable delay and Rx timeouts? Simply enable Rx as soon as the transmit is finished and keep it enabled? Not good from a power consumption perspective but it eliminates a possible cause of problems. You can then turn on the power savings one at a time once you know it works without them.
That is odd. My application doesn’t care about power so I have Rx enabled all the time, I never even touch those options since they default to off. I’ve not had any issues with not receiving something other than when there were configuration issues.
Since you can receive the first packet that would tend to rule out any fundamental configuration mismatch type problems.
You’re correct in thinking you can’t have both enabled at the same time.
But you can send disable Rx / go to idle followed immediately by enable Tx (or enable scheduled Tx).
And you can set an option on the Tx to enable Rx as soon as it’s complete with a delay of zero.
So you can have Rx enabled at all times other than when actively transmitting. And you can leave it enabled for hours without receiving anything without any issues other than increased power usage.
You should manually disable Rx before enabling Tx, on the DW1000 I think you can get away without doing this but it’s cleaner to. On the DW3000 you get an error if you don’t return to idle first.
