-
I've been building my DIY counter, with GPSDO ref clk. I do not have rubidium or cesium gear handy.
Are there any basic measurements one can make in order to characterize such a DIY gear without having something better to compare?
For example, the first thing came to my mind was to measure its own ref clock.
Getting a nice straight adev line in TimeLab.
Could the experts here identify some issues, the counter's and/or gpsdo's parameters (ie. its own jitter/noise background) out of such data? -
I've been building my DIY counter, with GPSDO ref clk. I do not have rubidium or cesium gear handy.
Are there any basic measurements one can make in order to characterize such a DIY gear without having something better to compare?
For example, the first thing came to my mind was to measure its own ref clock.
Getting a nice straight adev line in TimeLab.
Could the experts here identify some issues, the counter's and/or gpsdo's parameters (ie. its own jitter/noise background) out of such data?
This is "the fox watching the chicken shack"-- of COURSE the fox will say he is not guilty when some chickens go missing...
You need a separate (and preferably different type/brand) of GPSDO to measure another. Then, you have the problem of knowing which GPSDO is "wrong"-- so, now you need at least three of them to inter-compare (while more than 3 is more ideal). Maybe a few surplus cesium fountain standards (the legal definition of frequency), and then you are well on your way to buying an active hydrogen maser (100X more stable than a cesium standard).
Good Luck! Welcome to "precision nuttery"... -
That is the exact answer I've been afraid of..
When I mess with the design (small improvements here and there), while measuring my own ref clock
, I see some changes, ie Adev at 10secs goes from 4e-11 to 2e-11 and so on. So maybe it is related to various jitters coming from input signal conditioning, fpga logic, power sources stability/noise, temperature fluctuations, etc. How to get the data out of it..
Weird.. -
For the shorter time scales one could check against a good quality quartz oscillator (e.g. oven ). For the short times, up to a few seconds the fixed oscillator should be better than the GPSDO. So this should give some check of the counter artifacts (e.g. jitter, interpolator errors) and the PLL in the GPSDO. For checking the slower part is would need a really good second clock.
-
The counter is the project, right? Use whatever frequency reference you have for the counter timebase and your rf source timebase and get the counter working to your satisfaction. Then worry about whether your frequency reference is any good.
-
I adjusted my diy counter with ocxo to a Rb-reference. I didn't bother yet with gps disciplined xo's, although it's an interesting topic. I'd say use your gpsdo as a 'house reference' to all other oscillators - and that's it. of course, if wanna go timenuts, then you should watch out for Cs-references - and more than one only
-
The project is about the Counter and GPSDO. The GPSDO is currently PLL with XOR PD type, utilizing the same fpga I use for the Counter.
I've done measurements with different OCXOs and TCXOs (I've got a couple) against my GPSDO (NEO-7M and Trimble DOCXO). The adevs of those are 5-10x above my "measurement background noise" (with different shape after ~100secs, typical for OCXOs).
Now, what is the "background" - my naive understanding is following: when I measure the freq of my own Reference (GPSDO) via TimeLab, I should see some "artifacts" on the adev curves coming from some "irregularities/issues" related to my design.
The simplest verification of it is filtering/averaging of measurements in my MCU (stm32) - that clearly changes the shape of the adev.
With some measurements I saw the madev slightly changes its slope from taus to taus. That could be caused by various noise types.
Sometimes I see "waves" or "bumps" on the adev/madev.
So there is "something" you may "extract/identify" out of the adev/madev curve's shapes even you are measuring your own Reference.
I do understand this is a Catch-22 situation, but trying to find something which could indicate the right vector of progress.For the shorter time scales one could check against a good quality quartz oscillator (e.g. oven ). For the short times, up to a few seconds the fixed oscillator should be better than the GPSDO. So this should give some check of the counter artifacts (e.g. jitter, interpolator errors) and the PLL in the GPSDO. For checking the slower part is would need a really good second clock.
That is exactly I've been looking for.
-
Hi
Allow me to point you to the "Use of GPS Disciplined Oscillators for Frequency or Time Traceability" published by EURAMET, and available for download freely at https://www.euramet.org/publications-media-centre/technical-guides/
There are indeed other references on the subject (of which a few are listed in the guide from EURAMET), but start to take a look at the guide for inspiration.
Best regards
Ole -
Thanks, the guys in Braunschweig have got the gear (I need) handy..
-
For the shorter time scales one could check against a good quality quartz oscillator (e.g. oven ). For the short times, up to a few seconds the fixed oscillator should be better than the GPSDO. So this should give some check of the counter artifacts (e.g. jitter, interpolator errors) and the PLL in the GPSDO...
These are ~50 measurements of a 12.8MHz TCXO at 10ms sampling interval. The Reference is the GPSDO.
All three trends subtracted, a few outliers removed.Code: [Select]tau[s] MADEV[best]
0.01 4.8E-8
0.04 5.5E-9
0.1 1.3E-9
0.4 2.8E-10
1.0 2.2E-10
2.0 2.0E-10
3.0 2.0E-10
4.0 2.0E-10
-
As imo started this thread with a question if a rubidium and cesium oscillator is necessary and this is in the metrology section I would like to give some comments about frequency calibrations. I would say an uBlox NEO-7M in a week can give a calibration that is more accurate than most of our hobbyist needs and will rival a calibrated cesium like an HP/Keysight 5071. And I say calibrated cesium as even a cesium needs to have traceable calibration. I am not a metrologist and will hold this on my hobbyist level that I think also is a little bit the intention of the metrology section here in EEVblog. I were fortunate to attend several basic metrology courses including one about measurement uncertainty at the Swedish NMI (National Metrology Institution) but that were about 20 years ago.
As in the instruction for Lars GSPDO:
https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/?all
I have decided to use the word digits even if I know it is not an exact term. I also think that magnitudes of accuracy are fully relevant in my comments here. If I say 8 digits I mean it is in the range 1E-8 (0.01ppm or 10 ppb). As I am talking 8 to 15 digits that is a large span I have also found it useful for me. I use the terms accuracy, stability and resolution. With accuracy I mean in a way absolute traceable accuracy but relaxed to a hobby level. In the metrology world traceable means much more documented but I think that you even as a hobbyist needs traceability. If I have a 1 meter tape I have to trust it in a way but don’t have documents but still I believe it is within say 1cm. Without any traceability 1 meter could be 80cm or 80 meter. But I trust the manufacturer has something more accurate /that is traceable in some way). For stability I mean just what a lot of us mean by stable the 1cm is within 1cm but maybe at 98cm or 102cm absolute. Here also the time comes in. For how long is it stable? In the frequency calibrations you can talk about a calibration interval of 1 year so the unit has to be stable for a year if not calibrated in between. I often talk about 1 second to weeks. The reason is that we have radio signal that transfer the calibrations for frequency. Of course I talk about GPS and for 100 years radio has been used. As I am a volt nut also I here can see that it is very different way and more complicated to calibrate a voltage reference than a frequency reference. If you have one of the best voltage standards like the Fluke 732B you need to send it to someone regularly to have it calibrated and it is expensive. Probably more in the region of 1000USD with shipping insurance and everything associated than using a 10USD NEO-7M for frequency.
So back to the NEO-7M compared to the cesium, as I say in a week you can get the same accuracy. The NEO-7M has a spec of 30 ns RMS according to the data sheet. The best uBlox L1 GPS receiver as I see is the M8F with a spec of 20ns for an outdoor antenna and 500ns indoor. I guess this may be a little conservative but also reflect that the GPS signals are not perfect suffering from errors during transmission from the GPS satellites to the antenna. Satellite changes and the ionosphere contribute a lot. OK the good thing is that the NEO-7M are within 30ns RMS with a good antenna I presume. If you measure your counter and oscillator during a week (about 500ksec) you will have a resolution of what I call 13-14 digits and this is also what a cesium standard may give. Measuring for a week may seem complicated but with data logging and a program like TimeLab it is no problem I have found. So why a cesium? One thing is stability on short times. A NEO-7M at second to second basis is only about 8 digits. One thing is the jitter due to the principle it is made but also the GPS signal are not perfect as stated above. Other GPS modules in the 1 sec range may give 9 digits but this may also be because they already have a stable oscillator inside that gives better short term stability but say at 100 seconds range they are no better. Ok so a NEO-7m has eight digits at 1 second between measurements but 13-14 digits at week. Now we come to ADEV charts. I really like them as they in a simple way displays the stability over time. For volt refs I have done ADEV charts that that goes from sub seconds to tens of years by combining data. Like for oscillators you get the noise for sub seconds and the drift of the references will show up in the years range. For more explanation of ADEV see Wikipedia and I also give more simplistic explanations in my GPSDO instruction.
As a cesium may give 11 and even 12 digits stability at 1 second you can see that it is more convenient to use a cesium. But here is where the GPSDO comes in. If you have a very good OCXO it also gives you a stability of 11-12 digits at 1 second but due to drift the stability for a week is not good. By combing the OCXO and GPS you can get good stabilities over 1 second to weeks and forever. Yes you also get very good accuracy all times if the GPSDO is correctly done and the GPS signal available.
So my conclusion is that you don’t need a cesium or rubidium to get high frequency accuracies but they have advantages. As I have said I really like my DIY rubidium based GPSDO. Of course you also need a counter that can measure the difference.
Back to imo’s counter tests. Accuracy and stability are of course relevant but also resolution and linearity. Noise I think is included in my stability discussion in a way but the sources to noise as trigger levels and associated input circuits gives more details.
The first thing I like to ask you, imo, is what resolution your counter gives? I can guess from the charts you have that it is possible to get ADEVs at 1 sec of about 2E-10 (10 digits) and from my Arduino based counter with 1nS that gives 8E-10 ADEV at 1secs in best case and my TAPR TICC that gives 7E-11 with about 55ns resolution I would guess your resolution is in the range 100pS??
I see you use Modified ADEV (Madev or MDEV) but as this is a filtered value it may cheat you. I really like to see the MDEV but in combination with the ADEV as I think it gives more information.
You mentions wiggles and now we come into linearity of your counter. If you feed the same oscillator signal into two channels with a short fixed delay you will see no linearity errors just noise and resolution dependent ADEV. The ADEV curve will be a downward slope. To check the linearity you need a frequency offset. In the instruction for Lars GPSDO I used two OCXO’s with about 10 ppb (1E-8) difference as that gave me reasonable amount of samples but not too long times to cover the range of the time to digital converter. If you have a non linearity it may show up on the ADEV. But I guess it might also be other reasons to get wiggles.
So the first question what resolution do you have and the second could you give both ADEV and MDEV charts?
Lars
-
Quote
The first thing I like to ask you, imo, is what resolution your counter gives? I can guess from the charts you have that it is possible to get ADEVs at 1 sec of about 2E-10 (10 digits) and from my Arduino based counter with 1nS that gives 8E-10 ADEV at 1secs in best case and my TAPR TICC that gives 7E-11 with about 55ns resolution I would guess your resolution is in the range 100pS?? ..
So the first question what resolution do you have and the second could you give both ADEV and MDEV charts?
Lars,
my GPSDO and the reciprocal counter with a time iterator is all-in-one solution (NEO7M(ext_antenna)+stm32+FPGA+iterator+disciplining), still experimental one, however.
The reciprocal counter uses time-stamping so "any sample-rates" are possible.
I've been using the time iterator, tried with 2 versions - analog and digital.
Currently I work with the digital one - the TDC7200 clocked by the OCXO itself (or from an ext 16MHz XO).
Resolution? My current understanding is the best case scenario would be 55ps, but my 100ns ref clock measurements show a jitter (see below, it comes probably from the FPGA, breadboard, or from input signal conditioning circuitry) - therefore my rms resolution could be in the 120-150ps range.
The OCXO's PLL disciplining is done with a simple XOR gate PD @ 10kHz.
OCXO is an old ebay Trimble 34310-t with 160ppb/V and 10M@1.6V EFC.
Below the ADEVs and MADEVs of some measurements - a quality 12.8MHz TCXO, lowcost 12.8MHz TCXO, and lowquality 5M OCXO.
PS: added the picture with the jitter measured by the iterator - vertical is the measured "100ns ref clock", horizontal axis is the sample's N.
-
If I did not have anything better, then to start I would design the GPSDO for stability of the voltage control input to the VCXO and monitor that for days to weeks to at least get an idea of what is going on. The GPS constellation repeats twice a day and transmission conditions roughly repeat every day.
-
The GPS constellation repeats twice a day and transmission conditions roughly repeat every day.
Although technically the constellation repeats twice a day, in practice it does not. If a sat went directly overhead on the first pass, on the second pass it would have a fairly low and shorter visibility. -
Thanks imo,
now I understand better. First I thought you used the FPGA as counter. With the TDC7200 you should get 55ns resolution and ADEV below 1E-10 at 1 second if your reference and DUT oscillator is better than that. I guess one problem is that you don't have two oscillators that are enough good to measure and the other is of course the overall design including practical build that could affect.
All general ADEV measurements as far as I understand is depending on all three parts: counter, reference oscillator (internal or external) and oscillator under test. The worst of them will show up in the graph. Often this gives you have a downward slope on the small Taus up to say 10 seconds due to the resolution of the counter. When you have a more straight line from 10-1000 seconds or maybe even a slight hump if the reference is a GPSDO. If the DUT is a OCXO you will see an upward slope due to drift for the long Taus. If you switch the refence and DUT I guess you still have about the same result. If you have two GPSDO's the long term slope will go down, here you can also be cheated as the two sources are correlated.
As your TCXO and OCXO are not the best (except the trimble) what you see is the oscillators only. Also you know very little about the Miller style GPSDO performance. I like the Miller but it is not easy to predict the performance I think. It is very little published except one unit on leapsecond.com that had a very good OCXO (and the Navman Jupiter GPS).
I would also say I like your setup with GPS+STM+FPGA+TDC7200A from an experimenters perspective. You have the chance to learn a lot. This is why I like DIY!
Lars -
If I did not have anything better, then to start I would design the GPSDO for stability of the voltage control input to the VCXO and monitor that for days to weeks to at least get an idea of what is going on. The GPS constellation repeats twice a day and transmission conditions roughly repeat every day.
As you say one way to monitor an VCXO's voltage control line over time is to use it in a GSPDO. If the GPSDO can read the DAC and preferably store the readings I would say it is even easier. That was one of my goals with "Lars GPSDO". It stores the averaged DAC value every 3 hour for 18 days (due to EEPROM limit). So here you can easily get long term drift. As it also stores the temperature it is also possible to calculate temperature coefficient for the oscillator (including the DAC). Of course jumps of OCXO's is also interesting and a lot of other parameters....
Lot of fun for us that likes statistics.
Lars
-
The GPS constellation repeats twice a day and transmission conditions roughly repeat every day.
Although technically the constellation repeats twice a day, in practice it does not. If a sat went directly overhead on the first pass, on the second pass it would have a fairly low and shorter visibility.
Thanks Texaspyro,
This is link that might also be interesting, that seems to show what you say:
https://www.nist.gov/pml/time-and-frequency-division/services/gps-data-archive
I see it as data that shows what can be expected (in best case) from a timing receiver in US with a very good antenna. I am afraid that in Sweden it is a even a little worse but not so much.
I enclose two screen shots for the last 7 resp. 180days.
Another interesting note on this internet page is for us intersted in traceability:
"GPS disciplined oscillators can be used to establish traceability to the national time and frequency standards maintained by NIST, and the data available here can help support claims of measurement traceability."
Lars
-
Lars,
thanks for the hints!
The PLL's XOR phase detector "works". When the input signals are 50% duty and the LP filter is designed well it should work.
My loop settles in about 20 minutes and the short term fluctuations of the EFC are in hundreds of uVolts_pp. They may contribute to the background noise, sure. With 160ppb/V Trimble's gain and, say, 500uVpp noise at EFC it would be 0.08ppb_pp.
My Trimble is not a high Q one, it has some short term drift, therefore I was not happy with MCU+DAC (16bit) I had tried extensively before. The FLL loop (I was using the counter+iterator against NEO's 12MHz) of whatever design and params produced large DAC corrections such the EFC noise was "higher" than with the current XOR.
Sometimes I wonder how the designs, like the BG7TBL's one, show 10.000.000,000 after a few minutes, when equipped with apparently second hand OCXO's..
-
The GPS constellation repeats twice a day and transmission conditions roughly repeat every day.
Although technically the constellation repeats twice a day, in practice it does not. If a sat went directly overhead on the first pass, on the second pass it would have a fairly low and shorter visibility.
Here is a plot of GPS sat PRN 15 over a 30 hour period. The first and last areas were where the sat passed nearly overhead. The middle are was the orbit 12 hours after the first one... it barely got over the horizon.
-
Thanks, the guys in Braunschweig have got the gear (I need) handy..
They will have some gear at the Hannover Maker Faire this weekend I don't know whether anything there would be useful to know, but you could ask Henrik.
https://www.eevblog.com/forum/metrology/ptb-at-the-maker-faire-in-hannover/msg1815221/#msg1815221 -
@Lars, is there a chance to see a measurement from TAPR-TICC similar to mine above to make, say, 1000 measurements of its own 100ns ref clock period in ps, such I can see the 7200's results distribution?
-
@Lars, is there a chance to see a measurement from TAPR-TICC similar to mine above to make, say, 1000 measurements of its own 100ns ref clock period in ps, such I can see the 7200's results distribution?
Hello imo,
I thought I had done this test with the TAPR-TICC, but couldn’t find anything so I had to set up the TICC again and do the test from scratch.
When I tested my standalone GPSDO’s I see that I get around 8E-11 ADEV at 1 second with the TICC. In these cases I have used a PICDIV 26 to get the 10MHz from the GPSDO to 1Hz. Now I had a PICDIV 13 but I think it might be more that now with the 10MHz ref into the TICC and the same signal feeding the PICDIV I may have ground problems. The GPSDO’s I have used have had (external) isolated power supplies.
As you can see on the new ADEV and MDEV graphs they start at about 1.2E-10 at 1sec. I have about 400ns peak-peak on the phase readings from Timelab. The ADEV is really a straight line with slope -1 downwards. The MDEV suffers at longer times from room temperature drifts I think.
On the phase chart with about 1000seconds I think I can see about 50-60ns resolution but it is a little strange that it isn’t always say 55ns between the values. In Timelab I use time stamps with wraps at 1s check box to acquire data. If I remember correct I haven’t done any changes to the default TICC setup.
I have also enclosed a text file with about 1000 samples.
Lars
-
Lars, thanks! In meantime I messed with the TDC7200, creating a histogram while measuring with 12.8MHz TCXO, none OCXO nor GPS involved. TDC7200: Mode1, avgcycles=1, calperiods=10, clock 12.8MHz.
I did 20mil measurements (12.8MHz = 78125ps period) and got below histogram. It is my PITA, because of the left hand side of the histogram, and it is still wide, imho..
Also the bars around the period are in 6ps raster. While reading some posts at TI's blog (on TDC7200) it seems the results sometimes cluster, based on measured TOF and clock freq used.
The TDC7200's resolution is 55ns with 28ps accuracy and 35ps-100ps standard deviation (datasheet). The jitter/noise from your circuitry adds to it.
So I doubt somebody can see 55ps.
-
Perhaps my issue/question is a bit off topic but I'll give it a try.
Having built Lars' GPSDO I want to perform measurements concerning
(improving) it's performance. So, 'step 2' after obtaining a stable lock.
My goal is not primarily to obtain the best ADEV's but a short term stability
of around 1E-10 is acceptable with the lowest phase noise possible.
In the source code I inserted some extra options concerning adjusting the
PWM frequency of the DAC, presuming it might influence overall performance.
The GPSDO is intended as reference for a satellite PLL LNB (with an LO
of 9750 MHz locked to 25 MHz, i.e. multiplification factor is 390 and phase noise
impacts with the square of this mult factor (so 20log(390) dB).
I tried to read the text in Lars' PDF, but (apparently) I 'm missing/overseeing
something when it comes to using TimeLab.
From what I understand it is possible TimeLab listens to the serial frames the
Arduino is producing. What is not clear to me (although there is a screenshot in
Lars' PDF), is exactly how to setup/tell TimeLab to do so?
Anyone willing to elaborate on / help me with this? -
TimeLab allows you to read data in the csv format, and you may configure the TL parser in the setting window - for example whether your data is frequency, or a fractional freq, or phase.. etc, etc.
You send your data off the atmega328 via a serial into a terminal which can log the incoming data into a file, like TeraTerm for example, and in TeraTerm you will log the incoming data into a file, for example into the file MYDATA.TXT
Your incoming lines in csv will be for example as follows:
..
113, 0000, 1111, 12345678.883, 555, Hello World
114, 0000, 1111, 12345678.866, 555, Hello World
115, 0000, 1111, 12345678.821, 555, Hello World
..
where the frequency of interest in Hz is for example 12345678.xxx (or any other type of data)
Then you go to TimeLab and
Acquire->Acquire from a live ASCII file->
you open the MYDATA.TXT, configure the parser - you will see in a small window your data coming - and select which "numerical field" from the above csv line you want to analyze (in above case it is #4 x1.0 Hz), click "Start Measurement" and it starts to process your incoming data and you will see the nice graphs..