tcxo crystal should be improve the accuracy
-
- Expert
- Posts: 186
- Joined: Mon Dec 28, 2015 5:07 am
tcxo crystal should be improve the accuracy
hi,
I noticed that dwm1000 uses a normal crystal, if I use a TCXO crystal, I think it can improve some accuracy
I noticed that dwm1000 uses a normal crystal, if I use a TCXO crystal, I think it can improve some accuracy
Re: tcxo crystal should be improve the 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
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
-
- Expert
- Posts: 186
- Joined: Mon Dec 28, 2015 5:07 am
Re: tcxo crystal should be improve the accuracy
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
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
-
- Expert
- Posts: 186
- Joined: Mon Dec 28, 2015 5:07 am
Re: tcxo crystal should be improve the accuracy
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.
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.
please show the list, I will check it. thanks.the Decawave list where people have tried to model the crystal behavior
-
- Bitcraze
- Posts: 630
- Joined: Tue Jun 30, 2015 7:47 am
Re: tcxo crystal should be improve the accuracy
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.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
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.
Re: tcxo crystal should be improve the accuracy
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.
-
- Expert
- Posts: 186
- Joined: Mon Dec 28, 2015 5:07 am
Re: tcxo crystal should be improve the accuracy
about lps-node code , the uwb_tdoa3_anchor.c file , we measure the clockCorrection as following:You can log the measured clock drift (clock correction) with the tdoaEngine.cc log if you want to check it out.
Code: Select all
double clockCorrection = calculateClockCorrection(anchorCtx, remoteTxSeqNr, remoteTx, rxTime);
Code: Select all
0.999999604
0.999999620
0.999999609
0.999999620
0.999999602
0.999999630
0.999999614
0.999999603
0.999999474
0.999999754
0.999999592
another I will try your youngest strategy .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.
Last edited by justinleeyang on Fri Apr 03, 2020 3:07 am, edited 1 time in total.
-
- Expert
- Posts: 186
- Joined: Mon Dec 28, 2015 5:07 am
Re: tcxo crystal should be improve the accuracy
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.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.