We’re troubleshooting a new custom PCB design based around the DW3120, building on previous development done with the DWM3000EVB. Initial tests are a simple 2-way ranging and checking for errors. This is on a benchtop, with no more than 30 cm between modules, When using 2 custom PCBs, there are lots of errors. However if we use a custom PCB with a DWM3000EVB, the TWR works flawlessly, regardless of which board is set up as TX and RX. On the custom PCB we’re using a 2.5ppm TCXO running from the 3.3V rail. The DW3120 is running all supplies from the same 3.3V rail, a configuration suggested in the DW3120 data sheet for reduced component count. I’ve read several posts on troubleshooting DW1000-based hardware, and understand that a clean, low-jitter clock is crucial, and at least for the DW1000 a separate LDO for the clock is strongly recommended. As far as I know here is no such recommendation for the DW3120. We have a ferrite bead and a 10uF with a 0.1uF capacitor at Vin of the TCXO. Here is a screen shot of the clock signal.
This was measured at the input of the DW3120. The signal path from the TCXO is a 24.9-ohm resistor in series at the output, then through the recommended 2200pF series capacitor to the DW3120 at XTI. XTO is left floating. I know the overshoot is not ideal, but I’m not sure if it’s enough to cause a problem. I did a persistence measurement to check jitter and it appears to be well within spec (< 1 ps).
The fact that the custom PCB works fine when paired with a DW3000EVB is significant, but I’m not ready to state that the clock is not still at least part of the problem. For the next step, we plan to tune the termination to try and eliminate/reduce the overshoot. We might also try to work in an LDO mod (DW1000 recommendation) to see if that helps.
Any other suggestions for trouble-shooting would be greatly appreciated.
From memory the issue with a lot of TCXOs these days is that they use a digital compensation system which results in step changes in frequency and so can have a lot of phase noise when PLLed up to 8 GHz. Older parts with analogue compensation networks don’t have these issues and so perform far better.
Is there any easy way you could fit a crystal in place of the TCXO? Unless you need to operate over a wide temperature range then the crystal tuning setting can get you to under 1 ppm for normal usage and eliminates this as a possible source of issues.
Another gotchas that I’ve seen moving hardware is on the algorithm side. The antenna delay can be significantly different. The firmware uses the old values, calculates negative times / distances and rejecting the results as clearly junk.
Thanks for the advice AndyA. We have a working solution now. I looked into swapping the TCXO for a crystal, but it was just too difficult of a fit. Instead I voltage-limited the TCXO supply to around 2 Volts by using an appropriate sized resistor in place of the ferrite. The clock signal now looks more “crystal-like” with no overshoot. There’s more testing to do before we celebrate, but for now the results look promising. Thanks again for you help.
AndyA, I don’t know if you’re still monitoring this thread, but I wanted to provide an update on our testing and troubleshooting. As I last mentioned we had success with TDOA performance after trimming the TCXO power to eliminate the overshoot. Despite this success, we still have a range limitation of about 6m with two custom PCBs, and about 30m when using a custom PCB and a DWM3000EVB. My question is, could this still be related to clock signal quality? Otherwise I’m looking at potential problems on the RF side. This design has a dual external antenna (for the PDOA option) that is connected to end-launched SMA connectors. I’d like to get a spectrum analyzer to measure the magnitude of losses and/or interference. We’re under the assumption that when PDOA is inactive, the additional hardware will not affect TDOA.
Again, I appreciate any advice you or any other user has to offer.
With the same radio settings what range do you get using two DWM3000EVB?
With some quick in my head maths I make it about 15dB of gain difference to go from 6m to 30m. If changing one antenna gives you 15 dB then changing both should give you 30 dB more, enough for almost 200m range. Although I’d expect you to start getting other effects at those ranges so that probably isn’t realistic unless you can get the antennas a long way off the ground. But you should get a reasonable further increase.
Do you get the same range Custom to DWM as you do DWM to Custom or is there a difference? Clock and antenna issues I’d expect to be fairly symmetrical. Noise and distortion getting into the power amp would impact the Tx side more than Rx and so would have an asymmetric effect.
My gut call is that it’s probably still the clock. You had a know issue that was fixed in a less than ideal way, that makes it suspect at best. I would make it my first point to investigate although how much you can do there without a board re-spin is questionable, hacking clocks onto existing boards in a way that works well isn’t easy. Maybe a small module board that goes in place of the TCXO and implements new circuitry. Or remove the TCXO and strap in the clock from an DWM3000 module.
To answer your questions: With EVB to EVB we are able to get well over 100m range with no errors. The 30m range limitation with EVB to Custom is the same regardless of which one is the initiator.
With a little more effort we were able to fit a 10ppm crystal oscillator in place of the TCXO. This did not improve the range performance one bit. We may be dealing with an antenna issue as you mentioned, or maybe the RF path on the custom PCB itself. We’re going to schedule some testing in a RF chamber this week. Hopefully that will shed some light on the problem.
Thanks again for you helpful insight.
maybe a stupid question but the DW3120 have two RF outputs - double check that you are using the correct one. If you use incorrect one ant the port is not properly terminated then you can easily communicate over the unconnected RF port and something like 4-6m is doable.