SFD timeout errors

When doing DS-TWR ranging in good radio conditions where distance or any radio obstacles should not be issues, I still get SFD timeout errors (RXSFDTO flag in the status register) every now and then. The error happens when the DS-TWR responder is trying to receive the poll message from the DS-TWR initiator. This happens less than once in every 1000 measurements, but still quite regularly.

The error happens with 110k bit rate (Ch 5, PRF 64MHz, PLEN 1024, PAC 32). If I change the bit rate to 850k (PLEN 512, PAC 16) the error is much less frequent (less than once in a million measurements).

Having 0.1% of measurements fail is not catastrophic, but I was still wondering if someone would know what could be causing that, or is it just normal RX noise and to be expected to happen at this rate? The SFD timeout settings are correct and I have tested with “too long” timeouts (so there is no real timeout due to SFD not being present, but instead a failure to detect the SFD when it is there).

There is nothing exotic in the DS-TWR implementation and it is essentially similar to the Decawave example. This also happens when using two Trek devices as initiators and responders, so it is not a HW issue related to our hardware specifically.

DW1000 receiver is tuned this way, to give certain number of false positives (preamble detections) this improves RX sensitivity, but will every so often detect preamble from noise and then get SFD TO as no SFD present. 1 per second or so would be expected rate.

I met this problem too,one send to another one is OK,but when reverse it will cause SFD error,you mean it may becuase of noise,but why one side is OK and other side is bad.how can i to confirm this?

Hi there, I am new to UWB and need some help understanding if the SDO timeout frequency I observe is expected or “normal”.

I did a test on a DW1000 with the receiver being reenabled after every error and measured the average SFD timeout period. There are no transmitters in range (hopefully), so the air is “silent”. Under those conditions I get an SFD timeout on average every 7 seconds with this configuration:

dwt_config_t config = {
2,
DWT_PRF_64M,
DWT_PLEN_1024,
DWT_PAC32,
9,
9,
1,
DWT_BR_110K,
DWT_PHRMODE_EXT,
(1024 + 1 + 64 - 32)
};

But measured an average 0.15s between SDF timeouts with this configuration:

dwt_config_t config = {
4,
DWT_PRF_64M,
DWT_PLEN_2048,
DWT_PAC64,
20,
20,
1,
DWT_BR_110K,
DWT_PHRMODE_EXT,
(2048 + 1 + 64 - 64)
};

Is this expected?

Hi @carlos1,
I don’t think this error was expected, because the bit RXPREJ in SYS_STATUS don’t have a mask so you can’t easily reEnable the receiver with an interrupt, so you need to always ask for the SysStatus and check for RXPREJ.

I am not an expert but I think it’s normal that different config gives those different average time since it depends on the region where you are, the others frequency used that can leak in yours and create interference, create those false preamble .

I tried the first configuration you proposed wich is suppose to average to 7 seconds of up time until the false preamble but in my case. The receiver detect a false preamble after minimum 30 ms and maximum 4s.
I am programming from zero my code for this using an esp32. Instead of stopping to SFD timeout, my Dwm1000 detect an SFD but than stop at RXPHE. A phy error with 2 bit or more that were “lost”. Theres is only one time that I saw the SFD timeout and than 10 ms later the RXPHE was up and not the SFD anymore.

If you know anything that could help me please do so. I am also going to create a new topic since this one does’nt receive attention anymore and my problem is sligthly different even if I think it’s the same source. A false detection of the start of a preamble

Thanks for the help