SFDLED output pin activation delay

Wireless Connectivity Ultra-Wideband
1

Hi Guys.

I’m trying to use the DW1000 modules to implement a time synchronization system for nodes in a wireless network.

I want to use the pulses generated on the SFDLED pin to capture time stamps on a microcontroller. But in the DW1000 module user’s manual it is not specified what is the delay from the moment the receiver module detects the SFD until the SFDLED pin is activated.

The user’s manual specifies how to configure the duration of the pulse generated at the SFDLED pin, but it does not indicate the delay from the SFD detection to the SFDLED pin activation.

Is this delay characterized or described in any document?

Best regards.

2

Hi Jjps

One of the main features of the DW1000 is generating a precise timestamp on SFD. This is done taking into account even small antenna and transmission line delays that can be calibrated.

Using a pin and recording the timestamp on an external MCU does not make a lot of sense, the time it takes for the signal to travel from the DW1000 to your MCU and for the MCU to detect the GPIO change will already greatly impact the accuracy.

It is not characterised and it doesn’t make a lot of sense to do so. I would guess the delay is insignificant relative to the IRQ / counter delay of your MCU. This delay is typically in the order of μs, the DW1000 deals in orders of ns.

To take full advantage of the DW1000, I suggest using the SPI interface to read the internal timestamp of the DW1000. This will give you a far more accurate synchronisation than what you can achieve with a GPIO pin.

If using SPI is not an option, you might want to try to characterise this yourself, the internal register of the DW1000 should be able to hep you with this.

3

It may make sense if the purpose is transfer of time from node to node for the purposes other than location. For example, using an UWB signal to precisely synchronize wireless nodes to transmit at exact the right times. Perhaps that synchronization is adequate if it is within a few 10s of nanoseconds, and some MCUs can run timers that can capture fast.

In our experience, the IRQ interrupt from the DW1000 on packet SFD is quite precisely aligned with the packet reception. It has about a +/- 4 ns jitter, which comes from the alignment of the internal 124.8 MHz clock of the subsystem inside the DW1000. We use this time mark for precisely aligning the DW1000 time to the processor time using a timer capture input, and then we use that for network slot timing. You can’t use an interrupt routine to do this due to interrupt latency, you must capture the edge in hardware. This is one reason we can do thousands of locates per second in our system.

I don’t know if the SFDLED output is as accurate as the IRQ output. That is something you would have to test. I give it a fair chance it is as accurate, but that’s just using my intuition as to how it would be implemented internally to the DW1000.

Once you have the timer capture on IRQ, you can then read the packet RX_TIME and now you have a precise relationship between the packet arrival time the DW1000 recorded and the processor timer.

If your hardware allows (most don’t), you could run the timer on the same 38.4 MHz clock that runs the DW1000. If you do that, then you only need to learn the offset between them one time and you don’t have to worry about frequency drift.

If you want accurate correlation between DW1000 time and a processor counter, using a timer capture on the IRQ (or maybe the SFDLED) will perform much better than using SPI to read SYS_TIME. The uncertainties with the timer capture are very small, +/- 4 ns due to DW1000 jitter, and then whatever your timer clock period is (20 ns for a 50 MHz clock, say). If your MCU timer is limited in speed, that will hurt precision, of course. It is useful to have a 32 bit counter for this work since it runs at high speed.

Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408

1 Like