Antenna delay calibration

Has anybody tried to apply Decawaves antenna delay calibration algorithm ? I am trying to implement python script to calculate it but I stucked on one thing. In the APS014 document on 9’th page in the graph there is a step : “Select the best 25% of the set and include them in the new set.” The question is, on which criteria should select them?

Anybody ? :slight_smile:


Hi Barosz,

We did something on our own which works perfectly nice.

Most important, you have to be outside the range bias of the DW1000. Therefore you have to maintain a minimum distance. I recommed that you start at the recommend value (somewhere in 32000) from Decawave and than increase the delay by like 100 ticks, Record the read distances and employ a polynomial interpolation to match the expected distance vs. the record distance.

Again, mind the range bias of the DW1000.


I was actually just doing some antenna delay calibration yesterday.

I just took measurements at several different delay values (from around 16,000 to 22,500), each at a couple different distances (50cm, 150cm, and 250cm). And then did a linear fit mapping delay value to the error. After I solved for the zero-error value I plugged that delay in and re-tested, and got within 10cm for each of my 3 test distances.

I started at 16436, which is the default value from the DecaRanging application, and ended up using 21839.

Do you have documentation on the range bias?


Well, this may work until you don’t need to calibrate antenna delays for several devices. It is just much more convenient to code algorithm once, and then just place devices on calibration area and run a script :slight_smile:

Hi Spencer,

sure I have!

It is on page 11. The range bias is basically the non linear error, therefore it is not only a offset but a range depending offset. Decawave employs for the demokit an look up table to correct the estimated range. If you don’t do any range bias correction, and you make some measurements, you will notice the the error looks something like shown in Figure 11.


Thanks. That’s a great resource.

So if the timing error is based on RX power at the receive pin, would it make sense to apply the correction to every RX timestamp based on the estimated RX power (section 4.7 of the DW1000 manual)? I suppose there’s a performance trade-off because you’re applying the correction to every message instead of just once per ranging exchange, but it seems like it would be much less dependent on individual device characteristics (mostly antenna gain). It’s probably not best for everyone’s application so maybe that’s not why it’s default, but does it seem like it would work?

On my tag hardware I’m using the DWM1000 and I’m currently using the evaluation boards as my anchors, so I’m just using dwt_getrangebias() to correct for the range bias but I’m guessing that’s calibrated specifically for the case of two eval boards talking to each other.


Hi Spencer,

in the source from Decawave, the range bias is subtracted when the TWR is complete.

However, I would assume that a correction for every message reception would also work, but it will need other look-up tables.

I would also agree that the look-up tables are calibrated towards Decawave’s use case, e.g. TWR. I assume they would look different, for lets say SDS-TWR.


irst of all, I succeeded with implementing Antenna calibration algorithm. It was easier than I thought :slight_smile:
@Spencer and Mathias: Yes, those tables Spencer mentioned would look totally differently. They would differ even for DWM modules. Decawaves software takes into consideration only the range between boards, not the real source of error i.e. power level. They just simply correlated their power level with the range. If you use external amplifier let’s say, you need to either rewrite the tables and adjust the software, or just simply implement a functionality of power level measurement. As you see on the range bias error chart (fig 11 APS011) the error is pretty significant even for -60dBm. I wonder what is going on when the receive power is even higher :slight_smile:
I am also curious why they (Deca) put their effort into creating those look-up tables, and didn’t use the tool they created i.e. receive signal power level measurement.

Are you using your own hardware and antenna, or a DW module? I’d be interested to hear typical antenna delay values for the DWM1000 module.

I did something really hokey to produce some custom antenna delay values. It seemed to work OK (once anyway :slight_smile: I am assuming that all devices of the same design have near-enough the same AD values.
I embedded the initiator’s (4-byte) antenna delay in the ranging packet - extending the packet by 4 bytes of course.
The responder (rangee) finishes it’s usual ranging process and then updates it’s own antenna delay values with those it just received.
The initiator looks at the estimated range, over a few samples, and then adjusts it’s own antenna delay values in the appropriate direction, slowly hill climbing to some sort of stability.
I did this over a bunch of distances, outside the range bias distance of course… data -> spreadsheet… fit a line, hey presto.
Anyone out there willing to explain to this bear of little brain why this dumb approach won’t work - at least to first approximation?
Will the ++4 packet length affect things substantially?
Could I use this same approach to figure out the range bias values?



I have custom electronic design, and my antenna delays differ significantly on different devices. In order to obtain the reference device for antenna calibration values I implemented and algorithm described in one of the documents on Decawave site. If you are jusing just DWM 1000 modules, I think the antenna delays will not differ that much.


Bartosz Kawłatow


Thanks, that’s indeed that’s what I discovered. I went from the default: 16436 -> 16640 using my hokey method.
Did you find the range bias substantially different too, please?



range bias correction was implemented by simple Lagrange interpolation from the points taken from Decawave datasheet charts: range bias error and rx-power non linearity. It gave me suficient correction for my usecase. However, the range bias error compensation was based on rx power measurement from just last one message of SDS-TWR, so there is a place for further improvement :slight_smile:

Hope I helped,

Bartosz Kawłatow

I found the value was 16458 for my ch2 64kHz DWM1000 waveform and 16441 for my ch4 64 kHz waveform with the DWM1000. The datasheet says that the least significant bit in the delay parameter is 15.65ps. I have found this to be accurate in adjusting the delay by taking a single set of static averaged measurements and adjusting using:

delay_new = (dist_meas - dist_true) / speed_of_light / 15.65e-12 / 2 + delay_current
- distance is in meters and delay is in bits.

Note: The delay value seems to change not only with PRF, but also with channel #

Is someone willing to share their calibration algorithm code?
For prototyping I’m putting a custom antenna on an EVK and want to see the improvement of the antenna.

@deca_admin @Bartosz_Kawlatow In the Populate the set of candidate delay estimates algorithm, based on what criteria did you Select the best 25% of the set and include them in the new set?

When asked to set initial delays, what exactly should this (presumably matrix) look like? My first thought was the matrix should be similar to the distance matrices, i.e. a matrix of delays between d1d2, d1d3, etc. But then when assessing candidates is says to compute the tof_candidate as (2 * Delay_for_chip_1 + 2 Delay_for_chip_3 + 4 * ToFmeasured ) / 4. So I can’t be right. But then, what about chip 3? That’s not mentioned. The ‘example’ gives no information at all.

Also that formula doesn’t seem like it can be right since it is definitely going to produce a candidate that is worse that ToF_measured, since it’s just ToF_measured plus a bit.