Here is an interesting bit of code:
poll_rx_ts = get_rx_timestamp_u64();
resp_tx_time = (poll_rx_ts + (POLL_RX_TO_RESP_TX_DLY_UUS * UUS_TO_DWT_TIME)) >> 8;
dwt_setdelayedtrxtime(resp_tx_time);
uint32_t resp = dwt_starttx(DWT_START_TX_DELAYED);
This fragment of code is executed in the receiver application, when it receives the initial request for for ranging. The receiver sets up the DW to send back a response message after a fixed delay. It does this by reading the timestamp recording the instant the packet was received. Then it adds on a fixed delay, and then tells the DW to transmit at that time.
In my code the dwt_starttx function returns an error indicating that the transmit delay isn’t long enough.
In the code intended to run on the ARM M3 the constant POLL_RX_TO_RESP_TX_DLY_UUS is 330 (uS). In my M0+ code it has to be a lot larger. My code is not optimized and so far I have found that the value needs to be: 2200 > POLL_RX_TO_RESP_TX_DLY_UUS > 2300
On the init side I will have to extend those values too. No idea what to set there, but obviously bigger.
/* Delay between frames, in UWB microseconds. Was 140 */
#define POLL_TX_TO_RESP_RX_DLY_UUS 2000
/* Receive response timeout. See NOTE 5 below. Was 210 */
#define RESP_RX_TIMEOUT_UUS 3000
Yay!
This is single-sided one-way ranging and it is very inaccurate, though better than Nanotron, and RSSI. Obviously my random response timings are very long, which is a substantial source of error, and my antennae delays are not calibrated.