DW1000 Calibration

Hi,

We are developing tracking device using DW1000. As we refer the user manual, it seems some calibration we have to do for Antenna delay, crystal frequency etc.

Is it required to do Antenna calibration, crystal trim value calculation etc…and store in OTP memory by us or it is stored in OTP memory by decawave during chip manufacturing?

If so what all parameters requires calibration by the customer. Please provide the method for doing that.

Regards,
Shijo Thomas

Since the antenna and crystal are selected and attached to the DW1000 by the user it would be impossible for Decawave to store these values in the chip during manufacturing,

Antenna delay and crystal tuning must be done by the end customer after system assembly. They will be different between units and so if you want the best possible performance every unit must be calibrated individually. How much variation there is unit to unit will depend on your design.

To give you an idea of how sensitive things are, in my testing a loose SMA connector to the antenna would add around 5 cm to the delay.

The values can be stored either in the DW1000 OTP or in your owm flash/OTP memory, it depends how you write the firmware.

Methods for calibrating these things are in the decawave application notes.

Hi Ansell,

Thanks for the information.

Is there any demo project available for antenna delay calibration?

Regards,
Shijo Thomas

I’m not aware of a demo project specifically for antenna calibration but one may exist.

The reason there probably isn’t one is that all that is required is a ranging system or a positioning system that gives access to the raw ranges and a way of measuring the true positions. Why make a special demo when the standard ones do everything required.
e.g. with a 2 way ranging system you need 3 units and something like a laser range finder.
Measure the distances between each unit using radio (average 100+ ranges) and using the laser, take the differences and then calculating the delays for each unit comes down to maths as given in the app note.

For a TWR system you need 3 tags in order to know where the error is, with 2 you can tell the total delay for both units but can’t tell how much is from each unit.
For a TDoA system calculating the absolute delay on the receive antennas isn’t possible but you only need the relative delay between them which is easy to find.

The system I use is TWR based, rather than only calibrating 3 at a time I will put 7-8 tags in known locations and measure all possible ranges between them giving me 20+ measurements for 8 unknowns. I then use a least squares calculation to find the delay values that minimize the range measurement errors. By over determining the solution I reduce the impact of a bad measurement and also gain a method of detecting poor or inconsistent results.

@AndyA

e.g. with a 2 way ranging system you need 3 units and something like a laser range finder.
Measure the distances between each unit using radio (average 100+ ranges) and using the laser, take the differences and then calculating the delays for each unit comes down to maths as given in the app note.

  1. Is the maths as simple as: Total Antenna Delay = (distActual - distMeasured) / Speed of Light.
  2. Once I find the Total Antenna Delay, how do I set the TX_delay and RX_delay? Are they both equal i.e half the Total Antenna Delay.

I then use a least squares calculation to find the delay values that minimize the range measurement errors. By over determining the solution I reduce the impact of a bad measurement and also gain a method of detecting poor or inconsistent results.

Where could I find more information regarding the Least Squares algorithm? Is it the same as Least Square Regression. Could you expand on how you calculate the delay values based on the range measurements using Least Squares.

  1. Yes. In my system all of the antenna delay setting code stores the delay in meters rather than seconds. The final conversion to DW1000 clock ticks (divide by c, multiply by DW1000 clock rate) is only done right before writing to the registers. I started this way because for the prototypes I initially used zero delay and then in post processing applied the corrections to the measured ranges. I kept it that way after the delays were moved to the DW1000 delay registers because it makes the numbers nicer to work with and personally I find it easier to visualize.

  2. Yes, assign half the delay to each. This may not be perfect but it’s generally close enough. Especially when dealing with two way range systems where round trip timing is used so you always have the same number of transmits as receives.

  3. Yes, a least square regression is the same. My initial prototype system used a python script to do this, I’ve dug out a copy and attached it below. It uses the scipy library for most of the work. We don’t use this any more, it’s been moved into a c# application, but the basic concept remains the same.
    This same technique can, with sufficient anchors, be expanded to also estimate the anchor locations. Even under ideal circumstances (an empty field) this will get things a few cm wrong, indoors with obstructions it can get a lot worse. But depending on your environment it can be good enough for a quick and dirty setup or as a sanity check to ensure that the setup is good e.g. you don’t have two anchors swapped over.

CalAntennas.py (1.9 KB)