Lars DIY GPSDO with Arduino and 1ns resolution TIC

[Leo Bodnar]

What do these ADEV and MDEV charts actually measure?
To measure stability of an oscillator you compare it against another uncorrelated oscillator.
To get to true 10^-13 level, both of these uncorrelated sources should be at (actually, slightly below) that level.

Now, ADEV/MDEV are just statistical tools - like SD - and can be applied to any sequence of numbers.
But if sources are correlated then the results are not trustworthy or meaningful.
In extreme case, measuring a clock against itself will result in zero ADEV and MDEV.

Cheers
Leo

[iMo]

What do these ADEV and MDEV charts actually measure?

It is a method suggested by Lars - "Finding optimum time constant and setting linearization parameters" - see his .pdf guides at the beginning of this thread.

[Dbldutch]

Well imo thank you for clearing this up!

This column or numeric field selection in TimeLab is mighty confusing for new players, like me.

If you look at figure 6 on page 18 of the Lars document, you can see that he used Numeric Field # 3 when he collected live serial data. That is also what I used when I collected live serial data. When I switched to importing the data from a CSV file, it all went to hell because in this mode, TimeLab treats the Numeric Field information differently and I continued to use field number 3, and that was my trap. Or is it a TimeLab ambush? 

When you're dealing with the Arduino Serial Monitor, the columns are very well defined.
When you import them into Excel, the individual columns are put into individual cells.
When you export the Excel file to a CSV file, the individual cells are separated by either a "," or ";" depending on your country setting I believe.
All intuitive, universally understood and simple and Timelab in the live collection mode works the same way.

The following is my understanding of what I did wrong in the importing mode and gathered with your help.
First of all, I assumed the correct field based on the live mode and also CSV fields and never looked at the explanation that is in the attached file. My bad.

When you import the CSV file (=data from ASCII file) into TimeLab, it does not understand the CSV format.
It puts everything beginning with a + - . or [0-9] into a field. The field separation can be any other character.

In my case, I imported this into Timelab:

11:26:16.279 -> 72470;6;32905;51,9;Locked;-18;1848;500;250;
Using the Arduino/Excel/CSV format, the DAC value is in the third field. and that is what I used all along with all my import measurements. 

If I now understand it correctly, TimeLab creates the following numeric fields from my CVS file:

1: 11:26:16.279
discarded "->"
2: 72470
3: ;
4: 6
5: ;
6: 32905  <== the one we need
7: ;
8: 51,9  (note that this notation is due to my country setting. It can also be a period "." as the decimal separator)
9: ;
Discarded "Locked"
10: ;
Etc.

EDIT Nope, still got it wrong, see imo's explanation below.

Is my understanding (and explanation for other young players) correct?

[thinkfat]

What do these ADEV and MDEV charts actually measure?
To measure stability of an oscillator you compare it against another uncorrelated oscillator.
To get to true 10^-13 level, both of these uncorrelated sources should be at (actually, slightly below) that level.

Now, ADEV/MDEV are just statistical tools - like SD - and can be applied to any sequence of numbers.
But if sources are correlated then the results are not trustworthy or meaningful.
In extreme case, measuring a clock against itself will result in zero ADEV and MDEV.

Cheers
Leo

The reference is in a way the 1PPS signal from the GPS, through the control loop of the GPSDO software. The DAC output values come from the control loop and are a representation of the phase difference between the 1PPS pulses and the oscillator output zero crossings. Provided the control loop works (especially the smoothing of the jittery 1PPS signal out of the GPS receivers), the calculated ADEV and MADEV are actually somewhat meaningful, but a numbers in the 10^-13 range are very likely a scaling error when calculating the frequency from the DAC output.

[iMo]

The TimeLab considers only numbers starting "+", "-", ".", "0/1/2/../9" and ignores any other strings in between (PS: numbers incl. floating point, like "-123.456e78", ".123E-45").
TimeLab user manual:
http://www.miles.io/PhaseStation_53100A_user_manual.pdf

11:26:16.279 -> 72470;6;32905;51,9;Locked;-18;1848;500;250;

The numeric fields in your above case are therefore:

1: 11
2: 26
3: 16.279                    <------ your wrong field (seconds)
4: 72470
5: 6
6: 32905                     <== DAC: the one we need
7: 51
8: 9 
9: -18
10: 1848
11: 500
12: 250

[iMo]

Here is an example of MADEV (all trends subtracted) of 100000 random DAC integer values (32100+/-1) with 3.3e-12 multiplier (1sec sampling, 10MHz, freq diff):

min: 32099
max: 32101
std: 0.816
aver: 32100.00032

[Dbldutch]

Thank you all for the inputs and suggestions.
Now that I learned what I did wrong, I can start to compare various conditions.
I implemented the two additional suggestions from imo , and added the current booster to the reference and the 33uH inductor in series with the Vcontrol input.
This is now my hardware version 3.

Below are some preliminary results that I'm collecting.
The TC500 run was without the above modifications, my version 2. During this run, I noticed three periods without a lock. With an improved enclosure of the OCXO circuit, I hope to prevent that. The processor board and the GPS module is still in free air.

The next two runs were with version 3 and a TC4 to find the optimum TC, and after that a run with TC32 to see the effects.
Currently I'm running with TC200.

I'm still trying to profile this CTI OCXO and at the same time burning it in. The Bliley and Isotemp OCXO's are also burning in at the same time, just connected to a 5V supply.
From other postings, I understand that it may take weeks if not months for these OCXO's to stabilize again after their to be expected rough handling during removal of circuit boards and the rough handling during the transport.

My goal with these postings is to show other non-time-nutters that want to implement this simple and elegant design from Lars what the potential pitfalls are and what to expect.

Something is wrong with my setup or with the OCXO, because the adev/mdev charts show curves with higher TC’s that are progressively worse than with a TC of 4.

Please chime in if you see something worthy of sharing.

[iMo]

Could you post the raw data for "CTI tc4 a3.0 V3" plz?

[Dbldutch]

Hi imo, here it is.

[iMo]

Interestingly the MADEV's DAC sigma at tau=1000secs with my above stddev=0.816 (2 LSBp-p) is the same as in yours data with sttdev=375 (3341 LSBp-p). 
PS: your file is not .csv as you are using semicolon..

[Dbldutch]

@ imo, isn’t that to be expected with a TC of 4 and minimal damping?

PS Technically, you are correct. As I explained in my post #427, the CSV separator depends on your country setting, and has to do with the decimal separator. In my part of the world, the decimal separator is the comma “,” so that can’t be used as the CSV separator, which is why Excel uses the semicolon “;” instead. You should however be able to import the file with Excel as CSV, regardless of your country setting.

[Dr pepper]

I have built a couple of freq standards, using terrestial signals, but I fancy something a little more accurate.
Looking at Lar's project this looks like my kind of thing, esp the hardware simplicity.
Any pointers on this project before I start.
I built a circuit using a Dds chip Si5351 using Gps to discipline it, however I cannot get the thing better than 1e-9 or so, so an ocxo I think is the next step (I did ovenize the Si5151 module).
I put togther a webserver using an Esp8266 for this, some parameters are shown on gauges, and others on a google chart over a period of a few days, might interface this to it as well.

[Dbldutch]

While still tweaking, fiddling and learning, I have made another run to show the performance (I think) of the system as a whole.

With a damping of 3.0, I switched the system to the hold mode (h0) and tracked the result.
As to be expected, with the DAC output fixed, the frequency from the OCXO should drift away from the 1PPS reference. I was running with a TC of 4, so when I hit the h0 command, the DAC output level was not at the optimum lock level, which drives the level of the ramp. I don't think that matters much for this measurement.

From my understanding, even though the OCXO should be steady as per the specifications (+/- 0.5PPB/day), we still have the "system" jitter to account for, so there will be no pure straight line.

It's interesting to see the results though.
My steady "system" jitter is about +/- 20 nsec as you can see in the diff_ns report. I have no idea if this is good, bad or average.
However, I still experience anomalies in this report that I assume are coming from the GPS module's (NEO M8T) 1PPS signal. Although I always have about 10+ satellites with a lock above the 20dB level. Maybe it has to do with the fact that I don't have a clear view of the whole sky and satellite coverage is switching too much. My powered 28dB active antenna is outside on the window sill, almost at the corner of the third level of a 4 level apartment building facing East. The Sky View picture shows this.

So far, I've only been tracking the output from the code through the Arduino IDE serial monitor. Unfortunately, that ties-up my laptop (with limited USB ports), and there is limited storage before the output overflows. I'm now using a vintage Model B Raspberry Pi to monitor this output, and continuously log that into daily rotating logs. I will now also start to add the logging of the NEO-M8T as well to see if I can correlate anything to the diff_ns wiggles.

[UPDATE]
While playing with the recorded messages in u-center, it didn't take long to see major glitches. I looked in the corresponding Arduino log, but did not see a corresponding problem. I’m pretty sure this is the cause for the glitches I see on the scope, probing the output of the 4046. I have a picture of that several posts up.
Note that most satellites are gone over a period of a few clicks!

Any suggestions?
 

[thinkfat]

Just a sidenote: If you have a RaspberyPi connected to your GPSDO, you can run LadyHeather on it. The 6.14 beta version (and I believe earlier versions, too) support the "Lars GPSDO" to some extent. I think, however, that it only connects to the GPSDO command console and not to the GPS receiver at the same time so it may not be as useful.

[iMo]

My steady "system" jitter is about +/- 20 nsec as you can see in the diff_ns report.

The NEOs 1PPS jitter is 40-50ns p-p, thus I would say it is "normal". Also TIC jitters as well.

To make a "self test" you may create 1PPS off your 10MHz OCXO and feed it to the 1PPS input (there are 8pin PIC dividers binaries for this purpose available). That may show you the performance of your "TIC system".

http://leapsecond.com/pic/picdiv-list.htm
http://leapsecond.com/pic/picdiv.htm

[Dbldutch]

@thinkfat Yes I know, but I would like to start to log both sources with a precise time so I can reconcile them.
u-blox center is my preferred way of dealing with the NEO's. I also want to be able to program the NEO, and the Lars system on the fly.

@imo I have a DIY programmable counter that uses 390 dividers. It will take some soldering to create an external 10MHz input, instead of the internal XO that I currently use. This was my plan all along, I may expedite that now.

[Dr pepper]

Ok, as I mentioned I did play with this the weekend.
After fiddling with gain & time period I got the thing to lock with my ebay 10 mc ocxo.
Now on to the fine tuning, I have a couple of 63mc ocxo's, I want to get this to work with one of those, so I'll change the required variables in the code.
I notice the code stores the 5mc reference frequency /100-1, ie 49999, that being the case I'll see if I can retune my ocxo to a suitable value, and come up with a replacement constant.

[Dbldutch]

Today I rigged-up my setup to measure the overall jitter of the TIC portion of the GPSDO system.
I ordered the PD10 PIC divider from Leapsecond, but have not received a reply or confirmation from Tom yet.

Not wanting to wait, I took the 10MHz output from the CTI XO and connected that to my home build programmable frequency divider that uses 74LS390 decade counters.
Set to a 1PPS output, the signal of that instrument was fed into the system by taking out the GPS module and feeding it into the 1PPS input.

My scope was triggered on the 1PPS output from the frequency divider, and I used the second channel to measure the pulse at the output of the 4046 at the anode of the diode.

I was pleasantly surprised with the average jitter of only a few 100 ps, but also a bit unhappy about the random anomalies.

Overall, the jitter contribution of that part of the circuit is below 1ns. My assumption is that this is mostly coming from the HC4046.

[Dbldutch]

For the past 4 days (390,570 seconds), I have been logging the serial output with my RPi.
The GPSDO setup was with a damping factor of 3.0 and a TC of 200.

Below are some of the results in Excel that clearly show the effect of the ambient temperature on the system.
Both circuit boards are in plastic containers (of the Chinese food kind), with slits for the wires, so no draft.

You can clearly see when my room temperature goes up in the morning, and down for the night.
The last bit was recorded when we were not home, and the heating stayed at the night temperature. That portion of the graph is pretty flat.

I'm still seeing unexpected Allan Deviation graphs, so I continue to have difficulty fully trusting my setup or my pilot skills.
The following ADev and MDev charts are very different from what you would expect and see in most other cases, although Miti in post #72 has this too.
The graph goes up over time to a lesser precision instead of down to a higher one.
Lars has this advice "What is a little nice with the GPS modules PPS is that they are fairly predictable so if you from the PPS not get anything starting at about 1E-8 or 1E-9 at 1sec for ADEV and going down you can start to think." However, I have no explanation for this. Do you?

The last graph shows the frequency differences (FD) and that seems to show that the system is working reasonably well.
The highest spike shows a frequency of 10,000,000.004 MHz, and the lowest 9.999.999,997 MHz, limiting the results to the E-10 range.

As these deviations seem to come from the temperature effects, my next task is to see if I can reduce that with the compensation factor.

[thinkfat]

A day has 86400 seconds. You have a big hump at around 40000 seconds, right? So, there's a disturbance twice a day, which would match with your heating starting in the morning and shutting down for the night.

[iMo]

Your DAC data show your peak-peak during the most quiet period is 3E-10.
That is +/- 1.5mHz @10MHz. Pretty good result, imho.

MADEV - fyi Lars explained in his Reply #76 Miti's ADEV (in response #72) similar to yours..

[thinkfat]

I found this document from William J. Riley about frequency stability analysis techniques. See e.g. pages 47ff. for discussion of environmental effects (e.g. cyclic temperature changes).

https://drive.google.com/open?id=18Jwq-yZ_-3jfLXzhpwFXJr-n2OQAFen-

[Leo Bodnar]

If you are looking to identify regular periodic interference, especially, narrowband disturbance like mains hum or leaks of internal signals it is much better to use regular spectral analysis.

ADEV can be confusing since it smears interfering process all over the time scale with a dip at offending frequency and its fractions. It makes sense: if you take readings at exact intervals of disturbance period (e.g. every morning) then your accuracy is not affected.  Same at multiples of disturbance period (e.g. every Monday morning, etc.)  Think of ADEV as a chart of "how predictable my time would be if I were to take readings at this tau?"  It's nice to look at when it's low but not very useful in tracking down localised problems when it's not.

MDEV is even "worse" due to its higher averaging nature - its periodic dips are gentler so harder to identify.

Why not just use spectral analysis - like you would do on the other side of 1 second?

Leo

P.S. Bill Riley has retired but is still publishing good work. He made his Stable32 software available for free.  It does a lot of analysis in both frequency and time domains and statistical series analysis all in one place.

[thinkfat]

Anyway, this plot is just ADEV/MADEV derived from DAC output. This is not necessarily the actual frequency, especially with the temperature effects on the OCXO. When you've worked out the temperature compensation, it'll become more meaningful.

[Jacon]

---- He made his Stable32 software available for free....

Link for download is active on IEEE site, but download process stops with error after approx 10% received
(regardless of browser used)...