Two Way Ranging Distance Calibration

Hi,

I am using the ss_twr code from the decawave github:

When reading the values printed through UART on the init side, I am getting distance values of about 1.8-2.3 M (fluctuating) when the measured distance is 1.5 M. Is there any way to adjust the code so the distance is both more consistent and more accurate?
Thanks!

Hi Vik,

You must calibrate the antenna delay values in the code at a given distance. So for example set the distance to 2meters, and modify those value until measured distance is correct.

Hope it helps,
Yes

Hi, thanks for responding. Do you know where I can find these antenna delay values in the code?

Hi Vik,

They are easy to find in main.c with a bit of research:

/Should be accurately calculated during calibration/
#define TX_ANT_DLY 16300
#define RX_ANT_DLY 16456

Hope it helps,
Yves

1 Like

Forgive me for intrusion,Yves, is this weak delay difference important?
I’v got reference/measured diff about 3-5 cm at 10 meter base.

It depends how accurate you want things to be.

Hi,
I am a little confused because of the antenna delay values. I have a RTLS already up and running but did not make use of any external C code. I only use the stock PANS firmware image version 2.
I wonder if it a) made sense for me to alter the delays and b) if it was actually possible to do so. Or is that only important when using the TWR example? But what delay values does the stock firmware provide then?

Regards, Max

Hello, may I know how should I do the calibration without using any external code? I am using bluetooth BLE API to read the position information of the tag.

@maxbauer Did you figure out how to do that?

Hey there.
Well if you pretend to use PANS firmware you cannot change the code…So not possible to define antenna delay’s values like that. The only way is you correcting the values on a post processing program after receiving the range or use your own firmware and then do that. Just remember that the devices (if you have a development board) already have a value from fabrication stored on OTP but they come with a positive error (real - measure => 0).
Cheerz.

Yes I am using decawave 1001 dev board. Do you mean if I want to calibrate my board, I need to compile the C language code from decawave example and change the following two lines ([link](https://github.com/Decawave/dwm1001-examples/blob/1b2a46e14546d8f24cf08ff3d64d802e109cd2d3/examples/ss_twr_init_int/main.c#L64)) until I get good TWR accuracy.

Currently I try to use two device which one anchor and one tag. However there is ±20cm error from actual distance. Is it possible to increase the accuracy?

Hi there.

“Do you mean if I want to calibrate my board, I need to compile the C language code from decawave example and change the following two lines ( [link](https://github.com/Decawave/dwm1001-examples/blob/1b2a46e14546d8f24cf08ff3d64d802e109cd2d3/examples/ss_twr_init_int/main.c#L64) ) until I get good TWR accuracy.”

Yes correct. Well i dont know how is the handling of PANS code about ranges.

What im gona tell you is about my experience using my code because i want to have control on it and not using a “black box” where i dont know if the ranges are raw or not.

So with the mdek1001 (my case) the antenna delay comes with a positive error value of antenna delay, so all the devices that loads the calibration values from the OTP will have it. Then that error could be summed (from device A plus the device B error) and then you have that error of 20cm. In my case was something like that actuyally. If you have another devices and use it you should see some different errors maybe (if they have different antenna delay value).

Currently I try to use two device which one anchor and one tag. However there is ±20cm error from actual distance. Is it possible to increase the accuracy?

So what i did is just put them on a distance recommened (my case was channel 5 (128 preamble and 1024 preamble) - 5010mm) and then trying to find a “better” value for antenna delay. Remenber that this will be a improvement on LOS but in a case of NLOS could make the errors greater. Keep in mind that this calibration has to be on statistics measures like 99% of measure inside you measure and std.

Dont forget too about two important aspects! First the trim of crystal - that you have on OTP value too and secound the range bias correction that you could make it too. In this case you have documentation to help too on this task Decawave application notes. Keep in mind that for all of this there are a lot of “problems” like physical antenna rotation and reflection and so on…

I hope i could help.

Cheers.

May I ask how did you get the antenna delay value? I’m currently using 4 dwm1001 devices: 2 anchors with 2 tags. I also have a ± 20cm error with the distance measurement. Is there any other way of correcting this error – like in the post-processing stage-- besides the method youve mentioned?

Also, I noticed that the temperature of the dwm1001 module increases as it’s being used so I wonder if this could also be used to correct the distance measurement? since it could cause a clock drift of some sort and thus affecting the ToF computation.

Hey there!

Well, you can correct in post processing yes, but i did it my own firmware. I correct the antenna delay and then use a lookup table to correct the bias value. The antenna delay value was already stored on the OTP in my case because im using the MDEK1001 kit (12 devices). The only thing i did was to put them on a knownd distance (depending of your channel and frequency pulse) and corect the antenna delay. Them the correction of the antenna bias (although in my cause i used a lookup table like on the documentation from “sources of error” cause i didnt have the time to make a lot of measures).
Now, in LOS im having values <10 cm of error.

About the temperature, yes, it affects the measures but 1 or 2 ºC of difference, it’s like 5 mm of error ,so on indoor localization (depending of the type of buildings) doenst have so much impact like the NLOS measures or even a bad antenna delay calibration. But if you want you can use it to correct it too. You need to determine the temperature that you use to determine the antenna delay and the correct the value with the difference of actual temperature. With MDEK1001 kits, the devices comes with the temperaure of calibration of antenna delay and in case of need i could use that correct have of reference.

I dont know if it helps a lot but keep on!

Cheerz.

Hey @ruigomes,
according to Decawave User Manual it is possible to alter the value in the OTP for the antenna delays. If I did that while keep on making use of PANS, would that change anything? Or does that only have an effect if you write your own firmware?

Regards, Max

The OTP memory is called that because it’s one time programmable.
It has already been programmed with the delay, it can’t be reprogrammed.

Following the instructions in the manual you can still write to it but the new value will be ORed with the existing value.
In some specific situations you can make use of this to allow multiple writes but they are very limited. Unless you are very luck with the specific values involved changing a numeric value isn’t one of these situations.

If you want to set the delay yourself on a module which has it pre-programmed then using PANS probably isn’t an option. There may be a way around that but I’m not aware of it.

Okay. Thanks for your response. I’m using DWM1001 Dev Kits without any custom software running.
So I wonder what is the purpose of the dwm-simple package on github then? Isn’t its purpose to validate that the ranging works properly and if it doesn’t isn’t its purpose that you can change the Antenna delay values within the script to get the maximum performance out of the system?

Then, what would be the benefit if you can change the antenna delay values only for the range example script but not for a regular PANS use?
That still leaves me a little confused.

Regards,
Max

@maxbauer I’m trying to retrieve the OTP value and use that in the github example. Does anyone know if I can do this?

I also tried following the APS014 - Antenna Delay Calibration document to calibrate my DWM1001 dev kit modules, but I ran into some roadblocks. In the Populate the set of candidate delay estimates algorithm, based on what criteria do you Select the best 25% of the set and include them in the new set ?

Het there!
Well, i didnt reprogram the OTP values. I just use them and then I correct them with calculations. I make this because you have a number of different anchors and each one of them requires a different value to correct, and of course changing the tag the values must be again corrected for now…
Dont forget that if you want to reprogram new antenna delays you have to follow the documentation APS014 refered.
Cheerz

Hey @ruigomes,
how have you counter calculated the antenna delay values afterwards? Are the values in time units?

I understand that I should follow this guide but as @AndyA stated it actually wouldn’t change much. That’s what confuses me because I wonder what the benefit in changing these values in the OTP actually is…

Regards
Max

Hey there @maxbauer

I put the devices on the range I want to calibrate and then correct the ToF value that you obtain from the ranging protocol.
I did it in two fases so i could compare the difference with and without antenna delay correction. Then i apply the bias_correction. The units are the same as the antenna delay uses 15.65ps i belive.
So as you can see i dont “change” the OTP values, i just “corect” them. Like @AndyA said, thoose values are stored from fabrication and the way to change them are not “so simple” and there are a bunch of factors that you could not take care or are time consuming.
Keep in mind that if you use another device you should do a correction and the values to correct could be different. So each communication you can have a different value of antenna delay to correct.
This is just something if you really want a range at 10cm of error and a better position calculation but remenber that even with this, could not result a position with 10cm of error.

Sorry if i didnt help much.

Cheerz