I’ve enabled the Double Buffer using the API dwt_setdblrxbuffmode(1). The ex_02e_rx_dbl_buff example works perfectly (continuous receive mode).
If the API dwt_starttx() is called after the SYS_STATUS_RXFCG event, the peer DWM1000 does not receive the packet (no transmit error). If a dwt_forcetrxoff() is introduced after Rx and before Tx the packet is received on the peer.
Can someone share a working example of the scenario? Or TWR example with dwt_setdblrxbuffmode(1)?
The DW1000 IC can either do TX or RX, if it is already in RX then you need to call force TRX off to put the IC in IDLE before issuing a new command (e.g. TX).
Use of auto RX re-enable is not suggested, you could have timestamping issues (errors) if you use auto RX re-enable (as the first path detection algorithm is not initialised properly on error frames). Thus the example does not use this mode.
Ok, I’ve tried the dwt_forcetrxoff(), but a subsequent packet transmitted by the peer is missed (or interrupt not triggered). I suspect that the API dwt_syncrxbufptrs() called by dwt_forcetrxoff() has some effect.
Attached call setup detail:
Would help if someone can share an example of DS-TWR with dwt_setdblrxbuffmode(1) (with manual RX re-enable?)
so after responding you are using wait4response to enable the receiver. And then, you are saying that anchor just stays in RX until the next Poll? Do you enable RX in time for the Final? maybe you are too late, and the final is missed? can you give more details/steps/configuration of DW IC during the interaction shown.
POLL Requests are 1 s apart. Yes it just stays in RX till the next POLL, i don’t enable the RX for the FINAL or the POLL (EDIT: Always ON RX and No Timeout specified, and DWT_RESPONSE_EXPECTED is set). This is the same as the DS-TWR example, execept that i’ve used the 110Kbps config EDIT: and Always ON RX (No Timeout)
This below config works just fine if i dont set the dwt_setdblrxbuffmode(1). Let me know if you need more info.
//These values are for the 110kbps mode (5, 16MHz, 1024 Symbols)
static dwt_config_t config =
{
1, /* Channel number. /
DWT_PRF_16M, / Pulse repetition frequency. /
DWT_PLEN_1024, / Preamble length. Used in TX only. /
DWT_PAC32, / Preamble acquisition chunk size. Used in RX only. /
4, / TX preamble code. Used in TX only. /
4, / RX preamble code. Used in RX only. /
1, / 0 to use standard SFD, 1 to use non-standard SFD. /
DWT_BR_110K, / Data rate. /
DWT_PHRMODE_STD, / PHY header mode. /
(1025 + 64 - 32) / SFD timeout (preamble length + 1 + SFD length - PAC size). Used in RX only. */
};
#define TX_ANT_DLY 16436 #define RX_ANT_DLY 16436
/* Delay between frames, in UWB microseconds. See NOTE 4 below. /
/ This is the delay from Frame RX timestamp to TX reply timestamp used for calculating/setting the DW1000’s delayed TX function. This includes the
frame length of approximately 2.46 ms with above configuration. */ #define POLL_TX_DLY_UUS 2000 #define POLL_TX_TO_RESP_RX_DLY_UUS 140 #define POLL_RX_TO_RESP_TX_DLY_UUS 4000
/* This is the delay from the end of the frame transmission to the enable of the receiver, as programmed for the DW1000’s wait for response feature. */ #define RESP_TX_TO_FINAL_RX_DLY_UUS 500 #define RESP_RX_TO_FINAL_TX_DLY_UUS 4000
/* Receive final timeout. See NOTE 5 below. */ #define FINAL_RX_TIMEOUT_UUS 3300 #define RESP_RX_TIMEOUT_UUS 2700
/* Preamble timeout, in multiple of PAC size. See NOTE 6 below. */ #define PRE_TIMEOUT 8
Ok, I think I’ve found the bug, dwt_forcetrxoff() calls dwt_syncrxbufptrs() -> Wich resets the host side receive buffer pointer.
But for this use case, since the dwt_isr() already toggles the Host side Receive Buffer Pointer, this function call is not required.
I tested this by duplicating the dwt_forcetrxoff() function without the dwt_syncrxbufptrs(), and the fix worked.
@Decawave folks, kindly include this in your next software release.
I’m probably hijacking this thread a bit, but I think I have a somewhat related issue, even if double buffering is not enabled. I could not find anything either in the API manual or in the DWM1000 user manual that suggests that the DW1000 can only handle either RX or TX :-/ .
In my use case I’d like to keep the receiver running and have a delayed transmit waiting for its time, but that obviously does not work.
How am I supposed to handle such a situation? The point is that the calculated transmit time is generated with a certain jitter, but I don’t like to loose incoming messages for the time between the calculation and setup of the transmission (with delay) and the actual transmission.
If I could live with that do I have to explicitly turn off the receiver, start the transmission and on completion re-enable the receiver?
Is there another method which has less over-head to keep the receiver outage as short as possible?
[hr]
Ok, missed the state description:
Note that it is not possible to be in the TX and RX states simultaneously – the DW1000 is a half-duplex transceiver device.