Bitcraze Forums

hi,

I noticed that dwm1000 uses a normal crystal, if I use a TCXO crystal, I think it can improve some accuracy

Hi!

I looked into this a while ago and from what I understood it's not so easy or useful (depending on the use-case).

The first thing is that TCXOs seems to change frequency in discrete steps which can effect the measurements badly unless you really know how the crystal works and your algorithms take this into account. I've read some posts on the Decawave list where people have tried to model the crystal behavior to be able to get around this. So it seems to be harder than what I initially thought.

The second thing is our use-case for the loco positioning system, where the nodes are powered for long periods of time. For the first minute or so the node temperature will change as the PCB heats up, but after that the temperature is fairly stable from what we've seen. So if you're interested in powering on/off the system and directly doing measurements the temperature will probably effect it but once it's warmed up probably not so much.

The third thing is the algorithm that's being used. For our TDoA3 the clock drift is removed in the calculations, but for other algorithms this might not be the case.

It would be interesting to hear your thoughts on the above points, maybe some of the assumptions are wrong? If anyone has experience in this matter it would be really interesting to hear about it since I'm not at all an expert on this

hi, marcus:

Yeah, from the tdoa sync , we find that when power on the chip, the tcxo warm up about 1min . tdoa2 don't any question.
my doubt is tdoa 3 send a packet about random 30ms, the packet record the tx timestamp, and other anhcor receive and record the rx timestamp, badly, if the two packet time interval is 30ms, when you calc the distance diff with two anchor, I think the clock correction error is large, because the normal crystal, if we use the tcxo, it must also be synchronized once in 100 ms. so I want to konw how to correction use the normal crystal with tdoa3

hi,

and tcxo is indeed very stable. For example, the distance measurement has a stable jitter, which is generally less than 10 cm. In addition, there will also be a stable absolute deviation. We only need to do a linear correction. If an ordinary crystal is used, a non-linear correction is required. And the correction between each two devices may be different, so the consistency is poor.

the Decawave list where people have tried to model the crystal behavior

please show the list, I will check it. thanks.

my doubt is tdoa 3 send a packet about random 30ms, the packet record the tx timestamp, and other anhcor receive and record the rx timestamp, badly, if the two packet time interval is 30ms, when you calc the distance diff with two anchor, I think the clock correction error is large

From what I have seen, the clock drift changes very slowly in comparison to the time between packets, also during warmup. I have not made the calculations, but have assumed it can be ignored. If you calculate it, please share.
You can log the measured clock drift (clock correction) with the tdoaEngine.cc log if you want to check it out.

Another strategy would be to minimize the time between packets. When a TDoA packet is received in the Crazyflie, it is matched with previously recevied packets to find a suitable one for the TDoA calculation. There are two different algorithms for this matching: randomized and youngest. The default value for TDoA3 is randomized, but you can change it to youngest by setting the parameter tdoaEngine.matchAlgo = 2.

Here's one of the better explanations I found of the situation, but like I wrote this isn't exactly my domain so I can't judge if whatever is written is valid or not. There's more answers in the same thread as well.

You can log the measured clock drift (clock correction) with the tdoaEngine.cc log if you want to check it out.

about lps-node code , the uwb_tdoa3_anchor.c file , we measure the clockCorrection as following:
list some value, the result is TCXO:
so the correct jitter is about 3e-7, If you calculate the distance with the clockCorrection , this error is very large. if you use the normal crystal how about your clockCorrection ?

Another strategy would be to minimize the time between packets. When a TDoA packet is received in the Crazyflie, it is matched with previously recevied packets to find a suitable one for the TDoA calculation. There are two different algorithms for this matching: randomized and youngest. The default value for TDoA3 is randomized, but you can change it to youngest by setting the parameter tdoaEngine.matchAlgo = 2.

another I will try your youngest strategy .

marcus wrote: ↑Tue Mar 31, 2020 6:36 am Here's one of the better explanations I found of the situation, but like I wrote this isn't exactly my domain so I can't judge if whatever is written is valid or not. There's more answers in the same thread as well.

thanks for your share,Even if there are defects sometimes, we still have to use them, and we will do a lot of tests to avoid the problems of TCXO or reduce impact on positioning results.