DW3000 / DWM3001CDK – When to use OSTR + EXTCLK vs GPIO‑based SYNC for TDoA?

Wireless Connectivity Ultra-Wideband
1

I’m using DWM3001CDK boards as anchors in a TDoA RTLS system (DW3_QM33_SDK_1.1.1, custom Anchor_RX firmware). Right now my setup is:

  • Each anchor runs off its own internal clock (no shared 38.4 MHz EXTCLK).

  • A Raspberry Pi sends a SYNC pulse (GPIO18) to all anchors on P0.28.

  • On each rising edge, the firmware calls dwt_readsystimestamphi32() and logs:

SYNC A= TS=0x00HHHHHHHH COUNT=

RX A= … TS=0x<40‑bit RX timestamp> …

  • On the server, I use these SYNC timestamps to fit a linear clock model per anchor and map all RX timestamps into a common timebase before running TDoA. This is working well; SYNC and RX TS are stable and increasing, and I get reasonable positions.

I’ve read the DW3000 User Manual section 7.1 External Synchronisation and the description of One Shot Timebase Reset (OSTR) Mode and EXT_SYNC (register file 0x04). My understanding is:

  • Full OSTR mode assumes a shared 38.4 MHz reference clock on EXTCLK + SYNC, and lets the DW3000 reset its internal timebase deterministically.

  • With that setup, all anchors’ timebases are effectively the same counter (apart from cable delays).

My questions:

  1. For a practical indoor TDoA system with DWM3001CDK anchors, is Qorvo’s recommended approach today:

  • (A) the simpler GPIO‑based SYNC + software clock‑sync (what I’m doing now), or

  • (B) the full OSTR + 38.4 MHz EXTCLK + EXT_SYNC configuration as in the DW3000 manual?

  1. If I stay with independent clocks + GPIO SYNC:

  • Is using dwt_readsystimestamphi32() on each SYNC edge the correct and supported way to timestamp pulses for DW3000‑based TDoA?

  • Are there any accuracy or long‑term stability limits you recommend I keep in mind (e.g. expected drift over minutes/hours, typical achievable ranging error)?

  1. If I later decide to implement OSTR with a shared 38.4 MHz clock:

  • Are there any DW3000‑specific example settings for the EXT_SYNC / EC_CTRL registers (e.g. recommended OSTS_WAIT values) beyond what’s in the datasheet?

  • Is OSTR officially supported and validated on the DWM3001CDK hardware, or is it mainly targeted at custom DW3000 designs?

Any guidance on which approach Qorvo recommends for a multi‑anchor DWM3001CDK TDoA deployment (and any pitfalls to avoid) would be very helpful.

2

Hi,

I’m also developing a TDoA RTLS system using DW3000-based hardware (DWM30 shields with the DW3 SDK), and I’m currently running into clock drift issues that prevent me from getting stable or accurate TDoA results. Implementing a shared 38.4 MHz reference across anchors seems quite complex in my setup, so your GPIO-based SYNC approach is especially interesting to me.

Would you mind elaborating a bit more on the procedure you’re using?

In particular, I’d love to understand:

  • How you generate and distribute the SYNC pulse (rate, jitter considerations, wiring length, etc.).
  • How exactly you build the linear clock model per anchor on the server side ( fitting method, update window, how often you resync).
  • How you handle clock drift over longer periods, do you continuously refine the model or periodically reset it?
  • Any practical tips you’ve learned (SYNC frequency, minimum number of points, pitfalls to avoid).

Right now, independent clocks are giving me noticeable drift over time, so seeing a concrete, working software-sync approach would be extremely helpful before I attempt a shared clock or OSTR-based design.

3

The method with RPI gpio cannot get any closer required precision for TS.

Yes, the OSTR can work, gggbut it is problematic as you cannot neglect the temperature effect when distributing clock sync pulses. Calculate the effect to thd length of the cable and you’ll be surprised.

On the practice the Wireless Clock Sync is the most useful.

Good luck.