Crystal used in modules

which crystal is used in DWM1000, DWM1001, DWM1004, TCXO or normal crystal ?

1 Like

Hi,

On those modules (and all other availible modules) we use a 38.4MHz “normal” / quartz crystal oscillator. The DW1000 has internal crystal trimming capacitors allowing compensation due to frequency drift due to temperature changes. See section 5.2 Reference Crystal Oscillator in the DW1000 user manual, 2.2 DW1000 oscillator and quartz crystal in APS011: Sources of error in TWR schemes.

For examples, see PCN019 for the DWM1000, the DWM1001 schematic and BAMO, and the DWM1004 schematic.

How about removing the stock crystal and adding a TCXO?

Do the internal trimming capacitors mess up the frequency with respect to temperature change rather than improving the frequency when the Xtal is changed to TCXO?

This would be possible, but requires the metal shield can to be removed. This is not a trivial operation that can easily break the module or impact its performance.

Can you tell us why a TCXO would be a requirement for your use-case? Note that TCXOs often have more phase noise than regular crystals, low phase noise TCXOs are often expensive.

I suggest going for a chip down solution if a TCXO is a hard requirement or to use the modules with a crystal. Thanks to the crystal trim feature it is possible to minimise the CFO between devices even over a wide temperature variation.

1 Like

The trimming resistors should be disabled (set to 0x00) when a TCXO is used. Some TCXOs might require a load capacitance, but in this case I would suggest using a discrete capacitor.

We want to build anchors for TDoA, TCXO is more suitable for TDoA anchors than Xtal.

Unfortunately, it isn’t that simple.

See note in DW1000 Datasheet table 1 regarding VDDBATT:

“If a TCXO is being used with the DW1000 this pin should be supplied by the regulated supply used to power the TCXO.”

And see figure 37, the reference schematic, which shows an LDO and TCXO being used.

If you want to use a TCXO for your nodes, you basically have to build full custom nodes. Modifying an existing DWMxxxx module is not practical.

That being said, you can build a TDoA system without TCXOs as long as the anchors are not subjected to rapid swings in temperature.

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

We are going to use same external clock signal for all anchors through ethernet cable , It will probably solve the frequency drift issues.

That can be complex and tricky to do reliably.

See threads on the forum for issues some have had with wired synchronization, for example:

If you do manage to develop a wired clock distribution scheme, then it does solve the clock drift between nodes, they will always be the same clock rate.

But you do have to learn the offset between nodes since the clock delay to each node will vary even if you take extreme care to match cable lengths. This is because every DW1000 chip has a variation in the clock delay input buffer. Further, cable delay is not uniform and varies from cable to cable, and also with temperature and flexing.

What this means is that even with a distributed clock, you still need some form of periodic over the air synchronization process to keep the anchor nodes precisely time aligned. If you don’t and only perform a one time offset calibration, that will drift over time and temperature leading to less accuracy in location.

If you are going to periodically send packets for calibrating the offset, then you are already generating the data needed to perform modeling of the clocks at each node without needing the wired synchronization. Thus this is the most common approach to the problem and you rarely see systems with wired synchronization.

The most trivial form of over the air synchronization is using a single master time node which periodically broadcasts a time stamp packet. This node is received by all the anchors, which means the anchor array size is limited to one reception radius. As each tag packet is received at anchors, the anchor interpolates the tag received time between two time stamp packets and thus all tag packets end up in the master time node’s time domain.

The above is how our CUWB 2 system worked, single master time node. Later we developed the mesh synchronization algorithm we now use in CUWB 3 which has no reliance on a single master and breaks the single reception radius limitation.

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

1 Like

when the DW3000 will launch?, Is any engineering sample available for development?