DIY GPSDO project w/ STM32, TDC7200

[0xFFF0]

Thanks for the information. Much to learn. I'll try that. So the DynModel stationary command is not enough?

[hgl]

@hgl
Do you still have the .tim file, I'd like to zoom in so I can better understand the nature of the noise.

Sorry the old raw data file I had posted was the wrong one. Here are again the image and both data files.

[thinkfat]

Thanks for the information. Much to learn. I'll try that. So the DynModel stationary command is not enough?

No, but using the stationary model will help bringing down the time for the survey-in "somewhat".

[erikka]

This noise data makes more sense.
The FA2 has very good performance for a counter.
Here again compared to tinyPFA
Weird the phase of the FA2 has so much drift. I would expect some drift as it measures frequency and not phase but its a lot.
There is an average -2e-12 frequency offset

[cncjerry]

Thanks for the information. Much to learn. I'll try that. So the DynModel stationary command is not enough?

It depends on if you have highly accurate location information.  You need to run the survey for a day or two at a minimum.  That's why it has two parameters for setting the survey.  It could converge to less than .25m in 10 minutes but that doesn't mean that is an accurate location.

I've not had any luck with setting fixed location.  I run the survey with .25m if the antenna moves at all or the GPS reboots.  I have an old UPS I am going to put on it with an lt3045 regulator module in between.  I had thought about going to all batteries like in my phase noise test system as there you can see the results.

I would run just a simple standard deviation on your TIC data and see how it looks before/after a survey.

Jerry

[hgl]

The TDC7200 measures the elapsed time between a START pulse and up to five STOP pulses , further stops are ignored.

Minimum time between Start and Stop must be greater than 12ns and this is not guaranteed with the circuit that was posted here.  https://www.eevblog.com/forum/projects/diy-gpsdo-project-w-stm32-tdc7200/msg2826706/#msg2826706.

The temperature dependence is compensated by the measurement of reference cycles after the stop.
 

[hgl]

This noise data makes more sense.
The FA2 has very good performance for a counter.
Here again compared to tinyPFA
Weird the phase of the FA2 has so much drift. I would expect some drift as it measures frequency and not phase but its a lot.
There is an average -2e-12 frequency offset

This is perhaps due to timelab, which can only export phase. I attach the tim file as .txt you must rename it then again in tim
   

[erikka]

Thanks for the .tim file.
Its clear this is not due to FA-2 but due to processing in TimeLab
Thanks for all the clarifications!

[thinkfat]

Thanks for the information. Much to learn. I'll try that. So the DynModel stationary command is not enough?

It depends on if you have highly accurate location information.  You need to run the survey for a day or two at a minimum.  That's why it has two parameters for setting the survey.  It could converge to less than .25m in 10 minutes but that doesn't mean that is an accurate location.

I've not had any luck with setting fixed location.  I run the survey with .25m if the antenna moves at all or the GPS reboots.  I have an old UPS I am going to put on it with an lt3045 regulator module in between.  I had thought about going to all batteries like in my phase noise test system as there you can see the results.

I would run just a simple standard deviation on your TIC data and see how it looks before/after a survey.

Jerry

It should not take a day to reach 0.25m position uncertainty. A couple of hours should be enough. There's a couple of things you can do to speed it up, too:

For starters, you can increase the measurement frequency to more than 1 Hz. I've experimented with 4 Hz, but 5 Hz should also still work. This trick divides the time necessary by an according factor.

Second, disable GLONASS and enable only GPS and Galileo. I've found that GLONASS messes with positioning and also stability in general. At least on a Ublox M8T.

Third, enable SBAS while you do the survey, switch it off again after the survey has ended. This will increase precision of the position measurements taken and help drive down uncertainty faster.

[tomnut]

FWIW I find that the TDC7200 is absolutely reliable when its STOP is fed from a 10 MHz clean square wave. It will pick one of the rising edges and time that accurately.
It will sometimes read under 12 ns, sometimes over 112 ns, but it doesn't seem to make mistakes when the STOP rising edge is near its allowed minimum time. I've probably had some 100k pulses within +-1 ns of the minimum and never seen an incorrect result.

The minimum time from ARM to START must be respected, however. If you abuse that (say by trying to start on the edge of a 10 MHz clock of random phase) it will give you garbage.

[S57UUU]

The survey should be set to an integer multiple of 24h, to reduce the daily ionosphere variation. The amplitude of elevation error at my place is typically + -1m, see fig 4.3 here:

http://lea.hamradio.si/~s57uuu/mischam/gpsy/index.html

edit:

or do the survey at night, hours after sunset

[thinkfat]

The survey should be set to an integer multiple of 24h, to reduce the daily ionosphere variation. The amplitude of elevation error at my place is typically + -1m, see fig 4.3 here:

http://lea.hamradio.si/~s57uuu/mischam/gpsy/index.html

edit:

or do the survey at night, hours after sunset

Wow. What a write-up! I've always speculated about using the internal state of the GPS receiver for disciplining an oscillator but I was scared of replacing the LO. I know that the Trimble "Thunderbolt" GPSDOs use the same method, while most of the other commercial "telecom" grade UCCM modules just use the 1PPS output and maybe also quantization correction.

[iMo]

Btw. - there is the TDC7201 with 2 channels (and perhaps other features too).. I wonder whether it could provide some improvements over the 7200. It is in a 25balls BGA package, though.. I think I got it in past, but not elaborated yet..

[Clemgill]

Would be interesting to see (after you finalize your GPSDO) how the quant_err correction helps when you do 500-1000secs PID loop averaging (ie. MADEV with and without).
It is my understanding the "sawtooth correction" and the "quantization error correction" is the same.

The expression of the quantization error in picoseconds is especially convenient since the correction then becomes a simple addition. You just need to figure out the sign correctly, i.e. understand what the receiver is actually reporting. In the ublox case, a negative qErr means the true timepulse is abs(qErr) earlier than the TIMEPULSE signal, that means you need to add abs(qErr) to the measurement. In other words, you just add -qErr to the measurement and you're set.

Thanks for this discussion, but if I am not wrong, I seems too me that we should add qErr to the measurement instead of (-qErr)
hereafter is the rationale :
qErr         true timepulse      Corrected measerement
negative        earleir than TP      M - |qErr| = M -(-qErr) = M+qErr    because qErr is negative
positive        later than TP              M +|qErr| = M + qErr                    because qErr is positive

Is this right ?