I’m wondering if setting RXAUTR to 1 actually enables the receiver after an RX error (or after receiving a frame in case of double buffering).
In the EVK_SW package, what the driver does is checking if the [color=#111111][size=small][font=Tahoma,Verdana,Arial,Sans-Serif]RXAUTR [/font][/size][/color]bit is 1 and execute dwt_write16bitoffsetreg(SYS_CTRL_ID,0,(uint16)SYS_CTRL_RXENAB) to enable the receiver. This feels like that the [color=#111111][size=small][font=Tahoma,Verdana,Arial,Sans-Serif]RXAUTR [/font][/size]bit has no real effect on the hardware, the auto re-enable is actually a “manual” RX enable by the decadriver. [/color]
Is my understanding correct? Can someone clarify? Thanks!
Which piece of code are you referring to:
“In the EVK_SW package, what the driver does is checking if the RXAUTR bit is 1 and execute dwt_write16bitoffsetreg(SYS_CTRL_ID,0,(uint16)SYS_CTRL_RXENAB) to enable the receiver. This feels like that the RXAUTR bit has no real effect on the hardware, the auto re-enable is actually a “manual” RX enable by the decadriver.”
The DW1000 auto RX re-enable works as described in the User Manual. It will re-enable the receiver automatically when an error event happens. NOTE - it is generally not used as timestamping errors can propagate when RX is re-enabled automatically after error, as the RX is not reset.
“Note: Due to an issue in the re-initialisation of the receiver, it is necessary to apply a receiver reset after
certain receiver error or timeout events (i.e. RXPHE (PHY Header Error), RXRFSL (Reed Solomon error),
RXRFTO (Frame wait timeout), etc.). This ensures that the next good frame will have correctly calculated
timestamp. It is not necessary to do this in the cases of RXPTO (Preamble detection Timeout) and RXSFDTO (SFD timeout).” - User Manual note.
Thank you for your reply. I was referring to the code in dwt_isr() in deca_device.c under the decadriver directory of EVK_SW_Package.
Once example is:
//fix for bug 622 - LDE done flag gets latched on a bad frame
if((status & SYS_STATUS_LDEDONE) && (dw1000local.dblbuffon == 0))
{
if((status & (SYS_STATUS_LDEDONE | SYS_STATUS_RXPHD | SYS_STATUS_RXSFDD)) != (SYS_STATUS_LDEDONE | SYS_STATUS_RXPHD | SYS_STATUS_RXSFDD))
{
//got LDE done but other flags SFD and PHR are clear - this is a bad frame - reset the transceiver
dwt_forcetrxoff(); //this will clear all events
dwt_rxreset();
//leave any TX events for processing (e.g. if we TX a frame, and then enable rx,
//we can get into here before the TX frame done has been processed, when we are polling (i.e. slow to process the TX)
status &= CLEAR_ALLTX_EVENTS;
//re-enable the receiver - if auto rx re-enable set
if(dw1000local.sysCFGreg & SYS_CFG_RXAUTR)
{
dwt_write16bitoffsetreg(SYS_CTRL_ID,0,(uint16)SYS_CTRL_RXENAB) ;
}
else
{
dw1000local.cdata.event = DWT_SIG_RX_ERROR ;
if(dw1000local.dwt_rxcallback != NULL)
dw1000local.dwt_rxcallback(&dw1000local.cdata);
}
}
}
After reading the manual again, now I’m think that the RX was enabled “manually” in the piece of code above is because [color=#111111][size=small][font=Monaco,Consolas,Courier,monospace](status & (SYS_STATUS_LDEDONE | SYS_STATUS_RXPHD | SYS_STATUS_RXSFDD)) != (SYS_STATUS_LDEDONE | SYS_STATUS_RXPHD | SYS_STATUS_RXSFDD)[/font][/size] is not considered as an receiver error by the hardware. Am I correct?[/color]
in that piece of code, the auto re-enable was used with single buffer, this test was added to make sure the LDEDONE flag was not set incorrectly (prematurely) in cases when the previous frame was an error and RX was re-enabled automatically. Then because of having to do rx_reset the RX is re-enabled if auto re-enable is used.
This is an old API, I would recommend you use the latest APIs (available on Decawave’s website)
Thanks again for your advices. I have adapted my application to use the latest API. It seems that the RX auto re-enable is abandoned in this API (although hardware is still supporting it I guess). Without auto re-enable, even DWT_INT_ARFE event needs to be monitored by the host. But I guess this change will provide more stable performance.
I’m wondering at the moment which events should be monitored by the host now to prevent the RX from staying off unintentionally. My interrupt setting is pasted below, will it be enough? What about buffer overrun in the double buffer mode? The API states “/!\ This version of the ISR supports double buffering but does not support automatic RX re-enabling!” and there is no specific recovery for buffer overrun in dwt_isr(). Does this mean it’s up to the user to implement recovery from the overrun condition?
I see now that the buffer overrun won’t happen, because the receiver is always enabled by the host.
Before finish processing the current received frame, the host won’t enable the receiver. I guess this is a bit less efficient than the “RX auto re-enable” scenario in some cases, but prevents many unpredictable situations.