EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: lars on August 11, 2017, 09:18:19 pm
-
Yet another DIY GPSDO! On the internet you can find a lot of DIY GPSDO designs. What are the differences between them? Why this?
Some + and – I can come up with for mine:
+ 1ns resolution TIC (Time Interval Counter)
+ PLL (not FLL)
+ Uses Arduino (ok some might say it is negative)
+ Low parts count and cheap components
+ No need for a specific GPS receiver only requires 1PPS in
+ Easy adaption to different oscillators (from simple VCXO to Rubidium)
+ Configuration for VCO range, time constant (4-32000s) and a lot of other parameters
+ Outputs time error (ns), DAC value and temperature (and a lot of other information) to the serial port
+ Logs time error, DAC value and temperature every third hour
+ Stores last DAC value for use at power-up
-DAC resolution (now 16bits) and stability could be better
-No saw tooth correction
-No adaptive time constant
-Not using information from receiver e.g. number of satellites etc.
-No standardized communication protocol like many commercial GPSDO’s
-No display
Why did I do this? Since about 2010 I have developed my GPSDO. It started just because I was lazy and tired of tweaking my 10MHz house standard. The only thing I am proud of is the 1ns resolution TIC. A couple of years ago I published an old version on the time nuts forum. This time I decided to use this forum instead as I think my DIY GPSDO is something for experimenters in this forum.
For me it is perfect for experiments. I have learned a lot during the years I have used it (and developed it).
I have built several complete GPSDO’s but now the only one I have running continuous is a rubidium based DIY Arduino GPSDO I use as a lab standard for my instruments. That Rb GPSDO has been running almost continuous for more than five years with different versions of my Arduino software.
Today you can get a GPS module + antenna for about 10USD from eBay, an OCXO for 10-20USD, a metal box and connectors for about 10USD, the Arduino pro mini and all other components for about 10USD, So around 50-60USD should be enough to get all components for a complete GPSDO.
As I had problems with file extensions I added .txt to the arduino sketch .ino. You have to take away the .txt and place it in a folder with the same name. To easier read the file without arduino see the .txt without .ino in the file name.
I also had to divide the instruction as it was about 2MB. Sorry for the inconvenience.
Lars
-
Pages 8-18 of instruction
-
Last pages 19-21
Lars
-
An impressive looking design Lars. Thank you for sharing the full details and code. :-+
Given the very low circuit complexity and cheap arduino based implementation (I think it is a positive), it would be hard to find a reason not try it out. Time to modify my messy LEA-6T 100kHz PLL breadboard.
-
Thanks for publishing your design and experiences.
I have a long term project to produce a GPSDO but have got side-tracked on trying to improve my ADEV measurements (so I can select OCXOs). Also I keep changing my design approach which is half the fun.
I was interested to see that your currently run a rubidium full time - is this on all the time are just when you need it? I was leaning towards using an OCXO rather than rubidium because of better phase noise, lower power consumption and longer life. I have a couple of rubidiums but I wouldn't like to run them 24x7 for years because I'm not sure how much lamp life is remaining.
-
FWIW, I have an Efratom FRK Rb Standard that's been running 24/7 for 6 years. The voltage that represents the lamp output hasn't moved. These things have a long design life and are expected to be on 24/7. Problems with the lamp do occur, but I don't think it's something you need to worry about.
Ed
-
FWIW, I have an Efratom FRK Rb Standard that's been running 24/7 for 6 years. The voltage that represents the lamp output hasn't moved. These things have a long design life and are expected to be on 24/7. Problems with the lamp do occur, but I don't think it's something you need to worry about.
Ed
Thanks, that is useful to know.
They are certainly more stable when left running all the time - I found with mine that they needed a couple of hours or so to settle when I was making measurements - though they only take a few minutes to lock.
-
Hi Lars,
I realise that the forum requires you to split your pdf but, as a very minor point, it would be good to split it even pages so that those of us who still like to print things out and do so duplex can seamlessly merge the different sections.
eg 1-6, 7-14 etc.
Thanks again for writing up and sharing. This is probably a better forum to do so as I (and I suspect others) read stuff here but only read stuff on time-nuts if doing a particular search. I did join time-nuts for a while but the number of emails landing in my inbox, only some of which were relevant to my interests, was too much for me. (I know you can set up email filters etc but I prefer to keep my emails for communications and forums for news/general discussions.)
-
I realise that the forum requires you to split your pdf but, as a very minor point, it would be good to split it even pages so that those of us who still like to print things out and do so duplex can seamlessly merge the different sections.
eg 1-6, 7-14 etc.
The simplest way to reconstitute them into a single pdf is the online PDF Merge. https://www.pdfmerge.com/ (https://www.pdfmerge.com/)
You can then manage the odd/even printing as you normally do.
-
I need to follow this. I have most the stuff but just to lazy sometimes to follow up. Main problem is that I don't really require a bench 10Hz standard, but still I feel any guy must have one of these humming along.
Does that mean I might potentially a time-nut disease candidate? :-DD
-
Main problem is that I don't really require a bench 10Hz standard
It looks as if you're a Million times less susceptible than others. ;)
-
I've also been thinking putting together a GPSDO, and my thinking has been similar to your design. Some quick ideas for your design: could the 10M pull down be removed, and instead toggle an internal pulldown in the MCU at the appropriate time? I also worried about the temperature coefficient of the diode. Perhaps using a small high-side pFET instead of the diode could work better?
For my design, I was contemplating using the TDC7200, but that may be overkill.
-
Have you seen the Navspark, even the Navspark Mini, which is both a GPS and a microprocessor (32 bit) that can run Arduino code and is substantially faster than an Arduino? Also the GPS in it is quite good.
In keeping with the "ghetto" approach I am not even considering their timing GPSs, their $7 Mini will do.
Its PPS seems to be very reliable, even with a passive antenna and it's got the ability to act as a semi-stationary GPS to some extent.
It can generate a higher frequency signal by telling it to generate a certain frequency as a clock signal for i2c. How stable that is, if it is locked to GPS I don't know but it seems to me as if it does use the GPS to discipline its internal clock within limits so it is possible that even though it is a non-timing GPS the integration of the controller into a GPS might make it possible to implement a GPSDO with only the GPS/CPU and the OCXO and a display and perhaps some switches and a USB-UART dongle. With your existing code, since its Arduino-compatible.
It also has Beidou in addition to GPS which gives it very stable fixes when Beidou sats are available alongside the GPS ones..
-
Have you seen the Navsark, even the Navspark Mini, which is both a GPS and a microprocessor (32 bit) that can run Arduino code and is substantially faster than an Arduino. Also the GPS in it is quite good. In keeping with the "ghetto" approach I am not even considering their timing GPSs, their $7 Mini will do.
Its PPS seems to be very reliable, even with a passive antenna and it's got the ability to act as a semi-stationary GPS to some extent.
It can generate a higher frequency signal by telling it to generate a certain frequency as a clock signal for i2c. How stable that is, if it is locked to GPS I don't know but it seems to me as if it does use the GPS to discipline its internal clock within limits so it is possible that even though it is a non-timing GPS the integration of the controller into a GPS might make it possible to implement a GPSDO with only the GPS/CPU and the OCXO and a display and perhaps some switches and a USB-UART dongle. With your existing code, since its Arduino-compatible.
It also has Beidou in addition to GPS which gives it very stable fixes when Beidou sats are available alongside the GPS ones..
I worry there is no over-constrained timing mode in the NavSpark mini.. That'll probably add a bit to its PPS jitter. (I'm not sure how much).
I'm not convinced it's necessary to use a higher frequency reference clock. The PPS signal from GPS is normally specified to be accurate with sigma=10 or 15ns, even with sawtooth correction. Sampling the higher frequency from the receiver won't help (if sawtooth correction is used).
Also, loop constants are normally many minutes, comparisons more often than every second won't be helpful.... There should already be enough averaging.
-
How stable that is, if it is locked to GPS I don't know
It isn't locked to anything...
-
would I be able to use a different phase detector, such as MC4044P? It looks like the phase detector#2 out is the same as specified detector #3, which changes state only on any rising edge?
http://www.unitechelectronics.com/MC4044P_PLL.pdf (http://www.unitechelectronics.com/MC4044P_PLL.pdf)
-
The MC4044 is a TTL device rather than CMOS. I that means that it will have greater input loading on the OCXO. Its TTL output levels (rather than full swing CMOS) will probably affect the the characteristics of the voltage ramp on C1 (I note that the MC4044 needs an internal charge pump and amplifier in its loop filter).
As an aside, the HC4046 includes self-biasing CMOS Sig. and Comp. inputs, meaning that they can be AC coupled. Lars hasn't used this feature but it may be useful, depending on the output swing of the OCXO.
-
Main problem is that I don't really require a bench 10Hz standard
It looks as if you're a Million times less susceptible than others. ;)
Good one :-DD
Typos can be so fun on a technical site. :-+
-
The MC4044 is a TTL device rather than CMOS. I that means that it will have greater input loading on the OCXO. Its TTL output levels (rather than full swing CMOS) will probably affect the the characteristics of the voltage ramp on C1 (I note that the MC4044 needs an internal charge pump and amplifier in its loop filter).
As an aside, the HC4046 includes self-biasing CMOS Sig. and Comp. inputs, meaning that they can be AC coupled. Lars hasn't used this feature but it may be useful, depending on the output swing of the OCXO.
That sounds like a no... Otherwise I have an ON 14046, but not with the #3 detector, so I think it won't do either. I'll have to draw up a list of parts to make the shipping from DK worth it. Thanks.
-
That sounds like a no... Otherwise I have an ON 14046, but not with the #3 detector, so I think it won't do either. I'll have to draw up a list of parts to make the shipping from DK worth it. Thanks.
Why not use a SR latch/flip flop like the SN74LS279 or SN74*74? Are they higher jitter?
-
That sounds like a no... Otherwise I have an ON 14046, but not with the #3 detector, so I think it won't do either. I'll have to draw up a list of parts to make the shipping from DK worth it. Thanks.
Why not use a SR latch/flip flop like the SN74LS279 or SN74*74? Are they higher jitter?
I'm not savvy enough to figure that out. I suspect it would downgrade the design to FLL and there is still the matter of TTL levels (where is one reading CMOS levels for the specified PLL anyway? It is CMOS and TTL compatible so I thought output would be Vcc?).
-
Excelent info Lars. Specially in what to expect with different types of oscillators and gps.
I am starting to experiment with this and your post was useful to bring me down to reality,
here is another good article with a similar interpolator method that uses a74hc74.
http://n1.taur.dk/gpsdo2a.pdf (http://n1.taur.dk/gpsdo2a.pdf)
Thanks for sharing all your data
-
Yes, thanks all for posting the project information with so much details. I was looking more into the Time Interpolator circuit and discovered a patent issued in 2012 to Lewis Masters/Phase Matrix Inc. It's quite a brilliant way to increase the timing resolution.
-
Yes, thanks all for posting the project information with so much details. I was looking more into the Time Interpolator circuit and discovered a patent issued in 2012 to Lewis Masters/Phase Matrix Inc. It's quite a brilliant way to increase the timing resolution.
2012 sounds very recent. The general approach of time dilation by charging capacitors at different time constants has been around a long time - I think many oscilloscopes used to use it.
-
Yes, there are many patents dating back to the 60's and many are referenced:
https://www.google.com/patents/US8324952 (https://www.google.com/patents/US8324952)
Masters implementation is just different than the others discussed here (but I think Lars may have made reference to a similar approach in his write-up - I did not look into those other designs yet). What really qualifies it as unique :-// seems very much the same idea, just using switches to turn off charging and discharging circuits, and an amplifier before the ADC.
The concept was not something that I was familiar with, but the general problem was something that was lurking in my thoughts of using a micro to time the events by counting cycles, and how I was going to overcome this problem.
-
Yes, there are many patents dating back to the 60's and many are referenced:
https://www.google.com/patents/US8324952 (https://www.google.com/patents/US8324952)
Masters implementation is just different than the others discussed here (but I think Lars may have made reference to a similar approach in his write-up - I did not look into those other designs yet). What really qualifies it as unique :-// seems very much the same idea, just using switches to turn off charging and discharging circuits, and an amplifier before the ADC.
The concept was not something that I was familiar with, but the general problem was something that was lurking in my thoughts of using a micro to time the events by counting cycles, and how I was going to overcome this problem.
The patent from 2012 looks very similar to the PICTIC II design from 2010
http://www.ko4bb.com/doku2015/lib/exe/fetch.php?media=precision_timing:pictic_ii_schematic.pdf (http://www.ko4bb.com/doku2015/lib/exe/fetch.php?media=precision_timing:pictic_ii_schematic.pdf)
see page two with a current source Q1, diode D5 and capacitor C116 and two switches through D1 and D2 going to an op-amp and ADC!
Of course these designs are better than mine but not as simple. I have not yet seen any just using the diode, series resistor, capacitor and discharging resistor (except those clearly based based on my design as Nick Sayers and the Elektor GPSDO).
Lars
-
Excelent info Lars. Specially in what to expect with different types of oscillators and gps.
I am starting to experiment with this and your post was useful to bring me down to reality,
here is another good article with a similar interpolator method that uses a74hc74.
http://n1.taur.dk/gpsdo2a.pdf (http://n1.taur.dk/gpsdo2a.pdf)
Thanks for sharing all your data
I really like Kasper's article and have read it closely. I even at a time wondered if I should change to his design but still think my are simpler and easier with enough resolution and stability. I also have worked a lot to prove that my design is robust with regard to the sync between the phase detector and timer1 readings. Testing a new design, including all kind of modes, user cases and environment takes time.
Lars
-
Hello all,
And thanks for the positive comments.
About the pdf's:
Probably in the long term I should publish this somewhere else if the design works well for more people. Pdf-merge seems to be a good way to combine them even if I haven´t tried it (I have a complete pdf that took some time to divide ;)? ) .
About rubidium or OCXO:
I have my rubidium powered all times. Of course we have power interrupts. The longest continuous run without an interrupt has been above 30 million seconds on the internal time counter, that is almost a year!
I was happy to buy two LPRO rubidiums cheap five years ago so I have one spare that I only power up seldom. Now it has been on for a couple of months as I have done a lot of tests and wanted a second opinion from another rubidium. The reason I use the rubidium is that it is by far the most stable oscillator I have in hold mode (free running). For me that want to test other GPSDO´s this is the best choice. My continuously powered rubidium has very low drift. From the 3 hour logs the last 9 months I can see a drift of 700 dac_value units, that is about 1.2E-11 for 270 days so about 4E-14/day. Worse is the temperature coefficient that is about 8E-13/C but in hold mode the temperature is compensated so probably within +-2E-13/C. The worst problem is the air pressure sensitivity of about 7E-14/mbar. I have a pressure sensor BMP180 built in but it doesn´t compensate. The air pressure is mostly a problem for me at long runs that are week long, as the air pressure varies slowly.
For most people I guess an OCXO based GPSDO is best. It will give about 9-11 digits of frequency accuracy. For those that want even lower power of course an VCTCXO based with e.g. DOT050V is a very good choice but only gives 8-9 digits for short times (seconds to minutes).
A lot of people think OCXO based GPSDO's take too long time to start up. If you want the GPSDO to lock in 5 minutes that is just the warm-up time for the OCXO, but remember that even with a retrace of 10ppb after being off for a long time, you will never be off more than 10ppb, as the old DAC value is stored in the EEPROM. So you will have 8 digits and probably better within 5 minutes, but no locked LED. If you set a short time constant say 20 seconds the locked LED will come on within just minutes after warm-up. This will of course give more ripple on the frequency but not worse than other designs that promise short start-up times. If you really want very good frequency accuracy you need to have long time constants mostly depending on the 1PPS stability that limits this. Another thing to remember is that I have used a quite conservative lock time of five time constants to be sure the loop has settled. The frequency probably is stable after half of that time at most start-ups.
Lars
-
Going through the last weeks time-nuts archive I found that Stanford has updated the FS740 GPSDO/counter/generator manual (that some may have downloaded an earlier version from the links on page 15 of my instruction).
http://www.thinksrs.com/downloads/PDFs/Manuals/FS740m.pdf (http://www.thinksrs.com/downloads/PDFs/Manuals/FS740m.pdf)
The updated manual now contains the complete BOM and 20 pages of schematics last in the manual. For me that are curious it is always interesting to see commercial designs.
Here you can see how they have done their Time interval counter with 1ps resolution. They also seems to combine a 16+12bit DAC to steer the oscillator.
Read also the comments by Attila in the time nuts archive here:
https://www.febo.com/pipermail/time-nuts/2017-November/107608.html (https://www.febo.com/pipermail/time-nuts/2017-November/107608.html)
Lars
-
Thanks for your efforts! I build the minimal design on a protoboard with one of those 10$ OCXOs from ebay.
It worked well but i can only test it with my 53131a with the HS OCXO.
Now i started to design a pcb for that. If it works i want to add a distribution amplifier.
-
Hello Qw3rtzuiop,
Nice to see a PCB design of my GPSDO. It is always possible to have a lot of comments. Both on the layout and also on the schematic.
But my advise is just to go on if not someone find something really stupid you should change.
I decided not to do a PCB design for several reasons. The first is that everyone have different requirements on for example output ports, oscillator pinout and connectors. You have a point in having a distribution amplifier. I had salvaged boxes from automated test stations I designed long ago (as can be seen in the instruction). They had three BNC on one side appropriate for the 10MHz outputs so my prototypes uses parallel 74HC or AC04 for buffering with square waves out (+about 40-50ohm in series). Second: I have always been fortunate to have good PCB designers at my side in my professional job. So in a case like this I had just told them that I wanted a good ground plane and that the oscillator and buffer should be placed so crosstalk from the Arduino and GPS module power and signals were minimized. A third reason is that I am struggling with my health that is also a reason I am not very active on EEVblog neither reading nor writing.
Lars
-
I feel a little guilty to haven’t answered PM’s and probably will not do but instead do some general comments here. As I said my health is not well – frankly I am suffering cancer and treatments are tough. So for a long time I haven’t done something to my GPSDO project.
My LPRO rubidium based GPSDO is on all time and a little sporadic I check it. It is still very stable and due to the internal data logging up to 18 days (every third hour) I can follow the drift of the LPRO. So after 5-6 years I can see drifts below 1E-13/day (averaged over long times).
One question is if I have an updated software and the answer is no. Actually I have not found or heard of any bug so severe that I have had a reason to do any changes. I have a long list of improvements but as testing is so important I would like to have a very good reason to do changes.
Some ask about LCD and my answer is again about robustness and also that it is so many different GPS module so I recommend adding the display to a separate processor that also reads the GPSDO controllers serial line. Others ask about changing components but again robustness. Some ask about changing processor but that is really something for everybody interested in experimenting except me.
Back in March I was a little bit better and decided to start two of my OCXO based GPSDO’s to get more data and charts as I had seen a lot of more or less strange comment in other GPSDO thread here on EEVblog. I decided to take two GPDO that I know had OCXO’s with a lot of retrace, so not the best. One OCXO with about +10ppm retrace for a month and the other with -10ppm instead. Both OCXO were STP2187 double oven from eBay. I also had seen that at least one of them had jumps in the E-10 range even if with days or longer between.
As the Trimble thunderbolt is very admired by time-nuts I decided to setup the OCXO time constants to give about the same ADEVs as a non-optimized thunderbolt with TC 100 seconds. That is to give an ADEV at about 1E-11 at 100 sec. This also gives the frequency accuracy as I see from e.g. the leapsecond .com tests that give frequency stabilities and accuracies of about 1E-10.
http://www.leapsecond.com/pages/tbolt-tc/ (http://www.leapsecond.com/pages/tbolt-tc/)
http://www.leapsecond.com/pages/tbolt-8d/ (http://www.leapsecond.com/pages/tbolt-8d/)
As my GPSDO is not as good as the thunderbolt I chose 200s TC, so settling time will be about twice as long is my guess. One of my GPSDO’s had a NEO 6M and the other an LEA6T (timing receiver) as the LEA can be set for position mode I tried that first. This also showed that the ADEVs at 100 seconds were similar and at about 1E-11 for both the NEO and LEA. With a good survey and timing mode it was possible to get ADEVs in the higher -12 range, maybe a factor of two better for the LEA.
One of the things I wanted to test was how long time does it take to get the frequency accuracy in this case. My goal were 1E-10. After about 30 minutes both GPSDO were within 1E-10 measured with a TAPR TICC versus the rubidium GPSDO. It took about an hour to get the locked LED ON. This shows the conservative locked spec in the Arduino program but I prefer this instead of the other way. As the locked condition requires the phase/time to be within 100ns (low pass filtered with 16 seconds) for at least 5 time constants this means that the frequency should be within 100ns/200secs * 5 that is 1E-10 so on par with my goal of 1E-10 in this case. But if you look on a PI-loop with the damping I have set, that also corresponds to the default setting of the Thunderbolt it will converge in a smooth manner that gives better results. I have had that it is a drawback to have just one time constant and no switching of time constant or FLL locking in the beginning but I am not sure it is really a problem from a settling time point either. Having just one time constant and the classic third order PI-loop are very robust in my opinion. Having seen comments on time nuts with HP 38xx GPSDO’s giving strange results after jumps also gives these conclusions as a jump recovers nice on my design.
During the month I had the GPSDO’s on I had one jump that were enough large to turn off the locked LED. As I said the locked LED requires the time to be within 100ns. If the OCXO jumps 2E-10 and the time constant is 200seconds the loop will go away just below 100ns so the jump was above 2E-10.
I also had another occasion with the locked LED off that I traced to the signal from the PPS but don’t know if it were the GPS module or antenna. I should say I at both of these occurrences had a terminal program that logged the output of the GPSDO serial line otherwise I only afterwards could have seen from the logged 18 days data that the GPSDO were unlocked during 3 hours.
Lars
-
Hello:
Is there any other recommendations for a GPS receiver module, I note you recommend the Neo7M, but wondering if there are others that can be considered. Are some better suited to supplying a frequency reference. There is also the 8M/T model(s) and the Venus, but not sure as to what advantages/disadvantages they have. I was going to start with a old Jupiter-T TU60-D120 module that I have as it has a 1pps output.
Jupiter-T datasheet
6.1.1 Pin J1-6: 1PPS output This signal is a positive going pulse with the leading edge being the point of measurement for synchronisation with the GPS satellite transmissions. The pulse width is approximately 26 ms.
Regards
-
You might enjoy this series, on the topic...
Scullcom Hobby Electronics # 35 - Design & Build a GPS locked Frequency Reference Standard
https://www.youtube.com/watch?v=lbns-FvpzK4 (https://www.youtube.com/watch?v=lbns-FvpzK4)
Also at his website.
-
Hello:
Is there any other recommendations for a GPS receiver module, I note you recommend the Neo7M, but wondering if there are others that can be considered. Are some better suited to supplying a frequency reference. There is also the 8M/T model(s) and the Venus, but not sure as to what advantages/disadvantages they have. I was going to start with a old Jupiter-T TU60-D120 module that I have as it has a 1pps output.
Jupiter-T datasheet
6.1.1 Pin J1-6: 1PPS output This signal is a positive going pulse with the leading edge being the point of measurement for synchronisation with the GPS satellite transmissions. The pulse width is approximately 26 ms.
Regards
Hello Bryan,
As you indicate the new timing modules from uBlox like the 8-series and the Venus 838 could be better choices. I prefer the uBlox.
I only recommended the NEO7M as it were cheap, available and is easy to use and at the same time gives good performance that I have measured. For simple position receivers with 1PPS I guess the ones from Adafruit is worth looking for even if not state of art for a GPSDO.
I am also curious about the Furano GT87 and hope that somebody will test it and give ADEV and MDEV's.
The nice thing with Lars GPSDO is that almost every GPS module with a 1PPS out can be used if the amplitude is 3.3-5V and the 1PPS is accurate on the positive going flank. The pulse width can be down to 10uS and probably even shorter. A square wave also works.
As you have a Jupiter-T I would definitely use that first. I started with even older and more jittery GPS modules and without timing mode and it worked. Of course a modern timing receiver will give better frequency accuracy and ADEV's but the loop should settle in the same time.
Lars
-
Does anybody sell a Lars board (bare or stuffed) or have some Gerbers available? I've been wanting to do one but have not had the time available. Lady Heather does have some support for it.
I have a couple of GT87's. They are probably the best GPS out there in regards to the 1PPS. Their sawtooth correction range is a couple of ns and the span of the 1PPS jitter is in the 5 ns range.
-
Hello Bryan,
As you indicate the new timing modules from uBlox like the 8-series and the Venus 838 could be better choices. I prefer the uBlox.
I only recommended the NEO7M as it were cheap, available and is easy to use and at the same time gives good performance that I have measured. For simple position receivers with 1PPS I guess the ones from Adafruit is worth looking for even if not state of art for a GPSDO.
I am also curious about the Furano GT87 and hope that somebody will test it and give ADEV and MDEV's.
The nice thing with Lars GPSDO is that almost every GPS module with a 1PPS out can be used if the amplitude is 3.3-5V and the 1PPS is accurate on the positive going flank. The pulse width can be down to 10uS and probably even shorter. A square wave also works.
As you have a Jupiter-T I would definitely use that first. I started with even older and more jittery GPS modules and without timing mode and it worked. Of course a modern timing receiver will give better frequency accuracy and ADEV's but the loop should settle in the same time.
Lars
Thanks Lars, used to have a UCCM and Trimble but gave them up as unfortunately I have a poor view of the sky. But have the bug again so wanted to try a project for the fall, will give the Jupiter a try. One advantage I see with the newer modules is they can see more satellites, and for the most part should have better timing.
-
I have a couple of GT87's. They are probably the best GPS out there in regards to the 1PPS. Their sawtooth correction range is a couple of ns and the span of the 1PPS jitter is in the 5 ns range.
Interesting, I haven't seen the GT87's for sale in many places, at least not on Ebay. Digi-Key, but not very cheap though.
-
Here is a place in Germany:
https://www.buerklin.com/en/gnss-module-und-gps-module/p/64s3196 (https://www.buerklin.com/en/gnss-module-und-gps-module/p/64s3196)
The GT-8736 is the module on a breakout board.
-
Thanks, for the link, Digikey has a couple which is probably comparable in price. Still pricey compared to the Neos,
https://www.digikey.ca/products/en/rf-if-and-rfid/rf-receivers/870?k=furuno (https://www.digikey.ca/products/en/rf-if-and-rfid/rf-receivers/870?k=furuno)
-
Digikey seem only to sell the module or the very expensive development kit.
The GT-8736 module looks more useful at a reasonable price. The Furano web site doesn't have much info on the module except it reveals that it emulates the Motorola M12+ on which there is a lot of info:
https://www.cnssys.com/files/M12+UsersGuide.pdf (https://www.cnssys.com/files/M12+UsersGuide.pdf)
-
The Furano web site doesn't have much info on the module except it reveals that it emulates the Motorola M12+ on which there is a lot of info:
https://www.cnssys.com/files/M12+UsersGuide.pdf (https://www.cnssys.com/files/M12+UsersGuide.pdf)
The GT-87 can speak NMEA, M12, or Furuno ESIP protocols. Lady Heather can switch between them. The ESIP protocol seems to be slightly better than M12... it can report the sawtooth error to sub-nanosecond resolution. M12 is limited to nanoseconds (integer value).
The GT-87 docs say the the GT-87 can also support Furuno PFEC protocol, but this puts it into a funky, undocumented binary protocol that effectively bricks the unit... Heather blocks all attempts to enter PFEC mode.
-
Texaspyro mentions the GT-87 has superior 1pps performance, but not sure how the GT-8736 would perform.
-
Texaspyro mentions the GT-87 has superior 1pps performance, but not sure how the GT-8736 would perform.
The 8736 is jus the GT87 on a board with the M12 form factor/pinout. It's the one I did the testing on.
-
Hey Lars,
I made your GPSDO on a breadboard and I can't get it to lock. Please see attached. I assume the schematic is good and I verified everything with the oscilloscope.
I use Bliley NV47A1282.OCXO. The only problem with this OCXO is that it seems to have an internal voltage divider that keeps the VFC pin around 2.8V. I had to add a 100K resistor to GND to bring the control voltage below 1.54V (that's the VFC for 10MHz on my OCXO) with h1.
Could you give me a hint?
Edit: It locked few times but it is unstable. It keeps saying "Missing 10MHz?".
-
Success, it locked!
However, it doesn't lock with the calculated gain which is 100. I had to increase it to 200. I also get a lot of "Missing 10MHz?" before it gets close to the correct DAC.
-
Success, it locked!
However, it doesn't lock with the calculated gain which is 100. I had to increase it to 200. I also get a lot of "Missing 10MHz?" before it gets close to the correct DAC.
Hello Miti,
good that it locked but you have to blame me and my instruction that you have "missing 10MHz" due to insufficient hardware instructions on the 10MHz oscillator. The small section on the 10MHz oscillator doesn't mention square wave versus sine wave outputs from the OCXO. You have an OCXO with sinewave out. I have tested several with sinewave with good result. What I have missed in the instruction is that if the output is sinewave it is critical to have bias on the 10Mhz input. That is to add for example two 100kohm resistors as pullup and pulldown to ground and +5V respective on the HC390. This gives a DC bias of 2.5V. So my first suggestion is to add 100kohm from HC 390 pin 1 to pin 16 (+5V) and another from pin 1 to GND.
Hey Lars,
I made your GPSDO on a breadboard and I can't get it to lock. Please see attached. I assume the schematic is good and I verified everything with the oscilloscope.
I use Bliley NV47A1282.OCXO. The only problem with this OCXO is that it seems to have an internal voltage divider that keeps the VFC pin around 2.8V. I had to add a 100K resistor to GND to bring the control voltage below 1.54V (that's the VFC for 10MHz on my OCXO) with h1.
Could you give me a hint?
Edit: It locked few times but it is unstable. It keeps saying "Missing 10MHz?".
For the EFC input to Bliley NV47A1282.OCXO you have done exactly correct to add a resistor , in this case 100k to ground. Later you can probably test to have even a little lower resistance depending how the oscillator drift. If you have lower resistance the gain will change so you have to test it again.
As the output impedance of the PWM is about 78Kohm (39k+39k) and the input impedance on the OCXO according to the data sheet is 10-100kohm you get a voltage divider to the internal OCXO ref that you say is 2.8V. In this case you have an OCXO range of 0-4V. Some OCXO as for example the 8663 type might have above 5V EFC. In this case you need a resistor to a higher voltage. I have often used a 10k trimpot from the Vref on The OCXO to GND on the OCXO. Some OCXO's don't like as low a load of 10kohm on the Vref so that could sometimes be a problem but in very few cases.
-
I like your screen shoots. If you add the two 100kohm resistors (values not so critical, even a factor of ten will work to get 2.5VDC as long as the values are the same, if the OCXO has no coupling capacitor on the output you might need to add for example 10nF in series), it will be interesting to see a screen shoot of h1 and h65535 to see the diff_ns to see why you get instability with a gain factor of two wrong. Of course it could be due to the missing 10MHz that that I hope have gone away.
Lars
-
Hi Lars and thank you for the quick response!
It stayed locked for almost one day now. One thing I forgot to add regarding the sine wave output, I used a second HC4046 to make it square like in Brooks Shera's schematic, except for the 10K and 50K resistors, I injected the full 1.5Vpp to the input of HC4046 through 100nF capacitor. I've attached that part of the schematic. My 10MHz should be very reliable square wave. I observed that after power up, during and after warm up period, when TIC is high (500+) I get that message "Missing 10MHz?" so it must be something in the software. One thing that seems to have made it better, and I don't pretend I know why and what all the numbers mean, is when I changed the TIC_Offset from 500 to 650.
-
Hello Miti,
As you have used Shera's sine to square circuit it shouldn't be the problem I suggested in hardware. So now I am more confused!
The problem I see is that the "missing 10MHz" comments just is written instead of the TIC_value 1023 that is the ADC0 value read in the very short interrupt routine in the beginning of the program. The ADC0 reading is triggered by the 1PPS input.
So missing 10MHz must be because the pulse on the HC4046 output is too long and gives maximum ADC value. As the HC4046 is set high by the 1PPS and reset by the divided down 10MHZ to 1MHz the 1MHz if it isn't missing shouldn't give more than a 1us (1000ns). If the diode+3.9k+1nF and discharge resistor 10M are ok this shouldn't give more than around 970+-40 maximum ADC reading. With h1 or h65535 you should see the ADC readings changing fast on the filtx10 value but multiplied by 10 so if the filtx10 value is 6500 it is an ADC value of 650. The second row with ns values around zero (in locked condition) has some math on them and also subtracts the TIC_offset. Note: the filtx10 is only the ADC value in non locked condition as in the locked condition it is a low pass filtered value.
It is also intersting that now you don't seems to get missing 10MHz? Have you let the GPSDO cool down and restarted to see if you get the problem again?
About the TIC_offset it just and offset on the ADC reading. So if the TIC_offset is 500 and you have an ADC reading of 500 the input to the PI-loop will be 0 and no shift of the DAC value will happen. If you change the TIC_offset it will strive to 650 ADC reading instead. So if you change it on the fly you will see a reading on the ns value on the serial monitor of -150ns as the ADC reading is around 500 and the TIC_offset higher at 650.
Would be intersting to see what happens if you change the TIC_offset back to 500. As this is more than 100ns difference you will loose lock. But it should only take about 5-10 time constant to get lock again.
I have selected 500 as TIC_offset as that is around the mid point of the ADC range 0-1023.
Lars
-
Hey Lars,
I attached the h1 and h65535 screenshots.
One weird thing I observed, I would expect the voltage on C1 to have a base line of 0V with some short pulses. Instead, it stays around 200+mV with pulses. See the attache scope shots. Interesting thing is that if I disconnect the cap from the ADC input, everything is as expected so I thought there may be a leakage from the ADC input. The ADC input however stays flat at 0V. Only when they are connected together, the baseline jumps to over 200mV. This is SF ... or electronics. :-DD Could you check your circuit?
Edit: Just to be clear, when I say I disconnect C1 from A0, I mean that I separate R1, R2, C1 from A0, see the cut in the attached minimum working schematic.
-
The C1 must be a quality foil capacitor. What type do you use?
PS: at the pin15 of the 4046 you should see a short square 5V pulse, the pulse up to 1us long, once a second.
It charges the C1 (the longer the pulse the more peak voltage at C1) and the MCU does an ADC measurement asap.
The voltage at the C1 drops down to zero then (because of the 10M discharge resistor, D1 leakage and A0 input clamp diodes leakages).
Double check you get the <1us pulse at 4046_pin15 once a second. When you get the pulses more frequently it could create your "200mV dc level".
Also double-check the R1, R2, C1 values. Much larger C1 value than 1nF may create the 200mV dc level as well.
-
Hi imo,
C1 is a foil capacitor, not sure the exact type, and I do get a pulse between 0 and 1us and if you look at my scope screen shots, if I disconnect the circuit from the uC ADC, the result is as expected. Only when I connect them together I see that DC level, that's what puzzles me.
-
It could be your grounds (the gnd of the 4046 vs. the gnd of the Pro mini or atmega328) are 200mV off.
-
Thank you for mentioning Shera. I had bought all the components to build that design but got stymied by CPU programming and its environment. I can work with Arduino (not sure if I can comprehend the code here), but at least I have two HCT4046 detectors, and I must have had an idea for HC390 as my earlier post did not mention it. Anyway, I think I have all the parts, even a 5V VC/OCXO so I'll attempt to breadboard this up and see what I can get it to do. I really needed another GPSDO to verify the two repurposed Trimble units...
Thanks again Lars. Hope you are feeling well.
-
Can someone draw&post here, full schematic of Lars GPSDO solution, please?
-
I was just going to build the minimum schematic and the Arduino source as-is. The first post has all the details and PDF descriptions.
-
Hello Miti,
First I have to correct myself. The filtx10 is not only the ADC but also adds or subracts 10000 every 1000ns change on timer 1. But from your first screen shoot it seems the minimum value is 5250 that is 525 on the ADC. This explains why you had to set 650 as TIC_offset to get it locked. Normally the minimum ADC is around 10-12 (filtx10 =100-120).
Just another parentes is:
The h1 also shows that the diff_ns is about 100 and the h65535 on the next screen shoot shows -500 so the difference is 600. This is what I use for gain calculation Gain = 65535/600 that is about 100 that should be stored to Gain in EEPROM.
Ok so this is interesting (for me) and weird. I can't really see the problem. But as imo points out it could be a missing ground so please check them.
Your oscilloscope shoots are really nice. The time constant seems to be about 5ms that is very reasonable if your probe has about 10Mohm impedance. In parallell with R2 it will give 5Mohm and with 1nF it gives 5ms. So my guess is that R1, R2 and C1 is ok and also the diode.
What is strange is of course that both side of the disconnection goes to zero but not when connected together. I guess the probe ground have not been moved between the three measurements?
Another observation is that the slope on the disconnected is more an exponential function. On the faulty it seems to go down to 160mv and stop. Could be some diode effect??
Another strange thing is that the minimum ADC value of 525 corresponds to about 550mV. This is more than three times the value without the oscilloscope probe. I would have guessed maximum two times if the probe is 10Mohm.
Another test, if the Grounds are ok, is to parallel or change R2 to 1Mohm to see if it is a difference.
Another question: You are using a Pro Mini board?
The 1nF I have used have been ceramic SMD0805 NPO from diffent suppliers without problems so I don't think they are so critical.
Lars
-
Hi everybody,
The minimum schematic should work (with a 10MHz square input). If you want to add a temperature sensor have a look in the instruction of recommended types and setup.
The software should work without any changes. So you don't have to go into the code if you don't want to learn something about the code. The only important parameter to setup from the serial monitor after you have downloaded the program is GAIN. This is the loop gain and very important. In the instruction it is described how. In my last post I almost told everything with h1 and h655365 command and diff_ns to find the Gain. Remember to store it to EEPROM. The h1 to h65535 sets the PWM-DAC fixed. Very useful for testing.
Lars
@metrologist: Sorry to say my health is not going better. The cancer is too much spread, just hoping it will spread slowly only, for the moment.
-
Hi Lars,
I'm really sorry to hear that you're not doing well. Please let me know if you're not in the mood to respond to my questions.
I appreciate your help and the fact that you shared this complex project with us. The issues that I have are clearly related to my implementation. I measured quickly all the GND points and they are all within fractions of mV. I shorted C1 just to see the ADC reading and it was 10000 so technically 0. If it was a ground issue, the offset would still be present. I suspect some flux residues even tough I used rosin core which should be neutral, I will give it a good wash with Vigon EFM in the weekend. That stuff is amazing at cleaning boards. Why it doesn't show up when I disconnect the circuit, beats me. I will do more work in the weekend as I'm very busy these days.
I am using this https://www.banggood.com/Wholesale-New-Ver-Pro-Mini-ATMEGA328-328p-5V-16MHz-Arduino-Compatible-Nano-Size-p-68534.html?rmmds=myorder&cur_warehouse=CN (https://www.banggood.com/Wholesale-New-Ver-Pro-Mini-ATMEGA328-328p-5V-16MHz-Arduino-Compatible-Nano-Size-p-68534.html?rmmds=myorder&cur_warehouse=CN) pro mini board.
The capacitor is polypropylene film https://www.vishay.com/docs/26016/kp1830.pdf (https://www.vishay.com/docs/26016/kp1830.pdf) but as you said, shouldn't be critical. The GPS module is a Ublox Neo-M8T-0.
PS: If I can get it to work properly, with your permission, I intend to design a board. All SMT with Atmel and Ublox on the board. BTW, do you know what settings I need to do to take advantage of the timing features of Ublox NEO-M8T?
-
Hey, I just had an idea/question: what would it take for the Lars GPSDO to work with LadyHeather? I'm sure LH will work with most commercial GPS, but I suspect the Arduino would need to parse the GPS data and add its internal tuning and magic to its serial output. It might be able to emulate some other device, or LH expanded to cover this custom build.
I have verified that I have the two chips (one older SN7490N and newer HCT4046) and passives needed. Just need to find a diode and I should be ready. I have hundreds of SMT diodes, but have not figured out how to class them.
-
Hey, I just had an idea/question: what would it take for the Lars GPSDO to work with LadyHeather?
Supported already in Beta version....
pls look here:
https://www.eevblog.com/forum/metrology/lady-heather-v6-beta-for-windows-exe/msg1434005/#msg1434005 (https://www.eevblog.com/forum/metrology/lady-heather-v6-beta-for-windows-exe/msg1434005/#msg1434005)
-
Thanks! I see it in the list and am thankful Lars's design is being recognized. I really like this approach. I am not clear on what data is being used since the GPS and Arduino have different serial streams? I think you can run multiple instances of LH though. I suspect LH should use the Arduino serial data as that would provide the kind of data we're interested in for the oscillator. :-+
-
You can use the Lars GPSDO as the main "receiver" input device where it is treated as a time interval counter.
You can also use it as an "extra" input device with the GPS receiver as the main input device. In this mode the Lars GPSDO is used to calculate ADEVs while the main display is the GPS info. To use this mode use the /ei=port /itl command line options.
Note that support for the Lars GPSDO is a bit sketchy. I don't have one to refine the support. Also Heather does not send any commands to configure the Lars device (except via the !u (send user command). You can use the !t terminal emulator mode to talk to the Lars.
-
Thanks! I didn't know LH could utilize and extra input. :-+
-
Thanks! I didn't know LH could utilize and extra input. :-+
Yes, Heather now supports several external device ports including:
echo receiver data to a port
echo receiver data to a port in NMEA format
ticc/counter port
environmental sensor port
satellite / sun / moon / time tracking port
temperature control port
DAC / ADC port (not yet fully implemnted)
-
Thanks texaspyro!
I've got LH to work with Lars GPSDO as an extra input device but it keeps resetting the statistics. Every few seconds it flickers and the graph starts from zero again. It doesn't happen if I see only the GPS. Also, I cannot see the ADEV on the graph and I tried /ga.
It doesn't work for me as the main receiver or I don't know how to configure it. What commands do I have to send?
-
I've got LH to work with Lars GPSDO as an extra input device but it keeps resetting the statistics. Every few seconds it flickers and the graph starts from zero again.
There was a bug in some versions that caused the data to be reset every 10 seconds or so in some configurations. I am going to post an updated version in a few days.
The "A" keyboard menu controls what kind of ADEV info to show. The GA keyboard command toggles the ADEV plots on and off.
The GLP keyboard command will set the lat/lon displays to private so you don't have to edit your screen dumps.
-
just a proof - it locked for a couple seconds. The osc seems very sensitive to the environment, but not so much to the tuning control. I can monitor both GPS 10MHz and my OCXO and can see it is close to lock, looks stable for minutes, but then starts to drift. Tune voltage is typically stable around 2.2V, then the osc does not seem to respond quickly when it starts to bounce around 300mV swings, but the frequency can adjust high to low... I probably have bad components - the two "caps" make 1nF, but I'm not sure what kind they are - and everything on long leads hanging out in the air. :-DD I have a better oscillator, but then I'd need all the voltages, 12, 5, 3.3... It'w worth it to build it up right in an enclosure.
What's the batch file line (switches) so LadyHeather sees it? It did not recognize it.
"C:\Program Files (x86)\Heather\heather.exe" /5 /br=9600:8:N:1
-
I did a bit more work on the GPSDO today and I managed to reduce the voltage offset on C1 to about 100mV by cleaning up and shortening the ground connections. I still don't understand where is this offset coming from. It is way more stable now, I reduced the TIC_Offset back to 500 and I don't get the "Missing 10MHz?" message anymore.
I use separate regulators, one for OCXO and digitals, one for the Arduino. The GPS is supplied from the USB for now. Star ground, both 5V are rock stable but I still have the 100mV offset.
Anyways, it locks and stays locked now.
@texaspyro
I don't know why but whenever I connect the GPS module to LH SW, its sensitivity is greatly affected to the point where it doesn't get a fix anymore. The sensitivity stays low until I connect with U-Center and do a "Revert to default configuration" when it comes back to life again.
-
I've been having trouble with my old 7490 chip, the divided outputs are too low - rather it is my USB drive that struggles with the 500mA output and supply voltage drops to 3.9V. I was hoping to power solely from USB. I added a battery bank and it helped.
It will lock and stay for minutes. I found gain of h1 = 1600 and h65535 = -1750. I set gain at 20 and it locked in a couple minutes. Here I am, I will have to watch it for long time. 8)
So much more to read. :-+
edit added 8hr diff-ns plot, only lost lock for a brief period ;D
-
I have finalized the circuit and put it in the box. I still have some things to clean up but it is 95% done. The box is an Extron Ada 6 300MX that I modified for 50 Ohm like Gerry Sweeney did. The result is pretty good but not perfect. There's a bit of distortion in the sine wave and I think is again ground related. I may need to add a 15 - 20MHz low pass filter to clean a bit the high frequency components. It also may need some tuning. I think that once a proper board is designed, this may be a pretty good GPSDO.
-
I managed to reduce the voltage offset on C1 to about 100mV by cleaning up and shortening the ground connections. I still don't understand where is this offset coming from.
Look at the voltage difference between the "gnd pin of the atmega328" and the "gnd at the pro mini pcb pin".
There's a bit of distortion in the sine wave and I think is again ground related.
It looks like ringing. A suboptimal source/load impedance matching somewhere (it could be induced from an adjacent square wave signal, or, via gnd..)??
-
Yes, impedance matching is another possibility. The cable and the amplifier input are 50 Ohm but the OCXO output may be not. I'll have to rethink the circuit in that area.
Here's my Allan deviation after one day, t=100.
-
I did a bit more work in the weekend and here's the result. It is not perfect but I'm happy. The frequency counter doesn't seem to have a problem, it is very stable and the spectrum analyzer doesn't show tooo much garbage. The second harmonic is almost 56dB down, the third harmonic is only 36.5dB down but without a filter probably is the best I could get, and the fifth harmonic is 51dB down. There are some harmonics around 330MHz but they are 48dB down, I'm not too worried about them. Probably I should be worried if this was used as a reference for a radio but at this moment I'll be using it for my instruments only.
I tried a TC of 1000 but it looses lock in the afternoon when the sun hits my basement window. TC=500 seems to work well even though I think I'll try a bit higher when I have time.
-
Here's my Allan deviation after one day, t=100.
ADEV of what?
-
Here's my Allan deviation after one day, t=100.
ADEV of what?
I assume that 1ns of resolution average of 100 samples using Bliley NV47A1282.OCXO and Ublox NEO-M8T with ±11ns pps jitter - as reported by Lars solution (arduino output)?
-
I saw the ADEV and as I have used the output from the Arduino my guess was that it is the DAC values taken directly from the Arduino serial port into timelab. I confirmed this with Miti in a PM.
In my GPSDO instruction on page 11 I give some hints how to find optimum Time Constant. This is also what Miti done. The difference is he choose TC=100. I have recommended TC=4. The reason is that below the TC the DAC value is heavily filtered. This is the reason the noise from the GPS is not affecting the 10MHz output. I enclose the picture from the instruction, Note it is the blue line that is the normal response from an OCXO the red contains a frequency jump that upsets the data . As you see it is MDEV and not ADEV as I think it get closer to the real word to find the optimum. In the instruction on page 11 i give an explanation. But in short the GPS signal is filtered in software so it more is like the MDEV that also is a filtered value. For the oscillator signal that more is dominated by flicker noise the ADEV and MDEV is quite close.
Ok so what you see on Mitis ADEV is not relevant below 100 sec (as the TC=100). From say 200-300s to 1000s you see the GPS. And the minimum is at around 1000s. If this curve had been done with MDEV the GPS part has been slightly lower like in my picture. Also the minimum had probably been at around 700s and the minimum value around 7E-12. This point is also probably what you can get as ADEV at 700sec as here both the GPS and OCXO is affecting the loop. At lower taus the OCXO is probably similar as at 700s and above the GPS will make the output OCXO output go towards lower ADEV's. Probably at Tau 10000s it will be around 1E-12 with a Neo7m and better with a timing receiver.
Lars
-
Yes, it is indeed the DAC.
-
Do you mean the DAC value multiplied by "gain" (where gain = ppb/DAC)??
PS: I've been looking for best practices with the "similar" stuff here (https://www.eevblog.com/forum/metrology/how-to-test-a-diy-counter-with-gpsdo/)..
-
Lars, have you ever thought of using a TCXO as an OCXO using a temperature control loop, say putting it in a foam insulated box with a resistor for heat, and a temperature sensor, shaving a bit of money off of the setup?
-
Do you mean the DAC value multiplied by "gain" (where gain = ppb/DAC)??
PS: I've been looking for best practices with the "similar" stuff here (https://www.eevblog.com/forum/metrology/how-to-test-a-diy-counter-with-gpsdo/)..
Yes it is important with the scale factors when you work with Timelab. See page 12 in my instruction (found in first posts) and page 18 for a screenshoot of Timelab. Both for the DAC and ns-values it is good to have a sanity check of the scaling of your ADEV's MDEV's etc. I have often missed the ns or ppb and got a factor of a billion wrong. This is easy to see as you for example gets 1E-3 instead of 1E-12. It is worse if you just get a factor of 10 wrong. 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. This is also true for the Time interval Counters whether it is the TIC inside the GPSDO controller or an extenal counter. For the TCXO or OCXO you can also guess a little what you want to see. TCXO seldom goes below 1E-10. Only best goes to -11 regions.
Well so for Timelab and a gain of 500 (in the Arduino GPSDO) the Time lab numeric field will be multiplied with 2E-12. With a gain of 100 it will be 1E-11 (1E-9/100).
Also numeric field #3 is the DAC. The other important field to use is the ns-value that is numeric field #2.
Lars
-
Lars, have you ever thought of using a TCXO as an OCXO using a temperature control loop, say putting it in a foam insulated box with a resistor for heat, and a temperature sensor, shaving a bit of money off of the setup?
Yes as I like to experiment. The problem are that even the best TCXO like a DOT050V (from eg Digikey) uses AT cut crystals and therefor are at least a factor 10 worse in noise compared to an OCXO with an SC-cut crystal.
Also as soon as you try to put a xtal osc in a heated temperature controlled box you looses a little of the power advantage a TCXO have including startup time.
Lars
-
I have to apologise, I shouldn't have post the graph without me understanding what it does and how to read it first. I do everything on the run lately. I should slow down or stop posting.
So what that graph is, I finally understood myself |O, it is what Lars said, the DAC captured in the third numeric field from the Arduino serial multiplied by 2E-12 which in Lars's example with a gain of 500 and 130ppb range is the correct Hz/bit but in my case with a gain of 120 and a range of about 546ppb iiiiisss not...
On top of that I didn't read that I should use t=4 so that graph is garbage...almost.
I will redo it when I find the time with the correct time constant and the correct multiplier which in my case is more like 8.33E-12.
Did I get it right this time Lars? :-DD
-
Hey Lars,
I see some wild jumps in the TIC, please see attached. Do you know where they could come from? I don't think my OCXO can jump that bad... or can it?
I don't think it is the temperature, it wouldn't create such a big jump. Maybe is the GPS? One of the satellites may be out of wack? What a crazy thought !
By the way, I'm using a Ublox NEO-M8T in fixed time mode.
The jump is bad enough that it looses lock. It recovers after awhile and it seems to be stable before and after that.
-
Which one is the tic column? Is that the diff_ns right of Lock status? I would expect that to show the pps jitter and ocxo instability. Maybe you can trigger the pps and compare to the divided 1MHz on your scope to verify. It should not jump anywhere near as much as one cycle (1uS). IIRC, you would also see that as the pulse width on the phase detector output. Also, could it be something going on in the arduino?
-
The second column is TIC. There's a sudden jump from 6.9 to -88.8.
-
In the 3.png (the second column) you may see a repeating pattern 6 samples long..
-
I have to apologise, I shouldn't have post the graph without me understanding what it does and how to read it first. I do everything on the run lately. I should slow down or stop posting.
So what that graph is, I finally understood myself |O, it is what Lars said, the DAC captured in the third numeric field from the Arduino serial multiplied by 2E-12 which in Lars's example with a gain of 500 and 130ppb range is the correct Hz/bit but in my case with a gain of 120 and a range of about 546ppb iiiiisss not...
On top of that I didn't read that I should use t=4 so that graph is garbage...almost.
I will redo it when I find the time with the correct time constant and the correct multiplier which in my case is more like 8.33E-12.
Did I get it right this time Lars? :-DD
Hello Miti,
You don't have to apologise. The DAC values are very useful too. Of course one of the problems is to give enough information of the surrounding conditions for both me and others.
I have used both TC=4 (best) and also the chosen TC (eg 200 or 500s) to get different information.
If the TIC (ns-value) has been normalized for min and max and you use hold-mode it will let you learn more about your GPSDO. The second column is the TIC value in ns and the third DAC-value and I find them most useful.
But go for the TC=4s for tests with DAC-values and timelab (MDEV) as this requires no TIC-lnearization if you want to find optimum TC.
Lars
Ps. I really like your and metrologist reports, pictures and charts. Continue with this.
-
The second column is TIC. There's a sudden jump from 6.9 to -88.8.
The first column is seconds since start. So after about 230000seconds this happens so about 3 days.
The jump seems to be about 100ns so one 10Mhz cycle. So my thought is a glitch in for example from the HC390, maybe ground?? I don't think it any problem with the GPS receiver or OCXO but a glitch. if you have got a glitch it will stay as it does here. Normally I never see a glitch. A side note: On row 9 you see the timer1 value of 25088. This should be around 25000 in locked condition (reset at start and at larger glitches etc.). The timer1 is the 10Mhz divided by two (5MHz) and counted between 0 and 49999 so repeats every 10ms.
Remember that the second row is the 1PPS with about 21ns p-p jitter (due to M8T) relative to the 10MHz, so what you see is the 1PPS jitter and that varies with the 48MHz from the M8T GPS module. The 48MHz will slowly drift so you get a triangular shape (repeating pattern) if you plot the ns-value (and sometimes hanging bridges!).
Ok as the locked condition requires the ns-value to be within 100ns but are low pass filtered with 16 seconds the unlocked condition will come after some (many) seconds. Here we can see it after maybe 40 seconds in 2.png. But the Pi-loop strives to get the ns-value to zero so after some time it will go to zero. To get Locked again we need to be below 100ns ns-value for at least five times the TC (that is in this case 500s*5).
So in the 3.png we are back again with almost zero ns-values and locked mode.
Lars
-
Hi Lars,
I installed two temperature sensors, one in contact with the OCXO and the other one inside the enclosure to measure the ambient temperature. My thermostat is set to 23C when we're at home and 19 when we're not. I can see the temperature dropping up until 3:30 when the 23C setting kicks in. At that time, with TC=400, it has a hard time keeping with the drift. I would really like to add a temperature compensation but I don't know where to start between 1 and 10000. I know that you didn't have much success with the OCXO but maybe you can give me an idea where to start without over doing it so I can experiment around that number. I've attached a log that captured at least one of those temperature variations, maybe it can give you an idea. I know that it wouldn't be so trivial for me to figure out from the code how much weight that temperature coefficient would have in calculating the 16bit DAC value.
Thanks!
Miti
-
I moved my breadboard out into the lab where I have my Trimble UMCC running another experiment. I can use it's 10M sine wave output and monitor the OCXO under Lars disciplining solution. I can see the phase drift matches the reported ns value. (I had a lot of trouble getting my laptop to recognize Arduino, but eventually it just worked...)
I plotted a few hundred samples of ns (blue) and DAC (red). Using a TC of 4 and damping of 3. It's still open circuit flopping in the breeze. It's quite marvelous. I ordered some better parts to build it onto perf board.
I tried connecting with TimeLab and that seems to work. I'm not sure how TL knows which data to use. Also, when it connects it resets arduino.
-
OK, so I can use delayed acquisition or put a cap on the arduino reset pin. The live data does not look at all like the data that I can feed TL manually. I used the ns column with a 1E-9 multiplier. I need to tune the gain and TC proper to get meaningful results, this CTI OCXO should be better than this.
-
I will let it acquire more data but I think it is safe to conclude that a good TC in my case is around 500 not considering the temperature drift? Fact is that if I take the cover off of the distribution amplifier that hosts the GPSDO, it looses lock most of the time. I'll have to find the correct temp reference and compensation factor. Unfortunately my basement temperature varies wildly from 26 - 27 C in the summer to 17 - 18 C in the winter.
-
Hi Lars,
I installed two temperature sensors, one in contact with the OCXO and the other one inside the enclosure to measure the ambient temperature. My thermostat is set to 23C when we're at home and 19 when we're not. I can see the temperature dropping up until 3:30 when the 23C setting kicks in. At that time, with TC=400, it has a hard time keeping with the drift. I would really like to add a temperature compensation but I don't know where to start between 1 and 10000. I know that you didn't have much success with the OCXO but maybe you can give me an idea where to start without over doing it so I can experiment around that number. I've attached a log that captured at least one of those temperature variations, maybe it can give you an idea. I know that it wouldn't be so trivial for me to figure out from the code how much weight that temperature coefficient would have in calculating the 16bit DAC value.
Thanks!
Miti
Hello Miti,
I enclose a picture from Excel with your data. I struggled with an old version of Excel and the result is fat from perfect but I hope you can understand. I have plotted your temperature, DAC-value and TIC ns values from about row 10000, The first 10000seconds I discarded as you had done some experiments I think.
Ok so the first about 30000seconds (about 8-9 hours) the temperature drops slowly but the DAC-value not so much. But as you say a temperature change happens (in just 45 minutes) this makes the DAC-value change much more. After a while the temperature changes again but much slower but again not a lot of DAC-value change. So here you see the problem that I am not so fond of temperature compensation for OCXO. I can see if you have much larger temperature excursions in a GPSDO in short times that it might be useful.
Ok so what about settings? First the temperature compensation uses ADC values that for an LM35 sensor is about 10 ADC steps per C. So for -2°C it is about -20 ADC steps. So 50 DAC steps is -20 ADC steps worst case. This would mean a temperature factor of -2.5 that should be multiplied by 100 and inverted. So +250. But this will overcompensate slow changes. Also read the short instruction on page 13.
Lars
-
Hello again Miti,
saw that you just made another reply.
I think my recent reply covered what you just say that quick temperature changes is critical. Your difference between summer and winter shouldn't be any problem.
And thanks for your MDEV plot. Will use it in a reply to Metrologist. As I understand you have used TC=4 and aquired DAC-values from row #3 (Arduino) in Time lab?
By the way a lot of my prototype GPSDO works best with TC=500s but i still have chosen TC=200s. even if it gives slightly worse result but less sensitivity to quick "large" temperature changes (like sun on the box). It also helps if the OCXO has small jumps that I have seen on several OCXO from eBay (also mentioned in appnotes from vendors like MTI).
In last reply i also forgot to calculate your apparent OCXO temperature sensitivityas I intended. As you have 50 DAC steps and a gain of 120 the frequency changes 50/120 ppb = 0.4ppb = 4E-10 for 2°C that is 2E-10/°C but for the slow changes it is much smaller of course.
Lars
-
I moved my breadboard out into the lab where I have my Trimble UMCC running another experiment. I can use it's 10M sine wave output and monitor the OCXO under Lars disciplining solution. I can see the phase drift matches the reported ns value. (I had a lot of trouble getting my laptop to recognize Arduino, but eventually it just worked...)
I plotted a few hundred samples of ns (blue) and DAC (red). Using a TC of 4 and damping of 3. It's still open circuit flopping in the breeze. It's quite marvelous. I ordered some better parts to build it onto perf board.
I tried connecting with TimeLab and that seems to work. I'm not sure how TL knows which data to use. Also, when it connects it resets arduino.
Hi Metrologist,
You are absolutely on the right way. With TC=4 you get information on both the 1PPS (GPS module) for low Taus from about 10 seconds in the Timelab chart. The OCXO is just seen when the OCXO gets worse than the 1PPS. For you OCXO it probably will also be like Mitis at about 500-1000secs. Here your MDEV curve will be in the E-11 or E-12 range. You need to take at least a few hours of data. I prefer to see both ADEV and MDEV Time lab charts but as I say in the instruction page 12 (start reading on page 11) the MDEV has been best for me.
As you gather DAC-value data from row 3 (see page 18, Timelab call it numeric field #3) from the Arduino serial line into Timelab needs to know that it is row #3. You also have to use the correct gain in the same place to get correct conversion (see page 12 for the calculation and examples). If you have saved at least a few hours data from the Arduino serial monitor with TC=4 you can also import data into Timelab and do the same (remember conversion due to gain). It is a lot of possibilities for postprocessing Arduino data :) .
Lars
-
Thanks for your help Lars!
Yes, indeed, it is recorded with TC=4, 3rd numeric field X 8.33E-12. I didn't wait much longer as the plot didn't seem to change much, I will do it over a period of days once but I don't expect big change. I recalculated the gain by averaging 100 diff_ns readings for both h1 and h65535, before it was just by eye, and the new result is Gain=122, not too far from what I had before. I changed the temp ref to 420, it is about what I see now in the lab, and the temperature factor to 200, a bit less than you suggested so maybe I avoid over compensating. I'll keep an eye on the result and will post. I use TC=400 for now and will go down from there if needed or up to 500 if the TIC holds steady with the new temp factor.
Edit: The temp ref. =420 is the temperature of the OCXO and not what's in the lab since the temp sensor is silicon-ed to the OCXO side. :phew:
Edit2: It is 420 though.
-
I have a question for you all. I was surprised a few months ago to read that some of the non-professional grade GPSDOs still being sold for a lot of money on ebay basically are just a disciplined 10 Mhz source and GPS but the 1PPS is not disciplined any further by the OCXO GPS combination (to improve its jitter). They wire the internal GPS 1PPS directly to their 1PPS output and it is not smoothed out.
I suppose that to properly derive the 1PPS from the disciplined oscillator basically what would be required is a PIC chip that divides by 10 million (I think one of the the "PicDiv" preprogrammed PIC chips can do this) and then delivers a short pulse each time the positive going pulse occurs, with the setting for cable length on the input side fine tuned until the pulse matches the center of the stairstepping range (presumably the truest point along the 25 nanosecond second change range)
Its been a long day for me and I'm sleepy.. Is this right?
-
And here are the results with and without temperature compensation. Looks more stable to me after I set the TempCoef=200. Ignore that spike in the first graph, that's me.
-
Hi Metrologist,
...
Lars
Thanks, Lars. I calculate gain to be 19.2 (diff_ns = 1680 and -1740) and using g=20 you may see the green and blue curves below. It will not lock with TC over 10. I will wait for new components as I have electrolytic caps on the PWM filter and those old glass caps on the tic pulse (which might be OK), and also I have much better OCXO in 12V supply that may come to the board. I will need to read your info on setting linearization more. Note that I applied remove global linearization after acquiring data on each trace.
-
Metrologist,
A gain of <20 may be too low to have a decent control, you jump too much up/down per every bit of DAC. Even my gain of 122 I consider too low, one should aim toward 500 at least, as recommended by Lars, or even 1000. Too high though and you may not be able to control long time drift so I'm guessing, depending on the OCXO, up to 1000 you should be ok. I think is preferable to use an op-amp to adjust the gain and offset rather than resistors.
And here comes the question for Lars.
I know that you recommend resistors/trimmer pots to adjust the gain and the offset based on individual OCXO needs but doesn't that change the RC constant of the filter? In my case I had to add two 50K from VC pin of the OCXO to ground just to bring the DAC towards the middle of the scale. Adding more resistors to reduce the range/increase the gain would lower even more the impedance seen by the DAC. How would that affect the loop?
-
The R3,4,5 and C2,3 low-pass filter the two PWM digi outputs - thus creating the "16bit DAC" (by changing the PWM duty).
Loading them with R lowers the DAC max output voltage accordingly. It should have had no impact on the PI control loop timing..
I would add an single supply rail-rail opamp - you may amplify (EDIT: or divide in your case - for example from 0-5V DAC's output to 0-500mV , and add an X Volts offset such your OCXO's tuning range will be from X to X+500mV) and offset the DAC values easily then. It may add some noise and drift when not designed with care.
-
Yes, Miti. I was surprised that the diff_ns range was so large (note that now I posted the CTI spec and if my thinking is correct, then the voltage control range of 1000 to 2000 ppb yields gain of 32 to 65).
Also, there is a lot of drift when set to hold mode and it can vary in both directions. Setting damping too high and it will overcome one cycle. I'll look at the gain value again and measure the time difference directly. I'm going to try and optimize two circuits with two different OCXO's.
I found the CTI specs.
Product type: OSC5A2B02-10MHz
Nominal Frequency: 10.000MHz
Supply Voltage: +5V
Supply Current: Starting: ??600mA. Stability: ??250mA/+25Deg
Frequency Tolerance: 200PPb/ Vc=+2.0V(+25Deg)
Frequency stability vs. Temperature: 10PPb
Operating Temperature Range: 0Deg--+75Deg
Load Stability: 2PPb
Power Supply Stability: 2PPb
Aging: (after 30 days' power on) 0.5ppb/day
0.1ppm/first year
0.4ppm/10years
Short-term Frequency Stability: 0.05ppb/second (Allan Variance)
Warm-up Time: 100PPb/ Vc=+2.0V(+25Deg)
Voltage Control Characteristics:
Voltage Control Range: 1 ~2 ppm
Control Voltage: 2.0V
Slope: Positive
Linearity: 10%
Input Impedance: 100K??
Modulation Bandwidth: 10 KHz
Output Waveform: HCMOS Square Wave
Output Voltage:
VOH 4.5V min.
VOL 0.5V max.
Duty Cycle: 45/55 %
Rise/Fall Time: 6nS
Load: 15pF
Phase Noise: -80dBc/1Hz, -120dBc/10Hz, -140dBc/100Hz, - 145dBc/1KHz, -150dBc/10KHz
Operable Temperature Range: -40Deg~+85Deg
Storage Temperature Range: -55Deg~+105Deg
Package: 25.4mmX25.4mmX12.5mm(tin package)
The other I have are Milliren:
Output Frequency: 10.000MHz
Thermal Stability: ±1.0E-08
Temperature Range: -54°C to +85°C
Frequency Tolerance: ±1.0E-07 @ +25°C
Daily Aging: 1.0E-09/day after 24 Hours Continuous Operation
Mechanical Tuning: ±1.2E-06
Warm Up: 1.0E-08 after 3 Minutes referenced to 30 Minutes @ -40°C
Oven Supply Voltage and Power: 20VDC +/-5%; 7.5W Warm-up, 1.8W continuous at -40°C
Oscillator Supply Voltage and Power: 10 to 16VDC; 0.2W Max.
Output Power: +1dBm ±2dB
Short Term Stability: 5.0E-12 at 1 Second
-
Guys, in order to entertain you a little bit during your hard work - here is an idea how to adjust gain and offset such it fits an OCXO's tuning range best.. :D
The schematics:
1. at the input there is a resistive Divider (ie. it divides 1-5V DAC output to 100-500mV),
2. then an Adder (adds an Offset, ie. 6V for your OCXO) and
3. a "minus one" Multiplier (as the Adder does -1*(DAC+Offset) )
4. and finally the output goes to the OCXO's EFC input (the 100k there is the internal impedance of the OCXO).
With given values a DAC output of 1-5V divides to 100mV-500mV, adds approx 6V Offset (set via the pot trimmer) and the OCXO's EFC is then 100-500mV range around those 6V.
It needs a negative supply rail - that is pretty annoying.. :palm:
The below five colors are outputs for 1,2,3,4,5V input from the DAC.
You have to add a decoupling, use some better opamps (noise, offset, tempco), use stable and clean power supply.
Provided as-is, use at your own risk.. :)
-
Metrologist,
A gain of <20 may be too low to have a decent control, you jump too much up/down per every bit of DAC.
I thought it was the other way around, as a linear multiplier (or divisor). For example, higher end XO move less with proportional voltage change - if I understand, my Milliren moves only ±12Hz on the full 0 to 10V tune range. The CTI specs seem to say 20Hz over 5V range - but it looks like it moves a lot more and I need to measure it.
Guys, in order to entertain you a little bit during your hard work - here is an idea how to adjust gain and offset such it fits an OCXO's tuning range best.. :D
Oooh, that's fancy! Thanks!!! I was going to try a passive circuit. Am I right to think we do this to increase DAC resolution?
-
Metrologist,
A gain of <20 may be too low to have a decent control, you jump too much up/down per every bit of DAC.
I thought it was the other way around, as a linear multiplier (or divisor). For example, higher end XO move less with proportional voltage change - if I understand, my Milliren moves only ±12Hz on the full 0 to 10V tune range. The CTI specs seem to say 20Hz over 5V range - but it looks like it moves a lot more and I need to measure it.
On page 10 "gain = 65536 / VCO range (in ppb)". That means that your gain is too low because the VCO range is too big. Lars recommends restricting the range to 130 ppb using a "good" OCXO for a gain of 500, I don't know if this is only something that he chose empirically or he did some experiments with even lower range/higher gain. I'm talking OCXO only here because next he mentions Rubidium having a range of 1 ppb with the corresponding gain of 65536.
The PWM DAC that Lars implemented has a range of 5V. The CTI that moves 20Hz (I assume +/- 10HZ at 10MHz) over 5V has a huge range of 2ppm while the Milliren's range is 600ppb over 5V.
The jump per bit in the case of CTI would be 30.5ppt while for Milliren is only 9.2ppt. Lars's 130ppb recommended would jump about 2ppt and Rubidium would jump a whooping 0.015ppt (15ppq).
The reason why we want to use the resistors or the fancy circuit is to compress and offset the range of the DAC thus decreasing the 1LSB from 5V/65535 to a much lower value. The DAC resolution is defined as the number of bits and that stays at 16, it doesn't change. I've attached a diagram that shows the control voltage (thick black line) that my OCXO needs to keep the output frequency at 10MHz from power up to about 6 - 7 min when the warm-up period ends. You would expect to be a straight line after that but it isn't. In long term it seems to drift down very slowly meaning that the frequency tends to go up. The danger is that if you compress the range too much, after few years you may be out of the control range of the OCXO.
I hope it makes sense.
-
Thanks, Miti.
I was taking CTI 2ppm as 2000ppb, so the gain calculates to 32. I cannot maintain lock much over a TC of 8 with that low gain. The worst case should be g=65 if 1000ppb. I still need to measure the actual tuning range and that will be first thing I do next.
In honor of the hallowed ween, I have some scary images to post.
I set the gain to 200 and TC=12, shown in the first scope shot below. The phase oscillates within the 10s persistence, just under the TC, and keeps lock. The magenta trace is the tune voltage and it does not move much. If I increase gain, the phase change is faster and overcomes the TC and I loose lock (not shown).
I lower the gain to 100 and the phase change is slower and the tuning voltage is faster, shown in scope shot 2.
Lowering the gain to 32 I see scope shot 3. I cannot quite explain these results.
I have set my gain to 100 again and TC to 16 and was maintaining lock, so I started an MDEV analysis which had collected about 4 hours of data when I left it running. The "inflection" point Lars discusses was happening around 80 sec.
-
imo, what do you think of this circuit? I suspect it will be heavily influenced by the osc tune circuit, so perhaps a series resistor to the tune pin?
-
Guys, in order to entertain you a little bit during your hard work - here is an idea how to adjust gain and offset such it fits an OCXO's tuning range best.. :D
Oooh, that's fancy! Thanks!!! I was going to try a passive circuit. Am I right to think we do this to increase DAC resolution?
Yes, you may transform the 0-5V DAC range (ie the Lars design) to, say, 0-500mV (still 16bit resolution) and position this new DAC range around your OCXO EFC voltage of interest -> the voltage which fits 10.000MHz (with the Offset trimpot). You may power the Offset trimpot (the 10k trimpot in my schematics) from the OCXO's Vref output (to make it stable), for example.
Example: my OCXO has got the EFC tuning range from 1-6V, where my current exact 10MHz is at 4.2344V. I may go with the 500mV DAC range (Lars' 0-5V compressed to 0-500mV, and still 16bit resolution) and I will set the DC offset close to 4.00V.
Therefore the Lars' 16bit DAC will tune from 4.00 to 4.50V with full 16bit resolution. And my current exact 10MHz is in the middle of that range.
With aging it will walk somewhere, you have to judge how far it will walk and whether the 500mV range creates enough headroom for such a walk.
-
Some general comments about "gain". If you measure gain by using h1 and h65535 (min and max from DAC) and the formula you should be enough close for correct gain. If the gain is close say up to a factor of two it should still work. You could get more or less ringing when the DAC voltage should tune in but it should work still. If you look at the P-term it is proportional to gain but the I-term is proportional to the square. So if the gain is wrong it will affect both the time constant and damping of the loop but are not super critical.
The reason I choose 130ppb range and 2ppt (0.002ppb) DAC resolution is a compromise between ability to handle long term drift and quantization noise with only 16bits.
If we start with the 2ppt DAC resolution it affects the best possible ADEV you can get. With 2ppt (2E-12) you can get below 1E-12 in ADEV so a really good OCXO is needed. On page 18 figure 8 in my instruction I have by purpose selected a larger range so the minimum step is 1E-11 and still the OCXO131 gives 5E-12 in ADEV. I will come back to Metrologist's result later that seems strange.
For the total range of 130ppb I have used different ranges even if 130ppb seems ok for me even due to drift. I have had OCXO monitored for more than 10 years but not drifting above 100ppb. Often the first year are worse than the next 10. In many OCXO's with SC-cut xtals including the one Metrologist is using the 10 year drift are specified to 400ppb.
So with a 16 bit DAC it is a compromise between enough resolution to use the best ADEV compared to long term drift of the OCXO.
To change the gain Imo's tips are very good to add an op-amp as it gives a lot of flexibility. But I should should say I have only used trimpots and resistors. Most of the time my OCXO have had a Vref. But if not I have added a Vref IC of 5v or a MC7805 that have been enough stable.
As the PWM-DAC can be seen as a perfect 0-5V DAC with low output impedance followed by the filter with a DC output impedance of 78kohm (39+39k) any impedance to ground or Vref will shunt the output voltage. For example a 10kohm poentiometer in the middle position will be two 5kohm resistors in parallell making the parallel combination 2.5k. So with a 78kohm in series and 2.5kohm shunted the range will be about (78+2.5)/2.5 is about 32 times lower range. With a 50kohm pot it will be about 8 times lower range (higher gain). I have used 10-50kohm and some different resistors in series with the pot to get what I want. The pots have mostly been 20-25 turn small trimpots like Bourns 3296, Spectrol 64W or noname from eBay.
If we add a trimpot or other shunt element the last stage in the RC filter will be affected, but it is not so critical. Another possibility is to add some more series resistance after the last RC before the shunting trimpot (resistor). The two 4.7uF are selected to suppress the 488Hz PWM signal from the Arduino. So we want to have less than 1LSB of ripple after the RC filters. This are ok with 4.7uF but also close with say 2.2uF. I have also used 10uF. The time constant in the RC filters are still in the seconds region and don't gives a lot of phase shift compared to the time constants in the PI-loop and software low-pass filter.
One thing with the 4.7uF is that I recommend tantalum 35v as leakage may be a problem. I wouldn't recommend electrolytic. Film will probably be ok. I have a couple of new ceramic 4.7uf SMD that I have intended to test but not yet done. So far I have only used different brands of tantalum 25 or 35V with good results.
Lars
-
Hello Metrologist,
If I compare Miti's and your MDEV curves it is something fishy with yours. Miti's ends at about 1E-11 but yours at 1E-9 so a factor of 100 higher. As your OCXO is specified at 0.05ppb (5E-11) short term noise (ADEV) I would suggest that your curve at least should be below 1E-10 but probably 1E-11 also if ok.
With 1E-9 the result are as poor as a medium qulity TCXO and a TC above 10s is difficult to get for such a TCXO as it is so much frequncy ripple so the loop will go above 100ns that is the condition for locked. On page 18 figure 8 you can see a really good TCXO DOT050V from Digikey that gives ADEV's of 1E-10 but still don't use longer than TC=50s to get optimum results.
I can see some reasons:
- Fault in OCXO even if my experience says no even if it is used OCXO from eBay.
- The 5v supply and decoupling
- The 4.7uF electrolytic
- Noise due to grounds and the prototyping
Suggestions:
-Use different 5v to Arduino and OCXO and maybe add more decoupling on them (and close especially on the OCXO).
-Change the 5uF electrolytics to tantalum. Even 10uF or 2.2uF would be better if you have them in tantalum.
-Add a 20-100kohm trimpot (or two resistors) between +5v and 0v to the input of the OCXO to test if it gives a different result. You have to find out a new gain.
Another comment about the oscillocsope pictures. I really like oscilloscope pictures but in the this case the 10Mhz jitter will still be were even with a working loop if you check over some time due to the 1PPS (GPS noise). In this case with wrong gain and oscillations it is more reasonable to see it on the serial monitor and the DAC value going corrupt. What is reasonable is difficult to say. At short TC's the ripple of the DAC is higher but should be more just noise due to the 1PPS than something that oscillates up and down.
Lars
-
I have a question for you all. I was surprised a few months ago to read that some of the non-professional grade GPSDOs still being sold for a lot of money on ebay basically are just a disciplined 10 Mhz source and GPS but the 1PPS is not disciplined any further by the OCXO GPS combination (to improve its jitter). They wire the internal GPS 1PPS directly to their 1PPS output and it is not smoothed out.
I suppose that to properly derive the 1PPS from the disciplined oscillator basically what would be required is a PIC chip that divides by 10 million (I think one of the the "PicDiv" preprogrammed PIC chips can do this) and then delivers a short pulse each time the positive going pulse occurs, with the setting for cable length on the input side fine tuned until the pulse matches the center of the stairstepping range (presumably the truest point along the 25 nanosecond second change range)
Its been a long day for me and I'm sleepy.. Is this right?
Hello cdev,
Even if i am no expert I would say you are correct in your conclusions. I guess that the "professional" GPSDO's often have been used in telecom applications that requires good absolute timing compared to the "non-professional" like BG7TBL that more seems to be 10MHz frequency references. My intent with my GPSDO have also been a 10MHz reference. Of course the timing requirement is of importance. If +-11ns extra jitter is OK you an use the output from a uBlox series 6, 7 or 8 direct. We have to remember that the GPS in itself have many nanoseconds of variations over both a day and even in the minute range (for example due to satellite shifts). here I really recommend to see the NIST data archieves with data taken every 600 seconds to see the limits even under good conditions.
I have thought of how to add a jitter free 1PPS to my GPSDO. The simplest (that I use) is to add a PICDIV. This will not syncronize the GPS 1PPS but give a jitter free PPS. It is many PICDIV versions that can give 1PPS and also be syncronized. See Tom van Baaks PICDIV pages. You can buy them for just a few dollars and also Tom gives you the code so you can program the 12F675 by yourself. As the PICDIV #26 also give gives a chance to set another division factor I like it for testing of the TIC in my GPSDO.
If I were to make the best 1PPS I probably would add an extra uP (Arduino) to handle what i think is most important: Robustness. I think that having software to check that the 1PPS out really are aligned well with the GPS receivers jittery PPS are very important. How often should you check and what is a wrong PPS so it is time to align again? You have two edges of the 48MHz that makes the PPS possible to be +11ns or -11ns. Which are correct? So absolutely not impossible to handle but needs some care to get right.
Also the 10MHz gives 100ns between the positive (or negative edges) and need to be aligned either by the Arduino e.g TIC_offset and/or e.g. the cable delay in the GPS receiver.
Lars
-
imo,
I think we were simulating "for fun" in the same time. My version only needs 5V and any cheap rail to rail will do it.
The plots are before and after the 78K (to simulate the output of the DAC) and the outputs of the op amps.
R4 should be a trim pot to adjust gain and R1/R2 another trim pot for offset.
But as Lars said, a trim pot may be enough. ;D
-
Yea, making simulation is fun.. There are some limits, however :)
Opamps - with above schematics the 1LSB will be around 8uV (!). You would need a pretty good opamps for that - with input drift tempcos below 8uV/degC, for example. Also mind all possible noise sources start to interfere into your business.. On the other hand the DAC resolution with the above schematics will be 1-2ppt (with a 200ppb/Volt OCXO). So the question is whether the stuff with those opamps will not be over-engineered a bit :)
The PWM filtering - I would use a combination of tantalum and ceramics. The new ceramic multilayer capacitors (ie 10-22uF) have got an issue - their capacity drops down with applied DC bias - ie a 10uF/6V ceramic may drop to 2uF at 6V.
The PWM includes a lot of high freq content (ie the edges) thus ceramics in parallel with the tantalum one may help. Also mind the PWM made by atmel328 will always copy its 5V Vcc noise and stability..
-
Another idea - to decouple the PWM DAC from the noisy MCU or FPGA. You may use a single 5 pin smd gate, the gate gets its own 5V quality voltage regulator and good decoupling.
-
Yea, making simulation is fun.. There are some limits, however :)
Opamps - with above schematics the 1LSB will be around 8uV (!). You would need a pretty good opamps for that - with input drift tempcos below 8uV/degC, for example. Also mind all possible noise sources start to interfere into your business.. On the other hand the DAC resolution with the above schematics will be 1-2ppt (with a 200ppb/Volt OCXO). So the question is whether the stuff with those opamps will not be over-engineered a bit :)
The PWM filtering - I would use a combination of tantalum and ceramics. The new ceramic multilayer capacitors (ie 10-22uF) have got an issue - their capacity drops down with applied DC bias - ie a 10uF/6V ceramic may drop to 2uF at 6V.
The PWM includes a lot of high freq content (ie the edges) thus ceramics in parallel with the tantalum one may help. Also mind the PWM made by atmel328 will always copy its 5V Vcc noise and stability..
Before posting, I looked on Digikey's site for the cheapest rail to rail I/O from Maxim. Why Maxim, because they have a pretty good sample program :-[. I'm not an experienced designer so I may have missed something but look at MAX4232AKA, the cheapest in stock for $1.73 CAD. Offset voltage tempco +/-3uV/°C, sounds really good to me.
I agree that it may be a bit over engineered but hey, this is just for fun, for experimenting.
Talking about ceramic capacitor voltage bias characteristic, the manufacturers publish such data so you can select a capacitor that has the desired capacitance at the control voltage that your OCXO needs. This circuit is particularly predictable since the variation around that voltage is minuscule.
-
Just for fun, my Lars GPSDO and a second Ublox Neo M8T set to output 10MHz. The time-pulse jitter for this module should be +/-11 nS but looks a bit higher to me but maybe my signal is too weak, I'm using a small antenna in the window.
-
Just for fun, my Lars GPSDO and a second Ublox Neo M8T set to output 10MHz. The time-pulse jitter for this module should be +/-11 nS but looks a bit higher to me but maybe my signal is too weak, I'm using a small antenna in the window.
The 10MHz output from Neo 7/8 is broken. The clean output frequencies are those = 48MHz/N, where N=integer (like 4,5,6,..). It has been discussed few times here.
-
The 10MHz output from Neo 7/8 is broken. The clean output frequencies are those = 48MHz/N, where N=integer (like 4,5,6,..). It has been discussed few times here.
You are right, it is broken and I forgot about that, that may be the reason why the jitter is higher than specified. 2MHz is not broken though and the jitter seems to be within the limits.
-
The 10MHz output from Neo 7/8 is broken. The clean output frequencies are those = 48MHz/N, where N=integer (like 4,5,6,..). It has been discussed few times here.
You are right, it is broken and I forgot about that, that may be the reason why the jitter is higher than specified. 2MHz is not broken though and the jitter seems to be within the limits.
Humm, you think you have problems :D
Here is the PPS from two modules, both running in my front (equator facing) window for half an hour... that is quite a big spread, plus 250ns of lag...
-
Poke around in your vendors software for a cable delay setting.
Also you should look at the power supply situation, make absolutely sure that either the two GPSs are on separate supplies that supply each adequate voltage and current independently, or if they are on the same supply that the current draw from one isnt impacting the power supplied to the other significantly, in other words, make sure you have enough power to have the voltage stay stable to both at the peak current.
The 10MHz output from Neo 7/8 is broken. The clean output frequencies are those = 48MHz/N, where N=integer (like 4,5,6,..). It has been discussed few times here.
You are right, it is broken and I forgot about that, that may be the reason why the jitter is higher than specified. 2MHz is not broken though and the jitter seems to be within the limits.
Humm, you think you have problems :D
Here is the PPS from two modules, both running in my front (equator facing) window for half an hour... that is quite a big spread, plus 250ns of lag...
-
In case you plan to use the Neo modules for time/freq measurement purposes always use, for example, the external "28dB 3m cable" $3 antenna and put it outside your window..
-
May want to look at page 40 on the discussion on using ground planes with these puck antennas.
https://www.eevblog.com/forum/projects/a-look-at-my-symmetricom-gpsdo-(ocxo-furuno-receiver)/975/ (https://www.eevblog.com/forum/projects/a-look-at-my-symmetricom-gpsdo-(ocxo-furuno-receiver)/975/)
-
In case you plan to use the Neo modules for time/freq measurement purposes always use, for example, the external "28dB 3m cable" $3 antenna and put it outside your window..
I'm using Trimble 56237-50 and it is located in my basement's window. It only sees the west side of the sky. Talking about Ublox modules time mode, how do you put Neo M8T in time mode? This is what I did:
- In TMODE2 I selected Time Mode = 2 - Fixed Mode
- Fixed Time Mode True Position I entered the Long, Lat and Alt indicated by U-Center
- In NAVX5 I restricted Min/Max SVs to 1 -3
- In NAV5 Min SV Elevation = 10 deg
What's the difference between TMODE, TMODE2, TMODE3? What are the best settings for a GPSDO setup with a small patch antenna like this?
-
My version of Lars GPSDO with TC=500 did not loose lock once after I enabled temperature compensation.
Good job Lars, thanks!
-
The NavSpark Mini can be bought in a pack of six for $35 plus a few dollars shipping. They may also still be giving away one free if you pay shipping, So you can get seven for around $40.
All of my Skytraq receivers are extremely sensitive, and the Minis also support Beidou which seems to make them significantly better than my GPS and SBAS only older Venus 5 and 6 based non RTK GPSs once they have warmed up.
The (windows only, but wine-friendly) configuration tool gives a surprisingly large number of configuration options for such a cheap GPS and the sensitivity (with all skytraqs) is extremely good which means that it almost never loses lock, even indoors, if its on a half decent antenna (a passive antenna works fine). It is much better than Ublox in that respect.
In terms of reliability of its 1PPS being present frankly, its the best GPS Ive ever seen. It just works.
I have several of them now connected to my RaspberryPis indoors with no special care needed as to antenna placement, Only one is upstairs, none are on outdoor antennas, two are on home-assembled Taoglas 25mm passive patch antennas - They work great, literally 'never' losing their GPS lock.
I worry there is no over-constrained timing mode in the NavSpark mini.. That'll probably add a bit to its PPS jitter. (I'm not sure how much).
I'm not convinced it's necessary to use a higher frequency reference clock. The PPS signal from GPS is normally specified to be accurate with sigma=10 or 15ns, even with sawtooth correction. Sampling the higher frequency from the receiver won't help (if sawtooth correction is used).
Also, loop constants are normally many minutes, comparisons more often than every second won't be helpful.... There should already be enough averaging.
-
Hi,
I have been trying to understand Lars's code but even though it's partially documented I have been having difficulties making sense of some hard coded variables.
For example line 166:
timer_us = timer_us + 50000 - (((timer1CounterValue - timer1CounterValueOld) * 200 + TIC_Value - TIC_ValueOld)+50000500)/1000;
Where do the magic 50000 and 50000500 values come from? Any help?
Thanks,
José
-
timer_us = timer_us + 50000 -
(((timer1CounterValue - timer1CounterValueOld) * 200 + TIC_Value - TIC_ValueOld) >>> those are in 200ns timer1C_ increments (OCXO/2) and you add TIC_V diff value (TIC is the voltage measured by the ADC from 4046+diode+3.9k+1nF) in nanoseconds to it thus everything is in nanoseconds now
+50000500)/1000; >> you add 50000500 because you do modulo 50000 and you want to round properly (xxx.500) and finally you divide all by thousands to get microseconds
You do modulo 50000 therefore (an example)
timer_us = timer_us + 50000 - (((1)*200 + 530 - 490) + 50000500)/1000 = timer_us + 50000 - ((200+40) + 50000500)/1000 = timer_us + 50000 - (50000740)/1000 = timer_us + 50000 - 50000 = timer_us + 0 >>> no change as the 1PPS came within 1usec.. (or better to say: the OCXO's freq at this moment is such thus it fits into 1PSS +/-0.5us).
-
The (windows only, but wine-friendly) configuration tool gives a surprisingly large number of configuration options for such a cheap GPS
Lady Heather also talks to them... it's the same as Venus receivers. It might be recognized as a NMEA receiver unless you use the /rxv command line option.
-
timer_us = timer_us + 50000 -
(((timer1CounterValue - timer1CounterValueOld) * 200 + TIC_Value - TIC_ValueOld) >>> those are in 200ns timer1C_ increments (OCXO/2) and you add TIC_V diff value (TIC is the voltage measured by the ADC from 4046+diode+3.9k+1nF) in nanoseconds to it thus everything is in nanoseconds now
+50000500)/1000; >> you add 50000500 because you do modulo 50000 and you want to round properly (xxx.500) and finally you divide all by thousands to get microseconds
You do modulo 50000 therefore (an example)
timer_us = timer_us + 50000 - (((1)*200 + 530 - 490) + 50000500)/1000 = timer_us + 50000 - ((200+40) + 50000500)/1000 = timer_us + 50000 - (50000740)/1000 = timer_us + 50000 - 50000 = timer_us + 0 >>> no change as the 1PPS came within 1usec.. (or better to say: the OCXO's freq at this moment is such thus it fits into 1PSS +/-0.5us).
Hi,
Thank you very much for the detailed explanation, all clear now!
-
Hi Lars,
I found your thread and I really liked the way it is set up, so I decided to build one myself.
I already had a Bliley 10MHz ocxo with the following specs:
VCC=5VDC, Vout =0-5V, Vcontrol to obtain 10MHz =2,76V, so that should fit well in your design.
I used one of the Chinese NANO AT328 boards with USB on board, it runs your software well.
I ordered the parts and put it together, but.....
It did not work directly, so I did some troubleshooting.
I found the 10MHz being OK, meaning a reasonable square wave between 0V and 4.5V with an duty cycle of about 50%.
The divided 5MHz and 1MHz are OK too.
I used a Chinese 5V GPS receiver board, where I picked the 1PPS from the onboard series resistor with blue LED, also with proper levels.
And still it would not work.
It would never lock, but I would see the ns column and the ns difference column counting up- and down.
So, I tried to see the 0-1us pulse going into the arduino, and.... it was not there?!? :palm: :palm:
It took me a while, but I goofed big time when I ordered my parts.
I assumed that a CD4046 would be the same as a 74HC(T)4046, usually the CD4xxx is the same as a TI4xxx or a MC4xxx etc.
But, it turned out a CD4046 only has the first two comparators, pin 15 inside a CD4046 is just a zener coming from the +5V, |O |O |O
while a 74HC(T)4046 has the third comparator output on pin 15 you actually use in your design... :-+
So I ordered some 74HC4046's , as soon as they are here, I will follow-up.
To be continued, thanks for now,
Un saludo,
Leo
-
I finalized my GPSDO and placed it on the shelf where it belongs. Locked since October 2018. :-DD
It has 18 X 50 Ohm outputs.
-
Those Extron cases rule!
I have two of them and I think I am going to put my TruePosition into one and put one of these GPSDOs into the other. It will be a good learning experience.
I finalized my GPSDO and placed it on the shelf where it belongs. Locked since October 2018. :-DD
It has 18 X 50 Ohm outputs.
-
Those Extron cases rule!
I have two of them and I think I am going to put my TruePosition into one and put one of these GPSDOs into the other. It will be a good learning experience.
I finalized my GPSDO and placed it on the shelf where it belongs. Locked since October 2018. :-DD
It has 18 X 50 Ohm outputs.
True position?
-
True position?
Yes, but ... I'm being stupid about it.
I have (two) ADA 3 180s which have 9 10 MHz capable outs and 3 "TTL" outs each, plus four additional BNC cutouts which have black plugs in them now.
However- my TP GPSDO's and its GPSDO controller's current home is still inside a plain white cardboard box, with the holes for jacks and wires cut out of it. :o
It works but its a visual embarrassment.
Frankly, I am still indecisive about how I want to implement it.
I cant decide whether I want the 'front' or 'back' of the case to be the accessible/ control area, (leaning towards duplicating the same set of LEDs in both places) I haven't fully decided what controller to use or even if I want to use any of the existing ones. There is no great hurry, but I would like to get it done eventually and put it into a nice case. My Extron qualifies as more than just a nice case, its basically an ideal case, so I really have no excuse whatsoever now not to at least mount it in there so I can use it with external control with the distribution amp and TTL amp for the PPS while I try to cure my indecisiveness over the rest of the design.
TruePosition units are removed from telco service as cellphone time-delay of arrival locator units. They are similar in many respects to the symmetricom and Trimble UCCM GPSDO cards. Instead of the 5v supply they run off a 12v supply and are meant to live in a rack with other identical units. They speak to either RS232 or 3.3v UART controllers.
Thanks to pigrew and texaspyro, and a few others a very complete set of commands to work with them is available and for the money they cost (around $40-45) they are a real bargain. As far as accuracy they are comparable to the other telco surplus units. Which tend to cost a lot more.
They use the same Furuno timing GPS as many of the Symmetricom units.
Despite my now having one, the idea of building a GPSDO still appeals to me a lot, in terms of learning how they work.
Might be interesting to have one alongside the other maybe even receiving the exact same signal, split, to see what factors influenced the accuracy.
-
I haven't fully decided what controller to use or even if I want to use any of the existing ones.
Raspberry PI with the "official" 7" 800x480 touchscreen running Lady Heather...
Or, if you are a masochist, a $12 3.5" 480x320 touchscreen that plugs onto the PI... might even work with a PI Zero.
-
I have a very small 320x240 color ILI9341 SPI TFT display but its not a touch screen. I've thought it would be fun to try to make a useful display that somehow managed to make the dozen or so most relevant pieces of info visible in one glance but I'm not a good enough coder yet to do it without some toolkit and other programs to get the core elements from.
Although I like LH, I would never build a LH device to leave on all the time. The whole LH display of the satellites is overkill for me. But it would be great to be able to graph the GPSDO's fix or holdover status in a small area of it along with the other info. Pushing a button could turn on the full display for some length of time. pigrew's controller conveys a lot of info about the temperature of the oven vs. voltage being supplied and fix status. Correct me if I'm wrong but both LH and his controller work by putting the GPSDO into debugging modes. I wonder if that has any impact on the stability of the output signals?
Right now it seems to be unavoidable if one wants to get all the various bits of info at once. I wonder what is on the multitudes of pins on that huge header. Most of those extra pins seem to remain completely unexplored. I wonder if some additional probing might turn up more clues.
I would be happy to simply turn up some additional 3.3 or 5 volt logic signals on those headers to drive LEDs to indicate the various modes without needing to activate debugging modes..
I like the brightness and sharpness of the very small monochrome oled displays, but I am concerned about their longevity.
I am very sorry, I need to stop though, please forgive me for hijacking Lars' thread.
-
Although I like LH, I would never build a LH device to leave on all the time. The whole LH display of the satellites is overkill for me. But it would be great to be able to graph the GPSDO's fix or holdover status in a small area of it along with the other info. Pushing a button could turn on the full display for some length of time. pigrew's controller conveys a lot of info about the temperature of the oven vs. voltage being supplied and fix status. Correct me if I'm wrong but both LH and his controller work by putting the GPSDO into debugging modes.
You are wrong... there is no debugging mode. We do use some commands that output additional "debug" info.
What's wrong with overkill? Overkill is a good thing. Nobody like underkill. If you click on the plot header or use the ZP command, Heather shows the plot area in full screen mode.
-
I suppose a display could be dimmed to extend its life.
My main concern is display and GPSDO longevity.
You are wrong... there is no debugging mode. We do use some commands that output additional "debug" info.
What's wrong with overkill? Overkill is a good thing. Nobody like underkill. If you click on the plot header or use the ZP command, Heather shows the plot area in full screen mode.
Yes, that's what I would likely leave it on.
-
I suppose a display could be dimmed to extend its life.
Not really... most displays now use LED backlights... which tend to last for pretty much forever. I have LED backlit displays that have been on 24/7 for over a decade.
Older displays with CCFL backlights are a different matter. Those do degrade over time and the tubes need to be replaced... which is usually a royal pain in the ass.
-
Yet another DIY GPSDO! On the internet you can find a lot of DIY GPSDO designs. What are the differences between them? Why this?
Some + and – I can come up with for mine:
+ 1ns resolution TIC (Time Interval Counter)
+ PLL (not FLL)
+ Uses Arduino (ok some might say it is negative)
+ Low parts count and cheap components
+ No need for a specific GPS receiver only requires 1PPS in
+ Easy adaption to different oscillators (from simple VCXO to Rubidium)
+ Configuration for VCO range, time constant (4-32000s) and a lot of other parameters
+ Outputs time error (ns), DAC value and temperature (and a lot of other information) to the serial port
+ Logs time error, DAC value and temperature every third hour
+ Stores last DAC value for use at power-up
-DAC resolution (now 16bits) and stability could be better
-No saw tooth correction
-No adaptive time constant
-Not using information from receiver e.g. number of satellites etc.
-No standardized communication protocol like many commercial GPSDO’s
-No display
Why did I do this? Since about 2010 I have developed my GPSDO. It started just because I was lazy and tired of tweaking my 10MHz house standard. The only thing I am proud of is the 1ns resolution TIC. A couple of years ago I published an old version on the time nuts forum. This time I decided to use this forum instead as I think my DIY GPSDO is something for experimenters in this forum.
For me it is perfect for experiments. I have learned a lot during the years I have used it (and developed it).
I have built several complete GPSDO’s but now the only one I have running continuous is a rubidium based DIY Arduino GPSDO I use as a lab standard for my instruments. That Rb GPSDO has been running almost continuous for more than five years with different versions of my Arduino software.
Today you can get a GPS module + antenna for about 10USD from eBay, an OCXO for 10-20USD, a metal box and connectors for about 10USD, the Arduino pro mini and all other components for about 10USD, So around 50-60USD should be enough to get all components for a complete GPSDO.
As I had problems with file extensions I added .txt to the arduino sketch .ino. You have to take away the .txt and place it in a folder with the same name. To easier read the file without arduino see the .txt without .ino in the file name.
I also had to divide the instruction as it was about 2MB. Sorry for the inconvenience.
Lars
Thanks for sharing. Working it this way really cuts the price down huh...
-
There are a bewildering number of 10 MHz ovened oscillators available on ebay. What should somebody look for- what are good choices to use in your design that are also usually pretty affordable?
-
Good question cdev. I am now using CTI from queens_land, and I notice he has new samples now too. The used one is $6USD and I am using it simply for 5V convenience with Arduino and GPS module supply voltages.
-
Anybody heard anything from Lars lately? I hope he's OK.
-
This post on time-nuts describes his posting here, and it includes his email address. I don't see any more recent posts there, this is from September.
http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2018-September/094020.html (http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2018-September/094020.html)
-
Hi all,
here is my follow-up on the build of the Lars GPS-DO.
After I received the proper 74HC4046 I was able to complete the setup.
It's on a breadboard for now, because I haven't decided yet what kind of case I am going to use.
Anyway, here some of my findings during the build:
- I was able to test the 1PPS using a scope and could confirm the levels were OK. (Moving between 0,3V and 4,5V with clean flanks)
- The 10MHz coming from a 5V Bliley OCXO (bought cheap on eBay, used, taken from redundant Cellular Equipment. Nice actually, some people think -because they are 'old'- they will have less drift)
The signal is a square wave, but the flanks are not as clean as I would like them to be, more later.
- Using the IDE serial monitor I could send all the required commands like "h1", "h65535", "e22", "gxx", "s1" and finally "r".
I measured the voltage controlling the OCXO:
after sending "h1" [ENTER] I measured 0,47V at the input of the OCXO, and the value of "diff_ns" was around +720
after sending "h65535" [ENTER] I measured 4,67V at the input of the OCXO, and the value of "diff_ns" was around -750
So, according to Lars's description, my gain-value should be the difference between -750 and +720 = 1470, so 65535 / 1470 = 44,58 => 45
I wrote this value using "g45" [ENTER] followed by "s1" [ENTER]
After that I send a "r" [ENTER].
I let it run for some time (around 5-6 minutes) and at that point it found a "lock", with a "diff_ns" value of 34444 and an OCXO control voltage of 2,46V which sounds OK for a Bliley OCXO, but it would lose it after a few minutes again...
I checked all signals again using my scope, the only one a bit tricky was the HC390 output into the Arduino??
I will try to find how this input is setup in the code (Input_Pullup, Change, etc.), but by temporarily putting a 10k resistor to ground cleaned it up.
Without it, I found the "diff_ns" value would "jump" at random moments 220 down, so instead of a value around zero (between +17 and -15 ns) it suddenly would be -235 (just one time!) and come back to normal from there.
Obviously it doesn't help that my setup is on a breadboard for now, it will work better after I put all parts on a little PCB with shorter and cleaner wiring.
Anyway, for now it works and I am happy.
To be continued, un saludo,
Leo
-
- I was able to test the 1PPS using a scope and could confirm the levels were OK. (Moving between 0,3V and 4,5V with clean flanks)
The HC output signals should be much closer to Vcc and Gnd..
-
- I was able to test the 1PPS using a scope and could confirm the levels were OK. (Moving between 0,3V and 4,5V with clean flanks)
The HC output signals should be much closer to Vcc and Gnd..
Hi, I am in the process of putting it all on a perfboard pcb today as we speak, will check all levels after that again.
Using the breadboard and the somewhat longer wires caused a lot of ringing, all this was interfering with the signal quality.
Thanks for your remarks,
Leo
-
Leo,
Does it unlock if you don't touch it? My GPSDO always looses lock if I turn it on the side or upside down. It is known that gravity affects frequency in the OCXOs.
-
Leo,
Does it unlock if you don't touch it? My GPSDO always looses lock if I turn it on the side or upside down. It is known that gravity affects frequency in the OCXOs.
Hi,
I just put it all together again, and it does lock again.
And no, mine does not unlock when put upside down.
However, I do see a 'jump' in the offset when it's running normally. This does not change when put upside down.
See attached picture, is this normal?
Thanks, un saludo,
Leo
-
You may see similar periodicity in Miti's results here (https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/msg1901951/#msg1901951). It may come from NEO7M.
-
However, I do see a 'jump' in the offset when it's running normally. This does not change when put upside down.
See attached picture, is this normal?
Yes, it is, and mine is locked for 38 days so it is rock stable, see my pictures. A big improvement was when I enabled temperature compensation.
-
However, I do see a 'jump' in the offset when it's running normally. This does not change when put upside down.
See attached picture, is this normal?
Yes, it is, and mine is locked for 38 days so it is rock stable, see my pictures. A big improvement was when I enabled temperature compensation.
Hi,
yes, I do see the same, and it stayed locked perfectly for days now, even without the temperature compensation
It looks like there is one bigger step up (still small though!), and two small steps down to compensate for that. :-)
I am wondering, maybe it's possible the add an extra to the software, maybe an auto-calibrate routine?
At the moment I am thinking like this:
To add a separate "autocal" routine that can be called either by an interrupt (a button) and/or an extra software command that does the following:
During the "autocal", stop running, put a fixed "h1" value and read the offset, after that put a fixed "h65535" value and read the offset again,
and than do the math, to find the difference and use that to calculate the gain and save that instead of a manual gxx [ENTER] ?
Not sure how useful that would be.
Anyway, food for thought...
But first I am in the process of completing my box, I already added 3 channels of an 74HCT14 in parallel with three 150 Ohm resistors as buffer for both the 10MHz and 1-PPS output, so they are able to drive a 50 Ohm load.
I also want to use the rest of the HC390 to create extra divided frequency outputs, or even a second HC390, also buffered by more 74HCT14's, so I can use it as a scope timing calibrator.
To be continued, :-)
Un saludo,
Leo
-
@tvb has figured out an accurate, inexpensive way to do this that works well on all GPSDOs!
See the following.
http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm)
http://www.leapsecond.com/pic/picpet.htm (http://www.leapsecond.com/pic/picpet.htm)
http://leapsecond.com/pic/picpet2.htm (http://leapsecond.com/pic/picpet2.htm)
Hi,
yes, I do see the same, and it stayed locked perfectly for days now, even without the temperature compensation
It looks like there is one bigger step up (still small though!), and two small steps down to compensate for that. :-)
I am wondering, maybe it's possible the add an extra to the software, maybe an auto-calibrate routine?
At the moment I am thinking like this:
To add a separate "autocal" routine that can be called either by an interrupt (a button) and/or an extra software command that does the following:
During the "autocal", stop running, put a fixed "h1" value and read the offset, after that put a fixed "h65535" value and read the offset again,
and than do the math, to find the difference and use that to calculate the gain and save that instead of a manual gxx [ENTER] ?
Not sure how useful that would be.
Anyway, food for thought...
But first I am in the process of completing my box, I already added 3 channels of an 74HCT14 in parallel with three 150 Ohm resistors as buffer for both the 10MHz and 1-PPS output, so they are able to drive a 50 Ohm load.
I also want to use the rest of the HC390 to create extra divided frequency outputs, or even a second HC390, also buffered by more 74HCT14's, so I can use it as a scope timing calibrator.
To be continued, :-)
Un saludo,
Leo
-
Right when I said that my GPSDO is rock solid, it lost the lock after more than a month. Foggy morning, my GPS antenna is in my basement's window, I can only blame it on the GPS.
-
@tvb has figured out an accurate, inexpensive way to do this that works well on all GPSDOs!
See the following.
http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm)
http://www.leapsecond.com/pic/picpet.htm (http://www.leapsecond.com/pic/picpet.htm)
http://leapsecond.com/pic/picpet2.htm (http://leapsecond.com/pic/picpet2.htm)
Ulrich B did an AVR version of PPSDIV here (Bottom)
http://www.ulrich-bangert.de/html/downloads.html (http://www.ulrich-bangert.de/html/downloads.html)
Edit:
Seems like a Tiny84 has a full PortA (0..7) , meaning this one:
http://www.ulrich-bangert.de/PPSDivider.zip (http://www.ulrich-bangert.de/PPSDivider.zip)
Ought to work w.
#include <tn84def.inc>
The avr assembler2 runs fine in wine on linux
My avr assembler2 script
#!/bin/bash
wine ~/avr/AvrAssembler2/avrasm2.exe -I ~/avr/AvrAssembler2/Appnotes -I ~/avr/AvrAssembler2/include \
-d$1.obj -m$1.map -l$1.lst -e$1.eep -vs -v2 -fI $1 $2 $3 $4 $5
Result
$ avrasm2 PPSDivider-t84.asm
AVRASM: AVR macro assembler 2.1.43 (build 48 May 30 2011 10:07:37)
Copyright (C) 1995-2011 ATMEL Corporation
PPSDivider-t84.asm(1): Including file '/../avr/AvrAssembler2/include\tn84def.inc'
PPSDivider-t84.asm(87): No EEPROM data, deleting PPSDivider-t84.asm.eep
Notice:
The register and instruction counts are symbol table hit counts,
and hence implicitly used resources are not counted, eg, the
'lpm' instruction without operands implicitly uses r0 and z,
none of which are counted.
x,y,z are separate entities in the symbol table and are
counted separately from r26..r31 here.
.dseg memory usage only counts static data declared with .byte
ATtiny84 register use summary:
r0 : 0 r1 : 0 r2 : 0 r3 : 0 r4 : 0 r5 : 0 r6 : 0 r7 : 0
r8 : 13 r9 : 5 r10: 5 r11: 5 r12: 5 r13: 5 r14: 5 r15: 5
r16: 18 r17: 4 r18: 0 r19: 0 r20: 0 r21: 0 r22: 0 r23: 0
r24: 0 r25: 0 r26: 0 r27: 0 r28: 0 r29: 0 r30: 0 r31: 0
x : 0 y : 0 z : 0
Registers used: 10 out of 35 (28.6%)
ATtiny84 instruction use summary:
.lds : 0 .sts : 0 adc : 0 add : 0 adiw : 0 and : 0
andi : 0 asr : 0 bclr : 0 bld : 9 brbc : 0 brbs : 0
brcc : 0 brcs : 7 break : 0 breq : 0 brge : 0 brhc : 0
brhs : 0 brid : 0 brie : 0 brlo : 0 brlt : 0 brmi : 0
brne : 15 brpl : 0 brsh : 0 brtc : 0 brts : 0 brvc : 0
brvs : 0 bset : 0 bst : 0 cbi : 0 cbr : 0 clc : 0
clh : 0 cli : 0 cln : 0 clr : 16 cls : 0 clt : 1
clv : 0 clz : 0 com : 0 cp : 14 cpc : 0 cpi : 0
cpse : 0 dec : 2 eor : 0 icall : 0 ijmp : 0 in : 0
inc : 7 ld : 0 ldd : 0 ldi : 5 lds : 0 lpm : 0
lsl : 0 lsr : 0 mov : 0 movw : 0 neg : 0 nop : 1
or : 0 ori : 0 out : 3 pop : 0 push : 0 rcall : 0
ret : 0 reti : 0 rjmp : 1 rol : 0 ror : 0 sbc : 0
sbci : 0 sbi : 0 sbic : 0 sbis : 0 sbiw : 0 sbr : 0
sbrc : 0 sbrs : 0 sec : 0 seh : 0 sei : 0 sen : 0
ser : 0 ses : 0 set : 1 sev : 0 sez : 0 sleep : 0
spm : 0 st : 0 std : 0 sts : 0 sub : 0 subi : 0
swap : 0 tst : 0 wdr : 0
Instructions used: 13 out of 105 (12.4%)
ATtiny84 memory use summary [bytes]:
Segment Begin End Code Data Used Size Use%
---------------------------------------------------------------
[.cseg] 0x000000 0x0000a4 164 0 164 8192 2.0%
[.dseg] 0x000060 0x000060 0 0 0 512 0.0%
[.eseg] 0x000000 0x000000 0 0 0 512 0.0%
Assembly complete, 0 errors. 0 warnings
/Bingo
Edit: AVRasm2 - http://www.mikrocontroller.net/attachment/26295/AVR2.zip (http://www.mikrocontroller.net/attachment/26295/AVR2.zip)
AVRA, avrasm2 compatible - https://sourceforge.net/projects/avra/ (https://sourceforge.net/projects/avra/)
apt-get install avra
-
It should get better the longer you leave it on. See if you can move it outward so it has a better sky view. Also if you are using a patch antenna, try putting a larger ground plane underneath it in the center. (don't tilt the ground plane but be aware that if you are in the northern hemisphere most sats will be to the south and vice versa if you are in the Southern hemisphere more will be to the north) I often use a failed CD or DVD as a ground plane, that should be the minimum size you use. A bigger piece of metal is even better.
Right when I said that my GPSDO is rock solid, it lost the lock after more than a month. Foggy morning, my GPS antenna is in my basement's window, I can only blame it on the GPS.
-
Pizza pan to the rescue!
-
I was going to ask why is the 1V ADC range used? It seems you could use a 280 ohm resistor after the diode and have less noise on the higher range? But then I see how non-linear the charge curve is and you only get to use ~80% of the higher range anyway.
My new build did not work and I was having a hard time triggering on the ADC signal due to the noise and low signal level. I was able to get a good capture when triggering on the 1pps instead and discovered I had miswired the phase detector reset pin!
Here is a timelab plot with TC=4. Now I have set TC=400 but I think I can go much higher.
I'll build two of these with different oscillators and GPS. Still need to add a temp sensor and determine if I want to replace the divider pot with a couple precision resistors. Then I'll pack the box with fiberglass insulation.
-
Pizza pan to the rescue!
I'm ashamed to show what I use because it has this weird paint on it that is coming off that looks just horrible, but suffice it to say it was literally saved out of the garbage- its not perfectly flat, its an old pot lid with a shallow depression on the curvilinear top for its long ago lost handle just large enough for a typical GPS patch antenna. Unfortunately its made out of aluminum. So I have to figure out other ways to keep GPS antennas in place, or rely on gravity.
Its totally unscientific why I use it. I have no evidence that putting the gps in the depression would reduce multipath like a choke ring. It might even make it worse.
But it seems to work well as a ground plane.
-
I use an old circular saw blade.
-
I plot the self-reported ns, dac, and diff-ns for t=24h to t= 48h, right after I set tc=400.
-
I was going to ask why is the 1V ADC range used?
Because there is 1.1V Vref inside the atmega328.
-
Wouldn't it be better though if you could use the full 5V ADC range with a well regulated 5V supply? It seems the application is just for relative measurements where more resolution/less noise is a benefit.
-
The default 1ns/1LSB resolution is given by the RC of the pulse integrator (1000ns/1V) and the ADC resolution (1000 levels off the 1024 used) at Vref=1.1V.
You may try to decrease the tau=RC five times and use 5V Vcc as the ADC_Vref.
PS: ..or, you may try with 100ns/5Volt and the internal 10bits ADC. That gives you 100ps/LSB. Not sure what else would be impacted in the sw.
Mind with lower C you will get larger drop on the C because the leakages and dynamic parasitic capacitancies (ie the schottky diode and the ADC input), thus the non-linearity will be much higher.
Also with 5V Vcc at the 4046 the theoretical Vmax at the C will be around 4.6V only.
PPS: it may help to add a fet-input opamp as the ADC buffer.. And a fet switch for the C discharge, of course :)
-
Yeah, more would be needed. It looks ugly.
-
This works fine :)
-
It looks beautiful, but wouldn't that overload the 4046? That's why I used a 250 ohm resistor.
-
It will not work with 4046 (its phase_comparator_3 output is a voltage source).
You need a current source, feeding the diode. And the current source must be switched on/off by the 4046 (or an other faster phase comp). And all must be pretty fast.
The 100M is the input of a fet-opamp buffer put in front of the ADC.
You also need a switch for discharging the C after the ADC conversion.
-
Couldn't you just put an op-amp before the diode? I recall Lars acknowledging similar designs that used a current source here and with the full ADC range, and whether there was really any advantage. He seemed to have a similar tone about using a hardware DAC as well. I should review those designs that he referenced.
What I am seeing in my circuit now is a 10 ns oscillation on an approximate 50 seconds cycle, and I'm trying to understand what it could mean. I would suspect PPS jitter, but the UCCM reference I'm using should be very good.
-
Try to decrease the ocxo's gain.
-
One PID tuning technique is to set the D and I terms to 0. Then crank up the P term until it starts oscillating. Next increase D until it stops. Finally, mess with I until your brain leaks out your nose.
-
My last plot shows the dac in red trace - it is not changing over periods of 30 mins or maybe more. The dac does track/correct longer term drifts. What could oscillate with such a long period (50s)? I am powering this from a linear supply into a 7805 regulator.
-
My last plot shows the dac in red trace - it is not changing over periods of 30 mins or maybe more. The dac does track/correct longer term drifts. What could oscillate with such a long period (50s)? I am powering this from a linear supply into a 7805 regulator.
Assuming your blue trace is diff_ns, I see a similar behavior but with a different period and I think it is normal. The way the PPS is generated, if I understand correctly, from a clock that in case of Ublox is 48MHz, the CPU selects the best 48 millionth (+/- 1) or so edge to trigger the PPS. If your GPS's clock is so close to, let's say, 48MHz and the same (48th millionth) edge is the best for awhile, it will select that same edge, that drifts slowly however, to trigger the PPS pulse. Until one point when the 48th million and 1 is the best edge , and at that point you see the jump.
Or maybe your GPS has a VCXO and it keeps adjusting the clock.
-
The blue trace is ns. The green is diff_ns.
I could suspect the GPS/PPS if its jitter was expected to be around 25ns. Someone had posted their Trimble UCCM GPSDO measurements were much better (2ns?). Which edge is more likely to be moving?
-
I saw the oscillation in my design when the PI params were off (I doubt you can even use D). It is not only about PID params but about the sampling period "T" as well (it is related). With lower P/Is the oscillation period was longer. I spent a month with it. Tried PI, PII, PIID. After a lot of brain had leaked off my nose I switched to a simple "analog XOR PLL" :)
-
If the dac is not changing, then how can the (my) oscillation be related to the loop?
I will build a second unit to compare, but I'm not sure if I should build a copy and clock both with the same PPS signal or build with a different GPS and OCXO? If I build a copy and the oscillation is due to PPS jitter, then that would be mirrored and be in phase on both units. If it is a characteristic of the osc., then they will be similar but out of phase and amplitude, etc. If is a defect of the one osc., then the second may not oscillate. I'd prefer to build with different components, though.
-
All GPSs that don't attempt to reduce the TP jitter with sawtooth correction must I suspect show rate changes (a lot) within a range of (n) ns in each direction or more.
A UCCM GPSDO's PPS output is a tamed beast compared to a non-timing GPS's especially. Whether the PPS is coming at the right instant the second changes is a function of how accurately its adjusted, because the cable length and I am sure many other things (ionospheric conditions, whether its in stationary mode...and the position its got for its location is accurate- more?) also need to be taken into account.
With sawtooth error the period between peaks in the error changes, a lot, so does the shape of the sawtooth and which direction it slopes, in a recognizably characteristic way.
-
All GPSs that don't attempt to reduce the TP jitter with sawtooth correction must I suspect show rate changes (a lot) within a range of (n) ns in each direction or more.
A UCCM GPSDO's PPS output is a tamed beast compared to a non-timing GPS's especially. Whether the PPS is coming at the right instant the second changes is a function of how accurately its adjusted, because the cable length and I am sure many other things (ionospheric conditions, whether its in stationary mode...and the position its got for its location is accurate- more?) also need to be taken into account.
With sawtooth error the period between peaks in the error changes, a lot, so does the shape of the sawtooth and which direction it slopes, in a recognizably characteristic way.
My understanding is that over a long enough time period such correction doesn't matter, so how important it is depends on the loop time constant of the GPSDO. I don't have the reference to hand, but most plots of GPS 1PPS ADEV converge to roughly the same slope with averaging time.
-
Hi all,
I just finished putting it all in a box.
It works fine, and with the box it is even a bit more stable, I think because of the OCXO temperature being more stable.
I used two 6-channel 74HC14 as buffer for the outputs, I used three parallel inputs for the 1pps, three for the 10MHz, three for the 5MHz and three for the 1MHz I got from the 390 at pin 6 because of the better 60/40 duty-cycle there.
Each output has a 150 Ohm series resistor, every time I combined the three outputs as one, giving it an appr. 50 Ohm output resistance.
Here it is:
https://photos.app.goo.gl/DimgdLnNpAfeRTiu6 (https://photos.app.goo.gl/DimgdLnNpAfeRTiu6)
Un saludo,
Leo
-
This is what I see on the TIC.
My GPS is set ti timing mode and I only allow maximum 2 satellites at a time. I see big jumps when it changes satellites.
-
1 is the classic sawtooth pattern, that is what I've seen again and again in the literature.
Guessing - 1 is the GPS jitter measured against a good OXCO or already made GPSDO or rubidium?
What is 2?
-
cdev, 2 is a wider view, you can see the same jump in left side.
-
cdev, 2 is a wider view, you can see the same jump in left side.
And indeed, there it is!
All GPSs that don't attempt to reduce the TP jitter with sawtooth correction must I suspect show rate changes (a lot) within a range of (n) ns in each direction or more.
A UCCM GPSDO's PPS output is a tamed beast compared to a non-timing GPS's especially. Whether the PPS is coming at the right instant the second changes is a function of how accurately its adjusted, because the cable length and I am sure many other things (ionospheric conditions, whether its in stationary mode...and the position its got for its location is accurate- more?) also need to be taken into account.
With sawtooth error the period between peaks in the error changes, a lot, so does the shape of the sawtooth and which direction it slopes, in a recognizably characteristic way.
My understanding is that over a long enough time period such correction doesn't matter, so how important it is depends on the loop time constant of the GPSDO. I don't have the reference to hand, but most plots of GPS 1PPS ADEV converge to roughly the same slope with averaging time.
I think you're right as long as you are just looking for a frequency standard and don't need to know the (really!) 'exact' time which seems to be a technically daunting problem when you get into the nanosecond range so people shouldn't feel bad about that. It varies depending on things like your altitude too, because of relativity!
-
This is what I see on the TIC.
My GPS is set ti timing mode and I only allow maximum 2 satellites at a time. I see big jumps when it changes satellites.
Why do you limit the number of satellites? Typically, you want as many satellites as possible. The receiver then averages them and rejects the outliers. This gives a more stable result and minimizes any jumps when a satellite enters or leaves the constellation.
Ed
-
What you likely want, Miti, is to set an appropriate elevation or SN mask for your antenna location.
Launch a program that lets you visualize the orbits and signal strengths at relative points in the sky and note where the satellites are strongest, minus the bottom few degrees of elevation near the horizon. Pick a number for elevation mask that captures the strong signals and leaves out the weak ones.
Or pick a setting that excludes the marginal signals by strength.
Make sure your antenna is placed in the best possible location.
-
What you likely want, Miti, is to set an appropriate elevation or SN mask for your antenna location.
Launch a program that lets you visualize the orbits and signal strengths at relative points in the sky and note where the satellites are strongest, minus the bottom few degrees of elevation near the horizon. Pick a number for elevation mask that captures the strong signals and leaves out the weak ones.
Or pick a setting that excludes the marginal signals by strength.
Make sure your antenna is placed in the best possible location.
My Min SV Elevation is set to 10 deg. and the Min C/NO is set to 20dbHz.
Why do you limit the number of satellites? Typically, you want as many satellites as possible. The receiver then averages them and rejects the outliers. This gives a more stable result and minimizes any jumps when a satellite enters or leaves the constellation.
Ed
I quote from the Ublox document "Timing_AppNote_(GPS.G6-X-11007).pdf", section 1.2.2:
"Single satellite navigation can be useful under poor GPS reception conditions. Time information can be heavily degraded due to multipath effects. To avoid such degradation choose an antenna that primarily receives satellites with high elevation angles. Using the UBX-CFG-NAV5 message, low elevation angle satellites can be ignored. Furthermore the number of satellites can be reduced using the UBX-CFG-NAVX5 message."
Edit: Are you sure it averages the satellites? It's very hard to find any information regarding the Ublox timing mode other than what I mentioned before. It would make sense but I don't know where you found that?
-
Are you sure that your antenna setup doesn't have some problem? How long is the antenna feedline?
If everything checks out, You might want to try a different antenna with higher gain LNA?
But, it sounds like you know what you're doing there, and the behavior you're seeing might be what might be seen with a inadequate antenna or very long (or thin) feedline. Or maybe water or some other problem with the feedline. Of course if its indoors that wouldn't apply. I'm sorry to ask all these questions. To explain, I've spent a lot of time fooling around with antennas over the years but still when I got my own GPSDO at the beginning I made some of the classic mistakes. It seems like its human nature. That said I cant think of what would be causing that. Noise maybe- Noise, power supply noise?
Thats a shot in the dark. U-center has some settings you can use to measure how much noise is being picked up.
If you have a patch antenna, (not a QFH, some of the timing antennas - like my own, are QFHs) how is the ground plane under your antenna, is there a flat metal horizontal ground plane underneath the patch part?
-
But, it sounds like you know what you're doing there...
Appearance may be deceiving :-DD
cdev,
I don't have any major problem with my GPSDO, I was just showing metrologist what my TIC looks like. Lars seems to have done a very good job.
One minor issue is that with the number of satellites restricted to 2, I see some jumps (in the order of 10 to 40 ns, I think it depends if it is clear or cloudy) when it uses some satellites. Ed said that I should enable maximum number of satellites but I'm not sure about that. At least the only documentation that I found about the timing mode of Ublox modules contradicts that, if I read it correctly.
Anyway, my antenna is a small patch one, in the basement window, partially covered by a tree. :palm:
Still, I'm getting very decent levels, one sided though.
-
If I were you I would try to use Lady heather or U-center to determine a good elevation mask, not restrict the # of SVs, and just work with that. Also try to get a better sky view. Here is an idea. Can you put your antenna inside some plastic object that protects it from lawnmowers in the middle of your lawn, on the ground. The ground plane is meant to be in a situation like that, there is much less of a reason to put the antenna up high with a patch antenna than say with VHF as the signals you want come from above not the horizon.
Arguably the best place is on a good ground plane. Can you - just for the sake of knowing, put it in some waterproof enclosure (double plastic bags would be good) and then put it on a flat piece of metal a bit out on your lawn. If you hadn't done it before that might be interesting. My GPSDO had markedly better performance (with the antenna there (in the middle of an open lawn) than anywhere indoors or under the eaves.
-
I think Ed is right. I changed the maximum SV # to 25 but I kept the S/N and elevation restriction. That's after the red line. Looks much better, eh?
Edit: The graph is the TIC.
-
What you likely want, Miti, is to set an appropriate elevation or SN mask for your antenna location.
Launch a program that lets you visualize the orbits and signal strengths at relative points in the sky and note where the satellites are strongest, minus the bottom few degrees of elevation near the horizon. Pick a number for elevation mask that captures the strong signals and leaves out the weak ones.
Or pick a setting that excludes the marginal signals by strength.
Make sure your antenna is placed in the best possible location.
My Min SV Elevation is set to 10 deg. and the Min C/NO is set to 20dbHz.
If Lady Heather supports your GPSDO, you can use the SAE command to see at what elevation the signal strength starts to drop off. By setting the elevation mask slightly above this elevation, you'll reject a lot of marginal, multipath, and otherwise distorted signals.
Why do you limit the number of satellites? Typically, you want as many satellites as possible. The receiver then averages them and rejects the outliers. This gives a more stable result and minimizes any jumps when a satellite enters or leaves the constellation.
Ed
I quote from the Ublox document "Timing_AppNote_(GPS.G6-X-11007).pdf", section 1.2.2:
"Single satellite navigation can be useful under poor GPS reception conditions. Time information can be heavily degraded due to multipath effects. To avoid such degradation choose an antenna that primarily receives satellites with high elevation angles. Using the UBX-CFG-NAV5 message, low elevation angle satellites can be ignored. Furthermore the number of satellites can be reduced using the UBX-CFG-NAVX5 message."
Boy, some awkward wording here. 'Navigation' for a timing receiver?? Anyway, yes, you can do single satellite timing once you've done a survey to figure out where you are. But as soon as that satellite goes out of sight, you're screwed. Single satellite operation is a very limited form of operation that is only useful under very specific circumstances. The same comments would apply to running with a reduced number of satellites. I don't know where that would make sense.
Edit: Are you sure it averages the satellites? It's very hard to find any information regarding the Ublox timing mode other than what I mentioned before. It would make sense but I don't know where you found that?
The magic acronym is RAIM (Receiver Autonomous Integrity Monitoring) - often called TRAIM for Timing Receiver.... Timing receivers have it, navigation ones don't. Since the timing receiver doesn't have to recalculate position every second, it has lots of spare cycles to improve the quality of the timing outputs. The inner workings might be different for every company, but basically, the receiver picks the best satellites and tosses the rest. 'Averaging' might not be the correct word mathematically, but that's the effect. I'm not familiar with the M8T, but there might be a command to show you which satellites are used in the timing solution. The answer could change from second to second or minute to minute.
The M8T data sheet says in section 1.8.4 Timing integrity and availability:
Fix redundancy (RAIM)
The receiver automatically and continually adjusts the significance of individual signal measurements in the
reported estimate of time according to its quality and consistency. This ensures that the integrity of the
reported time is protected from individual faulty signals or measurements so long as there are more signals
in use than the minimum required. The minimum number changes depending on the situation but
whenever it is exceeded “raim active” is set in message TIM-TP to indicate that this protection is active.
Doing a quick browse through the datasheet, I saw a section on the Survey-In process. Although there isn't a lot of detail, it looks like it's a necessary step to achieve a stable output.
Ed
-
I did a Survey-In and the GPS is in Fixed mode. Unfortunately, after few days of Survey-In running, I couldn't get a position accuracy better than 16m, probably due to the position of antenna that only sees the west side of the sky.
Lady Heather does something weird to my GPS modules, it reduces the sensitivity dramatically. The signal level drops significantly and I have to do a restore to default to see them coming back to normal. It must send some funny messages.
-
You're not using the M8T sawtooth correction, right? (Since Lars' GPSDO doesn't utilize it.)
Previously you posted that you use the "UBX-CFG-NAV5" message - the implication seems to me to be that that message automatically sets the elevation mask in some way. Usually that wouldn't leave you with only a few satellites but if more than half of the sky was already blocked, sure, I could see you ending up with only a few.
The Skytraq/Navspark units are significantly more sensitive than the Ublox GPSs. maybe in your situation you would do better with one of them. They are so sensitive that for me, they work indoors without needing to be near a window at all.
-
I don't know how to use that correction. Can you point to a document that details that?
Previously you posted that you use the "UBX-CFG-NAV5" message - the implication seems to me to be that that message automatically sets the elevation mask in some way. Usually that wouldn't leave you with only a few satellites but if more than half of the sky was already blocked, sure, I could see you ending up with only a few.
I don't know what you mean by that. Take a look at the NAV5 configuration. You set the elevation, it doesn't set it automatically.
The number of satellite and the signal level is pretty good considering the antenna is in the window and I technically, visually, only see half of the sky. The U-Center seems to contradict that though.
Anyway, I'm not changing anything in my setup, it's good enough for what I need it for (a reasonably accurate and stable 10MHz reference), I'm just trying to understand how I can make the best out of it and understand more about the GPS gibberish documentation.
If you can point to a glossary of terms for GPS that would be very appreciated.
-
I'm worried about Lars!
I hope and pray he's OK and I wish him, and everybody on this forum, a Merry Christmas, full of hope, health and peace!
-
His last post was one week ago at https://blog.liw.fi/ (https://blog.liw.fi/).
-
Ublox has a book sized PDF document, their GPS compendium, do you have that?
Since you have a ublox GPS the chances of their using the same terminology is fairly good, often the same word or thing has different definitions depending on who is using it.
Its free.
To be honest with you Although I have one working ublox GPS and like their software, I'm far less familiar with it than I would like to be and have a bunch of other things that are a higher priority for me right now than that. That said, their software is quite good and the combination of it and their hardware is really educational. If you really want to dig around in their protocol there is another program called Comms Champion that speaks it - even the non-sanctioned parts of it.
I don't know how to use that correction. Can you point to a document that details that?
Previously you posted that you use the "UBX-CFG-NAV5" message - the implication seems to me to be that that message automatically sets the elevation mask in some way. Usually that wouldn't leave you with only a few satellites but if more than half of the sky was already blocked, sure, I could see you ending up with only a few.
I don't know what you mean by that. Take a look at the NAV5 configuration. You set the elevation, it doesn't set it automatically.
The number of satellite and the signal level is pretty good considering the antenna is in the window and I technically, visually, only see half of the sky. The U-Center seems to contradict that though.
Anyway, I'm not changing anything in my setup, it's good enough for what I need it for (a reasonably accurate and stable 10MHz reference), I'm just trying to understand how I can make the best out of it and understand more about the GPS gibberish documentation.
If you can point to a glossary of terms for GPS that would be very appreciated.
-
His last post was one week ago at https://blog.liw.fi/ (https://blog.liw.fi/).
I don't think he is the same Lars. He is Lars Walenius, while the one in the link is Lars Wirzenius.
-
Ublox has a book sized PDF document, their GPS compendium, do you have that?
Since you have a ublox GPS the chances of their using the same terminology is fairly good, often the same word or thing has different definitions depending on who is using it.
Its free.
Thanks! I didn't know about this book. It is exactly what I needed.
-
Thank you, Miti, for posting, and I am with your thoughts on Lars.
I've had some setbacks. First, my Jupiter GPS module fails to start. I played around for a day with it and at the end I reversed polarity the power and it got warm. I bought this GPS many years ago just to make a GPSDO. Then one of my UCCM GPSDO modules died. This is similar to the bg7tbl but by another. I'm not sure if just the 6V buck converter died or something on his interface board or the UCCM module. Another thread...
So, I dug out a Lassen GPS for the PPS. What's the best way to deal with the PPS here - I don't think there is anything in the gps to set? It keeps lock at TC=160. The sawtooth period started out around 3 seconds and seems to have increased to ~13 seconds. It's not supposed to swing that far, should be within 100ns. I'm also running a timelapse video of the two 10MHz signals on a scope, to see the wander and drift.
30X, 82mins:
https://www.youtube.com/watch?v=7PoQDyLP_Cw (https://www.youtube.com/watch?v=7PoQDyLP_Cw)
-
Looking at your video, I doubt you have a lock there. I have a Ublox GPS set to output 10MHz and I connected both, the GPSDO and the GPS, to the oscilloscope. They are pretty much locked as you see in the picture for weeks. You can see the expected jitter of about 20 ns but the two signals don't drift more than +/- 10 ns from what you see in the picture and always come back into alignment. The drift is so slow, it takes minutes or tens of minutes to go 10ns left or right and to come back. They never drift one full period.
-
To me, it looks like it's locked but there's noise on the oscillator's EFC line. The noise could be coming from the power supply or the PLL circuitry. The frequency excursions are so small that you might not be able to see or measure the noise.
If it wasn't locked, I'd expect the frequency difference to be larger and the drift would be in one direction rather than the back-and-forth that occurs. You can see the square wave tends to drift towards the right, but occasionally pulls back to the left to try and maintain the phase difference between the two.
Ed
-
Also doublecheck the atmega's Vcc decoupling. The noise at its 5V Vcc directly affects the EFC.
https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/msg1933384/#msg1933384 (https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/msg1933384/#msg1933384)
-
There may be EFC noise, but that is nothing we can see here. I am looking at the dac swings. I don't really know yet how the time constant is factored. I sort of expected the calculation to occur as some kind of average over the duration, but I see a new dac value every tic so I suspect a running average.
For fun, I just cranked the TC to 6000 and increased damping. The phase would then drift about 180 deg over an hour and the dac would cycle through 3 values as the sawtooth resets.
-
Hello for a few days testing versions of mini gpsdo. Very fast stabilizes OCXO.
(http://www.jo72.pl/kkm/gpsdo/1546033515401.jpeg),(http://www.jo72.pl/kkm/gpsdo/1546033412675.jpeg)(http://www.jo72.pl/kkm/gpsdo/1546033412764.jpeg)
Thanks to Lars for a very good project.
I wish you all happy and prosperous New Year
best regards
73 Marek SP4ELF
-
There may be EFC noise, but that is nothing we can see here. I am looking at the dac swings. I don't really know yet how the time constant is factored. I sort of expected the calculation to occur as some kind of average over the duration, but I see a new dac value every tic so I suspect a running average.
For fun, I just cranked the TC to 6000 and increased damping. The phase would then drift about 180 deg over an hour and the dac would cycle through 3 values as the sawtooth resets.
Metrologist,
If you see a different DAC every second, you're not locked. Once it locks, it is stable over longer or shorter periods of time, depending on the TC and the stability of your OCXO. Take a look at mine below. Can you post a screen shot?
-
Miti, the red trace in the earlier plot shows the dac setting. I'm just playing around with this very lousy GPS. The sawtooth correction is over 200ns. I can get lock with lower TC, but the frequency wanders all around following that PPS - you can see it bouncing in the video. It would be better to average more tics and I was trying with very long TC to accomplish that, but then no lock. I need to spend some time with the code and maybe make some modifications.
-
Sad news :'( :'(
https://www.eevblog.com/forum/metrology/farewell-to-our-friend-lars/ (https://www.eevblog.com/forum/metrology/farewell-to-our-friend-lars/)
/Bingo
-
Sad news :'( :'(
https://www.eevblog.com/forum/metrology/farewell-to-our-friend-lars/ (https://www.eevblog.com/forum/metrology/farewell-to-our-friend-lars/)
/Bingo
Yes, very sad. Lars was so helpful even when he was very unwell and undergoing treatment he still took the time to give detailed responses to technical questions.
-
I think the biggest favor we could do for Lars is learn from his design and postings and refine his GPSDO/TIC design while keeping it affordable to all.
It would be great to see more of the principles of accurate measurement incorporated into the body of knowledge that technically literate people learn to be so.
I know things like measuring where lightning strikes by time of arrival using GPS timing, seeing how all the pieces fit together to make some amazing accomplishment happen would make a lot of kids eyes light up.
The really cynical discussion going on in another thread has been making me think just how much we all need that for our sanity. It really is important not just to have dreams, but to actually realize them.
Knowledge and the scientific process is a magical thing and a principle that not only makes life interesting, it also will carry somebody through a lot of hard times.
-
I had recently gathered up the parts to start building his gpsdo. I will make the effort to complete it.
RIP, and thanks for sharing your knowledge.
-
Can anyone help me please?
I have been trying to tune my GPSDO, but I'm having some issues.
I started by limiting the OCXO frequency span with some resistors to the point where with "h1" I get an average of 57 for diff_ns and with "h65535" an average of -83. I think this makes the VCO range 140ppb so I set the gain to 465 (≈65536/140).
With this gain and default time constant I get a lock with no issues.
I then tried to tune the time constant. For that I set the time constant to 4 and ran timelab for frequency difference as DAC *2.142E-12 .
This is what I got for MDEV:
(https://imgur.com/zVVpETIb.png)
According to the documentation I thought that the TC should be where the graph inflects from descent to crescent, so it should be about 1000 on the graph above.
Issue is that I can't get a log with TC's bigger than 300. What am I doing wrong?
Also about the linearization parameters I have read the documentation again and again but I just don't get it, I'm supposed to change the TIC offset to 1000 and then?
Any help? Thanks!
P.S.-Just read that Lars passed away, my condolences to the family and friends.
-
Which GPS are you using and do you know the PPS jitter? Also, can you post some of your log data when locked at TC=300?
-
Leave the offset at 500. Try going from low to high with the TC. Set it to 200 and let it lock. After few hours go to 300 and so on. Do you have temperature sensors installed? Is the temperature compensation enabled? Post a screen shot after you send "f2". Keep in mind that higher the TC, longer the lock time is. For TC=500 for example, lock time is more than 41 min from the moment TIC is less than 100. The way you calculate the lock time is TC*5 in seconds.
-
Which GPS are you using and do you know the PPS jitter? Also, can you post some of your log data when locked at TC=300?
Hi,
I'm using a NEO6Q bases board designed by a project I was part of in the past. Have a 7M arriving on the slow boat from China. No idea about the 1pps jitter, I can try looking at it with the scope.
Since posting I realized I had TempCoeff set to 4 (I'm not using a temp sensor), must have happened when setting TC to 4. After setting it to zero I think things improved a bit. I can get a lock with TC=450 and it maintains the lock. If I then change it to 500 the lock is maintained for a few hours but then breaks.
I attach one of this experiments, I start with TC=450 and get a lock, then at time 18581 I change TC to 500, the lock breaks at time 35507 (about 5 hours later) and recovers at time 38021 (so after about TCx5). Then the lock is lost again at time 40389, a bit after I change the TC back to 450 and never loose lock again.
Leave the offset at 500. Try going from low to high with the TC. Set it to 200 and let it lock. After few hours go to 300 and so on. Do you have temperature sensors installed? Is the temperature compensation enabled? Post a screen shot after you send "f2". Keep in mind that higher the TC, longer the lock time is. For TC=500 for example, lock time is more than 41 min from the moment TIC is less than 100. The way you calculate the lock time is TC*5 in seconds.
No temperature sensors, reading trough the documentation I thought I wasn't supposed to use one when using an ocxo.
f2 taken from the attached doc:
Gain 465 Damping 3.00 TimeConst 500 FilterDiv 2 TIC_Offset 500
TempRef 280 TempCoeff 0 TICmin 12.0 TICmax 1012 Square comp 0.100
Warm up time 300 LockPPScounter 9582 MissedPPS 1 TimeSinceMissedPPS 10552
ID_Number 0 Restarts 40 Total hours 288
So even if things are better I'm still far from the ideal TC=1000 which I thought was what the previous MDEV I posted indicated, right?
Also I'm still lost when it comes to setting the linearization parameters.
Thank you both for your help!
José
P.S- File was too big to attach here so I saved it to google drive
https://drive.google.com/open?id=0B8279AP3EkuyNnl0aWhWdFJsQ1lpdzJGdmczZ3BfeG1tczg4 (https://drive.google.com/open?id=0B8279AP3EkuyNnl0aWhWdFJsQ1lpdzJGdmczZ3BfeG1tczg4)
-
According to Lars, your TC should be indeed 1000 but is seems extremely good to me. What OCXO do you use? Is the GPSDO enclosed or flapping in the breeze? A high TC makes it very slow to keep up with the temperature changes. That could be the reason why it goes in and out of lock.
I use temperature sensors in my GPSDO with OCXO and it makes a big difference. My GPSDO is enclosed and it stays locked with TC=500, that is my optimum TC, see page 4 for my MDEV.
-
I was also going to ask which OCXO. The tune range is limited to 140; I checked the NEO6Q PPS spec is <60ns 99%. I suspected that with a high enough TC, the tune response is too slow to chase that PPS - that is why I was interested in seeing some of the log file. Your PPS looks mostly within its 30ns spec.
I noticed that both times before NoLock, the tic value continued to increase until just over 100ns where lock was lost. Miti may be on track with applying temp compensation as something was causing an upward drift that looks like it just overran the dac.
Did you enable tic's extra digit for timelab and did you remove linearization errors from the resulting plot?
-
According to Lars, your TC should be indeed 1000 but is seems extremely good to me. What OCXO do you use? Is the GPSDO enclosed or flapping in the breeze? A high TC makes it very slow to keep up with the temperature changes. That could be the reason why it goes in and out of lock.
I use temperature sensors in my GPSDO with OCXO and it makes a big difference. My GPSDO is enclosed and it stays locked with TC=500, that is my optimum TC, see page 4 for my MDEV.
Hi,
I'm using an isotemp MOD:OCXO143-141 from ebay. The GPSDO is inside an enclosure but kind of ghetto style (I attached a photo of the setup).
Currently the only issue I see is that I have it very close to a window because with the present GPS module I need to place the antenna in the middle of the garden to get a steady signal and I was out of coax to make a bigger extension, and the nights have been very cold lately.
I have mounted an NTC now and I'm logging some data to tune the coeff.
Should I mount the NTC in contact with the OCXO, close to it, or in the middle of the enclosure?
I was also going to ask which OCXO. The tune range is limited to 140; I checked the NEO6Q PPS spec is <60ns 99%. I suspected that with a high enough TC, the tune response is too slow to chase that PPS - that is why I was interested in seeing some of the log file. Your PPS looks mostly within its 30ns spec.
I noticed that both times before NoLock, the tic value continued to increase until just over 100ns where lock was lost. Miti may be on track with applying temp compensation as something was causing an upward drift that looks like it just overran the dac.
Did you enable tic's extra digit for timelab and did you remove linearization errors from the resulting plot?
I didn't enable the extra digit, I thought it only affected the time error column which I didn't use with timelab (I used the DAC). How do I remove the linearization errors from the plot?
Thank you for the help!
José
-
TimeLab->Edit->Subtract global linear...
-
I'm using an isotemp MOD:OCXO143-141 from ebay. The GPSDO is inside an enclosure but kind of ghetto style (I attached a photo of the setup).
Currently the only issue I see is that I have it very close to a window because with the present GPS module I need to place the antenna in the middle of the garden to get a steady signal and I was out of coax to make a bigger extension, and the nights have been very cold lately.
I have mounted an NTC now and I'm logging some data to tune the coeff.
Should I mount the NTC in contact with the OCXO, close to it, or in the middle of the enclosure?
I didn't play with that particular OCXO but my Bliley NV47A1282 can only go to TC=600. It has a hard time locking with TC=500 though, I normally lock it with TC=400 and after few hours I change it to TC=500 and is stays locked if I don't turn the box upside down. I didn't go above TC=500.
I use two LM35 sensors, the one in column 4 (that's used for compensation) is siliconed to the OCXO, the one in column 11 is just an indicator, somewhere in the middle of the enclosure.
There's a post above from Lars in response to my question on how to calculate the TempCoeff, take a look . The TempRef is the average raw reading from the sensor in your lab over about a day or so.
And close the enclosure. It's essential for high TC.
-
Try using an Oscilloquartz 8663 DOCXO. I have found them to be virtually immune to room temperarure changes. Also, once they settle in (may take a few weeks) they tend to have very low drift rates.
-
Try using an Oscilloquartz 8663 DOCXO. I have found them to be virtually immune to room temperarure changes. Also, once they settle in (may take a few weeks) they tend to have very low drift rates.
I don't doubt it is an amazing OCXO but in this case I think it would complicate things. 12V supply, 0 - 10V VC. The schematic would need some upgrades.
-
12V in, LM7805 for the electronics. My 8663's tend to be on freq at around 4V in. The 8663 does have a Vref output (around 7V). You could switch a FET buffer powered by Vref driven by the Arduino PWM.
-
12V in, LM7805 for the electronics. My 8663's tend to be on freq at around 4V in. The 8663 does have a Vref output (around 7V). You could switch a FET buffer powered by Vref driven by the Arduino PWM.
In the datasheet, VRef is specified at RLoad>20KOhm, source resistance is 1KOhm, you'd need to buffer it for stability.
Look, I'm not saying it's not doable, don't get me wrong. All I'm saying is that it is not trivial, it would need some thinking and some testing... and that could be fun, I can't wait to see some results.
The result, however, may be pretty close to adding a temperature sensor to Isotemp or Bliley and finding the right TempCoeff.
Cheers
-
I lost lock! Shortly after changing time constant from 180 to 240. Then there was an oscillation between lock and no lock. Every lock showed a steep downward trend until lock was lost. I guess this is just the OCXO out running the dac here. Something else might have changed too because I was having trouble getting lock again at time constant of 120. This is with the Condor GPS. I can't understand why the dac has gone so far to keep it in range.
green 100 = lock
red = tuning dac
blue = phase offset (ns)
Edit: It ran locked for 19 hours and then broke out into the same oscillation as shown here, so something seems to be happening. I set to hold mode to run for the day and I'll see what the oscillator does. I'm going to build a second one with slightly different layout and I'll use precision resistor divider on the efc rather than a trimpot.
-
My GPSDO was loosing lock every time I connected or disconnected the FTDI serial cable to the PC. I tried one time to figure out where is that coming from but I didn't find an obvious reason. So instead of wasting more time chasing a ground loop or something else on a thing that otherwise works really well , I added a Bluetooth module. Now I can connect from anywhere in the house without disturbing the loop.
So far stable for at least 12 hours with TC=500.
-
Is there a full list of different OCXOs people have tried and their findings with them?
If not, there should be along with their typical costs on the used market.
-
I have 6-1/2 days of data with this CTI xtal - all daily plots on same scale and range except day 1 and 4.
Below are the latest 6 days with day 0.5 starting on the bottom and with higher TC (240). You can see it losing lock regularly. It was a little colder and the dac range was a little higher out of view.
Day 2 is better with TC 180, yet still struggling over long time periods.
Day 3 started in hold mode to observe xtal, then lower TC settings were used (~60-120). I could have picked a lower dac value.
Days 4-6 show a pattern that correlates. The plot center is mid-afternoon when it will be the warmest. It has been raining the last couple days and it's warmer with more stable temperature.
The top plot is all 6-1/2 days.
It looks like temperature effects and I suspect it may be more a result from the other components than the xtal. I do not yet have a thermistor installed so should check into that.
For contrast, I have added an almost 2-day plot of the same circuit, but with a lassen GPS. The plot range is opened up at least 2x. The PPS spec is 25ns for the condor and 100ns for the lassen.
BLUE is the ns value - typically ±50ns, over 100ns loses lock soon
RED is the dac value - typically range from 31100 to 30900 when locked
I will emphasize that when I was using the Trimble UCCM PPS signal, which I suspect my unit generates from its OCXO, the ns and dac was much more stable, with dac changes happening over periods of 10's of minutes rather that every few seconds with the more jittery GPS's.
-
What is blue, what is red?
-
I edited my post, Miti.
And, here is the same circuit with about half a day run in UCCM PPS and TC=400. It looks marvelous to me. It ran two days and lost lock only once (recovered after 5xTC). So, the only thing changed from the silky smooth of below and the noisy mess of above is the quality of the PPS. (you have to look at the ns scale of ±40ns vs ±150ns and dac range of 10 vs 200!)
I think software can improve that with some knowledge of the PPS characteristics. I read here that Lars does not use sawtooth correction, for example. I think it would be beneficial to average more samples before feeding the value to the loop calculation. I'm not good enough with the coding though...
-
I've attached mine with TC=600, about 9 hours, Excel cannot take more than 32000 values I think.
Bottom blue is TIC, red is DAC, top is the temperature. What a perfect mirror, DAC with the OCXO temperature.
-
I think xlsx files can handle 1,048,576 rows. It really starts to get slow at half a million records though... I'm undecided on what to do, so I put the UCCM PPS back on it with TC=200. Yesterday I let it run without PPS and it stayed within 100mHz the entire day (worst 9,999,999.904Hz). I need to add tempco as it may do more for me than it did for Lars.
-
I went back to my breadboard and installed a picdiv 10M->1Hz to generate the PPS, so the OCXO generates the PPS as well. I expected this would show the noise of the circuit in ns. Here is a plot with TC=20, TC=4, hold mode, and TC=4. Red is dac and blue is ns. If that is noise, that is a lot more than I expected. Also, the jumps may be because I removed several missing PPS or 10M? lines...
-
Your noise is 50ns_pp/6.6=7.6ns_rms. That is not bad..
The Lars' design uses rather simple hw for the phase measurement. Its performance could be heavily influenced by the construction.
MCU is noisy, its internal ADC could be with +/-2 LSB noise with good wiring (+/-2ns), the integrator is not linear and the readout depends on capacitor quality (ie. DA).
Another ADC error source could be from a jitter coming from the none-uniform start of the ADC's conversion (S/H moment) after the integration stops.
Also there is none highZ ADC buffer thus the reading might be influenced by the ADC's input currents.
Also the schottky diode has rather high reverse current, in hundreds nA range (and Temp dependent).
And 4046 is also not an ideal phase comparator (dead time etc).
I've been using the TI's TDC7200 digital time interpolator in my design, which claims 55ps resolution with 35ps stddev (my start/stop pulses are coming from an FPGA) and I get 150ps_rms (that is 1ns_pp) when lucky with my wiring (breadboard style).
-
Thanks for the explanation (ESR, DF and Q are all aspects of the performance of a capacitor...DA? oh, that DA https://www.eevblog.com/forum/beginners/fake-polypropylene-capacitors-from-china/?topicseen (https://www.eevblog.com/forum/beginners/fake-polypropylene-capacitors-from-china/?topicseen)). I can measure the critical caps, but they are old electrolytics and a very poor choice here. I wonder also if the loop could be oscillating due to the way I have the feedback, and also due to I'm using pre-made (longish) breadboard wires. I'm thinking of using a second OCXO to generate the PPS and compare.
-
DA with the capacitor in the "integrator" could be a critical parameter. You do not use an electrolytic capacitor there, I bet.
-
If you take a couple of photos of it - maybe some issue might be non-obvious but amenable to multiple minds working on the problem, and a process of elimination?
Breadboard wires vary as far as making a reliable connection. I wouldn't think they would be so reliable in many timing applications. maybe you could use redundant double breadboard wires where the connection is critical to the timing, the chance of a glitch might be much reduced if it took a simultaneous glitch on two separate wires at exactly the same time to equal a glitch for the GPSDO?
Thanks for the explanation (ESR, DF and Q are all aspects of the performance of a capacitor...DA? oh, that DA https://www.eevblog.com/forum/beginners/fake-polypropylene-capacitors-from-china/?topicseen (https://www.eevblog.com/forum/beginners/fake-polypropylene-capacitors-from-china/?topicseen)). I can measure the critical caps, but they are old electrolytics and a very poor choice here. I wonder also if the loop could be oscillating due to the way I have the feedback, and also due to I'm using pre-made (longish) breadboard wires. I'm thinking of using a second OCXO to generate the PPS and compare.
-
A simple "self test" would be to divide the
10kHz 10MHz (coming from the OCXO 100divider's output) to 1PPS (ie by PICDIV version doing /10000) and feed the gadget with those signals.
The ns readings should be all equal with no jitter (ideally).
You do not need an another OCXO for this experiment.
-
imo, how is that different than what I did? Except my OCXO does not have a divider, so I just use the picdiv to divide the 10M output.
I'm not sure if I am really troubleshooting a problem with this self fed loop other than there seems to be much more noise than I was expecting (~5ns pp). There are many good explanations for what I'm seeing, but...
... when I clocked this with UCCM PPS there seemed to be much less noise. That is why I wondered if there is a loop oscillation being driven by the feedback and some instigator.
-
imo, how is that different than what I did? Except my OCXO does not have a divider, so I just use the picdiv to divide the 10M output.
Sure, it could be done that way too..
Try the self test and you will get a feel what comes from GPS and what from your board.
-
Self test?
-
The "self test" means you feed the 1PPS and 10MHz inputs of Lars' board from the same Oscillator source (it
must may not be the OCXO, a simple canned osc is ok).
That way the phase diff of the edges (in "ns") should be constant and with smallest jitter (may be with none jitter).
If not, there is a problem with something on the board.
Another test: you may try to invert/invert/invert... (different taps) the 10MHz clock before entering the 390' dividers. That way you move the phase diff (in "ns") towards the upper end of the ADC. You should see different "ns" numbers for the specific taps, but always constant.
OSC-------------------------->INPUT 10MHz
|
------->PICDIV--------> INPUT 1PPS
OSC-------->74HC04------->INPUT 10MHz
|
------->PICDIV--------> INPUT 1PPS
PS: sorry I will fix my above post for clarity, the 10kHz I referred to was a wrong number.
-
I thought that is what I was basically doing, but I do not understand why the OCXO cannot be used?
-
What are your results with the test then?
-
What are your results with the test then?
Reply #233? I tried another oscillator but it has an AC sine wave and that would not drive the picdiv directly. I put that aside for now and...
I added NTC to the circuit - except I have to do it funny because I had 100k NTC. I used two of them in parallel (5V -- NTCs - ADC2 - 1k1 -- GND). That seems to keep the voltage under 1.1V at high temperatures (100C). So I'll be operating in the lower/less linear area of the response curve. (I'm not seeing cheap 10k NTC - they are all dressed up for Arduino with flowers and butterflies and cost $10 a piece).
ADC2 bounces around 241 to 246 and did not move much at all overnight, but there was a clear rise in dac from turn-on.
I set a Tempcomp of -1. I was confused on the calculation and what's the purpose of the TempRef, and I do not know if it's compensating the correct direction.
I lined up the time scales in the plots as I had more temp data from turnon. I did not bother to plot efc dac and ns values during warmup and unlock. The glitches in the temp data result from me changing sensor types and display of dac, C or F values.
Now, if I compare my ns value driving with picdiv pps in reply 223 with my ns value driving with a (supposedly more jittery) GPS PPS, I get confused.
-
It has been quite quiet here last weeks . . .
Accidently I came across this forum in my search for a simple Arduino based
TIC GPSDO and read the full thread about three times to try to get 'sound and vision'
with the design/concept and experiences of others.
Today I built the circuit using a Bliley NV47A1282 (same as Miti) and with some fiddling
I got a lock earlier this afternoon. But it seems it's not a lOck but lUck ; -)
I suffer from (too much) 'Missing 10 MHz?' frames and seek some guidance.
From what I understood (from this thread and looking in the source code) this
'Missing 10 MHz?' coincides with a full ADC (1023), (meaning?) the pulse is too long (?)
I use R = 4.02k, C = 1 nF and decharge R = 6.6 MOhms (2 x 3.3 M in series)
To prevent myself burning precious time, should I lower the 4.02k value?
-
I suffer from (too much) 'Missing 10 MHz?' frames and seek some guidance.
From what I understood (from this thread and looking in the source code) this
'Missing 10 MHz?' coincides with a full ADC (1023), (meaning?) the pulse is too long (?)
I use R = 4.02k, C = 1 nF and decharge R = 6.6 MOhms (2 x 3.3 M in series)
To prevent myself burning precious time, should I lower the 4.02k value?
Use the recommended parts and check your ground. I had the same problem and I had to redo my ground and to move the RC close to Arduino. Very close.
-
Thanks for the prompt reply Miti!
Indeed, my 'analog wire' apparently was too long (and therefore noisy?).
To make connections as short as possible I selected A7 as sample port,
soldered the components on the Arduino board (see picture below, I use a BAT86 diode)
and routed an extra GND wire from Arduino GND to HC4046 GND (pin8).
The result is flabbergastingly different in a positive sense!
Until this moment of writing it never missed a beat.
Edit some hours later: it still hasn't :)
In run mode the DAC value converged and clamped to 0 (zero), so I had to
to lower the minimal voltage at the VFC pin and used 100k parallel too.
Edit: changed the resistor to 51k1 (so that DAC value appears ~31000 when in lock)
Now with h1 and h65535 the difference in diff_ns was around 600, so my gain is 65536/600 = 110.
Edit:with 51k1 resistor h1 = 996 mV, h65535 = 2200 mV --> Δ diff_ns = 490 --> gain = 134, I took 128.
Letting it run, the contraption locked within 10 minutes :)
Edit: in warm condition (with 51k1 parallel to VFC) within 130 seconds.
-
Hi All,
I understand Lars as the designer of this GPSDO has pass away some times ago but I think some one can help me to understand something about this design.
using 1MHz and 1PPS as input for TIC how to calculated the TIC resolution ?
-
That is explained by Lars very nicely in "What is Lars Arduino based GPSDO Controller page 1-7.pdf", check the first post.
I've also attached a very interesting document to read.
Miti
-
Reading the patent 'diagonally' it seems to be (almost) the same principle
as in Lars' GPSDO?
BTW. I cleaned / simplified some of Lars' code and am now busy with an
algorithm to let the time constant (TC) converge to it's optimal (= maximal?)
value after a lock has been obtained (locking/starting with a lower TC).
-
I think there is a much earlier patent on the very concept.
-
BTW. I cleaned / simplified some of Lars' code and am now busy with an
algorithm to let the time constant (TC) converge to it's optimal (= maximal?)
value after a lock has been obtained (locking/starting with a lower TC).
Does it calculate the optimum TC or just "converges" to a max value that you determine and program into it?
-
From what I understand from Lars' philosophy is that the TC is a figure of merit
concerning the quality/stability of the system. In my words, the larger the TC
(where the system stays in lock) the better.
So what I now do, is start with a low TC and periodically (depending on the TC itself)
increase the TC (also depending on the TC itself and the stability of the system given this TC).
Now I use kind of exponential approach .. i.e. lower TC's will be increased less compared to large(r) TC's.
When the system starts to drift away 'too much' (i.e. TC seems too large) the TC
is lowered. The idea is to let the TC 'lock' (like a PLL) to its optimal (= maximal?) value
for a given system/setup and to figure out what 'too much' is.
Also plan to experiment with making the gain relative to the TC. Found out that while in lock
I can reach larger TC's by increasing the gain.
In the current run gain is fixed to 4x the 'h1-h65535' determined gain (which was 135, I took 128 so it's 512 now).
(Intermediate) results are that my system (not T-compensated) can reach TC 1024 (and
even higher, but I clamped it to 1024 cf Lars' comments), stays in
lock for several hours but then ... looses lock. So my challenge is to find a condition
to prevent lock loss.
-
I use temperature sensors in my GPSDO with OCXO and it makes a big difference.
Yep, just discovered the reason for this. A2 is floating and sampling A2 is almost the same as sampling noise ; -)
In the (current) sketch A2 readings are default taken into account to calculate the DAC value, as a result this
DAC value has intrinsic noise.
Solution for this issue:
1. Add temp compensation
2. Connect A2 to ground
3. Fixate A2 readings (which I did for the time being, LM35's have been ordered ; -)
-
When the system starts to drift away 'too much' (i.e. TC seems too large) the TC
is lowered. The idea is to let the TC 'lock' (like a PLL) to its optimal (= maximal?) value
for a given system/setup and to figure out what 'too much' is.
OK, after some experimenting with the following conditions:
- 'open contraption' (not in a casing yet & OCXO = Bliley)
- fixed ADC reading (and therefore ...)
- no temperature compensation
The GPSDO is ca. 15cm away from my computer mouse.
When I'm behind the computer, the TC varies around 250 +- 80
(depending on my coffee mug with fresh coffee ; -).
When away the TC varies around 500 +- 100.
It didn't loose lock (yet) and I think I found a criterion to
forecast/prevent an upcoming 'out of lock' situation.
-
You're not using the M8T sawtooth correction, right? (Since Lars' GPSDO doesn't utilize it.)
Previously you posted that you use the "UBX-CFG-NAV5" message - the implication seems to me to be that that message automatically sets the elevation mask in some way. Usually that wouldn't leave you with only a few satellites but if more than half of the sky was already blocked, sure, I could see you ending up with only a few.
The Skytraq/Navspark units are significantly more sensitive than the Ublox GPSs. maybe in your situation you would do better with one of them. They are so sensitive that for me, they work indoors without needing to be near a window at all.
I realise this is just over four months late but I felt impelled to give that statement about sensitivity some context. I've already read the whole of this thread two or three weeks earlier and was reading it again to refresh my memory since it's been so revealing a discussion on the subject of DIYing a GPSDO. There are still several points I only have a vague grasp on but I'm hoping to learn more by osmosis.
About two months back, I got a sudden and desperate urge to create an accurate 10MHz reference to substitute for the currently un-receivable WWV broadcasts I'd previously used nearly three decades ago as a calibration source so landed up buying a cheap u_Blox NEO M8N based Arduino/Rpi module which I could use immediately to provide a 10MHz calibration signal. As a substitute for the WWV 10MHz broadcasts, it's a vast improvement in spite of the jitter from dividing a 48MHz TCXO down to 10MHz (the least of the issues with disciplining an XO) and the varying ticks as it adjusts the PPS to stay synchronised to GPS (UTC) time by skipping/adding one full 20.8333ns clock period.
Such a polluted 10MHz signal whilst unusable as an external oscillator reference for comms and test gear, more than adequately serves as a calibration reference by which to trim internal clock oscillators. In my naivety, I'd assumed that the 48MHz TCXO in the u-blox module was simply being continually adjusted to hold it exactly on frequency, only to eventually figure out the horrible truth of the matter by careful comparison with a cheap AWG driven by a 0.1ppm TCXO that could keep the drift down to one or two ppb per half hour or so (stable enough to observe what was actually happening to the PPS when programmed to a jitter free 8MHz), using the signal generator to trigger the 'scope to reveal the jumps in phase of the 8MHz PPS signal.
Such corrective jumps can be heard as individual pulses on an HF radio tuned to the fundamental in NBFM mode and also on the third harmonic at 24MHz where these pulses are then three times the amplitude. Setting the PPS to 100KHz and listening to the 99th harmonic seems to produce a click amplitude similar to the 8MHz PPS signal as one might expect. However, the level of the click modulation disappears into the noise when listening to the 100KHz PPS frequency itself.
Prior to that discovery, I'd had high hopes of being able to clean up the PPS signal using a 3N502 clock multiplier chip to multiply the 4MHz PPS to a nice clean, jitter free 10MHz. However, that random dropping/adding of a clock pulse to correct in a method that parodies the "Leap Second" UTC correction mechanism every 5th of a second to every ten seconds or longer, rather put paid to that scheme. The result being that I do now see the point of all this extra complexity of an add on VCOCXO with startling clarity. :-[ The truth of the matter is that the starting point of any GPSDO should be the VCOCXO with the GPS module and associated paraphernalia as the "After market add-on".
Anyhow, that explains my interest in this thread but to get back to the observations made regarding GPS receiver sensitivity, I feel I should add my own observations just to provide the wider context. Whilst the M8N may not have been an optimum choice for a GPSDO project, it does appear to compare well against the old and once well regarded Navman Jupiter T's 10KHz jitter performance (as best as I can make out from the data sheet at any rate).
That 20.8333ns jitter will always be present regardless of whatever frequency the PPS line has been programmed to emit. The benefit of choosing a lower frequency is that this jitter represents a much smaller phase modulation (75 milli degrees at 10KHz versus 75 degrees at 10MHz). Whether this is any help towards reducing the effect of this "Leap Cycle" correction on the final PLL control signal, I'm not at all sure. TBH, any benefit is most likely simply going to be down to the longer time constant required with such a large division ratio in the PLL (the resulting 7.5 microdegree phase shifts on the 1Hz PPS seem to be just as big a problem). In short, it seems to me that it's this 20.8333ns random jitter that mandates long time constants in the PLL control driving the Vfc pin of the VCOCXO to filter out the effect of such phase jumps on the VCOCXO's output.
All that aside, whilst I was discovering the reason for the module's attached patch antenna proving to be a mere ornamental adornment[1], I discovered that, after the patch-ectomy (and removal of the microscopic LNA chip), the module could still retain lock on half a dozen or more satellites for several minutes after disconnecting the external active antenna (or the original patch antenna I'd now re-purposed with a 15cm flylead for use as a plug in passive test antenna)
Quite frankly, the module didn't need the help of a LNA chip to use the attached patch antenna. It seemed to manage remarkably well from what it could pick up on the 18mm's worth of strip-line between the SMA socket and the RF in pin whilst sat on my work bench some 16 feet away from the window. I suspect it might be just sensitive enough to acquire satellite lock given clear unobstructed sight of the sky but since it's raining right now, that experiment will have to wait a while.
The rain abated and I connected it up to a usb battery bank, after programming it to display a 5Hz 25% pulse to show the unlocked state with a 100KHz 50% for the locked state, and took it outside to get an unobstructed sky view. It did re-acquire enough satellites to get a lock after losing lock in the transition from 1st floor 'office'/'workshop' into the fresh air of the outside world.
After losing lock for several minutes whilst in the back kitchen, I was able to re-acquire lock each time I took it back outside, confirming that it could reliably receive satellites sans antenna connection without the use of a boost from an external antenna to get it to lock onto the signals as appears to be the case when indoors. Such are the vagaries of the SDR technology employed to detect such weak satellite signals that it should need such a strong hint of the signals it should remain locked onto in this case.
I'd previously observed it maintaining lock after disconnecting the antenna for ten minutes and longer before finally losing the signals completely, never to show even a hint ever again, or at least for maybe half an hour or more for even so much as a fleeting glimmer of signal. I had a sneaking suspicion that it was so close to the edge that direct sky exposure might well prove sufficient to allow it to acquire the signals without an antenna connection so it was rather gratifying to see such a positive result. :)
[1] This failure of the built in patch antenna, which by all accounts (and despite its less than ideal location on the backside of the module) should have produced workable signals, remained a mystery for several weeks before I finally discovered that it was merely held in place by a single solder connection and an adhesive pad, allowing me to remove it undamaged and with only minor damage to the through plated hole on the board used for the feed pin connection which will never ever be used ever again.
Lifting the patch antenna had finally revealed the true cause of its failure to provide anything other than fleeting signals, namely, several signal carrying traces within the ground-plane the antenna had been sat on. Little wonder it had totally failed to produce any useful signals. I can only suppose that this had once worked with previous versions of these modules with ground-planes devoid of any such signal traces and the manufacturer had simply overlooked this change and through inertia carried on fitting an antenna that was now doomed to certain failure by being grossly overloaded with RFI from those circuit traces.
Manufacturers can be such idiots at times. In this case, the antenna (and the LNA chip) had become a complete waste of BOMs as well as a source of frustration to the end user, many of whom would be making RMA applications. Others, like myself who were planning on using an external active antenna anyway, would save themselves (and the vendor) the trouble of RMAing the module, especially after discovering that a 3/4 wave 14cm piece of wire plugged into the SMA socket would serve as an effective substitute for a patch antenna despite the presence of the LNA attached halfway down the strip-line connecting the socket to the RF In pin of the u-blox module burdening the external antenna socket with an unwanted shunt impedance.
Removal of the microscopic LNA chip improved the performance of that 3/4 wave antenna. Strapping the patch antenna directly to the RF in line after the LNA-ectomy via a 4mm wire link failed to produce any signals but, after the patch antenna had been recovered from the board and a short co-ax fly lead soldered onto it to allow it to be reconnected via the antenna socket, it was able to give noticeably stronger signals than even the makeshift 3/4 wave antenna had given.
It may have been a useless adornment as supplied but, successfully divorced from the module, that patch antenna has now become a rather handy passive test antenna.
JBG
-
I have built an Arduino-based GPSDO with hardware and software based on Lars's design and have been been very pleased with the results, but I lack the equipment needed to properly characterize its performance. Following some discussion on the Time-nuts list, Bert Kehren offered to test it using his setup, which uses a cesium standard as its reference. It is currently warming up in his lab and he will be starting a 24-hour test run tomorrow. Here is Bert's initial report and some photos, results to follow.
-----
Recently Lars GPSDO came up on time nuts. I was working with Lars but we focused on other subjects. Never got around to test one. So when Jim Harman mentioned it I contacted him off list and offered to test his unit. He send me a picture of his unit. Oh boy but a promises is a promises. Encouraged him to stabilize it for shipping. Got it in the mail today. See attached picture. Had it up and running in 5 minutes. 5 minutes later 1 E -10. 10 minutes later 3 E-11. After an hour up and down in the E-12 range like all the other ones.
Will let it stabilize for 48 hours and do a 24 hour plot like we have done on all our other GPSDO's to better understand frequency over time due to ionosphere. Mainly due to the delay of ublox F9.
Jim can go in detail about his work with Lars
Bert
------
The first photo shows the unit in its original cardboard box, the second as currently packaged in a sturdier plastic box, and the third is Bert's test setup, showing a frequency error of 1E-12.
-
@jimharman Very interesting and promising results. Do I see a 12bit MCP4725 I2C DAC ?
In other words, did you rewrite the code to use that DAC?
-
Yes, switching to the MCP4725 is one of the changes I made. I wanted to avoid the original design's sensitivity to the 5V supply voltage. My OCXO has a 4V reference output and I use that to power the DAC. I use a resistor network between the DAC and the VFC pin of the OCXO to shift the DC level and reduce the control range, effectively increasing the 12 bit resolution of the DAC. A change I am contemplating is to switch to a AD5680 18 bit DAC.
A schematic is attached. Recent changes, not reflected in this schematic, are a circuit to linearize the diode-R-C integrator and also output buffers for the 10 MHz and 1 pps.
Earlier comments in this thread have indicated that people are having trouble with DC offset at the A/D. Having a short, low impedance ground system is essential.
Also I found that the fast risetime of the 5 MHz input to the processor can cause a lot of ground bounce. Adding the 100 ohm resistor in series with that line (R2 in the schematic) was a big help in cleaning up the ground noise.
-
I remember having read in this thread somwehere that somebody else mentioned having issues
with the 5 MHz signal and solved it with a pullup (or pulldown) resistor.
I placed the resistor ('R2') and see if the contraption behaves different. Thanks for the hint.
-
The R1=470ohm in above schematics is rather large for 10MHz, I would go with 50-100ohm as well.
-
I agree the 470 on the 10 MHz is big. The reason I chose that value is that the OCXO and the rest of the circuitry are on separate 5V supplies and there is a possibility that the OCXO might be powered and the rest of the system not. The 470 prevents drawing excessive current from the OCXO in this situation. It might be unnecessary, but the circuit works with it in place and better safe than sorry.
Performance especially temperature sensitivity might be a little better with a smaller resistor.
-
This thread is alive again. My GPSDO is locked for almost three months with a TC =600. I compare it with a Ublox set to output 10 MHz and there's a tiny drift left and right between the two outputs but never one full period, as it is expected from a PLL. I'm in process of designing a proper pcb that:
* Has a Ublox Neo-M8T GNSS timing module
* Can accept multiple OCXO types, sine, square, 5V, 12V
* Can accept PPS from an external GNSS
* Can use the PWM DAC or I2C DAC AD5693 with integrated voltage reference
* Has an active and passive offset and gain control circuit
* Has an integrated distribution amplifier with probably 4x10MHz outputs
Would be nice to have a jitter free PPS output, I'm still thinking how to do that, probably divide it from the 1MHz ot 5MHz output and synchronize it to the mid point of the GNSS PPS.
I experimented a bit with AD5693 DAC and it seems to be very good.
I'm not convinced that 18bits DAC would be necessary, reducing the DAC range to use most of the 16bit swing should be enough.
The project goes slow as I'm pretty busy but I'm more than half way through with the schematic.
Suggestions are welcomed.
-
This thread is alive again. My GPSDO is locked for almost three months with a TC =600. I compare it with a Ublox set to output 10 MHz and there's a tiny drift left and right between the two outputs but never one full period, as it is expected from a PLL.
The 10MHz of Neo7 is broken, as discussed many times. The only "clean" output is with frequencies where f=48MHz/N, N is an integer.
-
This thread is alive again. My GPSDO is locked for almost three months with a TC =600. I compare it with a Ublox set to output 10 MHz and there's a tiny drift left and right between the two outputs but never one full period, as it is expected from a PLL.
The 10MHz of Neo7 is broken, as discussed many times. The only "clean" output is with frequencies where f=48MHz/N, N is an integer.
I know that but broken or not, it is still 10MHz. Take a look.
-
This thread is alive again. My GPSDO is locked for almost three months with a TC =600. I compare it with a Ublox set to output 10 MHz and there's a tiny drift left and right between the two outputs but never one full period, as it is expected from a PLL.
The 10MHz of Neo7 is broken, as discussed many times. The only "clean" output is with frequencies where f=48MHz/N, N is an integer.
I know that but broken or not, it is still 10MHz. Take a look.
It turns out that the jitter you see when dividing the 48MHz TCXO clock of a NEO M8x module down to 10MHz is simply the consequence of using a non-integer divisor and is inconsequential compared to the insurmountable issue of the "leap cycles" correction system used to keep the PPS synchronised to GPS or UTC time (a parody of the leap seconds corrections to maintain UTC). That jitter is the least of your problems when it comes to disciplining a VCOCXO with a GPS module.
The NEO M8N can be programmed to output jitter free waveforms at 12, 8, 6, 3, 2, 1 MHz and successively lower frequencies by powers of two until you hit the limit at 15,625Hz (you can only program frequencies to the nearest whole number, fractions aren't allowed - the next lower frequency of 7,812.5Hz, therefore cannot be programmed).
If you program a frequency of 16MHz (48/3) and trigger your 'scope from a reasonably stable 16 or 8 MHz signal, you get to see the ratio of the displayed PPS waveform alternate between 67% and 33% duty cycle each time a "leap cycle" correction is applied. This also occurs with divisors of 5, 7, 9, 11 (all odd divisor values in fact).
If you have an HF reciever capable of monitoring these frequencies in NBFM mode, including odd harmonics, you can hear these 'leap cycle' corrections as regularish ticks[1], provided you choose a jitter free divisor. Monitoring the 10MHz or its third harmonic results in a background cacophony of chirps and beeps which seems to obscure this 'tick' noise. Monitoring the 8MHz will reveal this phase modulation which is (predictably) amplified when listening to the third harmonic by a factor of three.
Since it's only the relatively long time constants used in the Vfc output from the PLL which filter these phase discontinuities out, the minor 'jitter noise' in the 10MHz PPS signal becomes of no consequence in the face of this much larger issue. The raw 10MHz on the PPS line, whilst perfectly fine as an alternative to the 10MHz WWV time and frequency standard broadcast for calibrating oscillators, is totally unusable as an external clock reference for radio and test gear, hence the need to use a separate XO, preferably a voltage tunable OCXO as the external 10MHz reference for such equipment.
The GPS module is merely the after-market add-on that disciplines this high quality XO to keep it locked to an atomic clock reference, albeit with very slow phase variations from the primary atomic clock reference that disciplines the Caesium atomic clocks in the GPS and GLONAS satellites themselves.
In my naivety, I thought I could get round the 10MHz jitter issue by simply choosing a 4MHz jitter free PPS I could multiply back up to 10MHz with an ultra low jitter 3N502 clock multiplier chip until I finally recognised the rather cack handed method used to to keep the PPS synchronised to GPS/UTC by skipping or adding a full 20.8333ns cycle of the 48MHz TCXO rather than, as I'd assumed, by phase locking that 48MHz clock frequency reference.
In hindsight, this "'leap cycle' adjustment is simply a limit of the GPS methodology for keeping the PPS synchronised to GPS time sufficient to the basic navigation requirements (the 20.8333ns jumps in phase only account for a positional variation of some 20 feet of error which can be integrated over several seconds to reduce this error to a matter of just 2 or 3 metres in the final positional computations). Producing a low phase noise frequency reference was never in the original remit of the Navstar requirements other than as perhaps an optional external add-on disciplined oscillator. Optional because such additional complexity is surplus to the basic navigation function of the original Navstar (GPS) system.
In short, stop getting all fixated on this 10MHz 'jitter issue', the 'leap cycle' corrections are the real problem. Solve that one and the 'jitter issue' simply vanishes into the noise. :)
[1] The rate at which these 'ticks' occur, depends on how close to the exact 48MHz frequency the TCXO has managed to get (or not) and I have experienced tick rates varying from 4 or 5 ticks a second to ticks occurring once every 5 to 10 seconds and sometimes even longer.
JBG
-
The raw 10MHz on the PPS line, whilst perfectly fine as an alternative to the 10MHz WWV time and frequency standard broadcast for calibrating oscillators, is totally unusable as an external clock reference for radio and test gear, hence the need to use a separate XO, preferably a voltage tunable OCXO as the external 10MHz reference for such equipment.
Well, I can tell you that it was way better that the original TCXO installed in my HP 5385A frequency counter, before I had the GPSDO.
It may even work in the HP 8594E Spectrum Analyzer as it feeds a 600MHz PLL. So as long as that PLL locks on the external jittery 10MHz reference, and assuming that it has a reasonably long TC, it should convert into a clean 600MHz. I'll do a test one day.
My point is that it depending on the application, the jitterey 10MHz that comes out of the Ublox module may be way better, long term, than a free running OCXO, XTAL, TCXO....
-
The raw 10MHz on the PPS line, whilst perfectly fine as an alternative to the 10MHz WWV time and frequency standard broadcast for calibrating oscillators, is totally unusable as an external clock reference for radio and test gear, hence the need to use a separate XO, preferably a voltage tunable OCXO as the external 10MHz reference for such equipment.
Well, I can tell you that it was way better that the original TCXO installed in my HP 5385A frequency counter, before I had the GPSDO.
It may even work in the HP 8594E Spectrum Analyzer as it feeds a 600MHz PLL. So as long as that PLL locks on the external jittery 10MHz reference, and assuming that it has a reasonably long TC, it should convert into a clean 600MHz. I'll do a test one day.
My point is that it depending on the application, the jitterey 10MHz that comes out of the Ublox module may be way better, long term, than a free running OCXO, XTAL, TCXO....
You're unlikely to have that last statement refuted here (qualified perhaps but not refuted). :)
I'd qualify it by saying that it's not a matter of "may" so much as "will definitively" (be way better that is!). Long term, the PPS is never going to be adrift from GPS (and, leap seconds allowing, UTC) by more than 50ns for the foreseeable future, barring any outages of service. Indeed, even in the event of a disruption, the PPS will be resynchronised automatically once the service is restored, including the actual time of any timepieces relying on the service since all the time data to reset any clock is part of the navigation data payload.
Given a stable enough VCOCXO and an intelligent micro-controller algorithm which tracks the Vfc trend to provide the best possible hold over performance from the VCOCXO, the 'free running' OCXO may well be able to stay in phase over a several hours long outage successfully masking such outage effects on the reference frequency output from the GPSDO.
As for my own requirements, I'd be quite happy if my own GPSDO (when I finally get hold of a suitable VCOCXO and other bits at the end of this month to build one) can manage such a trick over rather more modest time scales measured in minutes. :)
There'll be time enough to develop such hours long hold over performance afterwards once I've got a basic GPSDO good enough for use as an external 10MHz clock reference to drive my cheap FY6600 AWG and anything else that can utilise or be modified to utilise an external clock reference.
JBG
-
Would be nice to have a jitter free PPS output, I'm still thinking how to do that, probably divide it from the 1MHz ot 5MHz output and synchronize it to the mid point of the GNSS PPS.
Take it from the 10Mhz and use a
PicDiv
or
AVR
https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/msg2042386/#msg2042386 (https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/msg2042386/#msg2042386)
/Bingo
-
Right but it has to be synchronized with the GPS PPS to have a real PPS.
-
Take it from the 10Mhz and use a
PicDiv
or
AVR
No need for a PICDIV since the Lars GPSDO is already dividing the 10 MHz down to 1 Hz.
-
Take it from the 10Mhz and use a
PicDiv
or
AVR
No need for a PICDIV since the Lars GPSDO is already dividing the 10 MHz down to 1 Hz.
Where does it do that? Am I missing something?
-
Where does it do that? Am I missing something?
Ooops, I think that was in a modified version that I saw a schematic for... |O
-
Hi,
I'm having some troubles with my Lars GPSDO. After more than 7 months (or so) when it stayed locked, it started loosing lock every few days. I caught some events that seem to be satellite related, unless the OCXO shifts phase all of a sudden. Please take a look. What do you think?
First I thought is power loss but it is connected to a UPS and it didn't loose a PPS for almost 9 months.
-
External GPS antenna is dying?
-
External GPS antenna is dying?
I don't have an external antenna, it is at the window. It didn't give me any troubles for 7 months.
-
It looks like you briefly lost gps lock, then are settled back into lock 12 hours later with a dac value ~30 points higher. How much does your dac vary in a day? I would plot dac variances over a long period to look for a trend.
-
Just found this nice PCB
https://github.com/Qw3rtzuiop/Lars-GPSDO-PCB
The pict(s) are for the rev1 pcb , not the rev2.
I just ordered a few on JLCPCB
/Bingo
-
Hello bingo600,
im responsible for the crappy pcb design.
I use the rev. 2 happily but im not a timenut and cannot confirm that this design is perfect.
The rev. 1 was missing an output buffer. Even plugging in some cables changed the output signal that the GPSDO unlocks.
Adding an output buffer fixed that problem.
I still have 8 unpopulated rev 2 pcbs if anyone is interested (price: shipping costs from germany).
-
@Qw3rtzuiop
PM sent
-
@Qw3rtzuiop
PM sent yesterday
-
I recieved all of your PMs.
When i looked up the prices I noticed that the German Post dont allow private customers to send goods via international mail. Since 2019 only paper is allowed :palm:
They are allowed to open and control the content. Instead I should use DHL (5-10€).
Im sorry but if youre outside Germany it is cheaper to buy them at JLCPCB/Elecrow/OshPark/Aisler.
-
Aron,
It would be nonsense to produce another pieces, when you have ready & spare ones :palm:
For me, that cost you mentioned is perfectly OK, just send 2 pcs in that package :-+
-
Agree with Jacon
2 pcs for me too :-+
-
It looks like you briefly lost gps lock, then are settled back into lock 12 hours later with a dac value ~30 points higher. How much does your dac vary in a day? I would plot dac variances over a long period to look for a trend.
Ok, I started monitoring the GPS. I think there's a flow in this design or in my implementation. Looks like my HC390 misses some pulses. I've attached a stripped down log of the GPS and one of the GPSDO. By my calculation the event happened around 0:58 UTC but around that time the GPS saw a healthy 11-12 GPS satellites and 9-10 Glonass. At no point around that time the lock was lost. The jump seems to be of about 500ns. I've also attached two more pictures with captures of lock loss, one of them again with a jump of about 500ns. Is like it looses half of the 1MHz pulse, like there's a 180 shift in phase at the 1MHz output.
In the gps.csv, the time is in GGA column 2 and the number of satellites in GSV column 4.
Do you have another idea?
This started happening randomly after 8 - 9 months with no issues.
-
Try to heat-up or cool-down the HC390..
-
I started wondering what it would look like if any one of the four edges were missed? It would be interesting to see the signals on a scope when this phase jump happens, perhaps by using a mask test and halt on fail. I wonder if EMI/RFI could be involved or whether some buffering/filtering could help.
-
Hi all,
I have build the GPSDO following the original schematic on perf board, although made some small changes. I'm using the Bliley NV47A1282. My version seems to have a finicky output because the slightest loading distorts the sine wave. After trying a couple of things I resorted to using another HCT4046 to create a square wave with an almost 50% duty cycle. I also used 100R in series between the HC390 and the Arduino Nano and another 100R in series with the HC390 10MHz input.
To create a mid-point for the DAC range at the mid-point of the Bliley frequency range, I used the 1PPS signal of my (genuine) NEO-M8T and the free running Bliley output on my scope, and adjusted it with a trimmer to get a steady, non moving drift, creating a manual lock. I then replaced the trimmer setting with a resistor in my case of 200K. The total DAC range now has a adjustment range of 7.9Hz. I verified this all with my counter.
I have noticed two problems.
The first problem is that using H1 to determine the gain does not work for me. The ns results drift linearly way out of range. Same with h65353. Setting the DAC value at mid-point creates a repeating but steady range of numbers, as expected. To calculate the gain, I used the delta of the Bliley in Hz, which is 7.9 Hz, or 790ppB resulting in a gain of 83, if my math is correct. :-//
The second problem is that with the standard lowest offset of 200, I can't get a lock, and if so, only for very brief periods. The ns value is too far out of range, beyond -100. I could cheat by set a higher lockPPSlimit in the code, but then a Lock is reported while there is too much jitter.
I modified the code to allow me to set the offset as low as 10. At an offset of 100, I got a lock, but still with too much drift. When I changed the gain from 83 to 830, the resulting lock has been running for 24 hrs without a glitch and with minimal jitter, I think. I have steadily increased the damping and I'm now running at a damping level of 10. I'm not sure if the damping counteracts the higher gain that I needed to set, but even at a damping factor of 0.5, everything seemed to work fine. See the attached scope capture of the 5MHz signal and the signal at the anode of the Schottkey Diode.
Can anybody enlighten me on these two issues?
Tks, Paul
-
Miti,
I don't think your problem is related to the GPS. The HC390 is not connected to it, only to the oscillator. The missing pulse must be found in that chain.
While monitoring my system for hours, while attached to a scope, I also noticed missing pulses or strangely distorted ones.
They can be observed or found easier if you can use the persistence setting of your scope, as I do. I doubt it is the HC390.
Below you can see such a strange behavior. Note that the small wiggle on the 5MHz caused a serious glitch or missing pulse on the anode side of the diode.
It probably caused the irregular entries in the trace.
I use a Bliley NV47A, but have two other types on order because I don't really trust mine yet, also because it has a very weak output driving capability.
Good hunting,
Paul
-
..I then replaced the trimmer setting with a resistor in my case of 200K. The total DAC range now has a adjustment range of 7.9Hz. I verified this all with my counter.
How did you wire that 200k resistor, plz?
-
Hi Imo,
The 200K resistor is between the VC of the Bliley and ground.
-
See the attached scope capture of the 5MHz signal and the signal at the anode of the Schottkey Diode.
Where the 5MHz signal is coming from? It should be 1MHz, afaik.
1MHz signal is 1us period.
Lars assumed the 1PPS rising edge sets the RS FFlop (aka phase comparator III) high, the RC starts charging via the schottky.
The upcoming edge of the "1us" pulse from HC390 then resets the RSFF to low, the RC stops charging and you get a voltage at the 1nF capacitor. The voltage is measured with the ADC afterwards.
The RC is set such the midpoint of the 1us period (500ns) is in middle of the 1.1V range of the atmega's ADC, that is about 0.5V.
Any phase diff between the 1PPS edge and the "1us" edge will create a different voltage, while 500ns diff is 0.5V.
The control loop via the MCU/DAC then sets the OCXO's freq such the phase difference between the 1PPS edge and "1us" edge is always as close as possible to 500ns (that means 0.5V at the ADC's input).
One problem I see is the simple RS FFlop. It is level sensitive, not edge sensitive. The phase comparator II is edge sensitive,
its output (pin1) inverted could be a better solution, imho.
With the current phase comparator III you may use a 74HC00 instead. My guts feeling is with such a simple RS FFlop the phase may revert suddenly and instead of, say, +15ns phase diff it will show -485ns next step (that is 500ns difference, the half of the 1us period).
Needs to be analysed somehow by experts, imho..
-
Hi all,
I have build the GPSDO following the original schematic on perf board, although made some small changes. I'm using the Bliley NV47A1282. My version seems to have a finicky output because the slightest loading distorts the sine wave. After trying a couple of things I resorted to using another HCT4046 to create a square wave with an almost 50% duty cycle. I also used 100R in series between the HC390 and the Arduino Nano and another 100R in series with the HC390 10MHz input.
To create a mid-point for the DAC range at the mid-point of the Bliley frequency range, I used the 1PPS signal of my (genuine) NEO-M8T and the free running Bliley output on my scope, and adjusted it with a trimmer to get a steady, non moving drift, creating a manual lock. I then replaced the trimmer setting with a resistor in my case of 200K. The total DAC range now has a adjustment range of 7.9Hz. I verified this all with my counter.
I have noticed two problems.
The first problem is that using H1 to determine the gain does not work for me. The ns results drift linearly way out of range. Same with h65353. Setting the DAC value at mid-point creates a repeating but steady range of numbers, as expected. To calculate the gain, I used the delta of the Bliley in Hz, which is 7.9 Hz, or 790ppB resulting in a gain of 83, if my math is correct. :-//
The second problem is that with the standard lowest offset of 200, I can't get a lock, and if so, only for very brief periods. The ns value is too far out of range, beyond -100. I could cheat by set a higher lockPPSlimit in the code, but then a Lock is reported while there is too much jitter.
I modified the code to allow me to set the offset as low as 10. At an offset of 100, I got a lock, but still with too much drift. When I changed the gain from 83 to 830, the resulting lock has been running for 24 hrs without a glitch and with minimal jitter, I think. I have steadily increased the damping and I'm now running at a damping level of 10. I'm not sure if the damping counteracts the higher gain that I needed to set, but even at a damping factor of 0.5, everything seemed to work fine. See the attached scope capture of the 5MHz signal and the signal at the anode of the Schottkey Diode.
Can anybody enlighten me on these two issues?
Tks, Paul
Yes, I have the same issue with the sine wave. That's why I did what you did but the output was still distorted. So in the end I added a resistor divider, something similar to Brooks Shera but different resistors, I don't remember the exact values, see attached, and I think that's the weak point that misses some pulses.
I also saw the other issue with H1, H65535, TIC_Offset. Don't bother changing the code. Measure your voltage at the VC pin of the OCXO with H1 and H65535. and scope the A0 pin. I bet it doesn't stay at 0V in between pulses. You need shorter and thicker ground wires. Here are the parameters that I'm using now.
EEPROM content:
restarts = 18
totalTime3h = 3159
temperature_Sensor_Type = 11
ID_Number = 0
TICmin = 120
TICmax = 1012
x2 = 100
TIC_Offset = 500
filterDiv = 2
warmUpTime = 300
damping = 300
tempRef = 417
tempCoeff = 200
dacValueOut = 22679
gain = 122
timeConst = 500
k = 111
Edit: See some screenshots in Reply #49.
-
imo,
Thanks for the explanation.
I should point out that my circuit works well, even with a TC of 500 over 24 hours. I have not gone beyond that yet.
I understand the working of the hardware, and verified the working of it, but still have problems with the presented results from the software though.
For my scope screenshot, I simply used the 5Mhz signal (output of the HC390 going to D5 of the Nano) as a reference for the diff_ns signal at the anode of the diode. I could have used the 10Mhz, or the 1MHz of course, to see the drift and jitter. I don't think that makes a difference?
After realizing :palm: that I should use the diff_ns values for the gain calculation, and not the ns values, I was able to get a decent gain value. I simply used Excel to let it calculate the average of the diff_ns values out of about two pages of the report. H1 produced +240 and H65K -166, resulting in a gain of 161.
Why this is significantly different from using the "real" frequency values for H1 & H65K of the OCXO itself (gain is 83) is one of the puzzles I have.
I appreciate the time and effort you guys put in to help others! :clap:
Paul
-
Miti,
Thank you for the elaborate answers. As with imo, I applaud you for your help in this forum! :clap:
I'm still struggling to understand what the software tells me, because in essence, my hardware seems to work very well.
Attached is a screen dump of both sides of the diode. As you can see, the ground level for the ADC has no issues. I took several precautions. As you know, the pulse height is compromised due to the X10 probe loading. The signal is a bit noisy probably because of my rather long probe ground lead and even more the fact that I use proto-board without a ground plane.
BTW, just for fun & learning, I also measured at what part of the pulse the ADC reads it, by adding a port output to the code that creates a pulse around that operation. The rising edge is pretty linear, but the discharge is not, and here is where the ADC measurement takes place. Does not matter much I think.
What I'm still struggling with is the relationship of what I'm seeing on the scope in terms of the width of the delta pulse signal (anode of diode), and what gets reported by the code.
If I understand the explanation from Lars, the filtX10 number includes the offset. If I take that number and subtract the offset, I get very close to what I see on the scope.
However, I still don't quite get the diff_ns reports in relation to filtX10 and also the ns numbers. They don't seem to jive with each other although Lars went through great pains in the code to get everything converted to ns. Maybe it's the damping? Mine is currently at 3 now. I need to play with that setting more.
I will certainly look at your settings and try them, and see if there are any glaring differences.
Tks,
Paul
-
The Bliley NV47A1282 where I already suspected a flaky output amplifier, just died on me. No signal out anymore. |O
These used Blileys have a long but very sad history with me now. The first one that arrived was DOA, never had an output. A replacement never arrived, and the third one died after a few weeks. >:(
With 4-6 weeks shipping time for each one, I've given up. Be aware...
-
The Bliley NV47A1282 where I already suspected a flaky output amplifier, just died on me. No signal out anymore. |O
These used Blileys have a long but very sad history with me now. The first one that arrived was DOA, never had an output. A replacement never arrived, and the third one died after a few weeks. >:(
With 4-6 weeks shipping time for each one, I've given up. Be aware...
For what its worth: I have a (used and aged) Bliley running for almost two years now with no problems.....
Just my two cents,
Un saludo,
Leo
-
BTW, just for fun & learning, I also measured at what part of the pulse the ADC reads it, by adding a port output to the code that creates a pulse around that operation. The rising edge is pretty linear, but the discharge is not, and here is where the ADC measurement takes place. Does not matter much I think.
Thanks for your presentations. Does the ADC sample at the shown pulse falling edge? I'd expect the discharge to follow a classic decay curve.
I was never able to get mine to remain locked much above TC 120 and only a few days around TC 240 ( I always needed a better GPS though). It's been a while since I had it on so getting inspired to connect it back up and remember what I was doing.
-
Hi metrologist (and others),
Here are the results of my learning experience with the ADC measurement of the TIC signal.
In the scope picture ending with 3514, on the bottom trace (in yellow) you can see the TIC pulse measured on the anode of the Schottkey diode, coming from the HC4046. The blue trace is measured on the A0 ADC input from the Arduino nano. The voltage is quickly rising until the end of the pulse and then starts to decay again. The pulse width can be anywhere between a few ns up to the maximum of 1us. The voltage at the ADC input is therefore a reflection of the pulse width. Note that due to the loading of my 10x (10Meg) probe, the 10Mohm resistor (R2) has the probe impedance of 10Mohm in parallel so the 10M becomes approx. 5Mohm, resulting in halving the discharge rate of C1, the 1nF capacitor.
In the text of Lars's document, he mentions that "As the 1PPS gives an interrupt to the processor the ADC will measure the voltage almost immediately after the charge is ended." While true in essence, the reality is that the Arduino is not that quick.
In the picture ending with 4342, the yellow trace shows the TIC signal again from the anode side of the diode. The blue trace shows the period of the ADC measurement. I made this possible by adding "probes" to the ISR code:
ISR (TIMER1_CAPT_vect)
{
timer1CounterValue = ICR1; // read the captured timer1 200ns counter value
digitalWrite(Trigger,1); // Trigger high
TIC_Value = analogRead(A0); // ns value
digitalWrite(Trigger,0); // Trigger low
PPS_ReadFlag = true;
}
Two things are important to know. The Arduino has a bit of a complex hardware interrupt system. The final entry into the ISR is not very stable in terms of timing. Second, the ADC read takes-up a lot of processor time. The blue trace shows the time of this cycle, plus the time of the output port changes, they also take-up some processor time.
I don't know where in this period exactly the signal is sampled. (You could find out and measure this by using a precise ramp and compare the ADC reported voltage alongside the ramp voltage)
The last picture (1344) shows both signals again but now in more detail so you can see that the sampling takes place quite some time into the discharge cycle of C1. Note that I had to use a scope probe, but even so, "immediately", is probably not what you expected.
Does it matter for the PI loop?
Not really, as long as everything is relative to each other.
Another take-away is that some designs went through extra hardware to create a constant current source to have a better charging linearity. This shows that this is a rather futile action. Time and effort would be better spent on the discharge cycle.
One idea that I have would be to eliminate the 10Mohm discharge resistor, and use a port from the Arduino to take care of the discharge cycle. I have not tried this yet, but my plan would be to use a digital port and set that as an input. This is a very high impedance state. Just after the ADC has sampled the pulse, which should now stay much flatter because there is virtually no loading, only leakage. I would then change the port to output, drive it low to discharge the capacitor and then turn the port back into an input again. All within the ISR. I could not find any reliable information on how hi-Z the digital inputs really are, but if you don't use pull-ups, it should be many times higher than 10Mohm, maybe well into the 100Mohms.
Anybody care to comment or elaborate?
Tks, Paul
-
I'd say the actual shape of the discharge curve is not really an important factor, as long as it's a constant between measurements and the sampling point doesn't jitter too much. What you're interested in is not the actual measurement but the difference between the measurements, which represents the drift.
-
Hi thinkfat,
That’s what I was saying, I think.
There is however a jitter factor due to the fact that the Arduino has no “real” interrupt, and I don’t know how much that varies. I will try to see if I can measure that, and how much of a factor that really is, because that could potentially be a factor for the PI loop. Although nice to know, there’s little you can do about it with this processor architecture.
BTW, I’m not implying that there’s something wrong anywhere with Lars’s design, far from it, I ’m just exploring, learning and trying to explain.
MfG,
Paul
-
Hi thinkfat,
That’s what I was saying, I think.
There is however a jitter factor due to the fact that the Arduino has no “real” interrupt, and I don’t know how much that varies. I will try to see if I can measure that, and how much of a factor that really is, because that could potentially be a factor for the PI loop. Although nice to know, there’s little you can do about it with this processor architecture.
BTW, I’m not implying that there’s something wrong anywhere with Lars’s design, far from it, I ’m just exploring, learning and trying to explain.
MfG,
Paul
If the jitter has a Gauss distribution, it will be averaged out, so it's not really a factor. I'd be more concerned about temperature drift of the 1nF cap and the two resistors. That's a systematic error you'd need to actively compensate. A 10Meg resistor isn't a really practical value, you're getting into the range of the input resistance of the ADC there. But again, as long as it's an invariant between the measurements it's not a factor. Regarding the dimensioning - you need a sufficient discharge current, you need to bleed the storage capacitor sufficiently so that the next pulse can charge it up again.
So in other words, I do agree with your proposed change. Get rid of the impractical 10M resistor and instead use an I/O pin to drain the stored charge. You can put a resistor in series to limit the discharge current but it should be OK, I think. This way, you can probably achieve a less steep discharge curve which will help with the inevitable jitter of the sampling point. But temperature compensation is probably the more important measure to be taken.
-
When I thought of testing the system stability, I'd thought it would be good to use a more stable PPS, such as from a divided 10M OCXO or even from the same OCXO being tuned.
-
The -2mV/C TC of the diode is much higher than TC influence of the 3k9 resistor (say 50ppm) and the 1nF capacitor (Lars had recommended C0G/NP0 one afaik). Use the TDK one as Kleinstein and AlexN recommended here:
https://www.eevblog.com/forum/metrology/diy-high-resolution-multi-slope-converter/msg2763326/#msg2763326 (https://www.eevblog.com/forum/metrology/diy-high-resolution-multi-slope-converter/msg2763326/#msg2763326)
-
I was thinking about going for a PPS capacitor, like https://www.mouser.de/ProductDetail/667-ECH-U1H681GX5 (https://www.mouser.de/ProductDetail/667-ECH-U1H681GX5)
But there's no temperature coefficient for capacity or leakage specified... That puts me off a bit. I may go with the TDK C0G/NP0 instead.
-
@Dbldutch:
There is however a jitter factor due to the fact that the Arduino has no “real” interrupt
Just out of curiosity: Is this verdict based on the fact that there is no constant delay from receiving an interrupt request to actually start the ISR, because the current instruction is finished before the IRQ is acknowleged (and different instructions have different execution times)?
Or am I missing something else?
-
When I thought of testing the system stability, I'd thought it would be good to use a more stable PPS, such as from a divided 10M OCXO or even from the same OCXO being tuned.
I'm probably going to try using another GPSDO I own for testing. The 10MHz output should be reasonably stable and the 1PPS output would be locked to it, sounds like a good testbed.
-
I spent some time measuring the interrupt latency from the 1PPS signal together with the "probes" in the ISR. (see my post above)
It seems there is a source of jitter that does matter in the PI loop and the overall stability.
I have triggered the scope directly on the 1PPS pulse and acquired the ISR "probe" that signals the start of the ADC read cycle.
As you can see, there is no Gaussian distribution and the jitter is up to about 200ns. We have already seen that the discharge curve of the 1nF capacitor is not linear, so the resulting voltage, that drives the DA convertor and therefore the VC of the oscillator will show this too.
How much depends on the amount and effect of the software filtering.
To eliminate this source of jitter, we have to change the discharge method by the 10Mohm resistor, which is also a significant source of Johnson noise.
I will try to change the hardware and software now with my proposed solution and make some more measurements. Unfortunately, I don't have a FET probe, so the discharge effect of the x10 probing stays until I have found another way of probing C1. I have some ideas...
Stay tuned,
Paul
-
Well, here's a surprise...
I removed the 10Mohm resistor and made a connection to port D10 with a 1K SMD resistor to C1.
I made the changes in the ISR to force the voltage on C1 to ground right after the ADC statement and made a few measurements.
No dice. It turns out that the voltage on C1 is already at ground level by the time my contraption is activated.
I suspect that there is much more leakage (must be the ADC?) than anticipated.
I added the raw ADC value to the display logging to see the result with and without my x10 probe, nada, no major change.
I added a 1% mica capacitor of 1nF in parallel, no major improvement. You can't go much higher because the rise time will become too slow.
So even after disconnecting the port connection to C1, and no probing from my scope it still worked. Go figure. :-//
Below is the ISR period including my port manipulation which is activated at the very end of the pulse.
I still get a lock and everything seems to work well...
Can somebody please verify this in his or her circuit?
Tks,
Paul
-
So how much time does it take from end of charging the 1nF to actual ADC sample and hold (plus minus the 200ns jitter)??
PS: The leakage via the 1N57xx schottky could be 10nA, via the ADC pin's clamping diode say 5nA..
You may improve that by replacing the schottky by the BAV199 and put a jfet/mosfet opamp in front of the ADC. But the input clamping diodes at the opamp's input will still leak..
PPS: in 10us 137us it drops 10mV, it discharges to 1% in 18ms (with 500ns input pulse)
-
imo,
Have a look again at the screenshot in an earlier post with the number ending in 4342.
That has the "probes" surrounding the ADC read instruction.
The ADC conversion time is specified to take between 13-260us in the ATmega328P AVR datasheet.
Also the entry into the ISR and the departure take-up a lot of time as well.
I will work on that next, but before we start to speculate I would like to get clarification that what I'm seeing is the way it is, and not a :palm: pilot error from me.
Enjoy!
Paul
-
With 200kHz ADC clock the S/H is done 7.5us after the start of the conversion and ADC is completed in 67.5us.
Provided the ISR takes 1.5us, the S/H is done in 9us. The 1nF voltage drop I see in the simulation is something like 1.1mV in 9usecs..
-
With 200kHz ADC clock the S/H is done 7.5us after the start of the conversion and ADC is completed in 67.5us.
Provided the ISR takes 1.5us, the S/H is done in 9us. The 1nF voltage drop I see in the simulation is something like 1.1mV in 9usecs..
That should not be a huge problem, right? The ADC is 10bit resolution, I guess using the internal reference of 1.1V. 1 LSB = 1mV. The ADC is spec'd for +/- 2LSB absolute accuracy, so 1.1mV should still be in the noise. So, you would not loose TIC resolution there.
-
Your ADC noise would be much higher provided your wiring and decoupling is not perfect.
4LSB p-p is a good result already, imho.
Also the 1PPS is not jitter free.
-
You could poll the pin connected to the 1Mhz signal to start the ADC conversion, instead of using an interrupt. That should eliminate one source of jitter. Or, connect the comparator output before the diode to another pin and poll that for the falling edge.
-
When looking at the oscope picture 4342 above - the actual ADC starts around 8us after the falling edge at the anode, the S&H is done at around 21us, the ADC finishes after ~114us (it looks like the ADC clock is ~120kHz).
What is the issue - the voltage at 1nF drops to almost 35% of the voltage @10us(!) for 1us input pulse - picture 3514 (with 5Mohm resistor = 10Meg || 10meg_probe). At 21us it would be 15%.
Doublecheck whether your oscope probe is set to 10x (10Meg).
Doublecheck the values of 3k9, 1nF, 10Meg in your wiring.
It seems like your 10Meg resistor is 10k in reality (with 10k the simulation shows drop to 38% @10us).
PS:
with 10Meg in the simulation the voltage drops 2.5mV in 21usecs (990ns input pulse).
with 1Meg in the simulation the voltage drops 20mV in 21usecs (990ns input pulse).
-
I'm wondering if a dual-slope converter could be an alternative approach... Basically, you'd charge a capacitor with the pulse from the phase discriminator through a resistor, then discharge it through the same resistor and measure the time the voltage stays above a certain threshold... This should double the resolution against just counting out the length of the pulse, no?
Don't mind me, I'm just thinking aloud...
-
Another thought - you may put there the TDC7200 (~50ps resolution), no need to mess with analog, the arduino library is available..
http://www.ti.com/lit/ds/symlink/tdc7200.pdf (http://www.ti.com/lit/ds/symlink/tdc7200.pdf)
PS: the calibration clock for the 7200 could be the OCXO itself. You may measure the time between rising start and stop edges, thus you may remove the 4046 too.
So you would need the 7200, 74HCxxx divider such you get the time diff somewhere into the 7200's range, atmega328p, and the PWM DAC as it is today.
The time difference between the 1PPS rising edge and OCXO's edge (divided say to 0.5MHz = 2us period) could be set such the middle will be 1us and the regulation range will be +/- 500ns.
7200 will then return results in Mode 2 from 500ns to 1500ns (that is -500ns to +500ns diffs) with 55ps resolution, 28ps accuracy and 35ps standard dev (see DS).
Btw, 500ns with 55ps resolution is 9090 counts :)
With good pcb layout the standard dev could be close to 35ns, that is 200ps p-p noise, imho.
-
I have indeed seen that chip mentioned in another thread about GPSDOs and was looking at the datasheet.
If I'm not mistaken, there is a mode that measures the time between the start pulse and the next reference clock edge. That would be exactly the same input as in Lars' design, phase difference in the time domain, just fully digital and without the dependencies to leakage and temperature.
What I don't understand yet is if the start and stop pins can just be tied together to form a TIC. It's not entirely clear from the datasheet. I think the chip disables the start detector while waiting for the stop pulse, so that should be all good.
-
There is no need to wire the start and stop pins together. The start pin will be wired to, for example, 1PPS and the stop pin to the OCXO's 500kHz. There will be none 4046. 7200 will measure the "time between the rising edges of those two signals" - it returns the difference "stop_rising_edge-start_rising_edge". Thus the same as it is today with analog TIC.
The 7200's start and stop pins are both rising edge sensitive.
PS: the 7200 replaces 4046+schottky+3k9+1nF+10Meg+ADC. The ISR will read 7200 (via SPI interface), and returns a number between 500000 and 1500000 (for 500ns to 1500ns difference between the edges, where the "middle" is 1000ns). The returned numbers will be "noisy", of course (as it is today too).
The atmega's sw needs to be adjusted accordingly - the control loop should be trying to set the OCXO's EFC voltage such the by 7200 returned number will be as close as possible to (500000+1500000)/2 = 1us, that will be the "exact 10MHz".
Why 500ns to 1500ns difference result? Today's system works such the analog TIC measures the difference with the result ranging 0ns-1000ns where the middle is 500ns. That 500ns (the middle) creates aprox 0.5V at the 1nF capacitor - that is in the middle of the ADC range. Current sw is chasing the middle, of course.
You have to adjust that because 7200 needs to be operated in certain range. Mode 1 is 12ns to 500ns for the "edges differences", while the Mode 2 starts at 250ns up. So let us take the Mode 2 and position the edge's difference as I suggested above.
You may think on a different differences range, sure. The 7200 is much more flexible in that regard, as there are not such limits as with the analog TIC used today.
PPS: I would also suggest to migrate the Vcc to 3.3V. Atmega328b works fine at 3.3V/16MHz. The 7200 is 3.3V.
You have to amplify the PWM DAC's amplitude to something like 1..7V to fit various OCXO's anyway.
EDIT: corrected the expected values the TDC7200 arduino library returns..
-
Hi, thanks for all the valuable input. I'm not afraid to change the code, I'm going to use a different MCU anyway. Likely, STM32F030 in LQFP-32 or TSSOP-20 package, if I can fit all the interfaces. Currently, I'm looking at two serial ports, one debug, one to a GPS module, SPI for the TDC, maybe another I2C for an external DAC (if I can convince myself that it's better than a PWM DAC). That might not fit the small 20pin package.
-
Regarding the DAC - make yourself a calculation on the required DAC resolution.
Input is the OCXO's gain in Hz/Volt (for example 1.5Hz/V).
Do compare the DAC's EFC voltage step with the TIC resolution such it finetunes somehow.
PS: here you may see (very bottom picture) how the TDC7200 returns a measurement of 100ns time difference (x-axis is the sample number, y-axis the actual time interval in ps), all wired on a cheapo solderless breadboard :)
The standard deviation was ~150ps, 4x worse than with proper design.
Do not do it that way, use by TI recommended layout with good start/stop signal impedance matching instead..
https://www.eevblog.com/forum/metrology/how-to-test-a-diy-counter-with-gpsdo/msg1808444/#msg1808444 (https://www.eevblog.com/forum/metrology/how-to-test-a-diy-counter-with-gpsdo/msg1808444/#msg1808444)
-
Hi guys,
To try to solve the mystery with the too fast de-charging of the 1nF cap., I completely rebuild the circuit.
While de-soldering, there was nothing wrong, apart from some solder flux underneath the SMD components (R1, R2 and C1).
The values all measured correctly. I use the suggested 1N5711 as the Schottkey, it seems to be working fine.
My scope probe is a decent quality x10 one (TESTEC HF series), without a switch.
I replaced the COG 1nF SMD cap with a small radial high quality 1nF COG capacitor.
I made the measurements again with and without the 10Mohm resistor in the circuit. There is NO change on the waveform. This is plausible because the effect of the 10M and/or the 10x probe is dwarfed by whatever else is loading the circuit. Believe me, there is nothing else connected or otherwise attached to the circuit. It's no rocket science, and there really is no magic involved. :phew:
Below is the "probed" ISR :
ISR (TIMER1_CAPT_vect)
{
timer1CounterValue = ICR1; // read the captured timer1 200ns counter value
digitalWrite(probe, 1); // create a signal to probe the ISR with a scope
TIC_Value = analogRead(A0); // ns value
digitalWrite(probe, 0); // stop the probe
PPS_ReadFlag = true; // gives the decharge cycle some time as well
}
The bottom trace (yellow) on the attached picture shows the probes surrounding the ADC read cycle.
The top trace is the voltage across C1, without the 10Mohm resistor present, but of course with my 10x scope probe. It also should have an impedance of 10M. (look it up if you doubt that)
As you can see, the de-charge of the capacitor has finished way before the end of the ADC cycle.
However, the circuit as is, with or without the 10M (resistor or probe) works!
So as a next step, I changed the code to show the raw ADC readings in the second column of the report. Below is one drift cycle.
2370 56 -39 33691 93.9 **** 49 560 500 1 23934 56.6 1120 0 0 0
2371 20 -70 33680 93.5 **** -32 200 500 1 23934 56.8 1121 0 0 0
2372 29 -63 33683 92.8 **** 8 290 500 1 23933 56.7 1122 0 0 0
2373 8 -81 33676 93.2 **** -18 80 500 1 23933 56.8 1123 0 0 0
2374 10 -79 33676 92.9 **** 2 100 500 1 23932 56.9 1124 0 0 0
2375 18 -72 33679 92.5 **** 7 180 500 1 23932 56.6 1125 0 0 0
2376 3 -85 33674 91.3 **** -13 30 500 1 23931 56.7 1126 0 0 0
2377 3 -85 33674 90.4 **** 0 30 500 1 23931 56.9 1127 0 0 0
2378 4 -84 33674 88.6 **** 1 40 500 1 23930 56.5 1128 0 0 0
2379 0 -88 33673 88.5 **** -3 0 500 1 23929 56.6 1129 0 0 0
(Note that I did not have the two LM35 connected properly - I use "****" instead op UnLocked))
The values, ranging here from 0 to 56 are relative to what I see on my scope, so the actual ADC reading of the value must be at the very beginning of the cycle. Luckily, just before the capacitor is completely discharged.
When I dis-connect my scope probe, and the circuit is still without the 10Mohm resistor, the ADC values are almost exactly the same. As to be expected.
I would like to re-iterate that there is no strange connection anywhere on the circuit board that would explain the way too fast discharge.
By simple deduction, the only unexplained factor that remains is the loading or low impedance of the ADC input of the Arduino processor itself.
The specifications list 100M as the impedance, as you would expect from a CMOS device, but wait, there is a gotcha! I also found this:
During an actual sample, the input resistance is temporarily a lot lower as the sampling capacitor is charged up so it is recommended that whatever you connect to the A/D have an output impedance of 10k or less for best accuracy. This is to allow the A/D input capacitor on the sample and hold to charge up in the time allotted to it between switching the input multiplexer over and starting the conversion. As you may know the arduino analogRead() function is designed and assumes the source impedance of voltage to be read is 10K ohms of lower. The fact that the AVR adc has but a single sample and hold capacitor but multiple multiplexed analog input pins means that you have to deal with the problem that is trying to read a high impedance signal.
Remember that the same ADC s/h circuit is also used for the two temperature inputs (A1 and A2)
I think the 10K output impedance clarifies what I'm measuring pretty well, unless there is something else and I have it wrong. :palm:
Is there one of you that can contribute or confirm this?
The big question however is: do we really care with all this if Lars's design works? (with or without the 10Meg)
Well, in my opinion only if you want to have a "real" 1:1 representation of the TIC value in relationship with the pulse width. (Yes I do care)
If so, the solution would be to add an op-amp as a non-inverting voltage follower between the C1 capacitor and the ADC input and also add my proposed circuit and code changes to dis-charge the capacitor under program control after an ADC measurement has finished.
Does this make sense?
Paul
-
The internal ADC S&H consists of 1k-100k serial resistor and 14pF capacitor (the cap is connected to Vcc/2).
The 14pF capacitor takes over a small chunk of charge off the 1nF capacitor, therefore the voltage drops a little bit.
The drop is tiny, however, like 14/1000.
The 10k "source resistance" is recommended such the 14pF charges up within 1.5 ADC clock cycle fully.
The fact the 1nF discharges so fast indicated an issue, imho.
The voltage at the 1nF drops to 50% BEFORE the actual conversion starts (your last oscope picture).
That tells me there is something of aprox 10k hardwired to the ADC input.
It could be your schottky is shorted or damaged. The 4046 output goes LOW after the pulse lenght measurment stops, and it could be the 1nF capacitor discharges itself immediately through the diode and 3k9 into the 4046 output which is at gnd level at that time..
I still strongly believe the blue voltage must stay at that initial 1V level during the entire 118us long ADC conversion.
PS: Below is a simulation with worst case scenario with the S&H (red) starting acting 10us after end of 4046 pulse measurement, S&H is 30us long, where it charges the internal 14pF via 1k.
The green is the 1V voltage at 1nF capacitor you should see, afaik.
-
imo,
You are absolutely correct. It is the Schottkey diode. I concocted another prototype and that worked as it should.
The diode I have been using seemed OK, but is not.
I feel like a totally dumb ass for missing this obvious problem. :palm:
The discharge now looks pretty linear within the ADC read cycle.
Blue trace is ADC window.
I'l hide in disgrace for a while... |O
-
Now it looks better, sure :)
But best you will see your yellow 1V voltage such noise free as it is my green voltage in my simulation above.. :P
-
That seems like a lot of noise. But I'm glad that is sorted because I was about to dust mine off and take some measurements. I like all the ideas and further insights, though. So a worthy discussion. :-+
-
It might make sense but your measurements don't support this theory. The charge drained into the sampling capacitor should cause a downwards step in the voltage at the start of the sampling time. Before and after the curve should be nearly flat. There must be something else going on. For example, schottky diodes have a significant leakage current. Or the pin might have a pull down enabled.
Of course the circuit works, but it is not to spec. The leaked charge causes a significant loss of dynamic range, iow, the tic resolution is far from the claimed 1ns.
PS: It really takes a lot of time to write a reply on the phone. By the time I finished, three other people responded to the same issue :palm:
-
The noise could be induced by the probe (gnd lead?), as the input of the ADC is an HighZ circuit (10Meg). You would need a fet probe or something like that. Doublecheck the wiring, grounding in a single point (star scheme), short wires, good decoupling (ceramic 100nF capacitors at each chip's Vcc and Gnd, etc.).
The next step is to return all that firmware coefficients back to normal values and test the stuff again..
PS: the voltage drop (as you can see in the above simulation with 1k internal resistor) is rather small, and could be less visible when the internal resistor is at the higher side of the spec (100k) and the drop slope will be slower. Also the 14pF capacitor is connected internally to Vcc/2, my simulation is "worst case" therefore the 14pF is wired to gnd and the "drop is higher". Moreover his voltage drop is covered by noise, which p-p is 30% of the ADC range :)
-
Of course the circuit works, but it is not to spec. The leaked charge causes a significant loss of dynamic range, iow, the tic resolution is far from the claimed 1ns.
Well, if I were a conservative diy maker I would claim 1ns rms..
-
Now that my circuit is finally working as intended, I continued to make the discharge modification.
On the scope shot with the number ending in 3248, you can see the normal operation.
The blue trace is the "probed" ISR surrounding the ADC read cycle.
You can see that the capacitor slowly discharges during the sampling period. This means that due to the almost 200 ns jitter caused by the interrupt latency, there will be differences in the value read by the ADC. Not much, but we're dealing with ppb sensitivity, and I simply assume that every bit helps. Obviously, the discharge is higher than normal because I used a x10 scope probe to see the voltage level.
I modified the ISR a bit further with my proposed solution, and by using a digital port to discharge the capacitor at a planned point, while keeping the voltage level flat during the sampling period. Flat meaning that there will still be some discharge due to leakage and loading but this is as far as we can go with this solution. I used a free port, D10 and connected that through a 1K resistor directly to A0. The 10M resistor is removed from the circuit.
The code changes are as follows:
At the very beginning of the code, I added this:
// add a decharge for C1 after the ADC read cycle
const int decharge = 10; // Decharge pin for C1. Port is toggled between hi-0Z input and output driven low
const int probe = 12; // create a probing signal within the ISR
In setup(), I added this:
pinMode(decharge,INPUT); // setup the port that will decharge C1
pinMode(probe,OUTPUT); // setup the port to allow a probe inside de ISR
Here is the modified ISR:
// Timer1 capture interrupt routine - this runs at rising edge of 1PPS on D8
ISR (TIMER1_CAPT_vect)
{
timer1CounterValue = ICR1; // read the captured timer1 200ns counter value
digitalWrite(probe, 1); // create a signal to probe the scope
TIC_Value = analogRead(A0); // ns value
digitalWrite(probe, 0); // stop the probe
pinMode(decharge,OUTPUT); // change port from hi-Z to output
digitalWrite(decharge, 0); // force it to ground to decharge C1
PPS_ReadFlag = true; // gives the decharge cycle some time as well
pinMode(decharge,INPUT); // revert the port back to hi-Z
}
The "probes" are not there forever, when you're done, you can comment them out.
The next scope shot, ending with 4047, shows the C1 voltage level with the blue trace, and the probe around the ADC cycle in yellow. (channels are reversed from the previous picture) The voltage level is now very flat throughout, even though I still have my x10 probe connected.
Right after the ADC cycle ended, the voltage is forced to ground getting the hardware prepared for the next cycle. The timing works out very well, the discharge during one instruction and with 1K in series only takes a few micro seconds to complete. The 1K is only there because I don't like shortening capacitors, even though the stored energy in this case is minute.
My Isotemp replacement for the Bliley OCXO finally arrived, so I can start the full testing procedure again. Up until now, I had been using my modified FY6600 Waveform Generator as a replacement. You can set the frequency down in the micro Hz to make tuning by hand to the 1PPS possible.
Enjoy,
Paul
-
Take a look at the yellow trace right before charging the capacitor. It doesn’t start at zero. I think if you don’t hold it low until shortly before the pulse, it will recover a bit and you introduce more errors than you tried to correct.
-
You have to discharge the 1nF via 1k for a bit longer than 1us.
Below the simulation - green is the 1nF voltage, blue is the 4046, red is the internal ADC's S&H and turquoise is your reset pulse 1us long.
I think based on the ISR source your pulse is even a bit shorter.
The green voltage will not go to zero based on the simulation.
-
10us long reset via 1k will do.
Mind there could be some recharging of the 1nF through the reset pin (needs to be investigated)..
-
Miti, the yellow trace you refer to is the probe signal.
The blue trace is the 1nF cap voltage. The little marker at the very left side of this trace shows the ground level. I didn’t see a residual voltage, even with higher sensitivity settings.
Imo, I do take the simulation serious. Thanks for the effort.
Obviously, I can do two things. One is to lower the 1K to say 470 Ohm or even 100 Ohm or add a few dummy instructions in the ISR code, or do both. I’ll try that tomorrow and report back.
Thank you all for contributing to this nice project.
Sad that Lars is no longer with us to witness the continued activity of his brain child.
Paul
-
Fyi- the peak current via 100ohm resistor will be up to 9mA with 1V at 1nF. So I would rather use the 1k and longer reset pulse (10-20us). You are not in hurry, you can afford that delay, imho :)
PPS: ok, this is atmega :), handling the pins takes with digitalwrite() around 3us people say, the pinmode() maybe the same, so you are somewhere around 8-10us with your reset pulse..
-
Aaah, my bad. :palm:
Can’t you leave the pin as output until all the processing is done?
-
I took the easy way, and just added a small delay after the digitalWrite:
delayMicroseconds(10);
I know, you're not supposed to put delays inside ISR's, but in this case it's OK.
As a result, I see no visual change of any charge residuals on the scope, but better be safe than sorry.
Now back to adding my replacement (used) Isotemp 143-141 OCXO.
BTW, this one also has a flaw, there is no V-ref output.
Out of 4 tries, I'm still not very lucky with any of them.
As it takes about 6 weeks each for delivery, buyer beware.
Enjoy!
Paul
-
In simulation I see a residual voltage at the 1nF (before TIC measurement starts)
10Meg reset 4mV
1k reset 9mV
Voltage drop from max voltage till end of S&H on the 1nF with 1k reset
100ns 2.3mV
500ns 8mV
900ns 13.2mV
And the TIC linearity with 1k reset (input pulse width vs. 1nF voltage at the end of S&H)
100ns 129.3mV
200ns 233.2mV
300ns 334.5mV
400ns 433.6mV
500ns 530.5mV
600ns 624.9mV
700ns 717.3mV
800ns 807.5mV
900ns 895.5mV
-
In simulation I see a residual voltage at the 1nF (before TIC measurement starts)
10Meg reset 4mV
1k reset 9mV
Not that it actually matters. As long as the voltage is well below the interesting center zone of around 500mV before the 1PPS pulse arrives, you're good. This is where the software should steer the loop towards anyway.
-
imo,
Good job.
I can see a residual of a few mV in reality as well, but it is well hidden in the noise and is dwarfed by the voltage level of the pulse that is used to make the ADC measurement. I have not gone back to measure the condition with the 10M present with this sensitivity.
I concur with thinkfat that this tiny amount will not upset the PI loop much. As a minimum, it's very stable and repeatable, so we could even compensate the ADC value with this residual amount. That's easy to do, but does it make practical sense?
The original task was to remove random jitter effects caused by the interrupt latency in combination with the dis-charge caused by the 10M. I believe that has been fixed now.
BTW, my Isotemp based setup is working (with the above modification), and I got a lock within 10 minutes. Two hours later it's still locked and looking fine.
-
The original task was to remove random jitter effects caused by the interrupt latency in combination with the dis-charge caused by the 10M. I believe that has been fixed now.
You had there something like 200ns p-p. Could you show how it is now?
Picture ending 4416.
The thermal noise of that reset 10Meg @20Hz BW (RC) and 25Celsius is 1.8uV rms (12uV p-p).
The ADC noise I would expect is something like 6LSB p-p, or 6mV p-p, or 6ns p-p.
The source of the 200ns jitter is the interrupt latency, it seems.
Also there is the NEO 1PPS jitter, easily up to 50ns p-p.
PS: the 1nF voltage difference for 500ns input pulse and S&H start jitter of 200ns p-p is 80uV.
-
I've taken Miti's .csv file (replay #286), and calculated the standard deviation of the second column, for the situation when locked properly (1783 of data).
The standard deviation is 7.133ns, or 47.1ns p-p (6.6x).
-
Just found this nice PCB
https://github.com/Qw3rtzuiop/Lars-GPSDO-PCB
The pict(s) are for the rev1 pcb , not the rev2.
I just ordered a few on JLCPCB
/Bingo
I got my PCB's today ... Now what to use for 1nF cap ??
I don't think i have anything "good" , just some cermic
And maybe i got some Vima Red.
/Bingo
-
NP0/CG0 ceramic 1nF, people say the TDK are best (see above posts).
-
The
C2012C0G1H102J - is not available
Nor is this one : FA28C0G2E102JNU00
And i'll have to do a $50 order @Mouser to get free shipping :(
Someone have a few ?
Or ... I have some "China" 1nF ceramic disk (The orange ones) , might try one of these for now
Edit: Got some NPO from here
https://www.ebay.com/itm/122455243378 (https://www.ebay.com/itm/122455243378)
/Bingo
-
For my own experiments I've now settled on using an actual DAC instead of PWM+filter, mainly for two reasons:
* using a DAC with embedded voltage reference will make the output less dependent on the supply voltage.
* The response of an integrated DAC is way faster than the PWM+filter. I've calculated that, using e.g. the STM32F030's timers to output a PWM, for 16bit resolution I'd end up with a PWM frequency of around 700 Hz and with a low-pass filter with a 0.1Hz cut-off frequency to reach <1mV ripple, while at the same time I'd see a settling time of close to 4 seconds. That's not going to be very responsive.
The structure is going to be similar to what has been suggested already, 10MHz into an HC390 which outputs 500kHz to a TDC7200, which also connects to the 1PPS output from the GPS and uses the 10MHz as reference clock. An STM32F030 to control everything, including an ADS5693R DAC. I decided to add an TLC2272 opamp as a buffer to the output of the DAC, I'll run it in 2.5V output mode and use the opamp to reach the voltage range of the VCO. Which will be, eventually, one of my LPRO-101 Rb standards. I've not yet decided if I'll add a NEO-M8T directly on the PCB or if I'm just going to provide a 1PPS input to the controller.
-
Imo,
I’m currently running a first 24hrs test run for my new oscillator, and I need to activate the probes in the ISR again before I can run the ISR latency measurement again. I’ll do it tomorrow when I have the data collected.
You are obviously more adept and experienced with this, why do you think the latency could be different now? It is based on the 1PPS pulse and the start of the ISR. Nothing changed as far as I can tell. Even though we know that the 1PPS has jitter, that will not show up with this measurement, right?
-
The 200ns p-p jitter comes mostly from ISR latency. It creates only 80uV p-p noise based on my calcs above. That is 50x smaller noise than the ADC noise I would estimate. So I would not be worried about.
The removal of 10Mohm helped to keep the voltage at the 1nF capacitor flat during S&H, that is an improvement.
The 1k reset with a pin will work, it induces some leakage and maybe noise but that needs to be measured somehow.
I think there is nothing to mess with at this stage, make the measurement, do log the data in a .csv file such you may analyze afterwards.
-
.. I've calculated that, using e.g. the STM32F030's timers to output a PWM, for 16bit resolution I'd end up with a PWM frequency of around 700 Hz and with a low-pass filter with a 0.1Hz cut-off frequency to reach <1mV ripple, while at the same time I'd see a settling time of close to 4 seconds. That's not going to be very responsive.
The MCU based GPSDOs usually work such they set a new DAC voltage in some longer period, like 5minutes or 10minutes, etc. It is expected the OCXOs are stable enough not to be corrected each second.
The XOR analog ones work differently, they are correcting "continuously".
FYI - there was a good long discussion with a lot of experiments on PWM in the Metrology section - https://www.eevblog.com/forum/metrology/lm399-based-10-v-reference/msg2271156/#msg2271156 (https://www.eevblog.com/forum/metrology/lm399-based-10-v-reference/msg2271156/#msg2271156)
Btw there is the stm32F334 with 217ps PWM resolution :)
-
If anybody is interested, some time ago I tried a real DAC AD5693 instead of PWM and it seems to work well. I didn't try it in real GPSDO though only h1, h65535 and many in between. It should reduce the switching noise a bit.
-
.. I've calculated that, using e.g. the STM32F030's timers to output a PWM, for 16bit resolution I'd end up with a PWM frequency of around 700 Hz and with a low-pass filter with a 0.1Hz cut-off frequency to reach <1mV ripple, while at the same time I'd see a settling time of close to 4 seconds. That's not going to be very responsive.
The MCU based GPSDOs usually work such they set a new DAC voltage in some longer period, like 5minutes or 10minutes, etc. It is expected the OCXOs are stable enough not to be corrected each second.
The XOR analog ones work differently, they are correcting "continuously".
Looking at Lady Heathers plots for DAC and Loop of the two GPSDOs I already have, the control loop adjusts the DAC every second (or every other second)...
Anyway, WIP schematics attached. I'm wondering about a few details, though:
* The layout guidelines for the TDC7200 suggest adding series resistors into the SPI lines. I've provided them, but I won't really need them if the layout is tight and the traces just a couple of millimeters, will I?
* Another recommendation is to have matched length START and STOP inputs. I think that's not relevant in my case, it will just skew the phase of the 10MHz against the 1PPS signal a little bit.
* I'm using a MC7805 for creating an 5V supply for the DAC and the Opamp (VDDA), with an added LC filter. Is that sensible?
-
:palm: never mind about this. Re: ISR discharge. Would it be better to set the pin open at start of the ISR and then leave it low on exit?
The MCU based GPSDOs usually work such they set a new DAC voltage in some longer period, like 5minutes or 10minutes, etc. It is expected the OCXOs are stable enough not to be corrected each second.
I don't know if the code addresses the PPS jitter but it seemed that one could leverage the relative stability of the OCXO to apply a correction. My GPS has a lot of short term jitter and it is cyclic, but it would seem long term timing would be accurate.
-
1. The layout guidelines for the TDC7200 suggest adding series resistors into the SPI lines. I've provided them, but I won't really need them if the layout is tight and the traces just a couple of millimeters, will I?
2. Another recommendation is to have matched length START and STOP inputs. I think that's not relevant in my case, it will just skew the phase of the 10MHz against the 1PPS signal a little bit.
3. I'm using a MC7805 for creating an 5V supply for the DAC and the Opamp (VDDA), with an added LC filter. Is that sensible?
1. I would let the resistor's there. They limit EMI between those two chips as well (the 22ohm in 500kHz? - nope, the 22ohm should be put in all SPI lines).
2. do it as best as you can.. I would split the "10MHz" via 2xinverters into "10MHz for 390" and "10MHz for 7200".
3. LC filter is ok, even 100nH is rather on the lower side (1-10uH would be better, imho). Add 10-22uF MLCC into VDDA.
7805 - stability - the DAC has got its own 2.5V 2ppm/C Vref, afaik.
Critical are the R6/R7 - their TC. If you use 50ppm/C resistors the TC of the gain could be 100ppm/C easily.
Also doublecheck the TC of the TLC272 input offset (1.8uV/C).. I would create a VDDA1 for the opamp. And from opamp's output an RC low pass, like 100ohm and 10n.
7404 input 10MHz squarer (fed by 1-2Vpp sine) - that is also a critical component (jitter). Such a simple solution does not work well usually.
I would put an inverter into 1PPS as well, but not from the same package as the 10MHz ones (there are 5pin smd 74xx inverters/buffers available).
I would also add a capacitor at the input of the 7805. Also a serial diode into the 24V rail.
Provided your system will take 40mA @5V the power loss at the 7805 will be 0.8W with 24V..
You are missing one important component of the GPSDO - "Locked" LED :)
-
May I have couple of suggestions?
* If you use inverters as buffers, you sine wave would be altered in case you use a sine wave OCXO, and I think a sine OCXO is preferable as it is more spectral clean. I would use high speed comparators.
* Some OCXOs need VC higher than 5V. It would be useful to the option to control the gain and offset of the VC above 5V. I've attached a schematic that I simulated some time ago. If R1/R2 and R7/R8 are trimmers, you can control the gain and offset of VC so your DAC will always work around 32768. And of course you should supply the opamps from 12V. Ignore the opamps that I selected, it was something fast.
-
1. The layout guidelines for the TDC7200 suggest adding series resistors into the SPI lines. I've provided them, but I won't really need them if the layout is tight and the traces just a couple of millimeters, will I?
2. Another recommendation is to have matched length START and STOP inputs. I think that's not relevant in my case, it will just skew the phase of the 10MHz against the 1PPS signal a little bit.
3. I'm using a MC7805 for creating an 5V supply for the DAC and the Opamp (VDDA), with an added LC filter. Is that sensible?
1. I would let the resistor's there. They limit EMI between those two chips as well (the 22ohm in 500kHz? - nope, the 22ohm should be put in all SPI lines).
2. do it as best as you can.. I would split the "10MHz" via 2xinverters into "10MHz for 390" and "10MHz for 7200".
3. LC filter is ok, even 100nH is rather on the lower side (1-10uH would be better, imho). Add 10-22uF MLCC into VDDA.
7805 - stability - the DAC has got its own 2.5V 2ppm/C Vref, afaik.
Critical are the R6/R7 - their TC. If you use 50ppm/C resistors the TC of the gain could be 100ppm/C easily.
Also doublecheck the TC of the TLC272 input offset (1.8uV/C).. I would create a VDDA1 for the opamp. And from opamp's output an RC low pass, like 100ohm and 10n.
7404 input 10MHz squarer (fed by 1-2Vpp sine) - that is also a critical component (jitter). Such a simple solution does not work well usually.
I would put an inverter into 1PPS as well, but not from the same package as the 10MHz ones (there are 5pin smd 74xx inverters/buffers available).
I would also add a capacitor at the input of the 7805. Also a serial diode into the 24V rail.
Provided your system will take 40mA @5V the power loss at the 7805 will be 0.8W with 24V..
You are missing one important component of the GPSDO - "Locked" LED :)
I added the resistors in the start/stop signals because the sample layout from the datasheet has them, I guess I'll keep them as well, I can always replace them with a 0R bridge.
Regarding the input sine-to-square, I took that circuit from the LPRO-101 user guide. They use a 74AC04, however. There's also a variant with a 1:1 voltage divider at the input of the inverter and without the feedback resistor for self balancing, would that be better? The data they provide for phase noise seem ok, < -150dBc @100kHz, < -100dBc @1Hz. They describe a variant with a high-speed comparator as well (LT1016) but the phase noise is worse.
I'd rather not add an inverter in the 1PPS signal, the TDC manual says it's best to use the rising edge for both start and stop, also the 1PPS signal will anyway be quite jittery, so I'd rather take it as it is and not add another jitter source. The PLL in the MCU will have to deal with the original jitter anyway.
Regarding R6/R7 - I can use 25ppm or better there. Not a problem, resistors are cheap, even with 25ppm TC. 10ppm gets you into 0.5€ in single quantities, but they're readily available, too. I don't think I'll use trimmers here. They definitely have a worse TC than a precision SMD resistor. If I want to change voltage, I'd rather change resistors.
The opamp is actually a TLC2272A, but the offset voltage TC isn't any better, still in the 2µV/°C range.
Still, on the topic of temperature stability, wouldn't the control loop eventually correct the offset? Of course there will be a drift while the temperature changes, but if it happens slowly, the control loop will be able to keep up and stay in lock. It's important for the hold-over case of course, but then an active temperature compensation will be necessary anyway. The STM32 has a built-in temperature sensor, maybe it's good enough for that.
Regarding the power dissipation of the 7805 - I'm using a DPAK package and there will be ample copper for cooling. The variant I chose has a TC of -0.3mV/°C
However, I'm going to change that to a 12V type and rather provide separate point-of-load regulators for the digital and the analog parts, instead of trying to decouple the domains via an LC filter.
Single circuit inverters - there's indeed a lot of them available. But most of them have Schmitt trigger inputs, would that be a problem?
The 24V supply will be taken from another project of mine, I already have a small PCB for the LPRO with overvoltage and reverse polarity protection, I will reuse that circuit.
BTW, the LPRO-101 has a trimming range of around 3 ppb over 5V, or 0.006Hz/V. I don't think I'll be in trouble for this particular use case. But the design should be versatile enough to support a standard OCXO, too, with only BOM changes.
-
Schmitt triggers are ok. Except the squarer, it should stay 04.
I would try with the opamp first on a breadboard whether the opamp works as expected (input 0-2.5V, look at output).
PS: this is a squarer I've been using. Tune L1C1 for the input frequency. The LC is a parallel tank. Keep R1 and signal source impedance low.
It creates up to 6-7Vpp at the HC input. Will be limited by clamping diodes, so you will see almost a Vdd p-p square. HC14 should work too.
-
Thinkfat,
My suggestion if I may, would be to move whatever is needed to square, buffer, drive and power the oscillator to a seperate board where the oscillator is on. This will allow you to test various oscillators while keeping the controller board universal.
I did the same with my prototypes and it allowed me to quickly change from a Bliley with sine wave output to an Isotemp with a square wave output. Also the circuit to drive the VC is most likely depending on the oscillator type, so it should go on that board too.
-
Imo,
I really appreciate your contributions and insights, although at times they can be a bit cryptic.
In a post just above you have this advice :” Schmitt triggers are ok. Except the squarer, it should stay 04.” Unfortunately, you don’t offer the reason or rationale.
When you discuss your own very interesting squarer design, you say “HC14 would work too.” As the HC14 is a Schmitt trigger, I’m a bit confused.
What is there against using a HC14 in a squarer in the first place?
-
Metrologist,
“ Re: ISR discharge. Would it be better to set the pin open at start of the ISR and then leave it low on exit?”
That won’t work because the ISR is activated after the TIC pulse is converted. I show that in a very early screenshot that shows when in time the ISR actually happens.
-
1. In a post just above you have this advice :” Schmitt triggers are ok. Except the squarer, it should stay 04.” Unfortunately, you don’t offer the reason or rationale.
..
2. When you discuss your own very interesting squarer design, you say “HC14 would work too.” As the HC14 is a Schmitt trigger, I’m a bit confused.
1. With the original squarer (7404) you put the 7404 into a linear mode (aka amplifier) by the resistor wired between output and input. It works with the standard 7404, it does not work well with Schmitt trigger (because of its hysteresis), however.
2. The wiring with an LC is using the LC as "an amplifier". The Q of the parallel LC tank amplifies and cleans up the input signal, so it works with 7414 as well.
You have to tune the L1C1 to the input frequency (ie 10MHz). L1C1 works as an amplifier and filter then - see below the amplitude of the signal at the 74HC input with 2 different C1 (25.2pF is closer).
PS: Below I added a "noise" to the input's 10MHz sine signal (a square wave ripple). You may see how the LC filter cleans the signal at the input of the 74HC up.
-
The output from a Rb-locked VCXO is usually not really noisy, however. In my case, I'm pretty sure I won't need a lot of cleanup before I feed the signal into a 7404.
Anyway I don't want to derail this thread any further. My own design is about as far from the "Lars DIY GPSDO" concept as it gets. I'll start a new thread on this board when I have the PCB done.
Thanks all for the valuable input!
-
@thinkfat: do not forget to add an external flash (ie fram spi) for your calibration constants.
Also add serial resistors in TX/RX (both for NEO and PC uart), ie 100-220ohm.
-
For the past couple of days I have been running tests on my new (used) Isotec 143-141 OCXO.
I already reported that this OCXO is partially broken, because it does not have a ref Voltage output.
The supplier gave me a full refund, so that's good.
I have been struggling with this OCXO however, and I want to share some of my observations.
The frequency out, with nothing attached to the VC input is just about spot on.
The adjustment range is pretty well centered at 1.9638V.
I have created a finer VC adjustment with a couple of resistors such that H1 will create a voltage of 1.773V and an avg of +186ns. H64K creates 2.152V and an avg of -200ns, resulting in a frequency delta of +/- 2Hz. The gain is calculated to be 170.
So far so good.
Attached are some Excel plots taken with a damping of 0.5 and a TC of 32. (Isotec.jpg)
The board with the OCXO is in a plastic container so no draft. The LM35 sensor is well pressed to the case, temperatures are stable.
Note the very regular swings in the ns and DAC values.
It seems to me that this OCXO is behaving weird and the PI does not get it under control. I do have a stable lock, but on my scope it looks jittery.
I have played with the damping factor, and when I progressively go to the maximum setting of 10.0, it's improving a lot, but far from stable. (Isotec d10.jpg)
As soon as I change the TC to a value of 100, I loose the lock right away.
What do you guys make of this specimen?
-
FYI - I got the same with my OCXO in past (double ovenized Trimble thermo isolated) - and I changed to XOR analog one afterwards :) Either oscillation like in your picture, or large random walk. You also confirmed my above estimation of aprox. 50ns p-p noise.
I think it could be related to: a) too noisy OCXO (or its regulation loop), b) finetuning the PI regulator's coefficients, c) the period of the DAC corrections.
PS: one important measurement is to disconnect the EFC wire and measure the free OCXO walk against 1PPS.
PPS: d10 picture: your OCXO gain is aprox 10Hz/V. With 125 DAC units average drift (9.5mV) OCXO drifted 0.095Hz in 5000secs. That could be an initial drift after long power off. The loop compensated for it. An OCXO switched off for long time needs several weeks to settle, people say.
-
Here is the Isotec free running, with my hand-adjusted synchronization to the 1PPS.
The spikes are when the TIC counter overflows at the 0 and 1,000 ns points.
This is only about 1,000 samples, but overnight shows the same thing.
The OCXO itself does not seem to be the problem for the oscillation.
I have also attached the schematic I used for the Isotec with the broken VRef output.
Any suggestions for improvements?
Funny enough, with a damping of 10.0, I can now get up to a TC of 500 already without loosing my lock. (1,000 fails)
Maybe the extra powered-on time made the difference as imo already hinted at.
-
Short comment:
1. 78xx are the poorest performers in terms of TC and noise, it could be the fluctuations come from there (I would replace the 7808 with something better)
2. pot trimmer - I would avoid it, large TC of resistance and of wiper contact
3. resistors around the EFC input - should be low TC ones
4. LM35 - with longer wires put a "68-82ohm ser 10u MLCC" between its output and gnd (close to its pins).
-
Free running picture - what is the 4usecs difference in 1000secs? I doubt it is the drift of your free running OCXO (aprox 4Hz in 1k secs)..
-
According to control theory rules of thumb, if your regulator is oscillating, your gain is too high for the response time of the process. I part of a PI regulator can also cause oscillation, should be small against P.
If I understood Lars' PI regulator correctly, try with less gain and shorter TC? But I might be completely off, I'm far from being an expert. But TC much shorter than the settling time of your PWM filter doesn't make sense as well.
-
FYI - here is the Lars' PWM DAC simulation.
It settles in about 3.8secs from 0V to 1.35V.
The PWM freq is 480Hz (arduino lib). R4/5 are the ESRs.
The p-p ripple is about 10uV.
-
There is no need to wire the start and stop pins together. The start pin will be wired to, for example, 1PPS and the stop pin to the OCXO's 500kHz. There will be none 4046. 7200 will measure the "time between the rising edges of those two signals" - it returns the difference "stop_rising_edge-start_rising_edge". Thus the same as it is today with analog TIC.
The 7200's start and stop pins are both rising edge sensitive.
I still have one question regarding the design you proposed - you've connected the 500KHz and the 1PPS signals to interrupt inputs of the MCU. I thought of only using the INTB output of the TDC to signal completion of a measurement to the MCU. That should be sufficient, no? Or did you have another reason to hook up those signals?
-
I do not know. You are going to write your own fw so it depends. You may use the INTs based on the 1PPS and 500kHz edges as well for something. I think Lars' version is using that somehow (I do not use Lars' system).
PS: Lars is using the 5MHz for feeding the Timer1 (200ns clock) for some internal purposes - (ie. he captures the Timer1 value at the beginning of the 1PPS ISR, he uses "timer_us" variable for "timer1 value in microseconds offset from 1pps").
For compatibility reasons I would feed 5MHz to the TimerX input as well. You will see whether it is useful or not.
-
imo,
I don't really understand what you mean with this "what is the 4usecs difference in 1000secs? I doubt it is the drift of your free running OCXO (aprox 4Hz in 1k secs).."
I have only shown one cycle, of many, many others during the long test.
Here is a bit larger section of the ns values during the free running oscillator run.
Does this clarify?
-
That is what I'd expect with a free running oscillator with no correlation to the 1PPS signal. It's just a tiny frequency offset, you cannot make any conclusion on the OCXO drift from that. If the frequency is off, you'll see the two signals drifting in- and out of phase just as is shown there. You should be able to calculate the frequency offset from that data, too. It's like watching two almost-aligned signals on an oscilloscope in XY mode ;)
-
I do not know. You are going to write your own fw so it depends. You may use the INTs based on the 1PPS and 500kHz edges as well for something. I think Lars' version is using that somehow (I do not use Lars' system).
PS: Lars is using the 5MHz for feeding the Timer1 (200ns clock) for some internal purposes - (ie. he captures the Timer1 value at the beginning of the 1PPS ISR, he uses "timer_us" variable for "timer1 value in microseconds offset from 1pps").
For compatibility reasons I would feed 5MHz to the TimerX input as well. You will see whether it is useful or not.
Lars used the 5MHz clock to extend the TIC range beyond the 1000ns the ADC is able to provide. However, the TDC7200 in Mode 2 can measure time intervals of up to 8ms. That should be plenty. No need to have a 5 MHz clock walking about on the PCB. I'm beginning to worry anyway if I can pull this off on a 2 layer PCB.
-
In theory you do not need the 1PPS and 500kHz interrupts, when using the 7200's INTB. In practice the signals could be useful ie. for detecting whether the NEO or the OCXO actually work (or are connected in properly).
Also clocking the STM32 off the OCXO's 10MHz could be an interesting option.
-
In theory you do not need the 1PPS and 500kHz interrupts, when using the 7200's INTB. In practice the signals could be useful ie. for detecting whether the NEO or the OCXO actually work (or are connected in properly).
Also clocking the STM32 off the OCXO's 10MHz could be an interesting option.
Yes, indeed, I've played with that idea, having a counter running clocked by (a multiple) of the OCXO clock and using the 1PPS as a capture event. But I think you don't need to clock the whole chip from the OCXO in that case, because the STM32 timers can do event counting as well. Also, you'd need to be very sure that the OCXO is connected before you switch from the internal RC oscillator to the external clock...
-
The main reason for running the STM32 off the OCXO is its "synchronous operation" thus lowering interferences (beat frequencies), even not so critical with the 7200, but still, you want to chase picoseconds and uVolts :)
Afaik some HP high end counters used to use a dithering of their clocks to avoid that..
-
I took the time today to make two of the modifications imo suggested:
1. 78xx are the poorest performers in terms of TC and noise, it could be the fluctuations come from there (I would replace the 7808 with something better)
2. pot trimmer - I would avoid it, large TC of resistance and of wiper contact
3. resistors around the EFC input - should be low TC ones
4. LM35 - with longer wires put a "68-82ohm ser 10u MLCC" between its output and gnd (close to its pins).
Instead of using the 78L08 as the basis for the 4V OCXO reference voltage divider, I'm now using an LM4040 4.096V shunt. (fed through a 3K9 resistor from the 8V to get a 1mA current)
The result is so remarkable it is beyond belief! Gone are the oscillations and the instability. If your OCXO does not have a reference voltage out, make sure you use a real reference. I'll show some results later.
I also did 4, but there is little change however. I think I'm going to be using a filter in software later on. I don't think the current variations are going to help if I invoke the temperature compensation.
I'll do 2 and 3 if/when I go to a pcb layout. Right now I'm still playing and experimenting. Yesterday I got my CTI OC5SC25 OCXO, still fitted on the original pcb that was cut from the original. After de-soldering, a quick test showed it to be working, so I'll have another one that I can play with.
More later
Thank you very much for your insights imo! :clap:
PS: it turned out that I was using a different setting for my measurement. The result with the reference is not that spectacular, but definitely a significant improvement.
-
The basic problem of all PWM DACs is the stability and noise of the Vcc the drivers are powered from. That is usually the Vcc of the MCU.
I posted a solution in past afaik - the PWM's low pass driver could be created from those 5-6pin logic gates, while the gate is powered from a clean 5V.
An ideal component is for example the "Single-Bit Dual-Supply Bus Transceiver With Configurable Voltage Translation and 3-State Outputs" - https://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf (https://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf)
which is sot-23-6 package with 2 voltages - ie. you may drive it from an 1.8V MCU, and at the other side from 5V quality voltage regulator (the PWM filter side).
-
Hi all,
After I got my third OCXO, the CTI OC5SC25, I made some more measurements.
Because my other OCXO, the Isotemp 143-141 had a defective Vref output, I suspected the results a bit.
I didn't need to worry, the results are very close.
To accommodate the CTI, I tried to keep the same VC adjustment as I used with the Isotemp. It turned out that the sweet spot for the CTI is at 2.62V, not quite in the middle of the 4V range, but it allowed me to use the same resistor network as with the Isotemp. The adjustment range is more than enough.
I adopted a different calibration method this time.
Instead of using my counter or DMM to set the midpoint by frequency or voltage, I simply started the program, set the DAC to midrange with h32767 and adjusted the VC trimmer such that diff_ns was around zero. I then switched to H1 and ran that for a minute. I copied the trace results to Excel and used that to calculate the average of diff_ns, and wrote that down. I then switched to H65535 and did the same. The results were +75 and -69, nicely centered, and that resulted in a gain of 455. The trimmer can be substituted by fixed resistors when this has been done, to remove some possible jitter temperature drift as was suggested by imo.
While playing around with different settings, I noticed an unexpected behavior that I want to share here.
I've learned that to get a feel for the whole system, it is best to start with a TC of 4, and the damping at minimum (at 0.5). This allows you to see the almost unfiltered results of the OCXO drift and the response by the program to stay locked.
In the picture below, that is shown by the first 650 samples. The excursions show that every second, the OCXO is nudged rather aggressively into shape.
If you now switch to a TC of 32, the default setting, the combination of the TC setting with the minimal damping is causing oscillations. This is the period from about 730 until 1200. This could be a "trap for young players", I certainly fell for it and I'm no longer young.
If you now add more damping, by setting it to 3.0, the oscillations are almost gone.
At about 1,540, I switched to a TC of 100. At about 2,000 I set the damping to 5.0. You can see the effects.
Note that with higher TC settings, the DAC output is progressively more filtered and so the excursions of the DAC output are limited in time and value. If you have an OCXO that drifts easily, it can get outside of the DAC compensation rate quickly, resulting in the system loosing the lock. The effect of filtering with a higher TC is much more aggressive than the damping factor.
I have also found that before you switch to a higher TC setting, you should have already the corresponding amount of "locked" time sampled by the system that the new setting demands, otherwise you'll loose the lock right away. I found it best to progressively increase the TC setting.
With both the Isotemp and the CTI, I have difficulty getting TC's above 500. With my now dead Bliley, I could get up to 1,000 easily. The Bliley has a much thicker casing then both the CTI and the Isotemp, maybe this is a factor because I have not yet activated the temperature compensation.
Enjoy!
-
I wanted to investigate the source and the amount of jitter that can be observed.
This measurement had been done before in an earlier post, but since I have more units, I could show additional information.
I have three different Ublox GPS modules.
I have a genuine NEO M8T, a fake NEO-6M and a fake NEO-M8N.
They are all on the same carrier. (I replaced one broken fake with the real M8T)
For the measurements, I used the NEO-M8T as the reference. Note that this unit is not completely set for the "timing" mode. Both GPS modules were connected to the same type powered antennas. The antenna cable going to the M8T is 4 feet longer. I usually have in excess of 10 satellites.
I triggered my scope from channel 1 connected to the NEO-M8T and monitored the other two separately.
The shot ending in 44 is the 6M and the other shot is the M8N.
The amount of jitter is about the same (about 50-60ns), and so is the position relative to the M8T.
From this it seems that it does not matter much which version you use, they all have the same 1PPS behavior.
While making these measurements, I noticed a missing or strange pulse every now and then on all three seperately.
Enjoy!
-
You may implement an "automatic adaptive setting" of the TC (time constant, should be higher than 4 secs, as 4 secs is the time constant of the pwm low pass filter) and the damping factor :)
Always start with safe values and slowly iterate to the optimal ones..
PS: is it possible to open the Bliley box (in fix the broken output)?
-
Well, yes, that's about the expected outcome. If you have an unstable OCXO, you have to discipline harder or more frequently than a good OCXO, or it will drift out of lock. If your regulation is too slow (TC too high, damping to high), it will not be able to kick the OCXO back into phase.
You'll see this in the ADEV chart: At low tau (< TC) the Allen deviation is limited by the OCXO, at long tau (> TC) the Allen deviation is limited by the quality of the time signal from the GPS system. That is why using a TCVCXO or completely uncompensated VCO is rubbish. You'll end up having to use small TC's and high gain and of course the short term ADEV can never be better than the free-running stability of the oscillator.
Practical example: I have a 10-digit counter that can give me up to 1E-9 resolution with a 20 second gate time. It cannot average over multiple gate times. That means, ADEV with tau=20s must be better than 1E-9 or it'll be useless as a reference clock for this counter. A GPSDO with an unstable oscillator will not do, even though at longer observation intervals it will appear "stable".
I have also found that before you switch to a higher TC setting, you should have already the corresponding amount of "locked" time sampled by the system that the new setting demands, otherwise you'll loose the lock right away. I found it best to progressively increase the TC setting.
This is due to the integrative part of the regulator. You have to null it before switching TC, but that will give the DAC a pretty hefty kick. You can, however, try to use the integrator content as a switching criterion for higher TC. If I is around 0 for a longer time period (a couple of TC), you can safely switch.
The trimmer can be substituted by fixed resistors when this has been done, to remove some possible jitter as was suggested by imo.
The trimmer will cause a higher temperature drift, not jitter.
-
In order to find the optimum TC, I used method number 2 from the description in Lars's document (page12).
I used a TC of 4 and a damping of 0.5, and plotted the live DAC values of the CTI OCXO in Timelab.
I don't understand the results I'm getting as I don't see the "intersect" where "a reasonable TC can be found".
I know it has to be below 500, because that setting causes the lock to be lost.
This is the first time I'm using Timelab, it can very well be a pilot error.
Any suggestions as to what the meaning of the plot is?
-
Have you subtracted the linear drift? How the MADEV looks like?
Also you have it run for longer than 1 hour to get taus around 1000secs.
PS: you may log the data into the .csv file and then load into the Timelab.
When you convert the DAC values into "freq differences" by multiplying XXX x10^-12 (the figure 6) it is equivalent to measuring the OCXO frequency. So I do not understand why Lars suggested in the version 1 the "hold mode" (you do not make DAC corrections, free running OCXO, afaik) and the version 2 in "locked" one.
Maybe he forgot to mention you have to have the EFC wire disconnected?
With EFC wired you will see the picture as you have measured - as you are locked to GPS.
-
In order to find the optimum TC, I used method number 2 from the description in Lars's document (page12).
I used a TC of 4 and a damping of 0.5, and plotted the live DAC values of the CTI OCXO in Timelab.
I don't understand the results I'm getting as I don't see the "intersect" where "a reasonable TC can be found".
I know it has to be below 500, because that setting causes the lock to be lost.
This is the first time I'm using Timelab, it can very well be a pilot error.
Any suggestions as to what the meaning of the plot is?
Well the first maximum is obviously your TC. Apart from that - no idea. Does Method 2 really call for a damping factor of 0.5? I'd leave it at the default.
-
78xx are the poorest performers in terms of TC and noise
if voltage regulator noise is an issue here, maybe this is an interesting read/remedy:
http://www.wenzel.com/documents/finesse.html (http://www.wenzel.com/documents/finesse.html)
-
As you wrote above with TC=4 and damping 0.5 you got "almost unfiltered OCXO drift". That is good as it is equivalent to the version 1 (hold mode). By measuring the ADEV/MADEV you will see the unfiltered OCXO drift and 1PPS jitter, but it is still "locked" so the ADEV curve will not go upwards with larger taus (like with a free running OCXO), imho.
Your maximum below 10secs is the filter loop constant, then with taus>10secs it drops down - downward slope - Lars wrote it is the 1PPS jitter.
In the picture you see the downward slope from the PPS jitter. At some point the slope changes and the oscillator drift and noise is seen. At this “intersect” a reasonable TC is found. If the oscillator has a lot of drift the slope start to go upwards to early (remember that the I-term compensates for linear drift). One recommendation is to use the “subtract linear drift” in time lab.
[attach=1]
Let run it for longer time (ie 6-12hours) to see the "intersect with subsequent plateau" (if any :) ).
With 6 hours you will get up to 5000secs tau (at 1sec sampling period).
With your 1-2 hours long measurement the ADEV error in the 500-1000secs tau area is huge, it will decrease with much longer measurement (see below the "error bars" you may switch on), and the intersect becomes visible, hopefully.
[attach=2]
PS: the red curve above is for an OCXO which "jumps" - like loosing the lock - therefore the curve goes upwards with larger taus (typical for all "free running OCXOs").
-
I have started the test again, this time for 6hrs, and with a damping of 3.0. In earlier tests, I did use this damping factor, but it seemed to make no significant change.
As soon as the current test finishes, I’ll show the results, and I’ll field a few more questions, but I already saw that my earlier tests were just a bit too short to register the change. They do now.
Thank you for the comments and suggestions so far.
-
As has been reported earlier, the pwm stability is depending on the Vcc of the Arduino board. To address that, I want to use a better voltage regulator. Unfortunately, neither Mouser nor Digikey have the temperature stability in their selection criteria and my Google searches were fruitless.
Can any of you recommend a few types that fit the application, are easily and widely available and can be managed package wise by a hobbyist? SMD is not the problem, BGA’s and the likes are.
Thanks!
-
What sort of power draw are you looking at?
What about a current boosted voltage reference.
-
Hello, is this mini GPSDO PCB available for order or as gerber?
Hello for a few days testing versions of mini gpsdo. Very fast stabilizes OCXO.
(http://www.jo72.pl/kkm/gpsdo/1546033515401.jpeg),(http://www.jo72.pl/kkm/gpsdo/1546033412675.jpeg)(http://www.jo72.pl/kkm/gpsdo/1546033412764.jpeg)
Thanks to Lars for a very good project.
I wish you all happy and prosperous New Year
best regards
73 Marek SP4ELF
-
Vgkid, your suggestion to look for a "current boosted voltage reference" got me on the right track. Thank you.
One of the first finds was the LT6658, a dual voltage reference. That looks like a great part to use for the Arduino supply and also for the OCXO reference voltage, or, If I decide to go to a "real" DAC, the reference for that. With 10ppm/C, that should work.
-
Hmm, I would rather stabilize the output buffers as I indicated above in Reply #381. If not using those special voltage level buffers, you may use any 74HC logic in a non-inverting configuration and power the 74HC with your clean Vref. An example below.
[attach=1]
-
That is an interesting and simple approach as well imo.
I will certainly try that solution soon.
-
Hmm, I would rather stabilize the output buffers as I indicated above in Reply #381. If not using those special voltage level buffers, you may use any 74HC logic in a non-inverting configuration and power the 74HC with your clean Vref. An example below.
(Attachment Link)
Hi all, I'm following this conversation with great interest!
Build the original Lars design about a year ago ( how time flies!) and consider upgrading my unit using the new suggestions being made here.
One question about powering the 74HCxx from Vref:
First we try to have the cleanest Vref possible, would using it for the 74HCxx not make it dirty again?
Just wondering,
Un saludo,
Leo
-
As promised, I would show the results of my earlier test, to find the optimum TC setting.
Below is the chart that has the earlier test with a TC of 4 and a damping of 0.5 and also the newer test with TC of 4 and a damping of 3.0
With the first test, I used the default setting for the duration, which is an hour.
I plotted the DAC values, that were converted into a frequency with the factor 2.2E-12 (my gain is 455) and I used the Frequency Difference setting.
When I did the test again for 6 hrs, it showed that I needed to do the earlier test just a little bit longer. Bummer!
I have included both the ADEV and the MDEV charts.
Both were adjusted with the "drift line" setting.
If I understand it all, the optimum TC should be at the start of the "flat line", in my case 800 with the MDEV chart. With the ADEV chart, it could even be higher at 1,000.
Earlier, I was not able to get up to that value, I would loose the lock already at 500.
I'm now running another test by which I very gradually increase the TC in smaller steps (t4, 32, 64, 150, 250 etc.) with several hours in-between to let the loop system settle.
I'll show those results later.
-
First we try to have the cleanest Vref possible, would using it for the 74HCxx not make it dirty again?
You want to have the cleanest and most stable PWM DAC possible. Thus one possible approach is to detach the PWM drivers from the MCU (the major source of noise, imho) and feed them with an external clean voltage.
Vref in my picture above could be a separate one, not related to OCXO's Vref.
@dbldutch: happy to see it worked..
Intersect - I see it at 700secs with MADEV.. :)
-
UPDATED with finished chart
I was able to very gradually increase the TC value, and I'm now running at 700 seconds with a damping factor of 3.0 with a solid lock.
Below is the MDEV report that I started with 700s and a damping of 3.0. The filter is applied. Unfortunately, even 18hrs is not enough to bottom-out. Bummer. But, it looks like I'm on the right track.
What I still don't get is the hump in the beginning (from 0 to 11 seconds). I don't see that in any of the other charts people have made. Can somebody explain this?
In earlier tests, I was probably too fast switching from a TC level to the next, or took steps that were too large. From what I gathered, you need to have enough data fed to the PI controller so it is stable enough before you can take the next step.
Some of you have commented on automating this procedure. It would be nice if you could explain in detail what you have done. Most importantly are not only the TC step size going up, and on what condition(s), but also what to do when you loose the lock, or are moving towards loosing the lock. This would be a nice addition to the code Lars wrote.
PS the title in the graph says t4, but I forgot to update the text before I started a new one. The test was run with a TC of 700.
-
I don't have a particular implementation in mind, but it seems natural to detect a stable lock by looking at the integrator state for a longer period of time. If you find it's staying close to 0 for many TC, it will not hurt to increase it. If its value increases continually it is an indication that the loop cannot keep the lock and a shorter TC should help.
-
Because I have two broken Bliley OCXO’s, both without the 10MHz output, I contemplated opening them up and see if I could possibly fix them.
Not that I had high hopes of fixing them, but I was interested to find out what is in the little cans as well.
Luckily, I didn’t need to get destructive, it had been done before:
https://www.eevblog.com/forum/metrology/teardown-of-bliley-ocxo-module/25/ (https://www.eevblog.com/forum/metrology/teardown-of-bliley-ocxo-module/25/)
After seeing the complexity of the circuit and difficulty in opening the can, I’m pretty sure my efforts would be fruitless.
They will get a good and final resting place.
-
I finally got the replacement for a Bliley OCXO that I ordered after I had 3 dead ones.
This is a NV47M1008, the M indicating it has a CMOS square wave output. Makes it easier for this application.
The circuit I published earlier has been modified and I implemented the suggestion from imo to separate the DAC PWM signals from the Arduino circuit with a pair of HC14's, to make it cleaner.
Because I don't have a better voltage reference in my stash that can drive a few mA, I used an LM4040 4.096V Zener shunt. At this moment I'm unsure if it's better to also power the VC circuit from this reference. Currently, because the Bliley has a 4V reference voltage, I'm using that. I can be convinced that it's better (temp co-efficiency) to have both circuits powered by the same reference voltage. BTW, I tried to use the Bliley V-ref to power the HC14 to no avail, as can be expected.
Here is the circuit I'm using for this OCXO. It can be easily changed for other types and brands.
With the current resistors for the DAC and VC offset, my gain is 231, a little on the low side. The ideal value should be around 500. After a few days of burn-in, I will raise the value of the 68K to 82K to reduce the frequency span, which is 3Hz at the moment.
Tests are running, I'll report them later.
-
Now the fun begins. I'm amazed that you guys achieve such high TC. It would work for a while but always lost lock within a week. Maybe the CTI OCXO is just too drifty (but is that what Miti uses?). I never got around to setting up some MTI OCXO's I had because they are 12V units and would tune 0-10V. A lot of interesting ideas to think about now...
-
implemented the suggestion from imo to separate the DAC PWM signals from the Arduino circuit with a pair of HC14's, to make it cleaner.
I see most timenuts uses HC04 AC04 as buffers , they say it's cleaner than than HC14.
Prob. the Schmitt that adds hysteresis.
Ie.
https://www.tapr.org/kits_tadd-3.html (https://www.tapr.org/kits_tadd-3.html)
http://www.tapr.org/~n8ur/TADD-3_Manual.pdf (http://www.tapr.org/~n8ur/TADD-3_Manual.pdf)
/Bingo
-
Experienced timenuts would advice you not to put logic gates, which work with different clock domains, into the same package.. It may come to "pulling", "beating", etc. :)
I wished someone measured those effects..
-
I'm struggling with my 4th Bliley, a model NVA47M1008 OCXO with serial number 285 0603.
I see massive jumps making this specimen practically unfit for this application. I'm not showing this, but the system recovers eventually.
This happens every couple of hours.
I've seen others reporting oscillator jumps, Lars included, unfortunately, they did not provide much information.
Not sure if this is a typical case, please chime in if you know more.
Another Bliley hits the dust.
-
Would that be on the order of a phase inversion? I seem to recall something about A/B/C mode operation of the oscillators, but not that they would switch modes during operation. I've had some power up in 'B' mode, 10.7 or 10.9MHz.
-
I'm struggling with my 4th Bliley, a model NVA47M1008 OCXO with serial number 285 0603.
I had massive injection locking problems with cheap Blileys. They were 100MHz but internal design was similar to 10MHz. Watch out.
I am curious as to why you are using internal Vref for the tuning voltage base? You are loading already very simple internals of the OCXO. Vref is generated internally by nothing more than a cheap 4.0V LDO which is then followed by an emitter follower (or capacitance multiplier if you will) and designed to be used as a crutch for a tuning trimpot in cases when there is no electronics around the OCXO. Tuning voltage is not ratiometric to Vref, so you just need a good stable low noise voltage - you probably already have it on your board elsewhere.
What I still don't get is the hump in the beginning (from 0 to 11 seconds). I don't see that in any of the other charts people have made. Can somebody explain this?
Do you have any running averaging going on in your data? Averaging will artificially improve ADEV or MDEV for shorter tau and will look like a hump.
Cheers
Leo
-
I'm struggling with my 4th Bliley, a model NVA47M1008 OCXO with serial number 285 0603.
I see massive jumps making this specimen practically unfit for this application. I'm not showing this, but the system recovers eventually.
This happens every couple of hours.
I've seen others reporting oscillator jumps, Lars included, unfortunately, they did not provide much information.
Now that you mentioned , that may be the issue with my Lars GPSDO. Something “jumps” randomly and I didn’t figure out what is it. It may stay locked for months, then loose lock few times a week. Every time it shows a big jump in ns. Details in some posts not to far above. I’m using a Bliley NV... something from Ebay
-
Hi Leo,
Thank you for chiming in.
I used the Bliley Vref in the hope it would provide a better thermal "connection" to the frequency setting circuit because the Bliley Vref circuit is inside the ovenized enclosure.
With all the data we collected, it's probably better to not use the Vref output on any OCXO at all and use a separate Vref circuit that can power the complete DAC circuit.
I tried an LM4040 4.096V Zener to power the DAC with the HC14 circuit, but there is still too much jitter.
Maybe a bit overkill, but I'm now using a 5V reference, the REF02EZ and I switched to my CTI OCXO again.
I use the Lars program to collect the DAC data, so there is no extra filtering afaik. I have seen some small humps in other charts, but none as big as mine. I'm not sure that bigger is better. ;)
-
Could it be a bug in the software?Some integer overflow not handled correctly?
-
After switching back to my CTI OC5SC25 OCXO, I ran a new measurement with the modified PWM DAC setup to determine the optimum TC value.
This test setup is explained in Lars's document as option 2 on page 12. I used a TC of 4 and a damping of 3.0.
The results are astonishingly different. :-//
Please help me to explain this vast difference.
Not very scientific, but this has changed between the two test setups:
1. The first test ran with live data, the second is an import from Excel made from the Arduino serial monitor.
2. With the first version I used a current boost circuit to reduce the temperature of the 7805 voltage regulator. With the second setup, I only use a 7805 regulator. (see the circuit diagram in the post just above)
3. For the second setup, the PWM/DAC circuit was moved from the Arduino board to the OCXO board and I added 100nF caps in parallel to the 4.7uF Tantalum caps. The PWM/DAC outputs (D3 and D11) are now connected through 20cm Dupont patch cables. In the previous version, these cables connected the output of the DAC circuit to the oscillator board. All connections between the two boards are made with these cables.
4. The second version uses the 74HC14 per imo's suggestion to reduce DAC noise from the Arduino supply.
5. For the second version, a REF02 5V precision voltage reference was added to supply the complete PWM/DAC circuit.
6. The gain for the first setup was 455 with an f delta of 1.4Hz, the gain for the second setup is 303 with an f delta of 1.1Hz.
7. Note that both setups already had the 10MOhm removal modification implemented. See my earlier posts.
8. The dip in the OSXO temp in the beginning is the dropping of the ambient office temperature for the night.
9. The OCXO board is covered during the tests by a plastic container to reduce draft effects.
My questions:
1. The mysterious (for me) hump in the old setup is gone. Why?
1. Are the hardware changes plausible cause for these results?
2. Where do the wriggles/oscillation come from in the new setup?
3. Why are the ADEV and MDEV charts so different for the new setup? (both have the drift line filter applied)
-
Your MADEV's sigma at tau=1000secs is now 1000x lower than in previous measurement.. That's suspicious.. :)
The oscillation - it could be you now operate in a sigma region where more finetuning is required.
I would boost the REF02's output current with a PNP and 220ohm resistor. It should not have any impact on noise and stability of the REF02's output. Add a 10uF tantalum (parallel 100n) at the output. For example:
[attach=1]
-
If you're talking about the hump at tau = 4s, that would be the effect of your control loop TC combined with the settling time of the PWM DAC.
If it's missing in the second setup, the settling time of the PWM DAC must have dramatically changed. It's now completely masking your loop TC.
-
I would also calculate the rms values of your above measurements (ns, DAC, ns-diff) - good for comparing the configurations. In your excel:
=STDEV.P(C:C)
where the ie. C is the column with your data.
-
I do not see a significant change in the PWM DAC settling time with the HC14 buffer - about 2.5 seconds in dbldutch's wiring.
My improvement N3.: I would wire a choke (10uH-100uH) in series with the EFC (at the OCXO's EFC input), best made of a small toroid. It will dampen 10+MHz leakage off the OCXO into the DAC.
-
1. The first test ran with live data, the second is an import from Excel made from the Arduino serial monitor.
Doublecheck your TimeLab settings. It could be you made a typo in the "Numeric Field" multiplier setting..
-
Hi all, thank you for the inputs. Interesting puzzle eh?
Here are some answers:
@thinkfat:
The most significant change has been the move of the PWM/DAC circuit to the OCXO board. Previously, I "transported" the very sensitive output with two un-shielded 20 cm wires to the OCXO board. Now the digital outputs are send across the wire and the whole (sensitive) circuit is close to the OCXO. That might explain the hump removal?
@imo
The standard deviations are :
ns 6.946
DAC 373.856
OCXO temp 0.226
diff_ns 9.552
filtx10 44.760
I have attached the Timelab settings for both measurements. The only obvious difference is in the Numeric Field. This value is calculated according to Lars's document on page 12 as 1E-9/gain. I already listed my gains. (Using e12 or E12 makes no difference)
I don't see a glaringly obvious explanation.
According to my reading of the datasheet, the REF02 should be able to deliver 10mA, and that should be more than adequate. I will try your suggestion.
I'm not sure I have a choke that I can use. I'm not very experienced with them, so I will have to research and learn and see if I have something in my stash that I can use or modify.
If (big IF) the modifications are indeed the cause of the major changes, my next step would be to try a "real" DAC with a reference, built in or not, like many of you suggested or already use.
I'm now running a test with a TC of 500 and damping at 3.0 and the prelim. results are strange as well.
-
I think the MADEV values below 1e-12 at tau=1000 are pretty unrealistic numbers, unless your OCXO is a fake and it is rubidium or cesium inside .. :)
The new PWM DAC cannot introduce such a huge difference, imho.
There is an issue somewhere..
The 5V/10mA could be ok for driving a 10k pot trimmer, but you have got there 4x HC14 inverters, which pull some current when in transition 0/1/0.
PS: the bottom "peaks" of the madev are spaced in 60secs period, it seems..
PPS: could you post your raw data from the last measurements, plz?
-
@imo,
Here is the zipped Excel file with the latest numbers of entries of the current test with TC 500 and damping at 3.0.
-
What I see off your data:
1. raw DAC data, 20.3 units RMS
2. madev with DAC*3.3e-12, freq difference, all trends subtracted
3. freq diff
4. setting
-
You have imported 3rd data column off the file, that are the "seconds" of the time information. Therefore the peaks with 60seconds period in your MADEV.
You have to import the 6th data column off your file.
-
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
-
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.
-
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. :palm:
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?
-
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.
-
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 (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
-
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
-
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.
-
Could you post the raw data for "CTI tc4 a3.0 V3" plz?
-
Hi imo, here it is.
-
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..
-
@ 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.
-
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.
-
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?
-
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.
-
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-list.htm)
http://leapsecond.com/pic/picdiv.htm (http://leapsecond.com/pic/picdiv.htm)
-
@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.
-
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.
-
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.
-
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.
-
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.
-
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..
-
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-
-
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.
-
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.
-
---- 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)... :--
-
http://www.leobodnar.com/files/162Stable32.exe (http://www.leobodnar.com/files/162Stable32.exe)
Bill has same dl problems and said that Stable32 Version 1.62 is the property of the IEEE UFFC. However, since it is freely available to all, he does not see any problem making available a downloadable copy. It should be also available on his website at http://www.wriley.com/162Stable32.exe (http://www.wriley.com/162Stable32.exe)
Link for download is active on IEEE site, but download process stops with error after approx 10% received (regardless of browser used)...
-
Hi all,
I ran another test again, this time with a TC of 500, and I also added the temp correction.
Here is how I figured out the two factors, following the example Lars has given in an earlier post.
To calculate the tempRef factor, I used the average OCXO oven temp. My sensor is pressed to the CTI case by elastic bands. It reads an average temperature of 50.8 degrees C, so I entered a factor of 508.
To calculate the tempCoeff factor, I used the 10 ADC steps per degree C. With a temperature drop of 0.5 degree C, this means -5 ADC steps.
When the OCXO temperature drops 0.5 degrees C, my DAC changes 100 steps. The temp factor is then 100DAC/-5ADC = -20 The tempCoeff factor is then -20 * 100 and inverted becomes 2,000.
Below are the results from TimeLab. There is a long period of minimal DAC changes that are a mixture of the TC factor of 500 and the temperature corrections. My overall precision improved a bit compared to the graph with a TC of 200 just above in an earlier post.
From the Excel data you can clearly see the period of very good stability as well. It turns out that the instability comes from the heating system changes.
At 22:00 hours the heating system goes to night-time and the heater in my office turns on at 9:00 o'çlock.
I have a system by which I can set and monitor the individual radiators in rooms, and I also monitor the central heating system itself. The last graphs show the heating activity in my office, and below it you can see the heating system activity itself. I track the water temperature going out and back in. The instability during the daytime is caused by me entering the room and doing work within a feet of the GPSDO, and also the effects of the heater turning on and off. The heater activity is represented by the black lines in the heater graphs.
The net-net of all this is that the GPSDO at this level of precision is far more sensitive to ambient temperature changes than I anticipated, and using the sensor connected to the OCXO may not be the best method to correct this.
I will now add another sensor on the processor board and start to use that for the compensation factors.
-
Putting the stuff into a paper box is not enough, imho. Make a box from ~3-4cm thick polystyrene and put there the OCXO and all the electronics (including Neo and voltage regulators, the OCXO's heater will stabilize the temperature inside the box). I bet you get a stability as within 40k-80k secs in your graph above, or better.
-
Haha imo, Chineese food in a paperbox is typical for the US, we get it in plastic boxes that are great to store food in for the freezer. ;D
I do take your point though. Right now, my controller board and the OCXO board are in separate flimsy plastic containers. The controller board does not benefit from the OCXO temperature, which is what I track and is very stable. I designed a PCB that will arrive later this week. It will fit into a metal enclosure and I can add insulation on the inside. The board features all the modifications we talked about, but can also be removed and can take all of my current OCXO’s and the 8663 Oscilloquartz that will arrive soon as well. I found enough parts under the Christmas tree to build up several boards so I can start to compare. How to do that will be a new topic I will need some help with defining so others can hopefully benefit as well.
I’m gradually becoming a (novice) time nutter... :palm:
-
My pcb's came in and I build-up the GPSDO with the CTI OCXO.
I'm running several tests and I'm now trying to tweak the temperature compensation.
My special insulation sheets are not in yet, so I use bubble-wrap to insulate the inside of the box for now.
First results look pretty good, better than by using the two protoboards.
I'm using an old front-panel, but I designed a replacement pcb that is on order.
I had to make a few changes to the circuit and the layout already because I goofed up twice, and otherwise made some enhancements after going through the first build-up.
When I'm done with the layout changes, I will publish the Gerbers.
Here are some first pictures.
The colored wires go to my Raspberry Pi monitor.
Update: I inadvertently did not update the tracefield in the TL screenshot. It was made with a TC of 500 and a damping of 3.0, I have updated the chart.
-
How to interpret the above MADEV with TC=4?
Pretty different to Lars' picture.
-
Hi imo,
I goofed by not updating the Trace field in the TL chart. I corrected and updated the chart.
It was made with a TC of 500 and a damping of 3.0.
-
Could you try with TC=4 too?
-
Hi imo, I started with that to do a first check and to determine the optimum TC.
This is made with a TC of 4, damping 3.0, gain 285, TL factor 3.5087E-12, no temp corrections.
The enclosure was still without the cover and front/back panels but everything was in a bubble bag together with the Raspi monitor.
See anything interesting?
-
Based on the picture your OCXO has some drift and/or jumps.
-
imo, that's not supported by the raw data but I agree that it looks a bit weird.
Granted, this run was the very first thing I did when I finished the pcb, so the temperature had not settled yet.
I'm running another test right now to figure out the temp compensation, but now that the GPSDO has settled in its new home, I will re-adjust the DAC setting, recalculate the gain, take out the temp correction entries and redo the TC4 measurement again.
After that I will switch to my second pcb with the IsoTemp OCXO and start that up.
-
I've removed first 6k and last 8k points from the measurement (unstable temp).
For record:
DACp-p = 2900 (1.02e-8)
DACstd = 343 (1.2e-9)
-
Thanks imo,
It seems that every time I run a test, TL produces different curves I can't explain. I'm getting frustrated and annoyed. |O
The updated chart shows that. Both IsoTemp plots were made under exactly the same conditions, one day apart. The green trace is the latest. Seems too big of a variance to me.
I'm afraid now that I'm hi-jacking this thread with my issues, but on the other hand, other newbies could potentially run into the same situation.
I considered starting a new thread, but this is so closely linked to the Lars GPSDO method of measuring the DAC results with TL that I decided against it. I hope I'm being excused. :-// I apologize up front though.
I ran a new TC4 test for the CTI, properly warmed-up for a few days in the enclosure and during the night (no disturbances).
At the same time, I also ran a TC4 test for the IsoTemp, properly warmed-up for several hours, in a bubble-wrap bag and also during the night. (don't have another enclosure yet)
The TC4 tests are described on page 11-12 from Lars' documents, and I used the second method to find the optimum TC.
Below are the combined results.
It seems that after warming-up, the CTI results are a little worse compared to the first plot. You would think that it would be better.
Although I'm easily running the CTI with a TC of 500, the MDEV plot seems to indicate an optimum TC of about 200 for both. Two hundred seems to be pretty poor.
The MDEV plot seems to indicate that the TempTech OCXO (bottoms at 1.37E-11) is not as good compared to the CTI which bottoms at 7.05E-11.
However, from Lars' comments on page 12, the sharp upward trend after bottoming out for the CTI indicates that it has a lot of drift.
The frequency plot shows no serious frequency jumps, but this plot also seems to indicate that the IsoTemp has a lot more noise/jitter compared to the CTI, which is much more stable. This to me seems to contradict with Lars' comment about drift on the MDEV plot.
What does the wriggle in the curve of the IsoTemp show after 4.000 seconds? What does that mean?
So can you infer the better OCXO by using the TC4 measurement results and if so, which is the better OCXO and what TL plot determines that?
-
While running a test with the free running OCXO, I noticed a gotcha, but at the same time an interesting feature.
When you select h0 to hold (freeze) the DAC value to be able to see the drift of the now free running OCXO itself, the DAC still gets updated if you activated the temperature and the tempCoeff settings. This temp compensation creates peaks in the diff_ns values and wriggles in the ns values everytime the DAC is forced to change to a new value. Because the temp values are not very stable, there is a period of these wriggles until the DAC changes to a stable value.
So, make sure you set the tempCoeff to zero before you start the test.
Another hint is to first select a lock with a reasonably high TIC value (100-250+) before you invoke the h0 test. This makes the drift line a little less drastic because the DAC value is then pretty close to the GPS synchronization.
The side effect of the "incomplete" DAC hold is that you can clearly see the effect of temperature changes on the DAC based on the tempRef and tempCoeff settings, which is otherwise not so easy to verify and check.
-
Applying temperature corrections while in hold mode is actually a pretty important feature for "holdover". I'm very sure this is by design and not a forgotten corner case.
-
@thinkfat, I called it a gotcha, and not an oversight or bug for the same reason.
-
It's only fitting that after my last post from exactly 6 months ago it is followed-up by a new one today.
I'm still learning, experimenting, fiddling and adjusting with this project. I have three working units, and I'm trying 5 different OCXO's in them, with mixed results. Because the electronics and software are identical, I can really zoom in on the OCXO performance the two different UBLOX GPS modules I use.
While hunting for the cause of lost lock's, I noticed a strange phenomenon on two of my OCXO's, the Bliley and the IsoTemp ones. The third is my best, the Oscilloquartz 8663-XS.
I'm using the Bliley as an example here, but the IsoTemp reacts the same way.
The Bliley with model number NV47M1008 has a gain of 440 and I'm running it with a TC of 500. With that setting I'm loosing the lock every now and then, but that's not the point.
The first picture shows a typical run with the Bliley. I've only selected a smaller portion of the data to show the effect. It's pretty clear that I loose the lock because the ns value goes beyond +/- 100ns. The Lock shows this as a reference. Note the Ambient Temperature graph. There is a dip at exactly the time where the Lock is lost. I can't explain this drop in temperature. The ambient LM35 sensor is "lying" on top of the section with the diode and 1nF capacitor, because it is the most sensitive to temperature changes. My OCXO's are all isolated in a hard foam box, even from the PCB. The OCXO temperature is not really influenced by this.
The second graph zooms in on the data and shows the leading edge of loosing the Lock and it shows that the temperature starts to drop after the Lock is lost. The third graph shows the trailing edge and you can see here that the ambient temperature starts to rise after the Lock has been obtained again.
I know that my Trimble, Bliley and the IsoTemp are prone to sudden changes in frequency, which is why the loop cannot compensate fast enough. I've tried a lower damping factor (down to 1.5), to no avail. The reaction time of the loop is too slow at a TC of 500 for the Bliley, and at a TC of 200 for the IsoTemp, which I'm running with a gain of 617.
Can anybody shed some light on this dropping ambient temperature phenomenon?
-
Two things:
- If you can log the power consumed by the Arduino board, try correlating that graph to the temperature log. How much power does the "Lock" LED consume? It goes off when you loose lock.
- Try with a larger "filterDiv" parameter, to speed up the loop response. At large TC, the TIC prefilter is maybe too aggressive.
-
Thank you thinkfat for the suggestions.
I thought about the LED, but it has a 220R resistor in series for a maximum of 22 mA. I doubt it has that much effect on the temperature inside the enclosure, but I can easily unplug the LED from the circuit and see if it makes a difference.
At first I thought about the 12V wall-warts producing a higher voltage at times, I use identical ones for both units. The Oscilloquartz version uses a 15V one.
That possible cause has been eliminated by switching to a 12V battery cell with a carefully set charge level.
By filterDiv, you mean the prefilter set by the p command I assume, because Lars uses two different names for the same thing I think.
Right now it is set at the default value of 1 second. Possible settings are 2, 3 or 4 seconds. Making the loop response faster by using a longer prefilter seems counter intuitive, but I'll give it a try.
Stay tuned...
-
Thank you thinkfat for the suggestions.
I thought about the LED, but it has a 220R resistor in series for a maximum of 22 mA. I doubt it has that much effect on the temperature inside the enclosure, but I can easily unplug the LED from the circuit and see if it makes a difference.
At first I thought about the 12V wall-warts producing a higher voltage at times, I use identical ones for both units. The Oscilloquartz version uses a 15V one.
That possible cause has been eliminated by switching to a 12V battery cell with a carefully set charge level.
By filterDiv, you mean the prefilter set by the p command I assume, because Lars uses two different names for the same thing I think.
Right now it is set at the default value of 1 second. Possible settings are 2, 3 or 4 seconds. Making the loop response faster by using a longer prefilter seems counter intuitive, but I'll give it a try.
Stay tuned...
The prefilter length is computed as "timeConstant / filterDiv". At TC=500, a filterDiv=1 gives a prefilter time constant of 500. Try 30.
What ublox modules are you using? The "ns" log shows quite a lot of deviation, more than +/- 50ns. Even without sawtooth correction, it's should not be that much. With my own design, using a NEO-M8T, after Survey-In completes, I never get more than +/- 10ns of deviation when running TC=500.
-
Hi Thinkfat, thank you for the suggestions.
After going through Lars' notes, I realized that I misunderstood what the prefilter or filterDiv stood for.
A short sample of the normal rate for the "ns" log is posted below.
I don't think this is dramatic for a NEO-M8N. With an outdoor active puck antenna I always have in excess of 20 satellites of which 10-11 are above 20dBHz signal levels.
[attachimg=1]
The more or less wild gyrations of "ns" start with a higher TIC value. The Bliley has an "ideal" value in excess of 1.000. I have been using 500, which is not too ambitious, but I loose lock too often. At 500 I wanted to see what I could do by tweaking the hardware, mostly looking at the supply decoupling. Maybe the incorrect FilterDiv setting is the problem. For some reason, all my three units had a filterDiv setting of 1. :-// I don't recall ever having changed them. In any case, I'm now running new tests with the filterDiv at 2, and the lock LED disconnected.
BTW, here is a short sample of my Oscilloquartz 8663-XS which uses a NEO-8MT in the fixed position mode. It shows what my hardware is capable of.
[attachimg=2]
-
I really ought to get my Lars GPSDO's assembled :phew:
Re Oscilloquartz
I'm just doing some Oscilloquartz Star-4 GPSDO - Burn in logging w a FS2 counter 10s gatetime , and a Trimble Tbolt as ExtRef.
Turn on time 3 weeks , and the DOCXO is beginning to settle.
/Bingo
-
I'm running another set of tests, after making some tweaks to the hardware, but also with the FilterDiv setting on 2 instead of 1.
Here are the results, just so you can see the difference between the two settings. This is from different runs, so the data is not the same but you can easily see that the DAC values much more closely follow the ns excursions, keeping the loop tighter.
This is the IsoTemp OCXO with a TC of 4, Damping 3.0 and FilterDiv 2.
[attachimg=1]
-
The LED for the Lock was disconnected, the dip is not as deep, but it's not the root cause for the temperature drop. I suspect that the Arduino activity during the lost lock is causing the on-board voltage regulator to drop temperature. That regulator is powering the LED too. This is not so easy to verify.
[attachimg=1]
-
I'm running another set of tests, after making some tweaks to the hardware, but also with the FilterDiv setting on 2 instead of 1.
Here are the results, just so you can see the difference between the two settings. This is from different runs, so the data is not the same but you can easily see that the DAC values much more closely follow the ns excursions, keeping the loop tighter.
This is the IsoTemp OCXO with a TC of 4, Damping 3.0 and FilterDiv 2.
(Attachment Link)
Just one question: Is the X axis seconds or minutes?
JBG
-
Seconds, tracking the output of the "Lars" program.
I'm feeding the Arduino with a regulated 8V input, and I've isolated all other circuits from the 5V output of the Arduino. There is only a 100uF cap on that pin now. The Arduino drives the lock LED of course. My assumption is that the Arduino spends less time filtering when the lock is lost, and loss of activity together with the switched off LED causes the temperature drop. I have three units, all with different OCXO's, and all three show the same behavior. You can only witness this when the OCXO is thoroughly isolated from the rest of the circuit, otherwise that temperature dwarfs the ambient temperature excursions. I'm measuring the ambient temperature with an LM35 on top of the R1/C1/D1 components.
Go figure... :-//
-
have you already set up your temperature compensation?
-
Hi Thinkfat,
No, I did not setup the temp corrections yet, as a matter of fact, I took them all out to help track down the much bigger issue that I have. I'll describe that in a separate post.
Besides, if you look at the data in my post #466 (top right hand graph), you see that there is not a great deal of DAC deviation caused by temperatures that is worth compensating.
Thank you for helping me out though.
-
I promised to show one issue that I had with my setup. This is a typical "trap for young players".
For several months I suspected bad behavior from my OCXO's, but because I have 5, with only one behaving as expected, I just couldn't believe 4 out of 5 were bad. I suspected temperature issues and the PWM/DAC circuit, but could not prove anything with the equipment that I had.
I've just found the problem, but only after modifying my DIY micro-Volt meter by adding logging capabilities.
The symptom was that I saw strange out-of-lock events that I could not explain. If you look many posts back, you can see that I used a suggestion from imo to isolate the "DAC" output pins from the Arduino 5V rail. The Arduino does some strange things to the ambient temperatures as I've found out, so isolating that circuit from the very sensitive rest as much as possible is a good thing. I used 74HC14 gates between the Arduino "DAC" outputs and the PWM filter. The 74HC14 got it's own 5V supply, generated by a REF02 voltage reference. Following another suggestion from imo, (post # 415) I added a current booster circuit that used one transistor and a bias resistor. There are several versions of that circuit that I've found. Here is another one:
[attach=1]
I fed that circuit with the output of an LM7808. This regulator feeds all the other separate 5V supply rails. In hind-sight, that was a mistake, I should have used a higher voltage. According to the REF02 specification, 8V is the minimum. When you measure the output voltage, it is fine and stable, so I didn't suspect it. It did see some oscillation on the output with a scope, and I removed a 2.2uF tantalum cap directly on the output of the REF02 to get rid of it. Although this was according to the datasheet. I also changed the transistor to a 2N3906 because that gave me better regulation.
When I was finally able to use my modified micro-Volt meter on the VFC output, I noticed glitches that shouldn't be there.
Below is a plot to show what I mean. These glitches are not coming from the DAC.
When I tracked the output of the REF02, I noticed the glitches on the last picture below. (both pics have a horizontal scale of 1 second per data point)
My assumption is that the regulation of the REF02 is compromised when the voltage of the LM7808 drops below a critical level. (if you use a micro-Volt meter on the output, you'll be surprised how wobbly these 78XX regulators are) The 220 Ohm bias resistor is also in-line with the REF02 input, and that drops the voltage below a critical point, causing the REF02 to sometimes get out of regulation, and causing the glitches on the output.
The REF02 only powers 4 gates of the 74HC14 plus the PWM filter and bias setting resistors for the OCXO. I measured the load to be less than 4mA, while the RF02 can sink 10mA. The booster is not needed, so I took it out, eliminating these mysterious glitches that haunted me for months.
Having fixed that, I can now continue to see if I can further improve the results some more, because I'm still a long way from where I think I can get to.
Stay tuned...
-
thinkfat,
In your forum post about your own development (DIY GPSDO project w/ STM32), you mention in post #192 that you should not use SBAS and should not use multiple constellations.
There is very little written about setting-up NEO's specifically with the Lars' system.
When I switch to only using GPS, I loose track (No PPS) for short periods of the sats several times a day as an example. Unfortunately, I only have access to an East facing windowsill on my 3rd floor apartment, so I need better coverage.
Can you give us the rational about using only one constellation? Is there a switch-over issue from one to the other in addition to what is in the u-blox M8 Receiver Description manual at paragraph 4.2.1?
Many thanks in advance
-
thinkfat,
In your forum post about your own development (DIY GPSDO project w/ STM32), you mention in post #192 that you should not use SBAS and should not use multiple constellations.
There is very little written about setting-up NEO's specifically with the Lars' system.
When I switch to only using GPS, I loose track (No PPS) for short periods of the sats several times a day as an example. Unfortunately, I only have access to an East facing windowsill on my 3rd floor apartment, so I need better coverage.
Can you give us the rational about using only one constellation? Is there a switch-over issue from one to the other in addition to what is in the u-blox M8 Receiver Description manual at paragraph 4.2.1?
Many thanks in advance
The documentation of the ublox m8t receiver recommends to not enable SBAS, because it will degrade the stability of the time pulse (see chapter 19.2) I have found that, too. SBAS is also primarily interesting for navigation, it has no benefit for timing.
The recommendation to only enable one major GNSS is from own experience - however, if you don't have sufficient sky view, this is a moot point. It is then more important to have satellite coverage, as obstructed sky view will degrade the timing precision anyway.
What I'm experimenting with right now is to enable SBAS only during survey-in under the assumption that the position average will converge quicker with the increased fix precision.
My current setup has GPS and Galileo enabled as major GNSS' permanently, with SBAS being switched in only during survey-in. My software handles that automatically.
-
I have finally found the root cause of the poor performance of my GPSDO's. It turns out that I have been looking in the wrong places.
To recall, I have 5 different OCXO's that all showed strange events that were difficult to explain, so I blamed it on the OCXO's. For several months they have been nursed back to an easy life after the most likely rough handling and transport. To no avail. The strange phenomena didn't go away, even though I was able to fix several smaller issues.
It turns out that my GPS modules, in combination with my geo position, the sky view and the place of the antenna, is the root cause. As I mentioned earlier, my puck antennas are located on a metal windowsill on the outside of my apartment. The window in the apartment building is East-facing, and there is another floor above me. This results in a very restricted eastern sky view.
I have three different GPS modules, a NEO-6M, a NEO-M8N and a NEO-M8T. The 6M and the M8N are confirmed Chinese fakes. As far as I can tell, the M8T is a genuine u-blox one. (also purchased from a french guy, probably the same one thinkfat got his from) The 6M has poor reception and is limited for my particular situation. The M8N seems to work fine, although it does not restart with the saved configuration. After a power-cycle, I have to put in the setup again.
Strangely enough, the M8T refuses to accept the activation of the Galileo sats. (I use the right NMEA version of 4.1) When I program the setting, it flips the activation check mark back to inactive. It does not show any min/max channels for Galileo either. Hmmm. Other than that, it seems to work fine. (it does not have the right firmware, see update below)
Here is a typical example of the best performance I could wring out of the GPSDO with the M8N and the Bliley NV47M1008 OCXO. These charts were made with a gain setting of 442, damping at 3.0, prefilter at 2, and a tc of 500.
[attach=1]
Note the swings in the "ns" chart between about +/- 50, compared to the rather good diff_ns chart. The sudden glitches that happened several times per day in the ns chart forced the GPSDO to loose lock. All of the OCXO's that I have and tried showed the same problem, so I have been hunting for these strange events.
For the last couple of days I have been switching the hunt to the GPS modules themselves because I was more and more convinced that the hardware performed as it should. While changing the NEO configurations with u-center, I noticed that the 6M would only see GPS sats. It looked like there were enough, always more than 3, so I set the minimum to 3, and the inclination to 20 degrees. Since then I lost lock with the sats every now and then. That put me on the right track.
I continued to change the settings on the M8N and the M8T and was eventually able to raise the tc to 1,000 while keeping a GPSDO lock.
I knew my M8T was better, so I took the 6M out of the GPSDO socket and mounted a BNC on the front panel with a connection to the now empty NEO socket. I fed the 1PPS output of the GPSDO with the M8T into the new BNC, in effect feeding that GPSDO with the reliable M8T 1PPS signal. Below is that result (Bliley tc 1000):
As you can imagine, I was elated with this result. I was finally convinced that my hardware is capable and working really well. Although I'm running with a gain of 442, I'm going to see if I can double that to get a better resolution for the DAC.
With this result it now turns out that my "reference" GPSDO with the M8T and the Oscilloquartz 8663-XS OCXO at a tc of 1,000 has some issues that I now need to hunt down. (Oscilloquartz tc 1000) It turns out not to be very stable. On my scope, the back-and-force drift between the Bliley and the Oscilloquartz 10MHz out wave-forms is very noticeable. I also still have issues with the M8N as well, so my conclusion for now is that in my particular case with my geo position and the limited sky view, the Chinese fakes have issues and are not good enough. Buyers beware!
[above edited for clarity & update:]
I have found that there is a huge difference with the Fixed Mode setting in TMODE2. Without the fixed mode, the readings are all over the place, and it shows on the TIC results as well. I ran a 24hr survey and used those results in the Fixed mode setting, and that improved the stability of the TIC dramatically.
My M8T does not have the required firmware and although I found it and tried, I can't load it due to communication errors with the device. Upgrading the fw for the M8T apparently is not without risks. In any case, that's why I don't have access to Galileo.
-
I managed to get the firmware of my M8T upgraded to 3.01
It was not easy.
The firmware file is hard to find, I found it here: https://www.eevblog.com/forum/metrology/u-blox-m8t-firmware-fw-3-01-tim-1-10/ (https://www.eevblog.com/forum/metrology/u-blox-m8t-firmware-fw-3-01-tim-1-10/)
The procedure to do the actual upgrade is not clear either.
I found a good howto description here: https://www.junipersys.com/data/support/Mesa-2-Ublox-GNSS-Firmware-Update.pdf (https://www.junipersys.com/data/support/Mesa-2-Ublox-GNSS-Firmware-Update.pdf)
Even then, there is one thing missing.
[attachimg=1]
In the field for the FIS file, you need to set the link to the flash file that came with your u-center installation. The flash.xml file is located in this directory.
Lastly, it does not take 30 seconds as is mentioned in the document, it took about 5 excruciatingly long minutes.
Don't forget to set the NMEA Version to 4.10 in the NMEA Protocol setup. (Version 4.11 did not stick, it reverted back to the old version)
I'm now acquiring the Galileo sats.
Enjoy!
-
The effect of a GPS glitch on the GPSDO.
I've noticed the following event while tracking my M8N GPS module.
Here is what happened in the u-center dashboard.
[attach=1]
My M8N reception uses a minimum SV elevation of 15, a threshold of 4 SVs and a minimum of 20dBHz. Notice the fact that I have many satellites with more than adequate reception quality. This is with the stationary configuration setting, so I'm a little surprised to actually see this result, even though I only have an eastern sky view.
The M8N is in my Oscilloquartz GPSDO, and that shows an immediate loss of lock. The settings are gain of 987, tc at 500.
It shows that the GPSDO is very sensitive to the GPS module performance, even though there are many satellites in view.
My other GPSDO's with the Bliley and the CTI both driven by the 8MT in the stationary setting and with the timing mode in the fixed configuration do not show anything of a glitch at all.
-
Using the "TIME" mode is one major contributor to GPSDO stability. The other one is "sawtooth" correction. The first one can be achieved easily under the command of u-center. The latter will require major changes to the GPSDO control software.
-
My Oscilloquartz based GPSDO is now
slaved connected to the master NEO-M8T, and the results are pretty remarkable. The switchover happened at about 45.000 on the horizontal (seconds) scale.
This is with a TC of 500 and a gain of 987.
I think I have found my root cause...
[attach=1]
-
My GPSDO with the Bliley NV47M1008 linked to the NEO-M8T has the best performance of the three GPSDO's I'm currently testing with my hardware. The results are almost too good to be true, I think...
This is with a tc of 1000, the rest default and no temperature compensation. My OCXO is in a foam box and has virtually no temperature influence I can determine. The drift of the OCXO is only in one direction, and even with a gain setting of 902, the DAC only needs minimum size steps to keep it in check.
Below are the MDEV and Frequency graphs from TimeLab.
I'm certainly no expert, but this is very impressive performance of the Bliley I think.
Maybe I got lucky... :-//
It also shows what the hardware is capable off, and it's probably worth considering adding the imo modifications that I described in detail many posts earlier. To quickly sum them up; use different regulators for all building blocks to isolate influences. Properly decouple all parts. Replace the 10M discharge resistor for C1 and do that by software control. Isolate the PWM/DAC outputs with gates that are powered with a reference supply to minimize the Arduino effects on the OCXO tuning. Put the OCXO itself in a foam box that also includes the bottom part. Extend the leads from the OCXO to go through the foam bottom which will further isolate the OCXO from the PCB.
-
So is my Bliley perfect?
No, well maybe. It has a weird behavior when warming-up.
After about a picture perfect 10 hours after turn on, I noticed this weird glitch. It briefly lost lock, but quickly got it back, but now with a DAC setting that is considerably lower than before. Since then, for a period of 38 hours and counting it has been extremely stable again as you can see in the previous post.
Interesting... it shows that nobody is perfect!
-
How did you generate the ADEV graph, what input and reference? The results are suspiciously good, worth looking into the methodology of your measurement setup.
-
Hi thinkfat,
I was expecting comments like yours... This Bliley OCXO seems to be too good to be true.
OK peer review:
I collect the data from the Lars' report through a Raspberry Pi that puts it into daily logs, which I then import and concatenate together in Excel.
From that data I then make the graphs that I show on this blog. I also use the DAC data and feed that into TimeLab.
My gain for the Bliley is 902 so the import multiplier becomes 1.10865E-12. After I import the data, I use all three of the Substract options.
When I added another 24 hours of data to that from yesterday, I got the attached graph out of TimeLab. This shows why I personally still have have difficulty interpreting the ADEV and MDEV TimeLab results. The Frequency Difference in TL jives with what I graph out of my Excel data, so that is consistent.
Unfortunately, I can't post the Excel file because even zipped it is already 34MB and too large to post here.
I have extracted the DAC data and put that into a zipped file. This can be imported into TL.
I also put the Excel file without graphs and some deleted columns to save space on my github site here: (removed link)
Looking forward to hear if you can spot something...
-
Here is a picture of wonderboy and also an MDEV and Freq compare with the other two OCXO's I'm currently testing.
The other two mere mortals are an Oscilloquartz 8663-XS with a gain of 987 and a CTI OC5SVC25 with a gain of 554.
-
I was assuming already that you only had the DAC output log to feed into Timelab, so unfortunately, the graphs that you get tell you nothing (well, a little) about the actual output of the GPSDO, unless you can be dead sure that a specific DAC output always corresponds to a specific frequency. Of course this is not the case.
The MDEV and frequency graphs give some insight into the overall system behaviour, though.
First of all, the tau=1s MDEV is effectively defined by the smallest step the DAC does with the GPSDO in lock. It depends mostly on the "gain" and the DAC width (16 bit, in your case) and the time constant. If you run with a smaller time constant, the DAC output will change more frequently and the small-tau MDEV will be larger.
The MDEV graph, if you only have the DAC values, tells you mostly how much the GPSDO control loop "disturbs" the ouput of the OCXO, and if you knew the MDEV for the same OCXO running against a stable reference (very stable Rb or Cs standard), you could infer something about the actual performance. In fact, you could mark the datasheet values of your OCXO, if you have them, in the MDEV graph and connect them with lines to have a baseline for the expected performance, and wherever the DAC MDEV is above that line, it "degrades" the performance of the OCXO.
The datasheet I found for the NV47A OCXO series says it has a 1s stability of around 1e-10, which is OK but not exceptional, your DAC MDEV is around 1e-13, that means the GPSDO doesn't impact the OCXO and it will exhibit its natural performance. But of course it cannot do better, so the output of the GPSDO is not stable to 1e-13 :)
Now on the use of the "subtract" options in Timelab - I'm not very familiar with the software but I suspect that they will only hide information that is in the data. For example, if you remove all trends in the data, it will make the GPSDO "look very good" for large tau, but it will also hide the OCXO's long-term drift behavior, which is an interesting property to know.
Another remark on MDEV - I'm not sure but I think the DAC output is a frequency-time series and not a phase-time series, because changes denote a change in frequency and not a change in phase. That is something to keep in mind.
-
Hi thinkfat,
Thank you for the clarifications. I agree with you, wholeheartedly, but keep in mind that just about every TimeLab graph presented on this particular forum is a presentation of the DAC values, all by themselves. So that's what I did as well. Even Lars only shows the DAC values in his document, and never once in relation to his rubidium standard, which would give us a reference. To compare results between various posted graphs, we all need to use the same data, and since Lars recommended (figure 7) to subtract the driftline in TL, so did I and many others.
It has been my understanding all along that because the 1PPS pulse coming from the GPS satellites drives the control loop, adjusting the OCXO to this standard. Therefore, all ns and DAC excursions are in relation to the stability of the atomic clocks in the satellites, which is why looking at the DAC values can be construed as showing the difference to an "absolute standard". I may not express this well, but that is my understanding. Please correct me if I'm wrong.
I already mentioned that I have difficulty interpreting what the TL graphs present, and prefer to look at the stability of the OCXO using Excel and looking at the TIC ns difference, stability/drift and the DAC stability and drift. If you collect temperature data as well, you can see those effects as well. Having said that, in absence of a ppb counter or an "absolute reference", all you can do is a relative compare between devices, which is why I collected data from a couple of OCXO's.
As a minimum, my data shows that the Bliley is a lot more stable than the Oscilloquartz, and that one is a lot better than the CTI.
Or is there another way?
-
As a minimum, my data shows that the Bliley is a lot more stable than the Oscilloquartz, and that one is a lot better than the CTI.
I'm not so sure about that. You'd have to run them all with the M8T GPS, with the exact same TC and filter settings (except gain of course), in the same stable environment, to make the graphs comparable.
BTW the only references to Timelab in this particular thread that I found are for finding the optimum TC. This is point where the GPS becomes "better" than the OCXO, i.e. where you start to see the drift behavior of the OCXO. If you think about it, to achieve the best performance you need to "slow down" the control loop to the point where it is just fast enough to compensate the long-term drift of the OCXO. This is the best possible case, have the GPSDO output be the free-running OCXO up to the point where the GPS is more stable.
-
They are all connected to the same M8T in the same hardware design and running with a TC of 1.000 except the CTI which used a TC of 500. I just switched it to 1.000, but I'm not too happy with it so I'm in the process of switching the CTI to my Trimble 65256 again. The reason is that OCXO's with a solid and thick case have virtually no hindrance from ambient temperature changes, if you put them into an isolation box all by themselves.
Both the CTI and the IsoTemp I tried have flimsy housings and suffer greatly from ambient temperature changes.
If you look in the original pdf from Lars, it shows the TL graphs that I referred to.
-
Well, the graphs on page 3 are against various Rb standards (PRS, LPRO), the graphs in the last PDF are all against "Rb3", which was probably Lars' house standard.
-
They are all connected to the same M8T in the same hardware design and running with a TC of 1.000 except the CTI which used a TC of 500. I just switched it to 1.000, but I'm not too happy with it so I'm in the process of switching the CTI to my Trimble 65256 again. The reason is that OCXO's with a solid and thick case have virtually no hindrance from ambient temperature changes, if you put them into an isolation box all by themselves.
Both the CTI and the IsoTemp I tried have flimsy housings and suffer greatly from ambient temperature changes.
If you look in the original pdf from Lars, it shows the TL graphs that I referred to.
I think what you can safely conclude from the graphs is that the whole system with the Bliley OCXO is the most stable of them, since the MDEV graph basically shows that the control loop has to do much less "work" to keep the OCXO locked. This might be due to the OCXO alone. If you isolated the other two OCXOs better from temperature changes, they will likely improve as well. But as it stands, under the conditions you tested, the Bliley is the "best". The final proof can only come from doing a measurement e.g. against a good Rb standard. This will bring you into serious "time-nut" territory :)
-
Just to see how far I could go with my now stable and reliable hardware and GPS setup, I selected a TC of 2,000 and ran that for about 20 hours. I also switched the CTI out for my Trimble 65256. This Trimble has a sine wave output, just like the Oscilloquartz.
During this run, there was absolutely no risk of getting out of lock and I think I can increase the TC even higher. The deviations get a little larger, so from a precision point of view for the output, it makes no sense to me. It looks like a TC of 1,000 seems to be optimal for all three of these OCXO's. Due to the thermal isolation I provided by boxing in these OCXO's, there is no temperature effect that I can determine, unlike with the CTI and IsoTemp ones.
-
Just curious if all the 10 MHz sine waves from all these oscillators remain in phase with one another, year in and year out?
Ive recently acquired a perfectly sized thermal box (used for shipping frozen goods, etc.) and I am wondering if I should first fireproof it, and then try putting my (Bliley OCXO containing) GPSDO in that and putting it in my basement and building a separate controller to put upstairs in the living area. I could maybe use it for training GPSDOs. Have a little "rack" for disciplining them. ;)
Just for fun.
-
Just to see how far I could go with my now stable and reliable hardware and GPS setup, I selected a TC of 2,000 and ran that for about 20 hours. I also switched the CTI out for my Trimble 65256. This Trimble has a sine wave output, just like the Oscilloquartz.
During this run, there was absolutely no risk of getting out of lock and I think I can increase the TC even higher. The deviations get a little larger, so from a precision point of view for the output, it makes no sense to me. It looks like a TC of 1,000 seems to be optimal for all three of these OCXO's. Due to the thermal isolation I provided by boxing in these OCXO's, there is no temperature effect that I can determine, unlike with the CTI and IsoTemp ones.
Yes, that's to be expected. There's a decision to be made where you want the best performance. If you want stability at small observation intervals, you choose a long time constant to slow the regulation down. If you favor long intervals, make the time constant shorter. Have a look at this image, it shows my DiY GPSDO against a commercial Trimble UCCM module. My own GPSDO is running with a time constant of 700 seconds, the Trimble is using whatever, but you can clearly see that it uses a different strategy: It sacrifices small-tau stability for a faster dive-down into stable regions around 100s.
[attachimg=1 width=800]
However, increasing the time constant looses its benefit at a point, as you cannot get better than the short-term stability of your OCXO.
-
@cdev,
I have found that boxing in the OCXO with dense insulation of 10-15 mm thick walls works really well separating the ambient temperature changes to that of the OCXO. Note that I also use the insulation between the PCB and the bottom of the OCXO. I extended the leads so I could do that. Furthermore, OCXO's with a thick/double casing like the Oscilloquartz, Bliley and Trimble are much, much better in this respect as well.
The OCXO temperature measured by the sensor inside the insulated box still changes somewhat with the ambient temperature, but the effects on the DAC are barely recognizable or so small that there is no need to use temperature compensation.
Below is my Oscilloquartz version.
-
@Dbldutch
Any plans on publishing the Schematic + PCB ?
/Bingo
-
@Bingo
Yes I will do so pretty soon. I'm on vacation right now while I'm still collecting data from my three OCXO's.
I will publish my findings on my own blog to not pollute this thread and when I'm done I will announce that here.
-
As I promised, here is the link to my own blog where I will describe my project and findings in more details, without "polluting" this blog.
I will be adding information as I go, since there is a lot to share and learn.
I would like to thank several of you for your generous support in picking me up when I stumbled or fell.
Here is the blog post: http://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html (http://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html)
-
I've been saving foam boxes to build a thermally managed enclosure at some point. Some time ago Lief Asbrink demonstrated a method for keeping his miri sdr dongle thermally stable, he buried it in a bucket of fine sand. He found that worked really well. The only thermally stable place in my house is the basement, so I am thinking it might be interesting to see if putting a GPSDO there made for a more stable environment.
@cdev,
I have found that boxing in the OCXO with dense insulation of 10-15 mm thick walls works really well separating the ambient temperature changes to that of the OCXO. Note that I also use the insulation between the PCB and the bottom of the OCXO. I extended the leads so I could do that. Furthermore, OCXO's with a thick/double casing like the Oscilloquartz, Bliley and Trimble are much, much better in this respect as well.
The OCXO temperature measured by the sensor inside the insulated box still changes somewhat with the ambient temperature, but the effects on the DAC are barely recognizable or so small that there is no need to use temperature compensation.
Below is my Oscilloquartz version.
I am thinking about building Lars's gpsdo in part so I can a second point of reference, to evaluate my surplus telcom GPSDO, and also because. I have almost all the parts already, with the exception of the OCXO. Because part of the reason I am interested in the project is "affordable science" I dont want to spend a lot on the OCXO.
Maybe $15-20 tops. I plan on using a navspark mini for the GPS. Do you think the Bliley you are using is a good choice?
I think spending much more than that would defeat my purpose of showing how it can be done for cheap. The navspark doesnt make sawtooth correction or anything like that available but it does let you tell the kalman filter its stationary. And it does keep a stable 1PPS even when it is deprived of most of the signal (one way to do that is put it in a antistatic bag. It is remarkably sensitive so works almost anywhere where there is any signal at all.
-
Hi cdev,
Do you think the Bliley you are using is a good choice?
The Bliley NV47M1008 I finally got, after receiving 2 failing ones, is the best of the 5 OCXO's that I currently have.
It has some strange jumps, but before and after the jumps it is amazingly stable with no temperature effects on the DAC at all.
I got mine for about $20-25
-
Correction from post 108:
The OCXO temperature measured by the sensor inside the insulated box still changes somewhat with the ambient temperature, but the effects on the DAC are barely recognizable or so small that there is no need to use temperature compensation.
After running the three OCXO's for several weeks, including with higher outside temperatures (very warm weather), I noticed that both the Oscilloquartz and the Trimble had some small temperature effects on the DAC. My assumption is that this effect will be less again when the outside temperature drops back, making the delta difference larger. This is probably the reason why I didn't notice it earlier, with lower outside temperatures.
I used the advised calculation described by Lars to determine the tempRef and tempCoeff values. For my Trimble that turned out to be a tempRef of 521 (daily avg OCXO temp of 52.17 degrees C), and a tempCoef value of 400. I still noticed some effects on the DAC, so the next day I increased that value first to 450, and a day later to 500.
The Oscilloquartz tempRef was set to 515 (daily avg 51.52 degrees C) and a calculated tempCoef value of 175. That did it, the DAC curve is no longer following the daily OCXO temp changes.
The Bliley still has absolutely no temperature effects on the DAC whatsoever. Not even a single DAC count, and that with a gain of 902. Splendid!
-
The Oscilloquartz tempRef was set to 515 (daily avg 51.52 degrees C) and a calculated tempCoef value of 175. That did it, the DAC curve is no longer following the daily OCXO temp changes.
That's a bit odd. The DAC temperature compensation should not stop the DAC from following the temperature changes, rather it should stop the TIC (and thus, the frequency) deviating in the presence of temperature changes. If the DAC is no longer correcting temperature effects, the frequency would change, this should be visible in the TIC values and cause the control loop to compensate (potentially driving it into unlock).
Maybe the DAC value Lars' firmware is reporting has the temperature compensation already subtracted?
-
Thank you for the reminder to check it thoroughly when it arrives!
Are there any other cheap OCXOs you would recommend that are comparable to the Bliley, in your opinion?
Hi cdev,
Do you think the Bliley you are using is a good choice?
The Bliley NV47M1008 I finally got, after receiving 2 failing ones, is the best of the 5 OCXO's that I currently have.
It has some strange jumps, but before and after the jumps it is amazingly stable with no temperature effects on the DAC at all.
I got mine for about $20-25
-
@thinkfat : Yes that is the case, I verified that in the code. The DAC calculation takes the temp compensation into account. This means that the DAC curve no longer follows the OCXO temperature curve while still compensating the TIC differences. I'll put some example graphs in my blog soon.
@cdev: The Bliley comes in several versions, with sine wave and square wave out. They can be obtained rather inexpensively. I have used this seller a lot. https://www.ebay.com/itm/1-Bliley-NVG47A1282-10MHz-5V-Sine-Wave-OCXO-Crystal-Oscillator/332416522967?hash=item4d65919ad7:g:~ecAAOSwPDRfGQUS (https://www.ebay.com/itm/1-Bliley-NVG47A1282-10MHz-5V-Sine-Wave-OCXO-Crystal-Oscillator/332416522967?hash=item4d65919ad7:g:~ecAAOSwPDRfGQUS) Both the Trimble and especially the Oscilloquartz are popular and therefore have higher prices. I have not tried other "heavy"or thick cased OCXO's. My CTI and IsoTemp OCXO's both have very thin casings and are therefore very sensitive to ambient temperatures, even when isolated, which is why I don't use them at this moment. My setup and environment (put everything in a sand box in the basement?) has to be changed considerably for me to use them.
-
Bliley is the brand that my True Position GPSDO uses (its a NVG47A1282) , and as far as I know the True Position's accuracy is very good, so it will be interesting to see how the two compare if they do.
The True Position is telecom surplus GPSDO that was used in a TDOA system for locating 911 phone callers physical location from the time the signals arrived. They typically lived in either dispatcher setings, or often, at cell phone sites, typically cabinets on telephone poles that were exposed to a wide variety of weather and still maintained a high level of precision, good enough for TDOA.
@thinkfat : Yes that is the case, I verified that in the code. The DAC calculation takes the temp compensation into account. This means that the DAC curve no longer follows the OCXO temperature curve while still compensating the TIC differences. I'll put some example graphs in my blog soon.
@cdev: The Bliley comes in several versions, with sine wave and square wave out. They can be obtained rather inexpensively. I have used this seller a lot. https://www.ebay.com/itm/1-Bliley-NVG47A1282-10MHz-5V-Sine-Wave-OCXO-Crystal-Oscillator/332416522967?hash=item4d65919ad7:g:~ecAAOSwPDRfGQUS (https://www.ebay.com/itm/1-Bliley-NVG47A1282-10MHz-5V-Sine-Wave-OCXO-Crystal-Oscillator/332416522967?hash=item4d65919ad7:g:~ecAAOSwPDRfGQUS) Both the Trimble and especially the Oscilloquartz are popular and therefore have higher prices. I have not tried other "heavy"or thick cased OCXO's. My CTI and IsoTemp OCXO's both have very thin casings and are therefore very sensitive to ambient temperatures, even when isolated, which is why I don't use them at this moment. My setup and environment (put everything in a sand box in the basement?) has to be changed considerably for me to use them.
-
After setting the temperature compensation and running with it for a few days, I noticed a strange side effect.
Here are the graphs for the Trimble, with the temperature compensation in effect:
[attach=1]
Note the Ambient and OCXO oven temperature graphs on the bottom first. When the temperature drops a bit around 30.000 seconds, there is a sudden steep rise in the oven temperature, until about 64.000 seconds when there is a sudden and steep drop. This is unrelated to the room temperature! These transitions can also be observed in the ns and DAC graphs. So despite the fact that the DAC graph is much flatter due to the compensation, there are some pretty serious side effects. The Oscilloquartz has exactly the same behavior.
As a result, I decided to disable the temperature compensation again. These two OCXO's don't really need it anyway.
-
I don't quite understand - are you saying the temperature compensation has an effect on the OCXO temperature? Or that there is a dip in phase error and DAC when the temperature changes?
-
thinkfat, it is indeed very strange but after spending more time on it, I may have an explanation :-//
Here are some observations to see if we can shed some more light on this.
Normally, and without temp compensation, all three GPSDO's virtually show the same daily ambient and OCXO temperature curves.
It's very hard to put my finger on it due to the fuzzy graphs, but I have to assume that the OCXO temperatures follow the ambient temperatures. They transition at the same time, but since the delta excursion for the ambient is a little bit larger than that of the OCXO, that must be the lead. That makes sense and is to be expected.
Below are the Bliley temperature curves during the same period as the previously shown curves of the Trimble with the temp comp.
The Trimble should have been the same. However, just when the temperature compensation was activated several days ago, the daily curves changed as I show in the Trimble example graphs above. These are very strange changes I cannot explain yet. I also looked in more detail to the Oscilloquartz, because it behaved different after the compensation as well, but it is not the same as the Trimble.
Also below is a zoomed-in portion of the Trimble graphs above.
Note that the transition in the OCXO temperature starts at point 338, followed by the gradual transition in the ambient temp that starts at 342 and the dip in the DAC that starts at point 347. These graphs seem to indicate that the OCXO temperature is the lead and that seems to indicate that it's a Trimble issue.
The big question still is if it's related to the activation of the temp compensation (unlikely because how?) or is it a strange coincidence that the Trimble itself suddenly behaves weird?
I don't know yet, it will take a few days of further observation to see if it happens again.
I'm also going to add more temp sensors to figure out where the ambient temp changes are related to. I doubt if it is driven by the room temperature alone because the ambient variations inside the enclosure are larger than those of the room temperature. I'll also put a sensor on top of the Arduino CPU.
-
Initially, I thought the Oscilloquartz had the same problem as the Trimble, because it also showed this strange jump in the temperatures after I initiated the temp compensation. However, on careful examination, it appears that this jump is driven by the ambient temperature. It starts 2 seconds before the OCXO temp follows suit. I see no evidence that the ambient temperature is driven by the room temperature, so what is causing this???
Very weird coincidence!
As I mentioned, I need to add more temperature measurements to learn more.
-
You mentioned there's an isolating box around the devices, right? So, it must be something happening in that box, a temperature jump of such magnitude can hardly originate from outside.
I have seen such jumps with my own GPSDOs, but they're just on my workbench, without any protection against air drafts and completely exposed to ambient.
-
@thinkfat,
It's a pretty serious box made from 10-15mm hi-density foam. Look at the picture at post #500.
There are no leaks in the box.
The logical conclusion is that it must come from the OCXO itself.
-
What just dawned on me...
Could it be that the internal OCXO oven controller switches to a higher temperature range when the delta with the ambient temperature becomes too small?
That would make sense, if it is really that smart and the frequency is not changing because of this...
Can somebody maybe confirm this?
-
Lots of the OCXO's are not made to be wrapped in extra thick foam (isolation) , they can't "Dump their heat when needed.
A cardboard box (or just inside a box) to isolate from "draft" is recommended , but take care when using thick isolation.
/Bingo
-
Are these double oven types? Maybe something triggers the secondary heater, an ambient temperature drop perhaps, and then the isolation is in the way of dumping the excess heat
-
@Bingo600,
Thanks for the heads-up. I started with the insulation project when I had effects I could not explain. Maybe now that everything is working as expected, I should revisit the insulation part. Before I do however, I want to learn more about the temperature sources and development inside my enclosures. There are still a few weird things going on.
@thinkfat,
The Trimble seems to be a double oven type, the Oscilloquartz apparently is not, but both have these issues.
I'll be back with more data...
-
I believe you may be overthinking this 'problem' (mainly on account you seem to be monitoring irrelevant data such as the OCXO's case (?) temperature - it's not entirely clear what's being monitored here - readings far too low to be actual oven temperatures and the "ambient" temperature (is this actual room temperature or that of the air within the enclosure?).
===========================================================================================
[EDIT 2020-08-07]
My bad! :-[ :palm: That data is only irrelevant in the case of a James Miller styled GPSDO design such as I've used in my MKs I and II builds. I apologise for belittling what is actually a vital sensor component in a micro-controller based design. Monitoring the OCXO's case temperature provides a 'catch all' temperature monitoring point to compensate for all sources of temperature variation.
[END_EDIT]
===========================================================================================
The oven control (going by the way my own CQE OCXOs respond to even the briefest of interruptions to their 12v supply) is done using PWM of a constant current supply to the heater (actually a power transistor, not a Ni-Chrome wire heating element) controlled by a simple minded microcontroller algorithm maintaining a thermistor at a fixed resistance value that corresponds to a precise target temperature (to better than +/- 0.5 deg C), usually around the 65 to 85 deg C mark.
I say "simple minded microcontroller algorithm" on account of the way it seems to assume every 'reboot event' can only mean it must be starting from stone cold so turns the heater up to "eleven" whilst it runs through the rest of its reboot initialisation sequence before doing the digital equivalent of exclaiming "Oh, shit! I've overcooked the XO!" and shutting off the heater current which then results in the inevitable under/overshoot wobble you'd normally only expect to witness during an actual cold startup event. :palm: :palm: :palm:
Of course, it may only be my CQE OCXOs that use such a daft reboot algorithm that tests the depth of the water with both feet and plunges straight into its "High speed warmup routine" before testing whether such an action is actually called for. Again :palm: :palm: :palm:
What I'm suggesting is, if possible, log the OCXO's supply rail voltage (and any other supply rails for good measure) to see whether there are any glitch events taking place to trigger these temperature anomalies (which rather look to my mind, more like software/hardware glitches than actual temperature events).
Single ovened OCXOs are influenced by changes of temperature to their immediate surroundings when chasing down parts per trillion stability levels. Double ovened OCXOs are influenced to a lesser extent but still not entirely immune to this effect which is why a modest amount of insulation around a single ovened OCXO can help by reducing internal thermal gradients between the XO, the heater transistor and the sensing thermistor despite the manufacturer's best efforts to keep all three tightly coupled to each other to minimise the effect of these temperature gradients.
Exactly how much insulation can be considered "modest" rather depends on the expected range of operating temperatures within the enclosure. Given enough insulation, even the modest 145mW dissipation from the XO and its LDO (CQE example) may be enough to raise the temperature above the set point in a particularly warm running enclosure on a hot summer's day outside of an air conditioned laboratory environment (a more likely scenario for a typical DIY GPSDO).
To my mind, the only sane way to deal with such temperature variations is to use a double ovened OCXO since trying to compensate for them requires the response to match the actual thermodynamics involved else you risk making the situation worse.
I've been following this thread with some interest since I may find myself having to use a microcontrolled solution to improve on my current hardware PLL controlled GPSDO project where the only major issue I have is due to the unpredictable nature of the ionosphere's effect on the propagation delay of the satellite signals which manifests itself as a variation of 30 to 40ns in the case of the M8N based MK I unit and around 10ns for the M8T based MK II unit I'm currently building. Sadly, even the timing receivers when configured to a fixed location aren't immune to these imperfectly corrected for perturbations in the electron density of the ionosphere :(
I'm now only awaiting the imminent delivery of panel mount 3.5mm stereo jack sockets to finalise my MK II build. I'm using one to provide a connection to the buffered EFC voltage and a stable 2v dc offset to let me monitor the voltage difference between them on the 1000mV scale of my cheap Mestek DM91A 9999 counts DMM in leu of spending over a hundred quid on a cheap 4 1/2 digit bench meter. I can now monitor variations in EFC voltage in 100uV increments with this cost effective solution - an order of magnitude improvement over using the DM91A just on its own.
Obviously, with no microcontroller nor DAC, I have no simple automated way to log data to generate fancy MDEV or ADEV plots, just observations from 'scope traces comparing both GPSDOs against each other and my stand in for a Rubidium reference, the OCXO in my FY6600, trimmed to within 5ppt by exploiting the 2G tipover effect to fine tune it against diurnal temperature variations and the almost imperceptible daily ageing effect.
It's not an ideal solution but it comes close enough to reveal the slow wobbles of phase shifting for minutes to tens of minutes variations in propagation delay from the changing ionospheric conditions. Unfortunately, the once superb stability of this free running OCXO seems to have gone all to pot this past week or so and it looks like I need to revamp the calibration trimmer circuitry (better 22 turn trim pot and more padding to limit the frequency trim range and quite possibly the use of a 5v CMOS RRO opamp to reduce slider contact resistance volt drop effects).
OTOH, I might just build my own double ovened OCXO using one of my ample stock of 10MHz CQE OCXOs to create a stable enough independent reference to compare the behaviour of my MKs I and II GPSDOs against. I'd like to take the basic hardware PLL based GPSDO to its limit before I start experimenting with microcontroller based designs since it will provide a useful benchmark to test such a new design against.
In the meantime, I wish you all the best with your own Lars based GPSDO design. I think you just need to step back and reconsider other possible causes for your current anomalous results. I know just how easy it is to get stuck down a dead end road where nothing seems to make sense any more. :-//
JBG
-
This is mostly for others following this blog, they may get confused by the following statement from JBG, the rest is mostly irrelevant.
I believe you may be overthinking this 'problem' (mainly on account you seem to be monitoring irrelevant data such as the OCXO's case (?) temperature
When you don't have the luxury of an atomic clock to your disposal to measure (compare) the accuracy and stability of your DIY GPSDO, you can use TimeLab to characterize your tool. Lars has several examples in his documents, go read them if this is new to you.
The way to use Timelab to characterize your GPSDO is to collect the DAC values and import them into the tool, while converting them back to a frequency representation. However, this only works when the DAC values have a 1:1 relation to the differences measured against the 1PPS coming from the GPS, measured by the TIC system in nanoseconds and the OCXO through the DAC settings.
When the DAC values are influenced by things like temperature, this will skew and distort the TIC relationship and hence the TimeLab representation is of less value. It no longer shows the true disciplined OCXO performance and stability.
The OCXO oven temperature can be monitored by Lars' program to get a handle on the temperature based deviations on the DAC, and his firmware can compensate the DAC settings by taking the OCXO temperatures into account.
The idea behind this is to get a DAC curve that is as much as possible devoid from temperature based deviations.
Below is an example of one of my GPSDO's, with the Trimble OCXO. The graphs show the DAC values, the OCXO temperature, the ambient temperature within the enclosure and the ns value coming from the TIC over a 24 hr period. The second graph shows the room temperature (in red) in my office. All temperatures show a dip of several degrees Celsius, and you can clearly see that the DAC follows this curve, which will compromise a TimeLab measurement. Note that the ns graph does not follow this.
This shows that it is very important to monitor the OCXO temperature and also find the source of deviations in order to properly compensate the DAC.
-
Apologies for using the phrase, " irrelevant data". Upon reflection, knowing how the seemingly small variations of room temperature can effect the OCXO in my cheap FG, monitoring the OCXO's case temperature seems about the best choice of monitoring point since changes of temperature here, once the oven has reached thermal equilibrium, will have the greatest impact on frequency stability. Not only that but it also includes not just the room temperature contribution but all other contributions from the rest of the internal components.
From my own narrow viewpoint of a basic hardware PLL based GPSDO, it just seemed to be an inevitable variable that would be cancelled out in the disciplining process anyway. However, what had struck me about the graphed data was the suggestion that these anomalies looked more like hardware or software bugs in the logging process.
These last graphs of the DAC values are very suggestive of variations due to ionospheric effects superimposed upon a longer term temperature trend (trying to interpret their meaning tends to leave me with a bit of a headache :-// ).
Although the contrast between the Lars design being discussed here and my Gyro inspired version of the James Miller "GPS Stabilised 10 MHz Oscillator", described here : -http://www.leapsecond.com/pages/gpsdo/ as:-
"This is about the simplest design possible for a GPSDO; with no DAC, no Vref, no time interval counter, no microprocessor. Just an XOR gate acting as a phase comparator against the 10 kPPS output of a Jupiter GPS engine. In spite of this simplicity, the performance is amazingly good"
couldn't be any greater, I thought my own observations, such as they are, might offer some small insight into this problem of inexplicable temperature excursions, even if only by way of 'light relief'.
As you pointed out, in the absence of such data to feed into mathlab, the only other way left open to gather meaningful statistics is to employ an atomic class standard such as a Rubidium oscillator. I'd love to possess one but long gone are those happy days when it had been possible to get hold of used units for just 100 to 200 quid. Since I'm not ready to justify the hundreds of pounds expenditure on one, I'm trying to make do with second best (a very finely trimmed OCXO).
My recent past experience with the OCXO installed in my cheap FG suggests I could DIY a double ovened OCXO using one of the spare 10MHz CQE single ovened OCXOs for this project which could perform better than what I'd been able to achieve with my cheap FG setup and perhaps suffice as a cheap stand in for the ideal of a Rubidium oscillator reference.
===========================================================================================
[EDIT 2020-08-07]
After embarking on yet another Holy Grail search for an affordable used Rubidium oscillator (10MHz), I finally located an LPRO-101 here:-
https://www.ebay.co.uk/itm/Datum-EFRATOM-LPRO-101-Rubidium-Frequency-Standard-10MHz-with-PCB-0-95mHz-test/184374703310?_trkparms=aid%3D1110006%26algo%3DHOMESPLICE.SIM%26ao%3D1%26asc%3D20131231084308%26meid%3Daddf23c2f69044fb9c1c50fa1541f942%26pid%3D100010%26rk%3D1%26rkt%3D12%26sd%3D181632863973%26itm%3D184374703310%26pmt%3D0%26noa%3D1%26pg%3D2047675%26algv%3DDefaultOrganic&_trksid=p2047675.c100010.m2109 (https://www.ebay.co.uk/itm/Datum-EFRATOM-LPRO-101-Rubidium-Frequency-Standard-10MHz-with-PCB-0-95mHz-test/184374703310?_trkparms=aid%3D1110006%26algo%3DHOMESPLICE.SIM%26ao%3D1%26asc%3D20131231084308%26meid%3Daddf23c2f69044fb9c1c50fa1541f942%26pid%3D100010%26rk%3D1%26rkt%3D12%26sd%3D181632863973%26itm%3D184374703310%26pmt%3D0%26noa%3D1%26pg%3D2047675%26algv%3DDefaultOrganic&_trksid=p2047675.c100010.m2109)
:wtf: That's taking the piss! Here's a nice petite TinyURL https://tinyurl.com/y23upfw5 (https://tinyurl.com/y23upfw5)
I've just "pulled the trigger" and for just under 200 quid delivered and customs charges pre-paid, I'll hopefully have a used but calibrated LPRO-101 in two to five weeks time. Sod the expense! It's only money after all (and I can't take it with me when I finally pop my clogs).
I've also downloaded every relevant document on the LPRO-101 from KO4BB's very useful web site like a "Good Boy Scout". :)
===========================================================================================
I'll save the data gathering operation for when I'm ready to try my hand with the Lars or a similarly based design after I've completed my MK II basic GPSDO to give me that added element of interest and motivation that I now require to embark on ever more complex projects these days.
JBG
-
After I took the insulation away from the OCXO's and ran the measurements again for several days, I have decided to put them back on.
Even with the DAC temperature compensation activated, the dependency of my GPSDO systems are too sensitive to the room temperature changes. So much so that I'm loosing lock constantly, while I ran for months without problems when they were boxed in. I only took the insulation away because it seemed that the OCXO oven temperature regulation was misbehaving when the room temperatures were in the order of 30 degrees C, during the current heatwave. My take on that is that maybe the delta temperatures between the ambient and the desired oven temperatures where becoming too small, and the oven jumped to a higher temperature setting.
I think I can live with that effect during a heat wave, rather then having them so sensitive to the room temperatures.
The alternative could be to put my metal enclosed GPSDO system wrapped in insulation inside another plastic enclosure to shield it better from "sudden" room temperature changes.
Has anybody collected experience using that approach?
-
My take on that is that maybe the delta temperatures between the ambient and the desired oven temperatures where becoming too small, and the oven jumped to a higher temperature setting.
You should see that jump in the supply current so monitor it.
-
thermal mass. (like very fine clean and and pure sand) would help, but would be a bit of a PITA perhaps.
I was thinking of this.
http://www.sm5bsz.com/linuxdsp/hware/mirisdr/thermal.htm (http://www.sm5bsz.com/linuxdsp/hware/mirisdr/thermal.htm)
After I took the insulation away from the OCXO's and ran the measurements again for several days, I have decided to put them back on.
Even with the DAC temperature compensation activated, the dependency of my GPSDO systems are too sensitive to the room temperature changes. So much so that I'm loosing lock constantly, while I ran for months without problems when they were boxed in. I only took the insulation away because it seemed that the OCXO oven temperature regulation was misbehaving when the room temperatures were in the order of 30 degrees C, during the current heatwave. My take on that is that maybe the delta temperatures between the ambient and the desired oven temperatures where becoming too small, and the oven jumped to a higher temperature setting.
I think I can live with that effect during a heat wave, rather then having them so sensitive to the room temperatures.
The alternative could be to put my metal enclosed GPSDO system wrapped in insulation inside another plastic enclosure to shield it better from "sudden" room temperature changes.
Has anybody collected experience using that approach?
-
Hi,
I built Lars' circuit and connected a Ublox Neo 7M. But I don't get stable ns tics. If I feed in 1Hz from a function gen, then I get a Lock. Do I have to make further settings in the U-Center? Where could the problem be?
time ns dac temp status diff_ns filtX10 tc filt timer1 temp1
...
38 38906 43622 0 NoLock 23996 184080 32 1 25228 0 1088 -1 65535 65535
539 28908 43692 0 NoLock -9998 184080 32 1 25177 0 1089 -1 65535 65535
540 -27090 43761 0 NoLock -55998 184080 32 1 24897 0 1090 -1 65535 65535
541 -54094 43831 0 NoLock -27004 184080 32 1 24763 0 1091 -1 65535 65535
542 37909 43901 0 NoLock 92003 184080 32 1 25222 0 1092 -1 65535 65535
543 28906 43971 0 NoLock -9003 184080 32 1 25178 0 1093 -1 65535 65535
544 -1090 44041 0 NoLock -29996 184080 32 1 25028 0 1094 -1 65535 65535
545 2905 38426 0 NoLock 3995 34030 32 1 25048 0 1095 -1 65535 65535
546 29906 38437 0 NoLock 27001 34030 32 1 25183 0 1096 -1 65535 65535
-
Maybe the LO frequency is waay off...
-
0xFFF0,
Very strange results you have...
Can you use a scope and look at both the 1PPS from the NEO and the 1Hz from your function generator?
Trigger the scope on the 1Hz signal.
The 1PPS will jitter about 20nS but otherwise should be stable. Both signals will slowly drift, but there should be no jumps.
In U-Center, you can exclude sats with a signal strength of less than 20dB. How many sats will then roughly remain?
Do you have a good view of the sky, meaning all around you (360 degrees), or is it severely restricted?
What kind of antenna do you use, and where is it located.
Can you post a picture of the GPS board?
Post a screenshot of u-center after it ran for at least an hour or so. (the longer the better)
Good luck!
-
I have been working on getting the temperature compensation running on my Oscilloquartz and Trimble OCXO's and wanted to share the before and after so you can see the effect.
I can only show three graphs and I need four so I will split the two OCXO's.
Here are the before and after for the Oscilloquartz.
You can clearly see that at first, the DAC values follow the OCXO temperature. This will skew the reports when you use TimeLab, because it uses the DAC values to calculate the 10MHz frequency stability. If the DAC moves around based on the temperature effects, so will the frequency, and this will show up in the TimeLab graphs. If we can eliminate, or reduce the temperature effect, the representation in TimeLab is much closer to the GPS disciplined OCXO reality, which is what we want.
After the temperature compensation is activated, you can see that the temperature now has a much more reduced effect on the DAC.
-
And here are the before and after for the Trimble.
After calculating the values, and running for a day, I actually tweaked the compensation by hand to get more accuracy.
-
0xFFF0,
Very strange results you have...
Can you use a scope and look at both the 1PPS from the NEO and the 1Hz from your function generator?
Trigger the scope on the 1Hz signal.
The 1PPS will jitter about 20nS but otherwise should be stable. Both signals will slowly drift, but there should be no jumps.
In U-Center, you can exclude sats with a signal strength of less than 20dB. How many sats will then roughly remain?
Do you have a good view of the sky, meaning all around you (360 degrees), or is it severely restricted?
What kind of antenna do you use, and where is it located.
Can you post a picture of the GPS board?
Post a screenshot of u-center after it ran for at least an hour or so. (the longer the better)
Good luck!
Could it be that I have a Neo7 where the settings cannot be changed? I've seen that there are devices with ROM. Changes are always lost.
-
It could be you have a counterfeit that isn't a NEO7 at all ;) Everything is possible.
But anyway, if you haven't grossly misconfigured Lars' software, it should achieve lock even with default GPS settings. Most importantly you need to set the gain correctly for your OCXO.
-
Could it be that I have a Neo7 where the settings cannot be changed? I've seen that there are devices with ROM. Changes are always lost.
Jepp, most Clones has no flash ram. You can check it in U-Center.
https://portal.u-blox.com/s/question/0D52p00008HKEEECA5/psa-fake-ublox-modules-and-potential-ways-to-identify-them
it should achieve lock even with default GPS settings.
Nahh, not really. If you set the U-blox M7N to Gallileo Satellites, you have a more accurate System, because Gallileo works with Maser-Clocks only.
Too many Satellites are not really good for the accuracy. We had the same theme in the BG7TBL thread.
-
Seems to be okay, but with ROM.
??:??:?? $GPTXT,01,01,02,u-blox ag - www.u-blox.com (http://www.u-blox.com)*50
??:??:?? $GPTXT,01,01,02,HW UBX-G70xx 00070000 *77
??:??:?? $GPTXT,01,01,02,ROM CORE 1.00 (59842) Jun 27 2012 17:43:52*59
??:??:?? $GPTXT,01,01,02,PROTVER 14.00*1E
??:??:?? $GPTXT,01,01,02,ANTSUPERV=AC SD PDoS SR*20
??:??:?? $GPTXT,01,01,02,ANTSTATUS=DONTKNOW*33
??:??:?? $GPTXT,01,01,02,LLC FFFFFFFF-FFFFFFED-FFFFFFFF-FFFFFFFF-FFFFFFFD*2D
-
Could it be that I have a Neo7 where the settings cannot be changed? I've seen that there are devices with ROM. Changes are always lost.
Jepp, most Clones has no flash ram. You can check it in U-Center.
https://portal.u-blox.com/s/question/0D52p00008HKEEECA5/psa-fake-ublox-modules-and-potential-ways-to-identify-them
it should achieve lock even with default GPS settings.
Nahh, not really. If you set the U-blox M7N to Gallileo Satellites, you have a more accurate System, because Gallileo works with Maser-Clocks only.
Too many Satellites are not really good for the accuracy. We had the same theme in the BG7TBL thread.
For a DIY GPSDO Lars-style, it doesn't matter if you use Galileo or GPS. It should still lock if you use a small enough time constant. As long as the time pulse is in the right ballpark, it'll be fine.
Anyway I don't believe the stability of the Galileo master clock can be transferred to the receiver, with all the uncertainty added by the transmission medium.
-
Fennec,
We had the same theme in the BG7TBL thread.
Can you please point to that section? there are way too many threads to plow through.
Thank you!
-
After I took the insulation away from the OCXO's and ran the measurements again for several days, I have decided to put them back on.
Even with the DAC temperature compensation activated, the dependency of my GPSDO systems are too sensitive to the room temperature changes. So much so that I'm loosing lock constantly, while I ran for months without problems when they were boxed in. I only took the insulation away because it seemed that the OCXO oven temperature regulation was misbehaving when the room temperatures were in the order of 30 degrees C, during the current heatwave. My take on that is that maybe the delta temperatures between the ambient and the desired oven temperatures where becoming too small, and the oven jumped to a higher temperature setting.
I think I can live with that effect during a heat wave, rather then having them so sensitive to the room temperatures.
The alternative could be to put my metal enclosed GPSDO system wrapped in insulation inside another plastic enclosure to shield it better from "sudden" room temperature changes.
Has anybody collected experience using that approach?
Whilst that would filter out the effect of sudden changes in ambient temperature, it does have the downside of elevating the operating temperatures of all the other components, notably that of any electrolytic capacitors which are best kept as cool as possible to maximise their limited service lifetime ratings. Solid state devices will generally be more tolerant of elevated temperatures unless they already run hot to begin with at more normal ambient temperatures.
Incidentally, the best OCXOs using true SC cut xtals have their oven temperature set point at 92 deg C, according to this article I found when trying to refresh my memory of the "Facts"
https://4timing.com/techcrystal.htm
Istr seeing temperature figures of 75 to 85 deg being mentioned for OCXO oven set point temperatures. That's significantly higher than I'd remembered but it does explain the upper ambient temperature limits of 80 deg I'd seen quoted for some OCXOs.
That higher temperature set point is all to the good since this provides a healthy leeway on just how much thermal insulation you can get away with for any given expected maximum interior case temperature without losing control of the oven set point temperature. With typically less than 100mW for the LDO, the oven controller and the oscillator itself, I guess you can probably take the OCXO's case temperature to within 5 or 10 deg of the oven's set point before compromising its stability.
IOW, your hypothesis over the OCXO switching to a higher set point temperature is somewhat in error, not the least because, should such an algorithm even exist, it seems rather unlikely with this Lars based design that the temperature would have increased to the point where such an action would ever be called upon. The point of the oven is simply to maintain the xtal oscillator at a precise temperature over a very wide range of external temperatures and nothing more. If the external temperature exceeds the manufacturer's limits, there's no fancy algorithm that can rescue the situation.
I'm surmising that since the device controlling the heater current also happens to be the heating element itself (a small tabbed plastic power transistor or two), control could simply take the form of an analogue negative feedback proportional controller (no need for fancy PWM to control a separate resistive heating element to avoid the switching device contributing any of its losses into the mix as well as any spurious switching transient noise from a microcontroller running a PID control algorithm (True SC cut somewhat eases the oven set point temperature precision requirements). However, that article didn't go into such detail with regard to oven controllers - that's just an 'educated' guess on my part and I'm probably way off the mark, being the long suffering serial victim of Sod's Law that I am >:(.
If you've managed to exclude any highly stressed electrolytics from the design, you could try adding a heating element to keep the interior at a moderately high set temperature, say another five to ten degrees higher than you'd expect to see under maximum temperature heatwave conditions otherwise your best bet would be simply to house the OXCO within its own little thermo regulated housing (assuming it isn't a double ovened OCXO to begin with).
Incidentally, you're not the only one experiencing peculiar VFC variations which, in my case, seem to be an OCXO issue quite possibly related to its oven controller or the 5 to 12v boost converter I'm using to power it. My MK II GPSDO (a modernised version of the James Miller design using a u-blox M8T) has been showing several millivolts variations over and above those expected from ionospheric errors over the past week or so since it was last powered up.
It's well at odds with the experience I'd had with the MK I's "Five Volt" 13MHz OCXO retrace behaviour where, for example, it would lock in at 3.293v and gently drop to 3.289 over the next two or three days before increasing back to the 3.293v mark to resume its 2mV or so per week upward ageing trend.
The MK II did a similar retrace over the first day or two (2.2815v dropping to 2.2791v) before increasing right up to a peak of 2.2860v a few days later only to drop down to around the 2.2835 volt mark where it's been hovering up and down by a millivolt or two ever since, way more than can be accounted for by uncorrected ionospheric errors alone.
It's a real puzzle which warrants further investigation with a Rubidium frequency standard which, according to the rather pompously named "Global Shipping Programme"'s latest email last Wednesday " has cleared customs and is now out for delivery with the courier" (at their Erlanger shipping centre in Kentucky??? :wtf:).
Presumably, according to my all knowing brother in law, it's now awaiting cargo space on the next available commercial airline flight which, thanks to the Covid 19 travel restrictions, are now in rather short supply. ::) :palm:
In the meantime whilst 'm awaiting delivery of that LPRO-101, I might as well carry on monitoring the EFC voltage before opening the MK II up to monitor the OCXO's 12v supply rail (I can already monitor the 5.310v Vcc rail through the sma socket I wired up to let me run FFT spectrum traces of its noise and ripple content via a 4u7 ceramic DC block bypassed with a 1KR to let me measure the voltage with a DMM without any need to open up the enclosure). There seems little point in disturbing it until I've got my Rubidium frequency standard all set up and ready to go.
If you do decide to run that experiment, do take care to avoid thermally overstressing any expensive components. It may fail but even a failed experiment leaves you a little wiser and hopefully not too out of pocket if you took enough care not to overstress anything expensive.
Unless you have a bad one, I rather doubt the OCXO is that sensitive to external temperature shifts as to cause the microcontroller to 'lose it big time'. It's either a flaw in the control algorithm or else a component that has an inordinately high tempco which is not being properly accounted for.
Past temperature related problems with this Lars design all seem to have arisen during initial testing outside of any enclosure where draughts and/or solar insolation have created fast temperature transients which more or less disappear once the project has been installed into its enclosure or simply shielded from those influences. In your case, boxing it up hasn't cured it of its seemingly inordinate sensitivity to external changes of temperature. The problem might simply be a wiring error or else something you've overlooked.
You might need to give it a few more coats of "Good looking at" to figure out the true cause of this temperature induced instability you're experiencing. Otoh, taking a few days break can often work wonders by allowing you to take a fresh look at the problem. :)
JBG
-
Has somebody figured out how to derive and display the true OCXO frequency from the data provided by the Lars program? :-//
I have tried the TimeLab method in Excel but that only works well when you subtract the frequency offset and the drift line and these statistical numbers are not available in the Lars program.
-
Has somebody figured out how to derive and display the true OCXO frequency from the data provided by the Lars program? :-//
I have tried the TimeLab method in Excel but that only works well when you subtract the frequency offset and the drift line and these statistical numbers are not available in the Lars program.
Even TimeLab cannot do that. It will display "something" because it cannot know how the data it is being fed was generated, and probably all assumptions on what the number represents are broken anyway. So it will not be a "true OCXO frequency". It's only a number with an unknown relation to the true OCXO frequency.
-
I think you can get really close though.
Consider that over a long enough period, like a day or more, the average DAC setting must be very close to the ideal 10Mhz by virtue of the GPS disciplining.
If you used that averaged DAC number, and subtract the actual DAC value from it, you get a delta of the ideal 10MHz.
If you multiply that delta with the gain multiplied with 1E-9 you get an offset in absolute fractions of a Hz.
My assumption is that this is the way TimeLab does it.
I tried that in Excel and it gets really close.
The challenge of course is in getting absolute values based on past averages, and we will never know exactly how close they are to the real thing.
I also have to assume that the display of the OCXO frequency on the BG7TBL is done the same way.
Or is there another trick?
-
The display would always round out to be less (maybe a lot less) than 1 significant digit away from 10,000,000 - but it might be hard to tell how much if the accuracy variation was in the millihertz range, as what do you compare it to?
-
The display would always round out to be less (maybe a lot less) than 1 significant digit away from 10,000,000 - but it might be hard to tell how much if the accuracy variation was in the millihertz range, as what do you compare it to?
Ultimately, the reference is of course the GNSS. The idea to use the DAC average (better, the DAC bias term in Lars PI loop) to be the "true" 10MHz and then compute the frequency offset in terms of DAC deviation from this "true" value has some merit, but unless you can compute the uncertainty of that value, it's useless to output anything. Moreover, this average is moving up and down quite a bit first and foremost due to thermal effects, so unless you can compensate all these effects perfectly, the DAC values are not worth a lot.
-
Hi everyone
After researching various designs for a GPSDO I settled on the Lars solution.
I've built it up and it works, but with a couple of issues. Sorry if these have been covered already, I have read most of the posts on this thread!
When I switch it on I get regular "Missing 10MHz?" for about 15 minutes, even though the 10MHz input is a good 5V p-p square wave. Eventually it will lock and the message no longer appears. Is there a setting I can tweak to stop this?
Also, it loses lock if I close the Arduino Serial Monitor. Shouldn't it run standalone?
TIA
Mike
-
Also, it loses lock if I close the Arduino Serial Monitor. Shouldn't it run standalone?
I have seen ardu namo's w. USB misbehave if you write from the ardu (seial usb) wo having a terminal open.
I did a check if usb serial was ready , before writing.
But maybe that's already in the Lars Source
/Bingo
-
Also, it loses lock if I close the Arduino Serial Monitor. Shouldn't it run standalone?
I have seen ardu namo's w. USB misbehave if you write from the ardu (seial usb) wo having a terminal open.
I did a check if usb serial was ready , before writing.
But maybe that's already in the Lars Source
/Bingo
But if I switch the GPSDO on without a serial connection shouldn't it run and lock?
Mike
-
OK I understand now.
The Arduino resets when you connect/disconnect the serial bus. :palm:
So much to learn ...
Mike
-
https://forum.arduino.cc/index.php?topic=500176.0
-
https://forum.arduino.cc/index.php?topic=500176.0]
Thank you sir, the 10uF solved the problem.
Now I have a working system. The "Missing 10MHz?" message stops after warm up and it locks reasonably quickly.
I ran a 12 hour MDEV measurement to get the hang of how TimeLab works.
Please could someone explain how to optimise the time constant, as I don't really understand the instructions that Lars wrote. Set the GPSDO into hold mode, but then what?
Thanks
Mike
-
I just saw this post by Bob ,KB8TQ, over on Time-Nuts on how to test an OCXO, this looks like a useful thing to add to this thread. He says that most salvaged OCXOs on EBAY etc, have issues, and this is a way to weed out the ones that are obviously defective from the good ones, (and the ones with more subtle issues, it seems). You need a multiple bench supply with adjustable voltage and current.
http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2020-August/101216.html (http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2020-August/101216.html)
[time-nuts] Datasheet for TeleQuarz 20TQG01?
Bob kb8tq kb8tq at n1k.org
Sat Aug 22 09:18:58 EDT 2020
Previous message (by thread): [time-nuts] Datasheet for TeleQuarz 20TQG01?
Next message (by thread): [time-nuts] Datasheet for TeleQuarz 20TQG01?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi
Regardless of who made it, OCXO’s often don’t do well after being knocked around.
The process of puling them off pcb’s is stressful to the internals. The shock and vibration
in normal “junk box” storage can be an issue. As a result, the original performance data
may not be of much use.
I’ve tested a lot (like hundreds) of surplus OCXO’s. Well under 10% of them met their original
performance specs. That’s just for the stuff I can test in the basement, with better test systems,
the total would be lower.
Pinout wise, the ground pin *should* be easy to spot. Normally it’s bonded to the case. Once you
have it identified, start looking at pinot diagrams for similar sized OCXO’s. It may fit a standard
pattern. That would give you a guess for the +12V pin.
Hook up with a supply set to about a 1.2A current limit. Apply 12V to the assumed supply and
ground. The part probably pulls < 1A and almost certainly pulls < 1.5A. After 10 minutes on power
the current should start to cut back. If the case gets really hot (like you can’t touch it for the count
of 5) then something probably is wrong ….
Once you have it on power, a ’scope hopefully will spot the output pin. If it’s a sine wave, running
without a load may give you a pretty distorted output. 50 ohms is a good guess for the load.
The EFC pin should look like a high resistance on an ohm meter. It may or may not have a bias
on it when the device it powered. Feeding it 0 and 2.5V while watching the output on a frequency
counter should let you ID it. After running the device for a day or three, “tune” the EFC to whatever
voltage gives you 10 MHz. That’s the center voltage for what you have, regardless of what it
was when it left the factory ….
Lots of fun !!
Bob
> On Aug 22, 2020, at 8:34 AM, Paul Boven <p.boven at xs4all.nl> wrote:
>
> Hi again,
>
> Replying to myself:
>
> More online searching has revealed that 20TQG01 is likely a date code (week 20 of year 2001, charge G?). The other identifiers printed on the OCXO are '7368' and 'EO10391410'.
>
> On 8/22/20 11:56 AM, Paul Boven wrote:
>> Dear time nuts,
>> In my surplus drawer, I found an OCXO which I would like to use for a home-built GPSDO. The part in question is a 10 MHz, 12V OCXO, type 20TQG01. It came from a flea market, and looks to have been removed from a PCB. It's fairly large metal case (h = 2.5cm, w = 4cm, l = 5cm) and has 7 pins. According to the seller, it achieves 1.2 ppb (!).
>> Unfortunately, the Telequarz group no longer exists, and I've been unable to find anything resembling a datasheet. Any further information would be very welcome, especially pinout and performance parameters.
>> Regards, Paul Boven.
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at lists.febo.com
-
Please could someone explain how to optimise the time constant, as I don't really understand the instructions that Lars wrote. Set the GPSDO into hold mode, but then what?
Thanks
Mike
OK I decided to do the decent thing and read this thread before asking any more questions. Several days later I have a better understanding :-+
I have built Lars' original circuit with an NDK OCXO that came out of an IFR signal generator. It's very sensitive to control voltage (1500ppb/volt) but I managed to get the gain up to 500 with a voltage reference, potential divider and a 4.7M resistor in the DAC line.
With default EEPROM values it locks quickly and stays locked over long periods. However there are quite a few "10MHz Missing?" errors during warm up. Once it's locked they disappear forever except if I use the h command (h0, h1 etc.) when they appear quite frequently again. This means I can't use the hold mode to estimate the optimum TC. I'm confident in the quality of the 10MHz input to the divider, so could this be a software issue?
Instead I plotted MDEV in locked mode with TC=4. Am I right that it's suggesting around 1,000s for the optimum TC?
Thanks,
Mike
-
Provided you have not tinkered with the data by removing the drift, yes, it suggests that. But you should display the error bars and maybe take more samples, right and the "end" of the graph the uncertainty is very high.
-
Provided you have not tinkered with the data by removing the drift, yes, it suggests that. But you should display the error bars and maybe take more samples, right and the "end" of the graph the uncertainty is very high.
OK, thanks. I will do a longer run but I get very impatient :(.
I changed the TC to 200 and it took 85 minutes to lock, even though the TIC value was below 100 at all times.
Still confused about the 10MHz Missing message.
Mike
-
Provided you have not tinkered with the data by removing the drift, yes, it suggests that. But you should display the error bars and maybe take more samples, right and the "end" of the graph the uncertainty is very high.
OK, thanks. I will do a longer run but I get very impatient :(.
I changed the TC to 200 and it took 85 minutes to lock, even though the TIC value was below 100 at all times.
Still confused about the 10MHz Missing message.
Mike
Oh, patience is a much needed trait when you tune a GPSDO ;)
The "10MHz Missing" message is printed when the ADC value is at 1023, i.e. at maximum. It should not get higher than 1000. Looks like the interpolator is not OK.
Take a look at the output of the 4046 and check the components from there to the ADC input pin. Maybe you need a larger series resistor.
-
The "10MHz Missing" message is printed when the ADC value is at 1023, i.e. at maximum. It should not get higher than 1000. Looks like the interpolator is not OK.
Take a look at the output of the 4046 and check the components from there to the ADC input pin. Maybe you need a larger series resistor.
OK will do.
Mike
-
I checked the series resistor and it measured 3.8k. I replaced it with a 4.7k and there were no "Missing 10MHz?" messages during warmup :-+
I've started another run with TC=4s (I'll leave it running longer this time). I notice that the values for TIC and diff_ns are much closer to zero than before.
Mike
-
Hi cdev,
I've been preoccupied with my latest addition, an Efratom LPRO-101, this past week so only spotted your post just now. That article on testing unknown OCXOs by Bob offers good advice but there is one worrying aspect of it concerning the choice of Vcc/Vdd voltage where he suggests you just blunder in directly with a 12v Vdd voltage. If he's talking about an OCXO for which there's seemingly no published datasheet to provide any firm guidance on the required voltage (and this seems to be the case), you could land up applying 12v to a 5v part which is guaranteed to make said 5v part instantly emit its 'magic smoke'.
This was exactly the situation I was facing just over 18 months ago with my very first (one and only) 13MHz CQE OCXO. Although it was a dead ringer for a 13MHz Vectron (the only datasheet I could download for any guidance), I was still unsure about risking 12v on what may have possibly been a 5v part (it looked like NOS rather than a carefully extracted OCXO removed from a decades old PCB where 12v was the most common Vdd specification).
I wasn't prepared to take any risk of 'smoking my 4 quid radioham rally bargain' with a 12v jolt so tested it on a 5v supply which proved sufficient for it to start outputting a 3v p-p square wave after about 10 to 20 seconds delay (it turned out that the voltage regulation with load of the humble 1117-5 is rather crap - I was actually only getting 4.82v at the 280mA (current limited) warm up loading upon the cheap LDO used on the solder-less breadboard power adaptor board).
After an 8 minute warm up time, the frequency settled down to 13MHz exactly and the current had dropped to 180mA. Using a potentiometer across the Vcc to supply a tuning voltage to the EFC pin proved it could be electrically tuned and thus a candidate for my GPSDO experiments (I'd already figured out a way to generate a 10MHz output locked precisely to a 13MHz square wave).
I tried powering it from a 6.9v rail (half of the 13.8v smpsu made up with a pair of 5v 10A Farnell switchers in series modified to output 6.9v each), monitoring the square wave output voltage which had shot up to 6v p-p. I decided to risk another volt's worth using a charged up NiCad in series (I didn't possess a 32V 10A max variable bench supply back then - I do now :) ) and saw the output had risen by yet another volt strongly hinting that the oscillator/buffer was seeing the full Vdd voltage rather than the 5v of an internal LDO which would be mandated by a 12v design.
I'd spotted a trend whereby I could expect to see a 10 or 11 volt p-p output off a 12v Vdd, assuming no loss of magic smoke, an output voltage I'd never ever seen specced by any of the many OCXO datasheets I'd perused so decided it was best to play safe and assume for the time being that it actually was a 5v part (after all, on a 5.2v supply, it was outputting a 4v p-p square wave within seconds of applying power and functioned exactly as an OCXO would be expected to behave. The only hint that it may have been a 12v part - the now slightly less protracted 7.5 minutes warm up time, wasn't strong enough evidence at the time to risk destroying my one and only OCXO to date.
One advantage in assuming a Vcc of 5v being the simplification of the power rails in my MK I GPSDO down to just a single 5.17v. The protracted 7 minutes or so warmup was no impediment since it meant less overshoot when it finally did get up to temperature - you really need at least half an hour either way for an OCXO to be reasonably settled down before the GPS stops chasing a moving target.
By the time I had more evidence of it being a 12v part ( a bunch of 10MHz sine output CQE OCXOs of exactly the same form factor and pin out I'd fortuitously chanced upon as a result of a continued fruitless search for a datasheet) by virtue of having enough spare 10MHz CQE OCXOs to risk blowing one up for just a modest 6 quid investment which revealed the exact same 280mA warm up current which, at 12v, dropped to just 90mA to give an identical warmed up power consumption of around 900mW, I'd already settled on a single 5.2v rail design, devoid of the need of another DC boost converter or the need to tie the power supply to a 12v only option in place of the 7 to 24 v requirement allowed by the buck converter I was using for the single 5.2v rail.
Apart from the protracted warm up time, that 13MHz OCXO worked just fine in my MK I GPSDO (essentially a variant of the excellent James Miller design). I only retested that OCXO with a 12v rail less than a fortnight ago after I had successfully commissioned and proved my MK II variant as its replacement, proving what I had long suspected that it had been a 12v OCXO all along - still, better safe than sorry. :) It had served me well as an ersatz 5v OCXO these past 6 months or so. Now it can serve as a memento of my first experimental efforts at designing and building a GPSDO - I doubt I'll find another use for it.
Anyhow, for anyone checking out their very first and only OCXO for which they have no absolute and incontrovertible evidence as to its actual voltage requirement, rather than plunge straight in with a 12v supply as Bob suggested (not a problem if you've bought a job lot dirt cheap), try a 5 or 6 volt supply to start with and monitor the Vref pin to check whether it stabilises at either 3.3 or 5 volts (the more ancient 12v OCXOs may have oddball 6 or 7 volt reference voltages). A 3,3v reference would strongly hint at a 5v OCXO whereas a 5v reference would suggest a 12v unit (that 13MHz CQE didn't stabilise at its 5.1xx volt set point until Vdd had hit the 11 volt mark).
Unfortunately, checking the Vref pin (if it has one - why would you even bother with an OCXO if it doesn't have a Vref pin?) isn't a reliable indicator - some OCXO's with a "Vref pin" are no better than those without by virtue of it not being connected to anything, hence the advice to monitor the output pin to look for it reaching a fixed p-p limit as the test voltage is ramped up.
Also, though I didn't appreciate it at the time, if the output takes 15 to 20 seconds or more to stabilise into a recognisable waveform on a 5v supply but appears much quicker off a 6v supply (2 or 3 seconds), that's a pretty good indicator that it's more likely a 12 rather than a 5 volt part. This was a more obvious indicator that the 10MHz units weren't 5 volt parts - they did eventually stabilise at a 3v p-p sine output after a 20 or so seconds delay on a 5.2v supply (slower than the 13MHz unit had done on a 4.82 volt supply - hence my doubt as to it being a 12v part).
A variable bench supply (which I didn't have when I was first trying to determine that 13MHz OCXO's voltage requirement) is a very useful tool in this case. Although the accuracy of their built in voltage and current meters (particularly the current meter) leave something to be desired in the cheaper (affordable) Chinese models, they're still good enough to indicate unexpected behaviour perhaps just in time to terminate the test before lasting damage has occurred.
However, a better strategy is to monitor the current demand at a 5.5 or 6 volt setting and wait for the warm up current to drop to a lower steady reading after maybe as long as 10 minutes if the part is a 12v one. The heater current is normally a constant current during the warm up phase so you can reconfigure the current limit setting on your bench supply to somewhere between the heating up current and the settled at temperature current and restart the test, allowing the current to stabilise at its set point temperature before increasing the voltage in small increments, looking for any departures from the expected small reductions in heater current demand to compensate for the voltage increase to maintain the steady energy consumption required to hold a constant oven temperature, not forgetting to monitor the clues provided by the Vref pin and the p-p output voltage level.
If you keep in mind that the absolute maximum allowed supply voltage stress of 7 volts typically quoted in datasheets for 5v parts, if you reach the 8v mark with no obvious symptoms of distress being shown, then it's almost certain you're dealing with a 12v OCXO where you can use one volt increments to reach a 12v target. Once you're confident you're testing a 12v part, you can 'ice the cake' with a 13.2v test to definitely confirm this (standard voltage tolerance for 12v parts being +/-10% - I took the test voltage on my 13MHz OCXO right up to 14v for good measure: I was curious and had no foreseeable use for it so wasn't concerned as to whether this would prove to be 800mV too many).
JBG
-
Wise advice from JBG.
I only currently have one OCXO, which was made by NDK and came out of an IFR signal generator. There is no data sheet for it but the IFR schematic shows it fed with a supply of 11V so I think it's safe to assume it's a 12V part.
I have a Trimble 65256 on order from China. It's advertised as a 12V part but I know that many of them are 5V so I will be adopting your cautious approach when it arrives.
As for a Vref pin, I wouldn't use one even if it was present as I think an external precision regulator would perform better.
Mike
-
I prototyped up the Lars GPSDO from the schematic in his original post, set a Ublox 7N to 1 Hz with a 10% duty cycle and connected the GPSDO to a BG7TBL Crystal Board dated 2016-09-25 with a DAPU 055A-HSDD OCXO. I had previously removed the trimpot on the OCXO board and replaced it with a 3 wire header for the ground, voltage reference and control signals. Lars original software was downloaded and used unmodified. I did use the F1 D command to set the DAC nearer the approximately 3.3 Volts needed to give a 10 mHz signal. The control voltage was monitored by a Fluke 45 DVM and the output frequency measured by a BG7TBL FA-2 Frequency counter with a gate of 1 second. A LPRO-101 rubidium oscillator, which had been calibrated to a Cesium Standard 2 months ago when I purchased it, was used as the FA-2 clock. One of the purposes of building the GPSDO was to provide ongoing assessments of accuracy of this clock, and perhaps eventually discipling it also. The GPSDO was run continuously for more than 24 hours before collecting the data shown in the attached. The Lars GPSDO appears to be accurate (assuming the clock is still on frequency) with a median value of 10,000,000.000 078 Hz and a mean value of 10,000,000.000 222 Hz with a n=25112. The frequency does vary over several milliHz as shown in the FreqTimePlot.pdf attached. Perhaps someone who is familiar with what this GPSDO could advise me how much the precision could be improved with better settings. By comparison and on the same scale is a similar plot from a BG7TBL GPSDO 2014-12-09 input with the same clock. Thank you. Bob
-
Hey, I read thru all the notes, Lars did a great job and Jim Harmon took it a step further with the 7200 and DAC. I plan to use Jim's design to discipline an Rb unit but instead of all the EFC stuff, the Rb I'm using takes a tuning word of .2e-11 offset so I can just send that over another serial line. I bought two of those M8T GPS units a while back, one for the Rb and another for a DOCXO.
Question: how are you getting the data for the Adev/Mdev charts? Is that coming off the Aduino in relation to the GPS 1PPS phase? I use a reference, either a Cs or another GPSDO, with Riley's DMTD as realized by Bert feeding a TIC. I want to compare this to my Lucent GPSDOs.
Thanks,
Jerry
-
Root cause found for the temp/ns/DAC jumps.
For several months I have been hunting for the cause of the strange temperature jumps of the three different OCXO ovens I have. For far too long, I suspected the temperature jumps to come from the ambient temp, or the OCXO oven and this would influence the ns/DAC jumps and so I was hunting in that direction.
I have finally found the root cause.
Below is what happens with my Oscilloquartz version. It is no longer using the full OCXO isolation, to avoid "over-heating" but the whole GPSDO unit is now in an extra enclosure with isolation to avoid sudden room temperature drifts.
These graphs run from midnight to midnight and are sampled every second as they are coming from the Lars firmware. I collect the output by a Raspberry Pi connected to the Txd/Rxd pins of the Arduino Nano. These daily log files are emailed to me.
To see what is going on during the day, I also use a USB-mini cable connected between the Arduino and my PC. I use the Arduino serial monitor to show the second by second Lars' report on my screen.
The cause of the temperature jumps, that literally changes from one second to the next, is due to my PC waking-up from sleep in the morning or going to sleep in the evening. This going to sleep or wake-up will activate or deactivate the power on the USB port of the PC, and hence will apply 5V to the Arduino through the USB serial link, or not.
This is interesting, because I feed a regulated 8V DC to the VIN power input of the Arduino, and I do not have any other logic connected to the 5V and 3V3 power outputs from the Arduino board. I only have a 100uF cap attached to the 5V output, and nothing to the 3V3 output. You would think that the 8V supply and the on-board voltage regulator would sufficiently power the Arduino, regardless of the presence of 5V coming from the USB connection. The Arduino circuit uses a Schottkey diode (D1) to "OR" the on-board regulated 5V supply with the 5V coming from the USB input.
For a reason I cannot explain yet, the Arduino ADC1 and ADC2 inputs that are used to sample the temperatures are influenced when you apply the USB cable with power. You can also see in the graphs that ADC0, used for the TIC input, gets the same treatment, and this influences the TIC measurement (ns graph) and hence the DAC.
Because of the DAC jumps, we have a "falsifying" event in the TimeLab reports.
The solution would be to use a USB cable with the 5V power removed, or remove D1 on the Arduino board. Unfortunately, this diode is located on the bottom of the PCB and is not easy to get to when you already soldered the Arduino on a main PCB, like I did.
-
Hey,
my english is not the best but I found this. Maybe someone can use it.
/attached
comes from https://ieeexplore.ieee.org copyright maybe? idk
[attachimg=1]
-
Wise advice from JBG.
I only currently have one OCXO, which was made by NDK and came out of an IFR signal generator. There is no data sheet for it but the IFR schematic shows it fed with a supply of 11V so I think it's safe to assume it's a 12V part.
I have a Trimble 65256 on order from China. It's advertised as a 12V part but I know that many of them are 5V so I will be adopting your cautious approach when it arrives.
As for a Vref pin, I wouldn't use one even if it was present as I think an external precision regulator would perform better.
Mike
Hi Mike,
thanks for that 'vote of appreciation'. :) The advice really only covers the situation where you just can't find a datasheet or any hints whatsoever of the Vcc / Vdd voltage requirement for a one and only example of OCXO. If I'd found a datasheet for the 10MHz CQE OCXOs, I might have dared to test the 13MHz unit at 12v sooner rather than much later using the additional clue given by both types exhibiting the exact same 280mA constant current warm up characteristic.
I never did find any datasheets for the 10MHz units and the vendor had no idea either so I only discovered they were a 12v type by risking one at the higher voltage (the difference being that I had another two to spare at that stage). I'd already committed to a 5 volt only design by then and since the 13MHz OCXO seemed to be coping much better with a 5.0v supply than any of those 10MHz variants ever did, I decided to play safe and carry on assuming the 13MHz OCXO was a 5 volt part with just a rather protracted warm up characteristic (I didn't have a variable voltage bench supply back then otherwise it might well have been a different story).
My thinking behind the use of an OCXO Vref instead of a separate high precision reference IC was that even if a cheap 'n' cheerful 1117-5 LDO had been used, the fixed loading from the oscillator and thermal controller and another fixed 1mA external load would eliminate the issue of voltage variation with current demand and the fixed 12v supply, likewise the voltage regulation versus input voltage variations and ripple leaving only the question of the effect of its TC. Guess what? With a precisely regulated 'oven temperature', this was simply going to be yet another non-issue! :)
Until I saw this blog posting:-
http://syncchannel.blogspot.com/2016/03/schematic-of-cts-1960017-10mhz-ocxo.html (http://syncchannel.blogspot.com/2016/03/schematic-of-cts-1960017-10mhz-ocxo.html)
I would have expected the Vref pin option to always be an excellent alternative to a separate (and expensive) high precision voltage reference IC. In this case, I'd agree with you regarding an external precision voltage reference IC being the much superior option. ::)
I suppose I should now qualify my recommendation with the phrase "provided it is a 5v reference in the case of a 12v OCXO or a 3.3v reference in the case of a 5 volt one and you run a basic verification test to prove they will be as temperature stable as you have every right to expect".
It seems at least one brand (CTS) cheats on this critical aspect of OCXO design so I can see why you have a different view to my own (so far I've only had experience of the CQE brand which doesn't cheap out on the Vref circuit). It seems I touched lucky with that batch of seven CQE 10MHz 12v OCXOs I'd purchased at just £4.99 each off a UK seller last year. If they're good enough for the Symmetricom GPSDO described here:- https://youtu.be/zkzMtLyqju4?t=793 (https://youtu.be/zkzMtLyqju4?t=793)
I think I can safely say they must be one of the better brands for use in a DIY GPSDO. :) That one is almost identical to mine in that the DOC number matches exactly that of all of the 10MHz units in my own modest collection (the 13MHz one has a different DOC number). Even the little blue circular stickers are the same except for the fact that on mine they appear to be a day/month code rather than whatever the 90/4 is supposed to represent. (on very close inspection, the number seems to be 30/4 - another day/month code, maybe the colour of the sticker codes for the year?). The layout on the label is different but all the numbers are present on both mine and that Symmetricom one. The 9850/0529 looks to be some sort of serial number since they're all unique on mine eg 0042/nnnn, 0047/nnnn and 0050/nnnn on the five remaining spares I have to hand.
I was rather pleased to see a CQE OCXO used in that Symmetricon GPSDO since I seem to be the only one mentioning this particular brand in these EEVBlog topic threads. They must be good quality OCXOs otherwise Symmetricom wouldn't be using them in any of their kit. :)
In my case, stability of this voltage reference trumps absolute accuracy since I just need a very stable meter DC offset to allow a cheap 9999 counts DMM to display the millivolts portion to within a tenth of a millivolt, allowing me to observe the effects of ionospheric and tropospheric timing errors, the latter being about a tenth of the former, inherent in the GPS navigation system which impose those annoying subsonic (mHz) phase shifts that become ever more evident when trying to use them to calibrate RFSs to within a few uHz in even the best of the single frequency (L1) GPSDOs.
Using a more expensive dual frequency timing receiver can dynamically cancel the ionospheric timing errors for each of the SV signals used in the navigation fix calculations but are a rather expensive solution for hobbyist use.
A GPSDO, whether a simple cheap DIY effort or a sophisticated expensive microntroller based one disciplining a high quality double ovened OCXO, might be accurate enough over days long intervals out to tens of years but they all stink when it comes to the minutes long periods of stability required to calibrate an RFS to within a few uHz of its potential accuracy within a reasonable span of time. To do that, you need to be disciplining another RFS which could be done with the cost effective Lars based design that doesn't have to cope with the unpredictable behaviour of OCXOs at this scale of precision.
Whilst a microcontroller based GPSDO can, in principle use a Kalman filtering algorithm to smooth out these annoying phase shifts from data collected over periods of 24 hours and longer, this seems like a "Catch 22" situation in that you're relying on what you're disciplining to carry on following a predicted trajectory by which to refine the tuning voltage to match an average of the previously collected data.
Unfortunately, even the best quality of double ovened OCXOs can't be guaranteed to always follow the plan and will depart from their predicted trajectory from time to time, requiring a contingency algorithm to promptly drag them back on frequency. It strikes me that the Lars design either lacks such an algorithm or else it isn't being properly tuned by those attempting to configure their own implementations (or, possibly overlooking unexpected shortcomings in their choice of components and circuit layout).
Disciplining a RFS is a lot easier. You only have to compensate for ageing once you've stabilised the base plate temperature and eliminated the effect of barometric variations (using a barometric sensor to compensate via the external tuning voltage input being the most practical alternative to a vacuum containment or, a little less impractical, a pressure regulated containment).
Of course, the main worry by hobbyists who've blown close to 200 quid on a twenty year old RFS is the remaining lamp life. Most hobbyists will put up with the limitations of an OCXO based frequency standard and only run the RFS for a day or three at a time for occasional use as a calibration standard in order to extend the service life of this precious commodity..
Considering the exorbitant pricing of a "High Quality" GPSDO, I think I'd prefer to take my chances and run a disciplined RFS full time - I'd like to see just how much longer a 20 year old RFS with a "Design life of at least ten years" will run for before it needs replacing.
JBG
-
I would have expected the Vref pin option to always be an excellent alternative to a separate (and expensive) high precision voltage reference IC. In this case, I'd agree with you regarding an external precision voltage reference IC being the much superior option. ::)
Yes I'd rather use an external reference with known characteristics than the unknown internal circuitry of the OCXO.
I think your requirements are rather more demanding than mine. All I need is an accurate affordable 10MHz frequency reference for occasional use to calibrate my frequency counter and other amateur radio equipment.
Mike
-
Of course, the main worry by hobbyists who've blown close to 200 quid on a twenty year old RFS is the remaining lamp life. Most hobbyists will put up with the limitations of an OCXO based frequency standard and only run the RFS for a day or three at a time for occasional use as a calibration standard.
I'd not trust a RFS that hasn't warmed up and settled for at least a couple of days...
-
Hats off to Lar's. I breadboarded his circuit, hooked it to one of my HP 10811s that sit on a board from an HP 5328 counter and gave it a shot. It wouldn't lock until I found I had to invert the EFC. So I made a simple change in the programming and it locked in about a minute (changed the positive to the negative terminal - Young Frankenstein) . Yet to see if it sticks but I'm optimistic.
I wish I had wired up the Lock LED to make it easier to watch. Anyway, lots of fun with a simple circuit.
Jerry
-
I've just finished a 5 day run of my Lars GPSDO with a 4 second time constant. Some results are attached, and I have some questions for the experts please.
1) Does the MDEV plot suggest an optimum time constant of around 500 seconds?
2) Given that my use for this is as a frequency standard for occasional calibration of test equipment I have no need to run it 24/7. If I chose a shorter time constant for a faster lock time what effect would it have on frequency accuracy?
3) Is it possible to deduce the quality of the OCXO from these results (e.g. good/average/poor)?
Thanks!
Mike
-
Is that really the DAC column you imported, or is it that TIC values? TIC values would be mostly useless, as they don't tell you enough about the OCXO.
-
The DAC is in the 3rd column. But the value jumps a lot.
-
The DAC is in the 3rd column. But the value jumps a lot.
Yes, but with TC=4 that's expected. The DAC follows closely the TIC and the ADEV or MDEV will eventually expose the point where the GPS beats the OCXO with regards to stability.
-
Is that really the DAC column you imported, or is it that TIC values? TIC values would be mostly useless, as they don't tell you enough about the OCXO.
Yes, I imported the DAC column.
Mike
-
Is that really the DAC column you imported, or is it that TIC values? TIC values would be mostly useless, as they don't tell you enough about the OCXO.
Yes, I imported the DAC column.
Mike
Did you by chance edit the series in TimeLab? Like, remove linear drift or drift curve? The MDEV graph looks a bit indecisive here, after 5 days of collecting samples, you'd expect a very clear uptick that signifies the OCXO drift. But it's going down and further down only.
-
The DAC is in the 3rd column. But the value jumps a lot.
Here's an extract from an overnight run with TC = 200s. The DAC value rises and falls slowly. Is that correct?
(I don't have any temperature compensation yet and the GPSDO is not enclosed).
Mike
-
Did you by chance edit the series in TimeLab? Like, remove linear drift or drift curve? The MDEV graph looks a bit indecisive here, after 5 days of collecting samples, you'd expect a very clear uptick that signifies the OCXO drift. But it's going down and further down only.
Yes I subtracted the global linear frequency trend. Here is the unedited plot.
Mike
-
Did you by chance edit the series in TimeLab? Like, remove linear drift or drift curve? The MDEV graph looks a bit indecisive here, after 5 days of collecting samples, you'd expect a very clear uptick that signifies the OCXO drift. But it's going down and further down only.
Yes I subtracted the global linear frequency trend. Here is the unedited plot.
Mike
Aha. Well, that's more like it. You know, by removing the linear frequency trend you edited out the very thing you've been looking for :-)
Now, how I'd interpret the graph is that this OCXO should be good up to a time constant of 2000 seconds, which is pretty impressive, especially since it is not protected against temperature changes at all.
PS: Note that the curve shows a clear drift behavior only beyond 20000 seconds, which is a bit too good to be true. That would be more in line with a Rubidium standard, but not with an OCXO.
-
Mike,
The DAC plot looks reasonable. There are no significant corresponding changes in the ns plot, although the excursions are a bit large. Due to the saw-tooth effect, this should create about a 20nsec "band", which it typical and sufficient. Your setup is not bad at all, most of the saw-tooth excursions are in a 15nsec band, which is very good. From your data, it looks like that the DAC just moves with the temperature.
Due to the temperature induced changes on the DAC (room temperature changes and draft), it makes sense to add OCXO temperature tracking. With that you can compensate the DAC with the temperature effects and try to eliminate them.
This is important because these temperature induced changes in the DAC values "falsify" a TimeLab plot based on the DAC values and therefore cannot show the "real" OCXO performance. This DAC-based TimeLab method is a poor man's way of looking at the OCXO performance, so keep that in mind.
-
When looking at the pictures in Lars' docs (page 19-21) he got something like ~1E-12 at 1000secs (in "the hold mode", not sure it is an identical measurement process, however)..
-
Thanks everyone, that's all very educational!
Now, how I'd interpret the graph is that this OCXO should be good up to a time constant of 2000 seconds, which is pretty impressive, especially since it is not protected against temperature changes at all.
The problem with such a long time constant would be the initial lock time (I think 2000 seconds would take around 3 hours with the warmup?) as I don't plan to run this continuously. However I will try it out of curiosity (this project is becoming addictive!).
I will add temperature compensation once I put it in an enclosure.
My Trimble OCXO is due to be delivered today, and yesterday I bought a Vectron oscillator on eBay from a UK seller (just £10 and it's new!) so I will have plenty to play with soon.
Mike
-
However I will try it out of curiosity (this project is becoming addictive!)
:-DD Welcome to the club!
-
Would you post photos of your device? A little hardware porn...
-
Would you post photos of your device? A little hardware porn...
Of course, here it is.
I'm running it off a 15V wall wart which supplies an LM7812 for the OCXO, then an LM7805 for the logic/Arduino/GPS and a REF02EZ for the OCXO control voltage.
All unused tracks on the stripboard have been removed, and I've built a transistor buffer for the 10MHz output.
The GPS antenna is an active puck mounted on a ground plane on the house wall with about 180 degree view of the sky.
Mike
-
My Trimble OCXO is due to be delivered today, and yesterday I bought a Vectron oscillator on eBay from a UK seller (just £10 and it's new!) so I will have plenty to play with soon.
Mike
A quick update on this. The Trimble OCXO is tatty but working, although very power hungry. It draws 1.9A on startup before settling down to around 200mA.
The output looks a bit noisy. This is with an open circuit control pin.
The good news is that the Vectron device I ordered is an MX2001X4 which appears to be what is fitted inside the Trimble module :-+
Mike
-
The assembly is quick and clean. What is the REF02 for? If the GPS fails?
-
The assembly is quick and clean. What is the REF02 for? If the GPS fails?
No, it's a precision 5 volt reference that feeds the resistive divider connected to the OCXO voltage control.
Mike
-
The assembly is quick and clean. What is the REF02 for? If the GPS fails?
No, it's a precision 5 volt reference that feeds the resistive divider connected to the OCXO voltage control.
Mike
??? The OCXO voltage control comes from Arduino PWM.
-
??? The OCXO voltage control comes from Arduino PWM.
Yes, but in order to reduce the tuning range of the OCXO to get the gain up to around 500 I had to add a resistor network and a 5 volt supply. I couldn't do it with resistors alone.
The circuit is attached. The 10M resistor has been reduced to 4M7 and the gain is now 585.
Mike
-
??? The OCXO voltage control comes from Arduino PWM.
Yes, but in order to reduce the tuning range of the OCXO to get the gain up to around 500 I had to add a resistor network and a 5 volt supply. I couldn't do it with resistors alone.
The circuit is attached. The 10M resistor has been reduced to 4M7 and the gain is now 585.
Mike
Ok, now I understand. A kind of limiter/bias. The REF02 can drift around 0.5mV, but I think that doesn't matter.
-
I posted this on another thread, but wanted to show the difference between an indoor and outdoor antenna on my GPSDO (very similar to Lars' design). This was the same antenna, but ran it for a few hours outside, then a few hours inside.
[attachimg=1]
-
I posted this on another thread, but wanted to show the difference between an indoor and outdoor antenna on my GPSDO (very similar to Lars' design). This was the same antenna, but ran it for a few hours outside, then a few hours inside.
(Attachment Link)
Would be interesting to know how much dB U-Center shows indoor and outdoor.
-
I posted this on another thread, but wanted to show the difference between an indoor and outdoor antenna on my GPSDO (very similar to Lars' design). This was the same antenna, but ran it for a few hours outside, then a few hours inside.
(Attachment Link)
Proof positive that it's vital to locate the antenna outside with as clear an all round view of the horizon as you can achieve! :) It doesn't matter how good the gpsdo is, a poorly sited antenna will seriously degrade the phase and frequency stability. There are enough deficiencies in the whole GPS system to start with without adding yet another deficiency in the form of a poorly located antenna. :(
John
-
I posted this on another thread, but wanted to show the difference between an indoor and outdoor antenna on my GPSDO (very similar to Lars' design). This was the same antenna, but ran it for a few hours outside, then a few hours inside.
(Attachment Link)
Would be interesting to know how much dB U-Center shows indoor and outdoor.
It's a surprisingly small 10 to 15 dB drop in the C/NO figures! :) I was testing the second of the last two 24 quid M8T modules I'd purchased some five weeks ago despite a seemingly minor "NAV5" bug, that turned out to be a USB2 winXP VM driver issue I'd discovered only a a day ago, in the first 41 quid one I'd purchased some weeks earlier from the Amazon seller "Amoq313" (the bad news is that he's now bumped the price to £59.19 - still relatively cheap, mind you) using the supplied IPX connected active 25mm square ceramic patch antenna on my bench, some 15 feet away from a lead roofed first floor bay window, when I wanted to force LoS to avoid wearing out the IPX connector so I could verify the 4Hz 50% unlocked PPS output I'd programmed (set to 10Hz 50% when locked for the purposes of this test).
Optimistically, I rather though that placing a small empty peanut tin and then a taller coffee powder tin over the antenna might have cut off the signals, especially if filled with steel wire wool to act as an "RF absorber". Fat chance! ::)
Just as on all previous attempts to provoke a LoS situation, human flesh still proves the most effective attenuator (using my hand to cover the antenna) even if it still wasn't enough to provoke an unlocked state (I wasn't about to risk damaging the module by sitting on it to degrade both the signal and my dignity any further).
Even disconnecting the antenna to invoke a LoS condition to lose (NOT "Loose"! >:() GPS lock can take several minutes to remove all trace of the SV signals from the sky map plot. These M8 u-blox modules (both N and T types) can maintain an extremely tenacious grip on its acquired constellation of SV signals unltil they all finally dip below the 5dB C/NO threshold for more than a few seconds.
It's an impressive 'Party Trick' to my mind, considering that even with a good antenna, the signals are still below the background noise, but it does make simulating a LoS condition a lot more tricky to achieve when you want to avoid undue wear and tear on the antenna connectors. However, I've just remembered that in the case of active antennas, an effective way to obtain another 20 to 30dB loss is simply to disable the active power in the ANT CFG settings (has no effect of course with a passive patch antenna). Dang it! I clean forgot that fact! :palm: :-[
John
-
... when you want to avoid undue wear and tear on the antenna connectors.
John
That's easy, just fit SMA connectors to the pads provided on the PCB.
Mike
-
... when you want to avoid undue wear and tear on the antenna connectors.
John
That's easy, just fit SMA connectors to the pads provided on the PCB.
Mike
That's all fine and dandy after you've verified that the delivered module is working properly before tainting it with the leaded goodness of 'proper solder' to avoid accusations by the seller, in the event you have to return it for a refund or replacement, that you've damaged it by careless soldering. :)
I've soldered edge contact SMA sockets to these modules in the past to avoid fiddling around with those pesky IPX connectors any longer than needed to do the initial test, using clip on connectors to the Vcc, GND and TTL serial contacts which have been more trouble than they're worth (I use an elastic band with a 4 pin header to provide a more reliable temporary connection for these tests now).
The MK I gpsdo build used a right angled edge soldered SMA socket to attach the module to the rear panel for additional support but the current MK II which replaced it makes use of an IPX ended panel mount SMA socket pigtail, mainly it has to be said due to the M8T module's location and orientation within the case.
Regardless of the connector type, it's still good practice to avoid a high connect/disconnect cycle count to keep wear and tear to a minimum even with the more robust SMA sockets if you can help it. :)
John
-
@Johnny B Good
Pls can you make some pictures from your "version". U know, pix say more than 1000 words..
@all (esp. Dbldutch)
Pls upload PCB files (projects) for maybe Eagle, Target something like that, so it make it way easier to change the PCB design. Just the Gerber files are hard to use.
Also pls upload more pictures, configs, wich OCXO you use, and the source code. It's way easier than to read the whole thread.
kr
-
Fennec,
I'm posting most of my stuff on my own blog to not pollute this thread more than needed, and through that you can get to my Github site. I think I mentioned that in an earlier thread.
https://github.com/paulvee/Lars-GPSDO (https://github.com/paulvee/Lars-GPSDO)
-
I have one of the exact same GY-GPSV3-NEO "blue boards" which Lars mentions in his original description, the one where to connect the 1PPS you need to connect to the high side of the LED resistor.
The GPS board is thinner than the typical PCB size and I had to use a shim on an SMA to use mine with the SMA connectors I had at that time. Now I have some that work without a shim, of course.
But to test the GPS with any SMA antenna just plug the antenna cable with its SMA edge mount in without soldering it.
You may have to use gravity to presss the tinned area - prop it up a bit at an angle to get it to make the connection adequately. It takes a little less than 15 minutes to work from a cold start.
Additionally, in my experience if one is careful the (male?) IPX connectors may last years and can be used dozens of times. You buy them premade. The other end is tinned.
-
@Johnny B Good
Pls can you make some pictures from your "version". U know, pix say more than 1000 words..
@all (esp. Dbldutch)
Pls upload PCB files (projects) for maybe Eagle, Target something like that, so it make it way easier to change the PCB design. Just the Gerber files are hard to use.
Also pls upload more pictures, configs, wich OCXO you use, and the source code. It's way easier than to read the whole thread.
kr
Well, I'm a little flattered that you think "my version" will be of much interest here since... well I'll quote this from the leapsecond.com article on a GPSDO performance comparison here:- http://www.leapsecond.com/pages/gpsdo/ (http://www.leapsecond.com/pages/gpsdo/) since it's essentially a re-spin of the following using a modern u-blox timing GPS rx module in place of the Jupiter-T, running at 100kPPS to simplify the divider and operate at a better optimised phase locking input frequency.
"James Miller Simple GPSDO
This is about the simplest design possible for a GPSDO; with no DAC, no Vref, no time interval counter, no microprocessor. Just an XOR gate acting as a phase comparator aginst the 10 kPPS output of a Jupiter GPS engine. In spite of this simplicity, the performance is amazingly good."
Not only does it lack all the essential component parts of the Lars design, it also lacks sensitivity to ambient temperature variations (just thought I'd toss that in >:D ). So posting pictures of "my version" and hand drawn circuit sketches here would, I suspect, be regarded as "off topic" and earn me a :--
I've been following this thread simply because it relates to a cost effective DIY GPSDO project and hasn't withered away like 99% of all other GPSDO related threads that I've been able track down. Also, of course, I'm doing this with a view to finally making use of one of my collection of three Nano3 boards, the first of which didn't get extracted from the anti-static bag it had been delivered in some 18 or months ago, until just a few months back to try it out with the "Blink" test program... er, sketch?
I've only made contributions where I've believed they might help, either in regard of more general problems that apply to all designs of GPSDO or where they might just prompt a fresh look at the problem. I know just how easy it is to become blind sided to a problem that ultimately in hindsight proves to be blindingly obvious now! ::)
I'm currently trying to build myself an RFS from an Efratom LPRO-101 rubidium frequency standard which means mounting it in an enclosure where I can stabilise the base plate temperature and compensate for the effects of changes in atmospheric pressure.
It turns out that it's not only ambient temperature variations you have to account for with a RFS but barometric variations as well and whilst I had hoped I could keep it simple and use a barometric sensor with analogue output which, with some pre-conditioning, could be applied directly to the freq tuning input terminal, it turns out that the most cost effective way is to use a cheap digital sensor and, you've guessed it, a nano3, so it looks like I'll be diving much deeper into programming the nano3 rather sooner than I thought.
If my nano3 based environmentally compensated RFS project succeeds, the next obvious project is going to be this Lars gpsdo one (leaving me just one spare nano3 to find a use for). Ultimately, if I'm going to discipline my RFS to a GPS based frequency standard, the Lars design is the most cost effective way to smooth out the minute to minute and hour to hour phase variations by averaging days' worth of timing data with a Kalman filtering algorithm to compensate for the ageing driven frequency drift of the RFS. It might be some time before I'm ready to make any experience based contributions to this topic though.
John (formally JBG)
-
Update on item #561: root cause of OCXO temperature jumps
Contrary to what I first believed the root cause for the OCXO temperature jumps was, it is not caused by the USB power connections (+5, GND or shield), but the data lines (D- and D+). I figured this out by using a break-out board contraption after I isolated the +5V line earlier.
If either one or both of the data lines are connected, both temperature measurements in the Lars report jump by about 0.5 degrees up when connected and down when not.
I can't explain that yet, can anybody? :-//
-
Dbldutch
Johnny B Good & all
Very interesting to watch/read both of you at work. You're doing a great job. Thanks a lot for this.
-
Update on item #561: root cause of OCXO temperature jumps
Contrary to what I first believed the root cause for the OCXO temperature jumps was, it is not caused by the USB power connections (+5, GND or shield), but the data lines (D- and D+). I figured this out by using a break-out board contraption after I isolated the +5V line earlier.
If either one or both of the data lines are connected, both temperature measurements in the Lars report jump by about 0.5 degrees up when connected and down when not.
I can't explain that yet, can anybody? :-//
Where's that Arduino, in the box with the rest of the GPSDO? Maybe it just consumes more power with USB connected. Maybe connecting the USB lines has an influence on the voltage reference for the ADC. Can you provide an external reference?
-
I took the time today to make two of the modifications imo suggested:
1. 78xx are the poorest performers in terms of TC and noise, it could be the fluctuations come from there (I would replace the 7808 with something better)
2. pot trimmer - I would avoid it, large TC of resistance and of wiper contact
3. resistors around the EFC input - should be low TC ones
4. LM35 - with longer wires put a "68-82ohm ser 10u MLCC" between its output and gnd (close to its pins).
Instead of using the 78L08 as the basis for the 4V OCXO reference voltage divider, I'm now using an LM4040 4.096V shunt. (fed through a 3K9 resistor from the 8V to get a 1mA current)
The result is so remarkable it is beyond belief! Gone are the oscillations and the instability. If your OCXO does not have a reference voltage out, make sure you use a real reference. I'll show some results later.
I also did 4, but there is little change however. I think I'm going to be using a filter in software later on. I don't think the current variations are going to help if I invoke the temperature compensation.
I'll do 2 and 3 if/when I go to a pcb layout. Right now I'm still playing and experimenting. Yesterday I got my CTI OC5SC25 OCXO, still fitted on the original pcb that was cut from the original. After de-soldering, a quick test showed it to be working, so I'll have another one that I can play with.
More later
Thank you very much for your insights imo! :clap:
PS: it turned out that I was using a different setting for my measurement. The result with the reference is not that spectacular, but definitely a significant improvement.
Hi Guys, one of you have the datasheet of the CTI OC5SC25 ..or thee connections... it seems hard to find.
Thanks,
Tony
-
@thinkfat:
All three of my GPSDO's (all electronics including the Arduino Nano) are inside an aluminum enclosure. The Oscilloquartz GPSDO enclosure is inside a plastic enclosure, and that is where the Raspberry Pi and the temperature sensor and fan is also.
However, I see this effect on all three of my GPSDO's.
I currently do not believe that the regulated 8V power applied to the Arduino plays a role, and neither do I believe that the onboard 5V regulator is the culprit. However the USB to serial FT232RL chip provides the 3V3 supply and that may cause the issue.
I do not know enough about the Arduino architecture, but I also suspect the Arduino internal reference used for the ADC's. Unfortunately I do not know from what voltage it is internally driven from.
It would take some serious surgery to change to an external reference and calibrate everything so I'm holding off on that idea, however good it is.
This must be an issue related to the Arduino Nano, and not related to Lars' hardware.
As a minimum, we now know the cause of the effect on the temperature, and what causes the jumps on the DAC.
-
After I put my Oscilloquartz based GPSDO inside a plastic container, and regulated the inside temperature with a fan, I am very happy with the results.
In the picture you can see the Trimble and Bliley based GPSDO's in their aluminum enclosures. The same enclosure for the Oscilloquartz is inside the plastic container.
There is a 30mm 5V fan high in the back of the plastic enclosure, and that is driven by an DS18B20 temperature sensor through a script on the Raspberry Pi, that is also inside the container. The RPi also logs the Lars' report and uses a wireless connection to mail me the results. You can see the 5 holes on the front panel where fresh air is sucked in. The air flow is only over the top of the electronics inside, while the GPSDO has bubble wrap insulation and is located on the bottom. The air flow does not strike the GPSDO.
I'm using a proportional PWM signal to drive the fan, and it keeps the temperature inside the enclosure at 33 degrees and within .2 degrees. The ambient temperature sensor inside the GPSDO enclosure is stable at 52 degrees, and the temperature sensor inside the isolation box around the OCXO is now also stable at 65 degrees, both within half a degree Celsius. I think I have finally isolated the temperature effects on the DAC, although the room temperature changes have been moderate the last few days.
The next step is to add a P(I?)D controller function to control the fan even better with larger swings of the room temperature, and I have ordered two more 30mm fans for the other two enclosures. I have high hopes that if I can control the ambient temperatures inside the GPSDO enclosures better, I can also largely eliminate room temperature effects on the DAC.
-
Bargain of the week. I bought this OCXO on eBay for just £10 from a local test equipment supplier. I don't think they knew what it was, as it was advertised simply as a 10MHz oscillator and has never been used ;D ;D. Sadly they don't have any more ...
[attachimg=1]
Anyway, here is the phase noise specification from the data sheet. Can anyone interpret this for me please? Is it a reasonable performance for a GPSDO?
[attachimg=2]
Mike
-
The last Vectron from ebay was defective.
-
The last Vectron from ebay was defective.
Oh I think I've got a good one. It tunes up to 10MHz at exactly half the reference voltage, and after 12 hours the frequency had moved by 10ppb. The spec is 1ppb/day after 72 hours so we shall see.
Mike
-
The last Vectron from ebay was defective.
Oh I think I've got a good one. It tunes up to 10MHz at exactly half the reference voltage, and after 12 hours the frequency had moved by 10ppb. The spec is 1ppb/day after 72 hours so we shall see.
Mike
Did you heat insulate it?
I have a nice OCXO for you:
https://www.morion-us.com/catalog_pdf/mv336m.pdf (https://www.morion-us.com/catalog_pdf/mv336m.pdf)
;D
-
If anybody sees any decen't new reliable 10 MHz OCXOs for sale inexpensively, not equipment pulls, please post them and what you know about them.
-
I'm currently trying to build myself an RFS from an Efratom LPRO-101 rubidium frequency standard which means mounting it in an enclosure where I can stabilise the base plate temperature and compensate for the effects of changes in atmospheric pressure.
I did that too - also with an LPRO, which I think is one of the best to use for this. It's a cheap way to get something that's getting on for caesium performance without the price. It's particularly easy using fan cooling.
One of the main reasons that I did it in the first place was to make a good reference for GPSDOs, but it was so good that I lost most of my interest in GPSDOs after that.
It turns out that it's not only ambient temperature variations you have to account for with a RFS but barometric variations as well and whilst I had hoped I could keep it simple and use a barometric sensor with analogue output which, with some pre-conditioning, could be applied directly to the freq tuning input terminal, it turns out that the most cost effective way is to use a cheap digital sensor and, you've guessed it, a nano3, so it looks like I'll be diving much deeper into programming the nano3 rather sooner than I thought.
I use an analogue sensor to bias the EFC too, but have been looking to upgrade. I thought that I'd found one in the Infineon KP236, but on testing there are larger steps in the output than I would like. Some old Bosch ones like the SMD288 are promising if a little noisy. I was trying to avoid having to use a digital sensor and microcontroller etc. just for a sensor, but it's looking like that's probably a good way to go. The effect of changes in barometric pressure seemed a bit delayed too, so using a microcontroller here could allow for that.
If my nano3 based environmentally compensated RFS project succeeds, the next obvious project is going to be this Lars gpsdo one (leaving me just one spare nano3 to find a use for). Ultimately, if I'm going to discipline my RFS to a GPS based frequency standard, the Lars design is the most cost effective way to smooth out the minute to minute and hour to hour phase variations by averaging days' worth of timing data with a Kalman filtering algorithm to compensate for the ageing driven frequency drift of the RFS.
I had also originally thought about making a full GPSDO with it, but did not end up doing that. Once you have temperature control, air pressure compensation and long term drift correction, a good LPRO could have a better stability than GPS out to a tau of days, so if short term measurements are relevant there's something very wrong. I think that it would probably take something like a u-blox ZED-F9 series receiver to see what's going on. I think that some folk on the time-nuts list were going down this route.
If you can do continuous measurements (such as with a TDC) what can be useful is adding other references (quartz/Rb/GPS) into the mix. That way, if you do get a frequency jump or any other strange issues, it's easier to see what has happened.
-
Does anyone has tried to discipline a Rubidium Reference like the FE-5680A or FE-5650A?
I've searched but I can't find an easy solution. The DAC is too imprecise to be used as a Mhz10 ... 000 reference. So you have to use the analoge side. And I can't find any information about that. Maybe the Heater itself?
My "good" FE-5680A is more than 10Hz off.
-
Does anyone has tried to discipline a Rubidium Reference like the FE-5680A or FE-5650A?
I've searched but I can't find an easy solution. The DAC is too imprecise to be used as a Mhz10 ... 000 reference. So you have to use the analoge side. And I can't find any information about that. Maybe the Heater itself?
LPRO-101 is an easy target. You can just hook up the DAC to the external C-Field input.
-
Did you heat insulate it?
Not yet, but I will when it's on the PCB. I'm just aging it at the moment ;)
I have a nice OCXO for you:
https://www.morion-us.com/catalog_pdf/mv336m.pdf (https://www.morion-us.com/catalog_pdf/mv336m.pdf)
;D
Well it's better than my Vectron but probably costs 10 times as much :(
-
I'm currently trying to build myself an RFS from an Efratom LPRO-101 rubidium frequency standard which means mounting it in an enclosure where I can stabilise the base plate temperature and compensate for the effects of changes in atmospheric pressure.
I did that too - also with an LPRO, which I think is one of the best to use for this. It's a cheap way to get something that's getting on for caesium performance without the price. It's particularly easy using fan cooling.
One of the main reasons that I did it in the first place was to make a good reference for GPSDOs, but it was so good that I lost most of my interest in GPSDOs after that.
It turns out that it's not only ambient temperature variations you have to account for with a RFS but barometric variations as well and whilst I had hoped I could keep it simple and use a barometric sensor with analogue output which, with some pre-conditioning, could be applied directly to the freq tuning input terminal, it turns out that the most cost effective way is to use a cheap digital sensor and, you've guessed it, a nano3, so it looks like I'll be diving much deeper into programming the nano3 rather sooner than I thought.
I use an analogue sensor to bias the EFC too, but have been looking to upgrade. I thought that I'd found one in the Infineon KP236, but on testing there are larger steps in the output than I would like. Some old Bosch ones like the SMD288 are promising if a little noisy. I was trying to avoid having to use a digital sensor and microcontroller etc. just for a sensor, but it's looking like that's probably a good way to go. The effect of changes in barometric pressure seemed a bit delayed too, so using a microcontroller here could allow for that.
If my nano3 based environmentally compensated RFS project succeeds, the next obvious project is going to be this Lars gpsdo one (leaving me just one spare nano3 to find a use for). Ultimately, if I'm going to discipline my RFS to a GPS based frequency standard, the Lars design is the most cost effective way to smooth out the minute to minute and hour to hour phase variations by averaging days' worth of timing data with a Kalman filtering algorithm to compensate for the ageing driven frequency drift of the RFS.
I had also originally thought about making a full GPSDO with it, but did not end up doing that. Once you have temperature control, air pressure compensation and long term drift correction, a good LPRO could have a better stability than GPS out to a tau of days, so if short term measurements are relevant there's something very wrong. I think that it would probably take something like a u-blox ZED-F9 series receiver to see what's going on. I think that some folk on the time-nuts list were going down this route.
If you can do continuous measurements (such as with a TDC) what can be useful is adding other references (quartz/Rb/GPS) into the mix. That way, if you do get a frequency jump or any other strange issues, it's easier to see what has happened.
The LPRO-101's are getting rather long in the tooth leaving you wondering just how long you've got before you resort to refurbishing the physics package with IPA to clean 20+year's worth of contaminants off the glassware and taking a hairdryer to the lamp in the hope of redistributing the rubidium back to where it belongs. They're a better choice compared to the FE5680As if you need a low phase noise reference you can use to transvert an HF transceiver right up to 24GHz without having to add a clean up XO.
I take your point over the use of a simple fan to control temperature. You've just got to pick a target temperature that's not too high for the sake of the electronics, yet not so low that the heaters in the physics package land up running too close to the limit for comfort at the lowest expected ambient temperature.
I reckon my chosen instrument case might be large enough to avoid the need for ventilation by varying the speed of recirculated airflow targeting the base plate to control heat dissipation into the relatively large surface area of the enclosure's panels. I've always got the option to add ventilation to the case if such a cooling scheme proves inadequate during the final commissioning test stage. It'll be interesting to see what stability improvement I can achieve with thermal regulation alone (first things first, especially the easiest ones to begin with :)).
I've already purchased a BMP280 module from here:- https://www.ebay.co.uk/itm/BMP280-Pressure-Sensor-Module-Arduino-Precision-Atmospheric-BMP180-Replacement/283518687928?hash=item420307dab8:g:3gAAAOSwLdVcpzYQ (https://www.ebay.co.uk/itm/BMP280-Pressure-Sensor-Module-Arduino-Precision-Atmospheric-BMP180-Replacement/283518687928?hash=item420307dab8:g:3gAAAOSwLdVcpzYQ)
along with a couple of 4 channel bi-directional logic level converters to interface it to my Nano3 so I can experiment with the BMP280 libraries and create a suitable pressure and temperature sensor module to replace whatever thermistor based fan controller I cobble together for my initial thermal regulation experiments.
Off the top of my head, I don't think you can sample barometric pressure readings much faster than ten times a second with the BMP280 anyway which is at least an order of magnitude quicker than I'd need even if I use an oversampling technique to filter out any sampling error noise for a once per minute update to the output signal driving the EFC input of the RFS. Even this rate is probably way faster than would actually be called for.
Changes of barometric pressure even in the case of rapidly approaching storms here in the UK seem unlikely to exceed a 10 hPa per hour. Checking out my inexpensive I.T. Works weather station's pressure trend histogram just now shows that between 4 and 8 hours ago, there had been a 'sudden jump' (basically a 1 hPa per hour rise) of 4 hPa up to the current reading of 1010 hPa. Actually, the histogram just updated to show that same jump as now spanning an 8 hour period! At those rates of change, the Nano3 won't be working hard so much as hardly working at all ::).
That remark about your LPRO being so good that you lost interest in GPSDOs made me smile. :) I fully appreciate where you're coming from. However, if you want to check and redo the calibration from time to time, you'll need to keep hold of at least one GPSDO even if its short term phase stability leaves something to be desired compared to a RFS.
I checked out the price of a ZED-F9 based plug 'n' play module - too bloody expensive for my taste :o. I'll make do with a humble single frequency timing module for my current gpsdo experiments for the time being. As for the idea of acquiring a TDC (I had to google that acronym - I'd seen it used before but couldn't recall exactly what it had referred to ::) ), I'll manage a bit longer without (just like I managed without a RFS until I just had to take a closer look at how my GPSDOs were responding to the effects of ionospheric disturbance to the ToF of the satellite signals :) ). And, to think this all started out as a means of accessing a high accuracy frequency reference to calibrate a TCXO (followed by an OCXO) upgrade of the crappy 50MHz XO smd IC in a cheap FeelTech FY6600 AWG function generator. :palm:
John (JBG)
-
The LPRO-101's are getting rather long in the tooth leaving you wondering just how long you've got before you resort to refurbishing the physics package with IPA to clean 20+year's worth of contaminants off the glassware and taking a hairdryer to the lamp in the hope of redistributing the rubidium back to where it belongs. They're a better choice compared to the FE5680As if you need a low phase noise reference you can use to transvert an HF transceiver right up to 24GHz without having to add a clean up XO.
I wouldn't worry so much about the physics package in the LPRO. I'm now into repairing/restoring the third RFS of that breed (two LPRO, one SLCR) and the physics package itself was never the problem. It was always something else, mostly aging of components due to heat. Should you really need to "rejuvenate" the Rb lamp itself, it's a quick and easy procedure. Besides, that failure mode is not typical to the LPRO.
The best thing about the LPRO is that it is a fairly contemporary design, with only two components (three, if you count the physics package) being unobtainable but possibly salvageable: The SRD in the cavity and the FPGA. Everything else is standard stuff you can buy from DigiMouser. The most expensive component is likely the RF MOSFET that drives the lamp exciter, at roughly $30 in single quantities. The transistors in the synthesizer are probably hard to come by but there are suitable replacements.
Anyway, there are still so many around that repair is not economically viable today.
-
Hi everyone!
I've been wanting to get a GPSDO for my lab for a while now. Thumbed through Lars's PDFs and realized this was a surprisingly trivial circuit to set up.
I spent a day in Kicad working on my own version, with the hopes to have a compact GPSDO with 4 buffered 10MHz outputs and a USB serial port for outputting NMEA.
Here's the result:
(https://raw.githubusercontent.com/W3AXL/Simple-GPSDO/master/kicad/sch/revA/sch-small.png) (https://raw.githubusercontent.com/W3AXL/Simple-GPSDO/master/kicad/sch/revA/simple-gpsdo.png)
And the PCB:
(https://raw.githubusercontent.com/W3AXL/Simple-GPSDO/master/kicad/board-model/board-small.png) (https://raw.githubusercontent.com/W3AXL/Simple-GPSDO/master/kicad/board-model/simple-gpsdo.png)
With the hopes that the final assembly will look something like this:
(https://raw.githubusercontent.com/W3AXL/Simple-GPSDO/master/cad/render-front.PNG)
I'd love to hear thoughts, and if I've made in major mistakes in the schematic that I should fix before I commit to buy the boards.
Made a github repo for the project as well, if anyone cares to check that out (https://github.com/W3AXL/Simple-GPSDO)
Can't wait to join the ranks of people keeping Lars's legacy alive!
-
For a bit of additional flexibility regarding the OCXO EFC, you might want to use something like the attached circuit as a buffer/amplifier. Nevermind the DAC, just have a look at U6A and U6B.
(https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/?action=dlattach;attach=1070018)
PS: attaching inlined images is forever broken it seems. It used to work. Not any longer :-(
-
The LPRO-101's are getting rather long in the tooth leaving you wondering just how long you've got before you resort to refurbishing the physics package with IPA to clean 20+year's worth of contaminants off the glassware and taking a hairdryer to the lamp in the hope of redistributing the rubidium back to where it belongs. They're a better choice compared to the FE5680As if you need a low phase noise reference you can use to transvert an HF transceiver right up to 24GHz without having to add a clean up XO.
Most of the problems that I've seen mentioned with LPROs are electronic, not lamp. Although the lamp has a more defined ageing characteristic than most other components, it is otherwise just one reliable component out of very many others, so tends not to be the cause of too many problems. Lamps have been gradually refined over the decades, and by the late 90's it appears to have become much less of an issue.
It's not just noise that causes problems with other types. The SRS PRS12 is excellent, but it uses a DAC for all it's adjustments. This limits the resolution to between 1E-12 and 2E-12, and there is the DAC non-linearity on top of that.
The FE-5680A type ones come in many different variants, and usually have a coarse temperature compensation that causes frequency jumps.
I once checked with Temex about their FRS series and was told that the analogue C-field adjustment was truly analogue and step-less, but neither of the two old Temex ones that I tried worked brilliantly.
Most rubidiums are so noisy that for RF applications you're often going to need to add an OCXO and lock that to the rubidium anyway.
I take your point over the use of a simple fan to control temperature. You've just got to pick a target temperature that's not too high for the sake of the electronics, yet not so low that the heaters in the physics package land up running too close to the limit for comfort at the lowest expected ambient temperature.
There's a table in the manual for it that shows the MTBF falling from 381,000 hours at 20°C to 134,000 hours at 60°C. There's really way too much concern out there about operating them at lower baseplate temperatures. The LPRO has a minimum operating temperature of -30°C, and often will be operating in equipment which has fans blowing air over them keeping the whole case at ambient (probably not at -30°C...). Keeping the baseplate temperature down towards room temperature - although not necessary - is not a crazy low target, but will increase the power consumption a bit and probably won't be practical with fan cooling unless you live in a far north cave. If the temperature is set too low it will just take a sunny day or a heater left on for longer than expected for it to get too hot and potentially mess up a long test run.
I reckon my chosen instrument case might be large enough to avoid the need for ventilation by varying the speed of recirculated airflow targeting the base plate to control heat dissipation into the relatively large surface area of the enclosure's panels. I've always got the option to add ventilation to the case if such a cooling scheme proves inadequate during the final commissioning test stage. It'll be interesting to see what stability improvement I can achieve with thermal regulation alone (first things first, especially the easiest ones to begin with :)).
I think that it might be a challenge to keep the temperature down with a closed case. I tried that with a power supply and there was still a lot of heat build up.
One issue with having the fan in more or less open air is that if the air temperature changes fast (such as opening a door) it tends to cause a temperature spike - adding an extra sensor measuring the temperature of the cooling air should help. Something this size does not have a single temperature anyway, but it may be as well just compensating for any remaining temperature fluctuations rather than trying too hard to remove them.
I was experimenting with a PWM fan that stopped rather than just going slow at minimum, and combining that with feedback should give good control.
I've already purchased a BMP280 module from here:- https://www.ebay.co.uk/itm/BMP280-Pressure-Sensor-Module-Arduino-Precision-Atmospheric-BMP180-Replacement/283518687928?hash=item420307dab8:g:3gAAAOSwLdVcpzYQ (https://www.ebay.co.uk/itm/BMP280-Pressure-Sensor-Module-Arduino-Precision-Atmospheric-BMP180-Replacement/283518687928?hash=item420307dab8:g:3gAAAOSwLdVcpzYQ)
along with a couple of 4 channel bi-directional logic level converters to interface it to my Nano3 so I can experiment with the BMP280 libraries and create a suitable pressure and temperature sensor module to replace whatever thermistor based fan controller I cobble together for my initial thermal regulation experiments.
Off the top of my head, I don't think you can sample barometric pressure readings much faster than ten times a second with the BMP280 anyway which is at least an order of magnitude quicker than I'd need even if I use an oversampling technique to filter out any sampling error noise for a once per minute update to the output signal driving the EFC input of the RFS. Even this rate is probably way faster than would actually be called for.
Changes of barometric pressure even in the case of rapidly approaching storms here in the UK seem unlikely to exceed a 10 hPa per hour. Checking out my inexpensive I.T. Works weather station's pressure trend histogram just now shows that between 4 and 8 hours ago, there had been a 'sudden jump' (basically a 1 hPa per hour rise) of 4 hPa up to the current reading of 1010 hPa. Actually, the histogram just updated to show that same jump as now spanning an 8 hour period! At those rates of change, the Nano3 won't be working hard so much as hardly working at all ::).
Since the sensitivity of an LPRO to pressure is <1E-13/mbar, but its nominal 1s stability is very much greater at 3E-11, there's not usually much need to worry about noise or sampling rate for pressure.
That remark about your LPRO being so good that you lost interest in GPSDOs made me smile. :) I fully appreciate where you're coming from. However, if you want to check and redo the calibration from time to time, you'll need to keep hold of at least one GPSDO even if its short term phase stability leaves something to be desired compared to a RFS.
The timescales involved are long enough that a GPS will usually be as good or better than a GPSDO anyway, as long as there are no major sawtooth issues. For calibration, I usually just log 1000 second averages of the 1PPS derived from the LPRO against the 1PPS from GPS. That makes it very easy to check the drift over hours or days.
I checked out the price of a ZED-F9 based plug 'n' play module - too bloody expensive for my taste :o. I'll make do with a humble single frequency timing module for my current gpsdo experiments for the time being. As for the idea of acquiring a TDC (I had to google that acronym - I'd seen it used before but couldn't recall exactly what it had referred to ::) ), I'll manage a bit longer without (just like I managed without a RFS until I just had to take a closer look at how my GPSDOs were responding to the effects of ionospheric disturbance to the ToF of the satellite signals :) ). And, to think this all started out as a means of accessing a high accuracy frequency reference to calibrate a TCXO (followed by an OCXO) upgrade of the crappy 50MHz XO smd IC in a cheap FeelTech FY6600 AWG function generator. :palm:
With me it was to calibrate an oscillator for a clock...
There are lots of cheap boards with TDC-GP21 or GP22s in them, and there are arduino libraries for them. Just add an arduino and a few other components and for very little you can measure short time differences of up to 100us quite well. Much cheaper to buy and run than frequency counter.
The TI TDC7200 is probably easier to use, but I've not seen any cheap boards for them.
This may be getting a little OT for this thread, but it is one of the few ways of actually testing a GPSDO. The self referencing measurements can only go so far.
-
Hi everyone!
I've been wanting to get a GPSDO for my lab for a while now. Thumbed through Lars's PDFs and realized this was a surprisingly trivial circuit to set up.
I spent a day in Kicad working on my own version, with the hopes to have a compact GPSDO with 4 buffered 10MHz outputs and a USB serial port for outputting NMEA.
Here's the result:
(https://raw.githubusercontent.com/W3AXL/Simple-GPSDO/master/kicad/sch/revA/sch-small.png) (https://raw.githubusercontent.com/W3AXL/Simple-GPSDO/master/kicad/sch/revA/simple-gpsdo.png)
And the PCB:
(https://raw.githubusercontent.com/W3AXL/Simple-GPSDO/master/kicad/board-model/board-small.png) (https://raw.githubusercontent.com/W3AXL/Simple-GPSDO/master/kicad/board-model/simple-gpsdo.png)
With the hopes that the final assembly will look something like this:
(https://raw.githubusercontent.com/W3AXL/Simple-GPSDO/master/cad/render-front.PNG)
I'd love to hear thoughts, and if I've made in major mistakes in the schematic that I should fix before I commit to buy the boards.
Made a github repo for the project as well, if anyone cares to check that out (https://github.com/W3AXL/Simple-GPSDO)
Can't wait to join the ranks of people keeping Lars's legacy alive!
Just one observation. I do think, imo, you have one too may switches on that front panel. :) To my mind, that just seems a little redundant when you can simply shut it off by literally pulling a DC jack plug out the back on those, hopefully, rather rare occasions when you might need to shut it down for repair/troubleshooting or upgrade work.
John
-
@Axel,
Although in principle, the schematic is very simple indeed, however, the devil is lurking in the details.
I suggest you give every functional block their own voltage regulator. Especially the NEO and the Arduino. Use some fer-rites to block the 10HMz coming from the OCXO back into the DAC circuit. The 1PPS signal introduces a lot of supply and ground bounce, be aware. To slow down some edges, use small resistors in series with the 1PPS, 10MHz and 5Mhz signals.
I also suggest you look at many posts up where a method was discussed to isolate the noisy Arduino PWM output for the DAC by adding some gates with their own seperate reference supply.
You don't mention the OCXO you're going to use (I can guess from the layout), but many of them are very sensitive to the ambient temperature. I suggest to add some hardware to be able to drive a small fan to keep the temperature inside the enclosure as stable as possible. For that you need temperature sensors for the OCXO and the ambient inside the enclosure. You'll need the OCXO temp sensor to use the compensation in the Lars program anyway. I am currently experimenting with a fan and I see great results in making the DAC output less sensitive to temperatures, which will help to truly analyze the GPSDO with TimeLab plots.
Succes!
-
Having lots of voltage regulators is a good solution to preventing noise. Long lines between voltage regulator and consumer cause voltage fluctuations due to the relatively high PCB line resistance. Every 100uV counts.
Is temperature compensation really crucial? We are talking about a GPSDO and not a free-running OCXO. Changes in temperature should be regulated away by the PLL. In my opinion, you just have to make sure that the OCXO is protected from temporary temperature changes, e.g. an open door. A good case is enough. Long-term changes are also eliminated by the PLL.
-
A DAC that is influenced by temperature changes falsifies the GPSDO analysis in TimeLab.
If you look back into several of my earlier posts, you can clearly see the effects room temperature changes have on the OCXO.
-
Having lots of voltage regulators is a good solution to preventing noise. Long lines between voltage regulator and consumer cause voltage fluctuations due to the relatively high PCB line resistance. Every 100uV counts.
Is temperature compensation really crucial? We are talking about a GPSDO and not a free-running OCXO. Changes in temperature should be regulated away by the PLL. In my opinion, you just have to make sure that the OCXO is protected from temporary temperature changes, e.g. an open door. A good case is enough. Long-term changes are also eliminated by the PLL.
I agree with that in general. Putting a lot of thermal "impedance" between the OCXO and the environment is better than trying to compensate temperature change in software. However, what you try to achieve is keeping the GPS influence on the OCXO minimal. That demands long filters and long time constants. The PLL will eventually not be able to compensate environmental effects any more, unless you help the regulation with additional information. With very long time constants you might get the PLL to unlock even due to small temperature effects.
In any case, requirements drive the design. What do you want to do with the GPSDO? What stability do you require over which observation time? A very long time constant might not be what you want, it tends to degrade stability over large observation intervals, with no obvious gain for short tau because of the inherent phase noise of the LO.
-
A DAC that is influenced by temperature changes falsifies the GPSDO analysis in TimeLab.
If you look back into several of my earlier posts, you can clearly see the effects room temperature changes have on the OCXO.
The changing DAC value ruins your measurement in Timelab, but not the accuracy of the 10MHz-OCXO.
-
Having lots of voltage regulators is a good solution to preventing noise. Long lines between voltage regulator and consumer cause voltage fluctuations due to the relatively high PCB line resistance. Every 100uV counts.
Is temperature compensation really crucial? We are talking about a GPSDO and not a free-running OCXO. Changes in temperature should be regulated away by the PLL. In my opinion, you just have to make sure that the OCXO is protected from temporary temperature changes, e.g. an open door. A good case is enough. Long-term changes are also eliminated by the PLL.
I agree with that in general. Putting a lot of thermal "impedance" between the OCXO and the environment is better than trying to compensate temperature change in software. However, what you try to achieve is keeping the GPS influence on the OCXO minimal. That demands long filters and long time constants. The PLL will eventually not be able to compensate environmental effects any more, unless you help the regulation with additional information. With very long time constants you might get the PLL to unlock even due to small temperature effects.
In any case, requirements drive the design. What do you want to do with the GPSDO? What stability do you require over which observation time? A very long time constant might not be what you want, it tends to degrade stability over large observation intervals, with no obvious gain for short tau because of the inherent phase noise of the LO.
Calculating the PI filter is a science.
-
The FE-5680A type ones come in many different variants, and usually have a coarse temperature compensation that causes frequency jumps.
I once checked with Temex about their FRS series and was told that the analogue C-field adjustment was truly analogue and step-less, but neither of the two old Temex ones that I tried worked brilliantly.
Most rubidiums are so noisy that for RF applications you're often going to need to add an OCXO and lock that to the rubidium anyway.
The FE-5680 breed of Rb standards is a very different design to the LPRO. They opted for an LO frequency of an even multiple of the Rb hyperfine resonance. That simplifies the design as you don't need a complex synthesizer to generate the 6.8GHz interrogation signal. Of course they then need a DDS to generate 10MHz from the LO output and that comes at a cost, too: the 10MHz output is not very "pure". But all in all, if requirements are met, this design is cheaper to make. Some FE5680 don't even have a 10MHz output, probably for a good reason.
The TI TDC7200 is probably easier to use, but I've not seen any cheap boards for them.
It would be simple enough to make a breakout board for the TDC7200. It is not a very complex device to operate. It's just cumbersome to solder, being TSSOP package and all...
-
@0xFF0
The changing DAC value ruins your measurement in Timelab, but not the accuracy of the 10MHz-OCXO.
Very true, but if you don't have a Rubidium or other standard to compare with, nor a counter that can measure down to 10^-12, TimeLab is your only friend that can help you to qualify your DIY GPSDO, right?
-
@0xFF0
The changing DAC value ruins your measurement in Timelab, but not the accuracy of the 10MHz-OCXO.
Very true, but if you don't have a Rubidium or other standard to compare with, nor a counter that can measure down to 10^-12, TimeLab is your only friend that can help you to qualify your DIY GPSDO, right?
yep!
-
@0xFF0
The changing DAC value ruins your measurement in Timelab, but not the accuracy of the 10MHz-OCXO.
Very true, but if you don't have a Rubidium or other standard to compare with, nor a counter that can measure down to 10^-12, TimeLab is your only friend that can help you to qualify your DIY GPSDO, right?
Well, but if you don't have any instruments that can appreciate such precision... What for? If you cannot 'see' your GPSDO, it is by definition good enough.
-
Hi,
Long time reader of eevblog, first post :)
I have build in the past this GPS DO https://www.instructables.com/id/GPSDO-YT-10-Mhz-Lcd-2x16-With-LED (https://www.instructables.com/id/GPSDO-YT-10-Mhz-Lcd-2x16-With-LED) and yesterday i have finished also the LARS version on a breadboard, tried the both on a 53131A (using them as external reference and measuring the other) and both are at 10.000.000 +-001-2mHZ when locked. ISOTEMP on the first, an old CORNING on the LARS GPSDO
I had the issues with the missing PPS and had to use a small coaxial cable to connect the C1 to ADC0 now it looks solid.
Any ideas why it is so sensitive ? I am using an Arduino Pro Mini (not Nano)
Since i am not an expert... i used the timelab on lars version for 3 hours and tried to interpretat the results.
Looks good i think (although there is an LM317 boiling hot because no 7805 on stock during the weekend...)
Comments are more than welcome !!! Feedback needed :)
-
Thanks for the advice and suggestions everyone, especially Dbldutch who I know has been doing amazing things with this design. Thankfully most of your suggestions are easy to implement with almost no increase to BOM cost. That's been the biggest driver here: right now my total BOM cost all-in is right at 100USD and I'd love to keep it right around there if possible.
I'll certainly look into adding individual regulators for every IC. I think I'll adjust the main reg to be a 12V-5V buck and have individual 3.3V linears powering everything directly. That way I don't have to worry too much about power dissipation with a 12V->3.3V linear conversion but I can still get relatively low-ripple 3.3V.
Filtering for the 1PPS, 5MHz, and 10MHz lines is easy. I'll also probably do a new revision of the board with the traces a lot further separated, and add some inline resistors and maybe even LPFs to the 5 and 10 meg lines. I'll definitely look into the PWM cleanup as well; I didn't thumb through all 25 pages before getting to work so there's definitely some useful tidbits here and there that I missed.
Likewise, temperature probes for the case and oven temps are also fairly easy to add in. A good idea for sure, I didn't even realize the code had provisions for temperature monitoring.
As some of you probably guessed, the OCXO I was going with originally was the McCoy OSC92-100B (also known as the Isotemp 134-12), but it seems as if this is less common on eBay than I thought (I bought the last one). I had originally intended to distribute out boards to some friends for them to build their own, but that requires them to be able to get ahold of oscillators for cheap. I'm now looking at the RALTRON OX4114A-D3-1-10.000-3.3 (http://www.raltron.com/wp-content/uploads/2017/04/OCXO-SERIEs-1000.pdf). It seems to have similar specs to the OSC92, is much smaller, and is available from Digikey for cheaper than I got the McCoy on eBay. whoops, that one has no electronic frequency adjustment. Also linked the wrong datasheet. Looks like the hunt continues!
At the end of the day, my goals for this project are two-fold: 1) a fun DIY project that will result in a useful piece of lab gear when everything's done, and 2) something to help my various used bits of test gear stay relatively in-spec. I'm definitely no "time nut" but I do a lot of RF projects and knowing I'm close enough to an accurate frequency is all I really need. My service monitor was last cal'd in 2002 so I'd imagine a good external reference will help things out.
Oh, and by popular demand the extraneous power switch has been removed in revision B:
(https://i.imgur.com/82DjOF6.png)
-
Just wanted to show the first results of my attempts to regulate the temperature inside the GPSDO enclosure, in an attempt to isolate the OCXO temperatures from the room temperature changes. All this to get a "pure" DAC result, devoid of temperature effects.
The data is taken from my Trimble based GPSDO, where the OCXO itself is insulated from all 6 sides in a 10-15mm thick hard-foam box. Inside the box is one of the LM35 temperature sensors.
I'm using the other LM35 that measures the ambient temperature right on top of D1/R1/C1 inside the enclosure to drive a 30mm 5V DC fan with a PWM signal, coming from a simple PID controller. Both LM35's are now low-pass filtered to get rid of the noise. I've drilled a few holes in the front-panel to let the air in, but tried to keep the air-flow away from the OCXO. The fan with the electronics is located on the back-panel.
I've modified the Lars program to add the required functionality.
UPDATE: I have posted the code on my Github site. https://github.com/paulvee/Lars-GPSDO (https://github.com/paulvee/Lars-GPSDO)
This small and simple addition is very promising I think.
-
I'll certainly look into adding individual regulators for every IC. I think I'll adjust the main reg to be a 12V-5V buck and have individual 3.3V linears powering everything directly. That way I don't have to worry too much about power dissipation with a 12V->3.3V linear conversion but I can still get relatively low-ripple 3.3V.
Unfortunately, LDOs are not very good at removing input supply ripple. You might want to look into adding a "capacitance multiplier" after the buck regulator to have a clean input to the LDOs:
https://www.youtube.com/watch?v=wopmEyZKnYo (https://www.youtube.com/watch?v=wopmEyZKnYo)
-
Curse this addiction >:D >:D
A few months ago I'd never heard of a GPSDO and now I have built two of them ...
[attachimg=2]
The first is to Lars' original design using breadboard construction with an NDK OCXO.
The second is Dbldutch's modified design on a PCB with a Vectron OCXO.
Both use a Neo-7 GPS and I have an active puck antenna on the outside wall of the house.
Time to do a comparison. See you in a few weeks :)
Mike
-
Attempting to compile v 3.51 on the Arduino and receiving a compilation error. error: 'loop_delay' was not declared in this scope
float derivative = (temp_error - prev_error)/ loop_delay;
Is there a missing library or is it just a missing forward slash and loop_delay is supposed to be a comment??
// *** paulv The fan controller
void control_fan() {
// Use the low-pass filtered ambient temperature sensor value.
// Do not mess with the original code so convert the value to Celsius here again.
ambient_t = temperature_to_C(tempADC1_IIR,temperature_Sensor_Type/10);
// PID calculation
float temp_error = ambient_t - cool_baseline;
integral = integral + temp_error;
float derivative = (temp_error - prev_error) / loop_delay;
duty_cycle = pwm_baseline + (Kp * temp_error) + (Ki * integral) + (Kd * derivative);
prev_error = temp_error;
if (duty_cycle > max_pwm) { duty_cycle = max_pwm; } // max = 100% = 255
if (duty_cycle < pwm_baseline) { duty_cycle = pwm_baseline;} // set minimum
/* for debugging:
Serial.print("Kp = ");
Serial.print(Kp * temp_error);
Serial.print("\tKi = ");
Serial.print(Ki * integral);
Serial.print("\tKd = ");
Serial.print(Kd * derivative);
Serial.print("\tambient temp = ");
Serial.print(ambient_t);
Serial.print("\tduty cycle = ");
Serial.println(duty_cycle);
*/
analogWrite(fan_pin, duty_cycle);
}
-
Attempting to compile v 3.51 on the Arduino and receiving a compilation error. error: 'loop_delay' was not declared in this scope
float derivative = (temp_error - prev_error)/ loop_delay;
Is there a missing library or is it just a missing forward slash and loop_delay is supposed to be a comment??
float derivative = (temp_error - prev_error) / loop_delay;
Looking at the code, and the position of the semicolon, I'm pretty sure you are missing a declaration for loop_delay. It's probably a variable (based on the lack of capitalization), but could possibly be a constant or a #declare. "loop_delay" might be in a header file. If you search through the code, do you see any other references to it?
-
There is no other reference to loop_delay in the sketch so has me scratching my head a bit. Unless it's in a missing header somewhere.
https://github.com/paulvee/Lars-GPSDO
-
loop_delay is the time constant for the "I" part of the PID. It must be defined somewhere. Maybe on the compiler commandline (like, adding a "-Dloop_delay=10" for a 10 second time constant) if it's not in the code.
-
Hi guys,
Very sorry for the introduction of the error in the source code. |O
I had initially defined loop_delay but that was taken out, unfortunately not completely.
This constant
int loop_delay = 1; // 1 second loop timewas initially used to indicate the loop time for the PID controller, but since it is always 1 second, I took it out of the definitions, but not from the PID function.
You can remove the loop_delay division from the PID controller.
-
Thanks for clarifying, appreciated. I was able to compile it after removing the division, as a matter of fact it compiled using the NANO as the board.
-
Alright, did some major rework to the schematic and board this week.
I think I'm going for something in between Lars's "minimum viable" design and dbldutch's "pursuit of perfection" design. Like I said before, I'll be more than satisfied with a GPSDO that gets me reasonable performance, especially for the price. Current BOM cost all-in is around $85.
New schematic:
(https://raw.githubusercontent.com/W3AXL/Simple-GPSDO/master/kicad/sch/revC/simple-gpsdo.png)
New board:
(https://raw.githubusercontent.com/W3AXL/Simple-GPSDO/master/kicad/board-model/board-revC.png)
Changes made:
- Now using Bliley NV47xx oscillator package since it's cheap and easy to get online
- Added LM35 temperature sensor next to oven package for some half-assed temperature compensation
- Buck regulator for 12V -> 6V and separate 5V LDOs for "digital" and "analog" power
- Switched to a vertical USB-C connection (because it's the only connector I could find with a vertical right-angle orientation)
- Added a ton of vias all over the analog signals to make sure I can minimize crosstalk and interference as much as possible
- Using double-stack BNC jacks for 10MHz output
- Much smaller board size due to smaller oscillator. Designed to fit in a Hammond 1455K1201
Things I'm still considering:
- Resistor dividers on EFC line to oscillator, for more precise voltage control
- Moving the logic gates a bit further from the oven (probably not super necessary)
- Standoffs for the GPS module so it's not just hanging on by the headers
Opinions, comments, and anything else are always appreciated! This has been one of the most in-depth designs I've done in a while so I'm really enjoying the process.
-
Looks nice :-+
But once you get into time nuttery, you would want a buffered 1PPS output too.
How about reverse polarity protection ?
I killed a FEI 5080A Rubidium , by being lazy and not testing that some IDI.. PSU designer made the "screen +" and the "inner core -"
/Bingo
-
Are those R17-R20 10k resistors "placeholders" or do you want really go with 10k? That is too much for that kind of circuit, isn't it? I would expect a few hundreds of ohms there..
Also I would add a 3.3uH-10uH choke followed by 1u||10n to ground as a filter after the switcher.
PS: the L1=33u seems to me too large too, it will just pickup a noise, moreover it could create an instability of the loop.
Mind the USB is a great source of noise coming from your PC..
-
RE: Reverse Polarity Protection, that's a great point. I'll stuff a small diode/fet combo somewhere to take care of that.
RE: 1PPS, I'd love to, and a friend who's interesting in buying one of these from me asked about it as well. I've got an internal PPS test point but I don't really have any room left in the case for PPS, unless I added another BNC above the GPS/power connectors.
RE: OpAmp Gain Resistors, thanks for bringing that up. I ripped that buffer circuit straight from Brian Dorey's 10MHz project. (https://github.com/briandorey/10Mhz-Frequency-Standard-Distribution-Project/blob/master/Schematic%20and%20PCB/10Mhz%20Frequency%20Standard%20-%20Distribution%20Board.pdf) The Bliley OCXO I'm going with is a square wave output, and as far as I can tell it's not expecting a low impedance of any kind on its output. Are you concerned about loading of the OCXO?
-
RE: 1PPS, I'd love to, and a friend who's interesting in buying one of these from me asked about it as well. I've got an internal PPS test point but I don't really have any room left in the case for PPS, unless I added another BNC above the GPS/power connectors.
Use sma .... sma->BNC adapters are cheap
/Bingo
-
@ Axel
Good job with the circuit.
Be aware that the Bliley has sine-wave out and square-wave out versions. You could add the "miti" squarer parts as placeholders.
Two small and easy things that will help to reduce side-effects. Use high-efficiency LED's, as a minimum for the Lock signal, so you can increase the resistor size and reduce current. I've shown the effects on the loop in one of my earlier posts.
If you don't want to give the NEO it's own regulator, add a small value series resistor and a larger reservoir cap in the supply line to the NEO. It has it's own 3V3 voltage regulator, so a bit less than 5V in is no problem. As an alternative, you could also feed it with your 6V supply. This will help to reduce the 1PPS bounce effects.
As an option, put a 68 Ohm resistor in series with the LM35 dataline and use a 10uF T cap from the data to GND. Alternatively, you could also add my low-pass filter in the firmware.
Add placeholders for the parts that can drive a fan, you'll be happy you did afterwards.
Good luck!
-
I've just run my new GPSDO with the Vectron OCXO for a couple of days and would appreciate the experts' opinion on the results.
I have a gain of 590, TC of 200s and TempCoeff of 0. The OCXO temperature varied by less than two degrees.
I'm curious about the slope on the DAC value.
Thanks,
Mike
-
vref use on GPSDO?
I have an OCXO that has both the EFC and a vref connection. Its my understanding that this is the point that represents the highest tip of the control voltage range. Is it used?
-
The OCXO either loses heat or it heats up more and more. In any case, the temperature control does not seem to be working.
-
Curse this addiction >:D >:D
A few months ago I'd never heard of a GPSDO and now I have built two of them ...
(Attachment Link)
The first is to Lars' original design using breadboard construction with an NDK OCXO.
The second is Dbldutch's modified design on a PCB with a Vectron OCXO.
Both use a Neo-7 GPS and I have an active puck antenna on the outside wall of the house.
Time to do a comparison. See you in a few weeks :)
Mike
Blimey, Mike!
That was bloody fast work! I started working my way from using a NEO-M8N module as a cheap 10MHz/30MHz reference to check the calibration of an HF Transceiver I hadn't re-calibrated in over twenty years for lack of a suitable antenna and propagation conditions to receive the 10MHz WWV broadcast I'd last used, gulp! back in the early nineties!
Happily, the HF rig was still within 0.5Hz at 30MHz (after a half hour warmup). My next calibration exercise on the 50MHz TCXO upgrade oscillator board I'd used to replace the crappy 50ppm smd XO in an FY6600-60M is what started me down the road to DIYing a 'proper GPSDO' a whole 18 months ago now,
It took me 12 months just to complete a MK I version and then another 4 months to respin it into a MK II version which I'd unwittingly morphed into a modern day version of the James Miller design. :) I've got three nano3s waiting to be utilised but DIYing a GPSDO is a lot simpler without such encumbrance.
I'm taking a keen interest here because the only sensible way to go take filtering time constants much beyond 5000 seconds is to use a microcontroller and Kalman filtering to discipline a Rb oscillator from 24 hours or more's worth of GPS timing data. I'm going to start disciplining a much easier beast to tame than an unruly double ovened OCXO when I get round to trying my hand at a microcontroller based GPSDO. :)
However, my first non-trivial use of a nano3 looks like it will be to control the RFS's baseplate temperature and compensate for barometric pressure variations to simplify the disciplining to just compensating the more predictable ageing characteristic of a RFS. I'll save the thankless task of disciplining an OCXO till when I feel more comfortable in using a microcontroller to keep such an unpredictable beast as an OCXO on track.
As you gain more experience and strive for ever better stability out of your GPSDO projects, you'll become a lot more aware of the GPS system's weakness as a frequency and timing reference source soon enough, assuming you're not already well acquainted with its deficiencies to begin with.
My plan to discipline a RFS is just my way to bypass all the hassle of an OCXO based GPSDO and cheat my way towards the goal of a reference operating at the 1.0E-14 limit of the GPS master clock itself. What I'll do after that, Deity only knows - probably dabble in the voltnut domain (either that or just vegetate into a senile old age). :-\
John
-
I'll certainly look into adding individual regulators for every IC. I think I'll adjust the main reg to be a 12V-5V buck and have individual 3.3V linears powering everything directly. That way I don't have to worry too much about power dissipation with a 12V->3.3V linear conversion but I can still get relatively low-ripple 3.3V.
Unfortunately, LDOs are not very good at removing input supply ripple. You might want to look into adding a "capacitance multiplier" after the buck regulator to have a clean input to the LDOs:
https://www.youtube.com/watch?v=wopmEyZKnYo (https://www.youtube.com/watch?v=wopmEyZKnYo)
You're only bloody right about relying on LDOs as a switching hash filter add on to a switching converter since above 100KHz they start looking like high pass filters. The real value of using an LDO, post converter output, is to restore regulation lost the the resistance of an RC LPF placed between the switching converter's output and the input to the LDO.
It's the RC LPF which deals with suppression of switching hash - the LDO is simply there to regulate the voltage unmolested by switching hash and ripple from the converter stage.
The 'capacitor multiplier has its own issues of energy loss and is not really a viable solution in this type of ripple suppression, being aimed at dealing with the more sedate 100 to 120Hz ripple components of a conventional mains voltage psu.
The charm of the humble RC LPF, apart from its compact simplicity, is its almost total lack of self resonance effects into the hundreds of MHz that such switching hash frequencies can extend into. However, that benign filtering characteristic comes with an efficiency cost and a requirement to restore voltage regulation with an LDO so tends to be used to power the more sensitive and less power hungry parts of a system. If you feel the need for such measures, target their use with with care.
John
-
@Mike
I have seen the same DAC slopes for several of my second-hand OCXO's as soon as I powered them up. For some of them, it took several months to stabilize, so I just left them with power on, and kept them well insulated before I started using them in my GPSDO's.
Even after many months of using them in a GPSDO, after a cold start, it takes a few days for some of them to really settle. And I'm witnessing this again even with my temperature controlled enclosures as well, so it's not always temperature related. On top of that, my Bliley still has some strange jumps in the DAC value when it starts from a cold state. After several days it is rock-stable now, but it used to take several weeks before the jumps stopped.
The good news is that eventually, they all stabilize. At least that's what I've seen with the 6 different used OCXO's I have.
It has been reported that the rough handling of the old equipment they were in, the removal from the old PCB's and finally the transport could be the cause. These things apparently can be extremely delicate.
The net-net of all this is that you should wait for the OCXO's to stabilize before setting the temperature correction and also before analyzing your GPSDO with TimeLab, however tempting that may be.
-
The OCXO either loses heat or it heats up more and more. In any case, the temperature control does not seem to be working.
Nah, that's typical for 2nd hand OCXOs that have been off for a while, ripped off of a PCB, bumped around in junk bins, mishandled in shipping, etc. Like Dbldutch said, it's going to take weeks if not months for to stabilize. I have the same behavior right now with a used MV85A that I use in a GPSDO. Short term stability is quite nice, but initially it drifted like crazy. It's been over a month now and it still hasn't completely found its bearing. It's much, much better now, though.
-
Thanks for all your suggestions but I think I've worked out what's causing the DAC slope.
It corresponds to 2mV per day which for my OCXO equates to 0.9ppb (I measured the sensitivity before fitting it to the GPSDO).
The OCXO aging spec is +/- 1ppb per day after 72 hours of operation so this looks like a good fit!
This OCXO was sold as new, so although the date code is 2011 my assumption is that it has never been used until now (the pins had no evidence of being soldered).
What about the other graphs? Will the shape of the MDEV curve change after running for a few weeks?
Mike
-
vref use on GPSDO?
I have an OCXO that has both the EFC and a vref connection. Its my understanding that this is the point that represents the highest tip of the control voltage range. Is it used?
No, I have a separate precision voltage source for Vref.
Mike
-
The OCXO either loses heat or it heats up more and more. In any case, the temperature control does not seem to be working.
I haven't implemented temperature control yet. tempCoeff=0.
Mike
-
That was bloody fast work! I started working my way from using a NEO-M8N module as a cheap 10MHz/30MHz reference to check the calibration of an HF Transceiver I hadn't re-calibrated in over twenty years for lack of a suitable antenna and propagation conditions to receive the 10MHz WWV broadcast I'd last used, gulp! back in the early nineties!
Hi John
That's precisely my reason for building this, as last year I bought a Yaesu FT-840 transceiver and wanted to check its calibration. I have an end fed half wave antenna which allows me to receive WWV after midnight, although it's very weak and probaby not a good calibration source!
Mike
-
Because I don't have a counter with a high enough resolution and precision to measure the GPSDO 10MHz output other than by using the TimeLab "trick", I have been on the look-out for an alternative.
It seems like this "competitor" to the Lars GPSDO has an interesting aside, a counter that has the sought after resolution and precision.
Have a look: https://www.instructables.com/id/GPSDO-YT-Disciplined-Oscillator-10Mhz-Reference-Fr/ (https://www.instructables.com/id/GPSDO-YT-Disciplined-Oscillator-10Mhz-Reference-Fr/)
Any comments?
I have ordered an ATMEGA 328p chip and will try to only use the counter function.
It may work, or it may not...
I'll keep you posted.
-
Because I don't have a counter with a high enough resolution and precision to measure the GPSDO 10MHz output other than by using the TimeLab "trick", I have been on the look-out for an alternative.
It seems like this "competitor" to the Lars GPSDO has an interesting aside, a counter that has the sought after resolution and precision.
Have a look: https://www.instructables.com/id/GPSDO-YT-Disciplined-Oscillator-10Mhz-Reference-Fr/ (https://www.instructables.com/id/GPSDO-YT-Disciplined-Oscillator-10Mhz-Reference-Fr/)
Any comments?
I have ordered an ATMEGA 328p chip and will try to only use the counter function.
It may work, or it may not...
I'll keep you posted.
Use this one (updated version )
https://www.instructables.com/id/GPSDO-YT-10-Mhz-Lcd-2x16-With-LED/ (https://www.instructables.com/id/GPSDO-YT-10-Mhz-Lcd-2x16-With-LED/)
I have build it on a breadboard before trying LARS version, "looks" accurate, meaning i have tried on my counter while using LARS as a reference and then this one both are stay locked at 10MHz (0,001 Hz)
-
Have a look: https://www.instructables.com/id/GPSDO-YT-Disciplined-Oscillator-10Mhz-Reference-Fr/ (https://www.instructables.com/id/GPSDO-YT-Disciplined-Oscillator-10Mhz-Reference-Fr/)
Any comments?
These GPSDO work with a FLL not with a PLL. The lock is very fast and stable. Are there any further experiences with this type? Unfortunately there is no source code from the project.
-
I've just run my new GPSDO with the Vectron OCXO for a couple of days and would appreciate the experts' opinion on the results.
I have a gain of 590, TC of 200s and TempCoeff of 0. The OCXO temperature varied by less than two degrees.
I'm curious about the slope on the DAC value.
Thanks,
Mike
So far I have bought 3 Vectrons on ebay. The first did not work at all, the second the REF-V was defective, the third finally worked. I can't make the seller responsible now, but mostly they are destroyed during transport.
-
I'll certainly look into adding individual regulators for every IC. I think I'll adjust the main reg to be a 12V-5V buck and have individual 3.3V linears powering everything directly. That way I don't have to worry too much about power dissipation with a 12V->3.3V linear conversion but I can still get relatively low-ripple 3.3V.
Unfortunately, LDOs are not very good at removing input supply ripple. You might want to look into adding a "capacitance multiplier" after the buck regulator to have a clean input to the LDOs:
You're only bloody right about relying on LDOs as a switching hash filter add on to a switching converter since above 100KHz they start looking like high pass filters. The real value of using an LDO, post converter output, is to restore regulation lost the the resistance of an RC LPF placed between the switching converter's output and the input to the LDO.
It's the RC LPF which deals with suppression of switching hash - the LDO is simply there to regulate the voltage unmolested by switching hash and ripple from the converter stage.
The 'capacitor multiplier has its own issues of energy loss and is not really a viable solution in this type of ripple suppression, being aimed at dealing with the more sedate 100 to 120Hz ripple components of a conventional mains voltage psu.
The charm of the humble RC LPF, apart from its compact simplicity, is its almost total lack of self resonance effects into the hundreds of MHz that such switching hash frequencies can extend into. However, that benign filtering characteristic comes with an efficiency cost and a requirement to restore voltage regulation with an LDO so tends to be used to power the more sensitive and less power hungry parts of a system. If you feel the need for such measures, target their use with with care.
John
Capacitance Multiplier play their role in audio equipment. They will filter audible hum. I think in GPSDO they don't make any sense
-
They can adjust frequency every 1000 seconds only. The rest of the time the OCXO effectively drifts around. No temperature compensation either. Suitable for an Rb standard, or for an extremely good OCXO. Not possible to provide 1PPS output, either, as they're only frequency locked.
-
So far I have bought 3 Vectrons on ebay. The first did not work at all, the second the REF-V was defective, the third finally worked. I can't make the seller responsible now, but mostly they are destroyed during transport.
I was lucky, mine came from a test equipment supplier a few miles from my home. It's a shame he didn't have any more.
Mike
-
Hi guys:
New to this forum thread. I am very interested in bread-boarding my first GPSDO attempt, and have some Bliley and other 5 and 12 volts OCXO's in the parts bin. I have already built various Arduino Nano projects and also have an Agilent 53131A counter and a resonable scope. I have been using a "commercial" BG7TBL eBay GPSDO for the last few years. So now I would like to learn more and try building one. QUESTIONS:
1. What is the latest version schematic that has evolved from all the discussion here about improvements?
Is this exists, does anyone share the arduino sketch code so I can get started learning how it works?
2. Does anyone share the KiCad files so I can learn to adapt a PCB to the OCXO and parts that I have?
(I have recently installed KiCad, and need an excuse to start learning it :-) )
3. Has anyone in the forum made a PCB with multiple mounting holes for the various OCXO types/sizes?
4. Is it best to use a square wave or sine wave OCXO for this project?
Sincere Thanks in advance for any mentoring/guidance,
Neal
N6YFM
-
@nealix
I suggest that first of all, you read this complete blog from beginning to end at least once. Yes, it may take you a day or two, but the information in here is invaluable. All what you're asking for is there, including the source code.
If you want, you can also have a look on my personal blog for more information about what I did. On that blog is also a link to my Github site with code, schematics and PCB information, albeit made with DipTrace.
http://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html (http://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html)
Be careful though, this topic can be very contagious, before you realize it, you're a time-nut.
-
@Dbldutch
I read your entire blog. Thanks.
I have a question about the GPS modules. You talked about the M8T (expensive) and less cost M7N and Neo 6M modules.
Once you finally found a good view of the sky, had enough satellites, and saved coordinates in the EEPROM, did you still find the
need for the expensive M8T, or did you find adequate operation/accuracy using the Neo 7N or M?
(I should qualify that I am not looking for perfection, just reasonable accuracy for the average radio and test equipment hobbyist.
Also, I do have a proper outdoor GPS antenna mounted in a 360 degree clear-sky view. My GPS disciplined dual-timezone wall clock
project always shows 12 sats with it's NEO 6 module)
Second question - You mentioned in your blog's GPS section;
"One other mistake I made was that I didn't save all the settings into the NEO EEPROM and so I lost them after a power cycle. Because I no longer monitored the NEO output, I was unaware of this."
Where do I read to learn more about how to do the above, how to store things in the EEPROM? Is there a forum post, or is that from
some other web site or article or user manual? Would it perhaps be the u-center program at the Ublox site?
And is it just the local coordinates that you store so after a power cycle it can lock faster? Or do you make other settings such
as modes, etc?
Thanks again for getting me started. I have some GPS modules already, and also ordered some of the other parts today.
Cheers,
Neal
-
@Dbldutch
I read your entire blog. Thanks.
I have a question about the GPS modules. You talked about the M8T (expensive) and less cost M7N and Neo 6M modules.
Once you finally found a good view of the sky, had enough satellites, and saved coordinates in the EEPROM, did you still find the
need for the expensive M8T, or did you find adequate operation/accuracy using the Neo 7N or M?
(I should qualify that I am not looking for perfection, just reasonable accuracy for the average radio and test equipment hobbyist.
Also, I do have a proper outdoor GPS antenna mounted in a 360 degree clear-sky view. My GPS disciplined dual-timezone wall clock
project always shows 12 sats with it's NEO 6 module)
Second question - You mentioned in your blog's GPS section;
"One other mistake I made was that I didn't save all the settings into the NEO EEPROM and so I lost them after a power cycle. Because I no longer monitored the NEO output, I was unaware of this."
Where do I read to learn more about how to do the above, how to store things in the EEPROM? Is there a forum post, or is that from
some other web site or article or user manual? Would it perhaps be the u-center program at the Ublox site?
And is it just the local coordinates that you store so after a power cycle it can lock faster? Or do you make other settings such
as modes, etc?
Thanks again for getting me started. I have some GPS modules already, and also ordered some of the other parts today.
Cheers,
Neal
Only timing receivers like the M8T will have an "overdetermined clock mode" which calculates precise timing instead of precise position (can't do both): You supply a precise position, the receiver calculates precise time. A general purpose receiver cannot make use of an externally supplied precise position, it will calculate position and time for every measurement interval, usually once per second. Accuracy of the time pulse generally depends on the precision of the position, so if the position uncertainty is high, so is the time uncertainty. With a general purpose receiver under open sky, the position accuracy will be maybe down to 2 or 3 meters. But as you can feed a timing receiver with an arbitrarily precise position, you can get the uncertainty it down into the centimeter regime.
Eventually, any GPS module will do, but of course there will be an impact on the stability. A timing receiver after a good survey-in will output a time pulse accurate down to 1ns, if your GPSDO software makes use of the quantization correction. A general purpose receiver will be in the >20ns range. This means heavier filtering and longer time constants will be needed to achieve good short-term stability. For long term stability it doesn't matter a lot. Quality of the OCXO matters, though: An OCXO that ages fast or has high susceptibility to temperature changes will require a faster control loop, which will not be able to filter the timepulse noise of the GPS as efficiently.
Regarding configuration of the Ublox modules and saving to EEPROM, that's done with the U-Center software indeed. But I'm not aware that you can also save a position. I think after a restart, if you don't feed a position externally or start a survey-in, it will function as a regular GPS receiver.
-
You can buy these modules (not cheap, ~$130):
Multi-band GNSS receiver with nanosecond-level timing accuracy:
https://www.u-blox.com/en/product/zed-f9t-module (https://www.u-blox.com/en/product/zed-f9t-module)
-
Neal,
If you have a good location for the antenna with a 360 degrees view of the sky, there is less need to use a timing receiver. I have a very poor view of the sky which is why I have to rely on a timing version.
The U-Blox website gives you access to the datasheets and documentation. I could not find much information in blogs so I had to look it all up and give it a try.
There are cheaper sources for timing receivers other than buying them from U-Blox, Google is your friend.
Success!
-
I got a little tired of re-programming my GPSDO's after I changed a fan controller parameter while tuning the PID controller.
I have now added code to the Lars program to incorporate the settings of the minimum PWM, the maximum ambient temperature and the Kp, Ki and Kd gain parameters. Both the info and help display(f1) and the list of current variables (f2) incorporate these changes.
The code for version 3.60 is on my Github https://github.com/paulvee/Lars-GPSDO (https://github.com/paulvee/Lars-GPSDO)
Enjoy!
-
I should qualify that I am not looking for perfection, just reasonable accuracy for the average radio and test equipment hobbyist.
Hi Neal, and welcome to the forum.
I am only a couple of months ahead of you on the learning curve and will leave the difficult answers to the experts :)
However, my needs are the same as yours and my philosophy is to start cheap and work up. On that basis I bought a couple of GY-GPSV3-NEO modules on eBay for UKP7 each and an active GPS antenna for UKP9. The antenna is mounted on the house wall and can see about half the sky. It works fine for me (so far ...) although my GPS modules are the NEO-7M which doesn't have the EEPROM so you can't update the firmware.
Mike
G8GYW
-
Thanks again for getting me started. I have some GPS modules already, and also ordered some of the other parts today.
Cheers,
Neal
I can recommend this: https://www.youtube.com/watch?v=q_KOPdy6VYc&t=637s (https://www.youtube.com/watch?v=q_KOPdy6VYc&t=637s)
-
Just wanted to show the first results of my attempts to regulate the temperature inside the GPSDO enclosure, in an attempt to isolate the OCXO temperatures from the room temperature changes. All this to get a "pure" DAC result, devoid of temperature effects.
The data is taken from my Trimble based GPSDO, where the OCXO itself is insulated from all 6 sides in a 10-15mm thick hard-foam box. Inside the box is one of the LM35 temperature sensors.
I'm using the other LM35 that measures the ambient temperature right on top of D1/R1/C1 inside the enclosure to drive a 30mm 5V DC fan with a PWM signal, coming from a simple PID controller. Both LM35's are now low-pass filtered to get rid of the noise.
@Dbldutch
When you say that the LM35 is low-pass filtered, I assume that is in software? Or have you updated a schematic to show
the interfacing of the LM35 and filter? I have already downloaded and looked at; Controller Schematic V2_1.jpg
Is C11 and R12 the filtering you mention, or is it in software on your version 3.6?
Cheers,
Neal
-
@Neal:
The capacitor and resistor in the hardware actually does very little to filter the LM35 output. It helps but the output still jitters a lot from second to second.
I used a quick-and-dirty IIR filter to average the acquisitions in the software. In my V3.6 software, look at lines 97..101 for the details.
Because Lars also uses one of these values for his temperature compensation, in a (for me) rather complicated way that I didn't want to disturb, I only filter the LM35 outputs for the status display. They are at lines 1040 and 1079. I use this status display for my analysis in Excel.
I hope this helps.
-
Yes, thanks, that helps a lot.
I also ran across this: https://elvistkf.wordpress.com/2016/04/19/arduino-implementation-of-filters/ (https://elvistkf.wordpress.com/2016/04/19/arduino-implementation-of-filters/)
which, with your answer, now make perfect sense :-)
Thanks!
-
I've just seen this, which appears to be a Trimble GPS antenna/receiver for almost no money:
https://www.ebay.co.uk/itm/Acutime-2000-GPS-Smart-Antenna-for-Precise-Timing/233702099796 (https://www.ebay.co.uk/itm/Acutime-2000-GPS-Smart-Antenna-for-Precise-Timing/233702099796)
Would this be a good source for the 1pps signal?
Mike
-
I've just seen this, which appears to be a Trimble GPS antenna/receiver for almost no money:
https://www.ebay.co.uk/itm/Acutime-2000-GPS-Smart-Antenna-for-Precise-Timing/233702099796 (https://www.ebay.co.uk/itm/Acutime-2000-GPS-Smart-Antenna-for-Precise-Timing/233702099796)
Would this be a good source for the 1pps signal?
Mike
I have one of these (in a box somewhere).
I seem to remember the 1pps is accurate to 40ns , not stellar.
The multiplug is a funny beast ... Can you source it ?
/Bingo
-
I've just seen this, which appears to be a Trimble GPS antenna/receiver for almost no money:
https://www.ebay.co.uk/itm/Acutime-2000-GPS-Smart-Antenna-for-Precise-Timing/233702099796 (https://www.ebay.co.uk/itm/Acutime-2000-GPS-Smart-Antenna-for-Precise-Timing/233702099796)
Would this be a good source for the 1pps signal?
Mike
The press release says something like "synchronized to UTC within +/- 100 nanoseconds (one sigma)". I guess that may be before "sawtooth correction"? The user manual says "50ns against UTC". Not stellar. But as far as bang-per-buck is concerned, a timing receiver ready for montage for 10 bucks is hard to beat.
-
The multiplug is a funny beast ... Can you source it ?
You can use regular "Dupont" jumper wires to populate the connector. How you secure them is up to you. I've used cable ties to bundler them. Maybe candle wax or casting resin to fill the housing?
-
The multiplug is a funny beast ... Can you source it ?
You can use regular "Dupont" jumper wires to populate the connector. How you secure them is up to you. I've used cable ties to bundler them. Maybe candle wax or casting resin to fill the housing?
It's a standard military connector, you can find them on eBay.
-
The press release says something like "synchronized to UTC within +/- 100 nanoseconds (one sigma)". I guess that may be before "sawtooth correction"? The user manual says "50ns against UTC". Not stellar. But as far as bang-per-buck is concerned, a timing receiver ready for montage for 10 bucks is hard to beat.
The User Guide says "Over-determined Clock Mode with a timing accuracy of <15 nanoseconds (one sigma) to UTC, GPS, or GNSS time."
I don't know how that compares to my NEO-7 which quotes "30ns RMS"?
-
If you have a general purpose NEO-7 receiver, the Trimble will likely get you better stability. Maybe you can even improve on the 15ns with a longer position self-survey (seems you can configure that).
My NEO-M8T can do better than +-10ns accuracy (peak, not RMS, after sawtooth correction), but it needs a really good position uncertainty. I ran a survey-in setting a boundary of < 200mm position uncertainty, and after that it claimed 2ns time accuracy.
-
It's an attractive price but I think I'll give it a miss. It would need a cable making up and an RS-422 to USB converter plus yet more software to learn.
I do need a better antenna installation though as my NEO-7 can only see 3 satellites despite being wall mounted outside the house.
Oops software glitch. It's 13 now ...
Funny how my smartphone can see 16 from inside the house :-//
Mike
-
Funny how my smartphone can see 16 from inside the house :-//
Your smartphone is cheating. It has a lot of assistance from the network (time, coarse position, almanac and ephemeris for all constellations) so it only needs exact time (easy to receive). Then all it has to do is track the satellites.
-
Your smartphone is cheating. It has a lot of assistance from the network (time, coarse position, almanac and ephemeris for all constellations) so it only needs exact time (easy to receive). Then all it has to do is track the satellites.
Thanks for that. I'm getting there slowly ...
My external antenna is seeing 10-12 satellites which should be enough for the GPSDO. I'm getting a splitter so I can feed my GPS clock as well.
Mike
-
@Dbldutch
Hi: I notice on your Oscillator Circuit V2 schematic from GIThub, that the voltage control line going into the OCXO goes through a DC choke filter, a 33uH L102 inductor. Can you share more detail on this? I understand the purpose, in filtering out higher frequency noise on the voltage control line to the OCXO, but is it a 1/4 watt, 1/2 watt, or 1 or 2 amp inductor? I assume since the average OCXO can take a little over an amp while heating, then around 600ma running, that the inductor might be bigger than 1/4 watt types? But how do you calculate the size/wattage/part needed? What specifically is L102 if I want to use one (or wind it myself)?
Second question: On that Oscillator Circuit V2 schematic, the main schematic is using a Bliley NV47M1008 with an R109 of 27K ohms. But the little table at the bottom
right of the schematic shows R109 as 330K ohms for a Bliley. Quite a difference. What do you suggest would be the proper starting point for R109?
Third newbie question :-) : I have both Arduino Nano 5 volt modules and also some Arduino Pro Mini 3.3 volt modules. If I decide to start with the Arduino Pro Mini
modules so that the 3.3volt logic will all match, should I still use the series 100 ohm resistors that you show on your Arduino Nano digital I/O lines?
Last question for now; On your Controller Schematic V2_1, you have 68 ohm resistors in series with the LM35 output. What made you choose this value?
Is that a form of the low pass filtering based on R12/C11 for the LM35?
Sincere Thanks.
@everyone
I finally decided to compare my china fake U-blox Neo-6 GPS modules (all 5 are fakes), to a real U-Blox purchased via reputable USA supply chain.
I ended up buying a Mikroe GNSS 7 Click module from Mouser (also carried at DigiKey), which has the U-Blox Neo-M9N that just started shipping last month.
Ref: https://www.mouser.com/ProductDetail/Mikroe/MIKROE-3922?qs=GBLSl2AkirvsES1Toi%252BOeA%3D%3D (https://www.mouser.com/ProductDetail/Mikroe/MIKROE-3922?qs=GBLSl2AkirvsES1Toi%252BOeA%3D%3D)
WOW!. The Neo-6 modules are good, even as fakes. But, the Neo-6 only gets USA GPS sats. The new Neo-9 series will simultaneously receive all four
systems (BeiDou, Galileo, GLONASS, GPS / QZSS). With an indoor GPS puck antenna near a window, Neo-6 with just USA GPS could give me maybe 5 to 6
SATs. But the new Neo-M9N give me closer to 20 satellites indoors. Impressive little module for $40 USD.
Cheers,
Neal
-
Hi Neal,
Q#1: I use two choke filters.
One for the VCF input, and I just used what I had available. I once ordered a selection from a China source. Unfortunately, no documentation. They look like .25W resistors and cannot carry much of a current. They are there to keep the 10MHz from the OCXO from getting in the DAC adjustment circuit. The value is not very critical but they do make a large difference.
The second one is used in series with the powerline to the OCXO. I used a Ferrite I already had available. It has a few holes (we call it a pig-snout in Dutch) where the lead is winded through a few times. It can carry several Amps. It is there to keep hf noise from the outside (switching power supply) from getting in the OCXO. For a picture for this one, have a look at one of my pictures of the PCB in an earlier post, or look for a picture on my blog.
Q#2: I used the values in the table. The resistors in the diagram where just placeholders for the OCXO that I used first. Don't forget that these values are dictated by the gain setting procedure, and are highly depending on the quality of your OCXO and the sensitivity of the adjustment.
Q#3: The small resistors in series are there to remove some of the sharp edge transitions that may cause cross-talk or ringing. Leave them in.
Q#4: I used what somebody on this blog recommended. 68 Ohm in series with the data line and a 10uF capacitor to ground. Yes it is a low-pass filter.
You are right, only NEO's at model 7 and up can be configured to receive all the constellations. If you don't have a clear view of the sky, get a timing version like the 8MT.
Good luck!
-
Hi Neal
Just to add to what Dbldutch said (I have built his circuit and it works very well).
The voltage control input to the OCXO is high impedance so almost any size choke will be OK. I used these 0.25W 33uH chokes:
https://www.ebay.co.uk/itm/Inductor-Choke-Coil-1-4W-0-25W-Values-0-1uH-to-1mH-Various-Pack-Sizes/152687409289?ssPageName=STRK%3AMEBIDX%3AIT&var=452270326536&_trksid=p2057872.m2749.l2649 (https://www.ebay.co.uk/itm/Inductor-Choke-Coil-1-4W-0-25W-Values-0-1uH-to-1mH-Various-Pack-Sizes/152687409289?ssPageName=STRK%3AMEBIDX%3AIT&var=452270326536&_trksid=p2057872.m2749.l2649)
And for the supply ferrites I used these:
https://www.ebay.co.uk/itm/PACK-OF-4-FERROXCUBE-MHC6-6-10-4B1-MULTI-HOLE-FERRITE-CORES-10MM-BY-6MM/122831367380?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649 (https://www.ebay.co.uk/itm/PACK-OF-4-FERROXCUBE-MHC6-6-10-4B1-MULTI-HOLE-FERRITE-CORES-10MM-BY-6MM/122831367380?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649)
The Mikroe module looks like a bargain (£29 in the UK). Does it have a 1pps output line or do you have to tack a wire on?
Mike
-
The two that Mike took the effort to look up are indeed the ones I use.
Thanks Mike!
-
But the new Neo-M9N give me closer to 20 satellites indoors. Impressive little module for $40 USD.
Cheers,
Neal
M9N Accuracy of time pulse signal RMS 30ns
99% 60ns
M8T 20ns
You don't need 100 sats, you need a stable Module.
-
You are right, only NEO's at model 7 and up can be configured to receive all the constellations. If you don't have a clear view of the sky, get a timing version like the 8MT.
Is the M8T pin compatible with the 7N? If so I could swap the module on one of my boards.
Mike
-
As far as I know, the 6, 7 and 8 are all pin compatible.
I swapped my Chinese copy of the 6 with a genuine M8T on the same carrier.
-
Is the M8T pin compatible with the 7N? If so I could swap the module on one of my boards.
Mike
Yes we did it in the BG7TBL thread.
-
M9N Accuracy of time pulse signal RMS 30ns
99% 60ns
M8T 20ns
You don't need 100 sats, you need a stable Module.
@Fennec:
Thanks, I do understand that, and did at the time. But I could not locate any supplier of a breakout module board with the M8T on it
for anywhere less than $100 USD. Where do you guys find a timing module on a breakout board that can actually be used without
doing your own wave soldering and PCB design? I did find a person selling on Tindie selling the SkyTraq timing module and ordered that:
SkyTraq Venus838LPx-T Timing GPS module breakout
Add a u.FL to SMA pigtail?: No
Add an amplified u.FL patch antenna?: No
Connection style: SIP
Unit Price: $50.00 + free shipping.
Quantity: 1
But I also ordered the Ublox M9N breakout module I mention above at the same time, just to compare, since I knew
that module would arrive in a few days, and the Skytraq takes about a month to get here.
Cheers,
Neal
-
Hi Neal
The Mikroe module looks like a bargain (£29 in the UK). Does it have a 1pps output line or do you have to tack a wire on?
Mike
Yes, it does have 1-PPS output. Here is the schematic of the board;
https://www.mouser.com/datasheet/2/272/gnss-7-click-schematic-v100-1863770.pdf (https://www.mouser.com/datasheet/2/272/gnss-7-click-schematic-v100-1863770.pdf)
It also comes with the backup battery installed.
Neal
-
But I could not locate any supplier of a breakout module board with the M8T on it
for anywhere less than $100 USD. Where do you guys find a timing module on a breakout board that can actually be used without
doing your own wave soldering and PCB design?
You like it accurate, so you have to pay. If you need just a "frequency" you can set a cheap $US15 UBlox module output with UCenter.
I do not understand why you want to use an "High End Lars-Board" with the lowest quality pulse generator. :rant: :-// :-// :scared:
Contradiction in terms
See att
https://www.ebay.com/itm/1x-Ublox-LEA-6T-2-000-50-channel-15ns-1pps-Timing-GPS-module-WD22UGRC/313149500246?hash=item48e92a2b56:g:IR8AAOSwULhfEG5T (https://www.ebay.com/itm/1x-Ublox-LEA-6T-2-000-50-channel-15ns-1pps-Timing-GPS-module-WD22UGRC/313149500246?hash=item48e92a2b56:g:IR8AAOSwULhfEG5T)
-
OK it's time to ask the experts a question please.
I've been running my GPSDO for a while now with tc=200s and tempCoeff=0 just to put some aging on the OCXO, which was sold as unused. The first graph shows what happened over a three week period.
Regarding the time constant, I thought 200s would be a reasonable number to start with, but I've now started a run at tc=4s to determine the optimum value. The second graph shows the current result but I will leave it running to improve the accuracy.
Here's the question. With tc=200s it loses lock, then recovers, several times every 24 hours. How do I determine the cause?
Mike
-
Mike,
You can't tell that from the MDEV chart.
You'll need to store the report from Lars' program over a 24hr period and use Excel to chart the ns, DAC and OCXO temperature values to try to make sense out of what's going on. Can you publish those graphs, or post the excel file with the report?
-
But I could not locate any supplier of a breakout module board with the M8T on it
for anywhere less than $100 USD. Where do you guys find a timing module on a breakout board that can actually be used without
doing your own wave soldering and PCB design?
You like it accurate, so you have to pay. If you need just a "frequency" you can set a cheap $US15 UBlox module output with UCenter.
I do not understand why you want to use an "High End Lars-Board" with the lowest quality pulse generator. :rant: :-// :-// :scared:
Contradiction in terms
See att
https://www.ebay.com/itm/1x-Ublox-LEA-6T-2-000-50-channel-15ns-1pps-Timing-GPS-module-WD22UGRC/313149500246?hash=item48e92a2b56:g:IR8AAOSwULhfEG5T (https://www.ebay.com/itm/1x-Ublox-LEA-6T-2-000-50-channel-15ns-1pps-Timing-GPS-module-WD22UGRC/313149500246?hash=item48e92a2b56:g:IR8AAOSwULhfEG5T)
RE: I do not understand why you want to use an "High End Lars-Board" with the lowest quality pulse generator.
:-) :-) If you read a little higher, you may notice that I purchased both a Skytraq Venus838LPx-T Timing GPS module breakout,
AND the U-Blox M9N. The M9N is a very good enough receiver for hobby level work on my projects, and got here in days,
so I could play and learn while the Skytraq takes one month to arrive.
Some of us are "time-nuts" {tm}, but I am not. My personal goal for this project is to learn more about how a GPSDO
really works, learn time lab and lady heather, and compare the result to my $175 commercial GPSDO. If I wanted or
needed "Aerospace" level accuracy, I could indeed choose to rip the wallet wide open and spend spend spend. But I like
the idea of seeing if my parts spend can be less than or equal to the commercial unit, yet match or exceed it's performance.
Each person has a different reason. :-)
As far as accuracy for the $50 Skytraq Venus838LPx-T Timing GPS module:
The Venus838LPx-T module will provide PPS quantization error correction messages, allowing you to remove the quantization
error present on the PPS output. Without correcting this error, the PPS will have approx. ±6 ns of jitter.
Back to the non-timing and typically fake eBay U-Blox Neo-6 modules; They are more than good enough for
my GPS disciplined Wall Clock projects, where a human can't tell if you are half a second off;
https://nealix.zenfolio.com/img/s/v-10/p4012064259-4.jpg (https://nealix.zenfolio.com/img/s/v-10/p4012064259-4.jpg)
https://nealix.zenfolio.com/img/s/v-10/p4012064258-4.jpg (https://nealix.zenfolio.com/img/s/v-10/p4012064258-4.jpg)
https://nealix.zenfolio.com/img/s/v-10/p4012064260-4.jpg (https://nealix.zenfolio.com/img/s/v-10/p4012064260-4.jpg)
https://nealix.zenfolio.com/img/s/v-10/p4012064255-4.jpg (https://nealix.zenfolio.com/img/s/v-10/p4012064255-4.jpg)
and finally, when I receive the Skytraq Venus838LPx-T Timing GPS module and can build Lars/PaulV's schematic,
this is what I wish to compare results to (The simple China BG7TBL GPSDO that uses FLL instead of PLL):
https://nealix.zenfolio.com/img/s/v-10/p4012055982-4.jpg (https://nealix.zenfolio.com/img/s/v-10/p4012055982-4.jpg)
and yes, accurate to half a Hertz is more than good enough for my amateur hobby needs.
So anyway, thanks again for putting up with another newbie here. But I am learning from you guys and having fun
at the same time. For that, huge thanks!
Cheers,
Neal
-
Mike,
You can't tell that from the MDEV chart.
You'll need to store the report from Lars' program over a 24hr period and use Excel to chart the ns, DAC and OCXO temperature values to try to make sense out of what's going on. Can you publish those graphs, or post the excel file with the report?
Thanks Paul, here's a 24 hour extract.
Mike
-
Does anyone here know where can I find a datasheet for the CTi OCXO model OSC5A2B04 ?
Thanks,
Neal
-
Does anyone here know where can I find a datasheet for the CTi OCXO model OSC5A2B04 ?
Thanks,
Neal
I think they share the pin-out of all the other OCXOs with the same size and footprint. Or what else did you haven in mind looking for in the datasheet?
-
Does anyone here know where can I find a datasheet for the CTi OCXO model OSC5A2B04 ?
Thanks,
Neal
I think they share the pin-out of all the other OCXOs with the same size and footprint. Or what else did you haven in mind looking for in the datasheet?
I am trying to decide which OCXO to use for my first build here.
For square wave, I have the CTi and the ISOTEMP.
For Sine, I have an 8663, a pair of Morion MV85, a CMAC, and a couple of Bliley 1282's.
Any opinions or favorites re which one I should build my first unit with?
Cheers
-
@Mike
Attached are the charts based on your 24hrs Lars' report on your Vectron.
From the ns chart, it seems your GPS signal is too noisy. It really should be within +/- 20ns.
I would investigate why this is so by analyzing the NEO performance with u-center. If you didn't already put it in stationary mode, I recommend you do that. Also, do you limit the reception to better than 20dB? How many sats do you then have, and which constellations do you receive. Is your view of the sky OK? All these questions can be answered by u-center. I should point out that many of my own earlier strange GPSDO behavior were caused by the poor results coming from the NEO. By using an M8T timing version due to my poor reception, all my troubles melted away like snow in spring.
What is strange is that nowhere are your ns values going beyond +/- 100ns, so this is not the reason for loosing the lock.
If you look at the filt output, it follows the lock status. I cannot find a reason for loosing the lock based on the control loop of the system.
If you look at the DAC data, it seems that it is still settling. The curve is slowly moving down.
I also included the 3 hr averages from the status report. You can clearly see the settling of the OCXO in the curve. Your 3 hr OCXO temperature has a lot of movement.
Your temperature reports seem a bit off. If you use temp for the OCXO, that seems a bit low, and it varies quite a bit. I also looked at the temp1 data, and it is around 29 degrees but varies the same way. Is that sensor measuring the inside of the enclosure? Is the enclosure really closed, or do you have the lid open? I suggest you close it.
This was with a TC of 200. I think you are now running with a TC of 4? This will really show the components because there is no filtering taking place.
If you can, post that TC 4 run as well.
Can you also post the f2 and f4 reports together with the status reports?
I'm puzzled by the frequent lock losses though.
One suggestion I have is to clear the EEPROM with e22, restart the program and input only the required values like gain, TC and temp sensor type (11), then save them with s1.
Good hunting!
-
For Sine, I have an 8663, a pair of Morion MV85, a CMAC, and a couple of Bliley 1282's.
The MV85 is definitely my favorite of the day. Beware of fakes, though.
-
Attached are the charts based on your 24hrs Lars' report on your Vectron.
Paul, many thanks for looking at this for me. I have trouble producing those graphs because I use LibreOffice Calc and it is very slow and crashes frequently on large files. I also have Excel 2003 but that has a limit of 65k rows and 32k points for a chart.
You could be right about the satellites. I can't receive any at all with a puck antenna even on the window sill. My active outdoor antenna is mounted on the house wall facing east and usually sees 10-12 satellites. My U-Blox is a NEO-7N.
It will take me a while to respond to all your suggestions. I'd like to leave the tc=4 run for a bit longer before trying anything else.
Mike
-
Mike, when you have about a day's worth of data for the TC 4 run, upload that file, but also post the f2 and f4 reports.
-
Paul, many thanks for looking at this for me. I have trouble producing those graphs because I use LibreOffice Calc and it is very slow and crashes frequently on large files. I also have Excel 2003 but that has a limit of 65k rows and 32k points for a chart.
Mike, take a look at Matlab or Octave (free Matlab clone). It's definitely worth it and gets things done much faster than messing with apreadsheet. Takes some getting used to, but handles big data sets much easier than Excel/Calc.
-
You could be right about the satellites. I can't receive any at all with a puck antenna even on the window sill. My active outdoor antenna is mounted on the house wall facing east and usually sees 10-12 satellites.
A GPS patch antenna should always be facing up, or close to up or be pointing at the clear patch of sky -with an elevation mask set! the elevation mask will then reject odd order reflections, which are polarity reversed.
An elevation mask is always a good idea with a patch antenna.
Also, it sounds like you may be using it without a ground plane. A patch antenna doesnt work properly without a flat piece of metal beneath it. Ideally it should be aligned with the horizon, really.
Thats an integral art of the antenna. It doesnt responate properly without it. At the minimum you should use something like a junk CDRom or ideally a piece of steel the magnet can adhere to. A piece of PCB will do fine too. The bigger it is the better it will work! I also put a small ferrite on the coax coming from them to decouple the feedline. That usually makes a small but meaningful improvement in the pattern.
I recently got a NanoVNA and its obvious when sweeping the passinve GPS antennas I have why the groundplane is essential and why it should be larger. They clearly come from the factory tuned to a large GP, like the roof of a car. There is a very noticeable dip at the resonant frequency and if you use a passive GPS antenna with the factory's minimal ground plane you can see how radically it shifts with a small versus large ground plane.
They come just as the ceramic element with a peg, to connect it, the equivaent of having an antenna supplied just as a whip, and a PCB pattern, the device, not the antenna - manufacturer ususally provides their own PCB and it is the groundplane.
Basically, the groundplane makes the antenna. So you cant just put a puck antenna on your windowsill and expect it to work. What I would do is take a junk CG and using any available means, attach that to your puck's bottomside. They are cupposed to magnetically affix to an automobile roof. Thats how they are supposed to be used.
But just a CD/DVD will give you just enough GP to get it to work. A bit larger would be better. 20 cm or more, several wavelengths, would be ideal if its practical. It will improve your performance a lot. Anything flat and conductive will do it. Put some copper tape on your windowsill.
A lot of people make this mistake. The same appllies in any rover, UAV, etc. situation.
-
If you can, post that TC 4 run as well.
Can you also post the f2 and f4 reports together with the status reports?
Here are the requested reports.
I believe the temperature readings to be accurate. The Vectron OCXO runs much cooler than my Trimble. The ambient sensor is positioned next to D1. The board is in an enclosure (same as yours) with the lid on.
Mike
-
Also, it sounds like you may be using it without a ground plane.
Not so sir. I placed the puck on a sheet of copper clad PCB but it would still only receive satellites when outside the house. When you consider that the GPS module and puck together cost 7 UK pounds I'm happy to consign that antenna to the bin.
That's why I gave up with the puck and mounted an active antenna on the house wall.
Mike
-
I would investigate why this is so by analyzing the NEO performance with u-center. If you didn't already put it in stationary mode, I recommend you do that. Also, do you limit the reception to better than 20dB? How many sats do you then have, and which constellations do you receive. Is your view of the sky OK? All these questions can be answered by u-center. I should point out that many of my own earlier strange GPSDO behavior were caused by the poor results coming from the NEO. By using an M8T timing version due to my poor reception, all my troubles melted away like snow in spring.
My NEO-7 was in Portable mode. I changed it to Stationary mode and captured the attached images. However as my module is an M suffix it appears that I am unable to save configuration changes? I couldn't find where to limit the reception to >20dB.
Mike
-
Disable SBAS. It doesn't typically help the stability of the timing signal.
-
Paul, many thanks for looking at this for me. I have trouble producing those graphs because I use LibreOffice Calc and it is very slow and crashes frequently on large files. I also have Excel 2003 but that has a limit of 65k rows and 32k points for a chart.
Have a look at gnuplot
/Bingo
-
Also, it sounds like you may be using it without a ground plane.
Not so sir. I placed the puck on a sheet of copper clad PCB but it would still only receive satellites when outside the house. When you consider that the GPS module and puck together cost 7 UK pounds I'm happy to consign that antenna to the bin.
That's why I gave up with the puck and mounted an active antenna on the house wall.
Mike
Is the GPS antenna's normal up pointing sideways? Thats what I am getting at. It may work fine, but I would put it on a 90 degree bracket and groundplane.
and if there is still enough sky view that it still works, set an elevation mask perhaps. Ive lived in lots of flats at various times where the only sky view is up an air shaft. I'd be surprised if that worked well but as long as the GPS can see a few sats at once it should woirk enough to get a lock. Newer GPS receivers are pretty sensitive.
-
@Mike
I looked at your TC4 results.
The graphs I made from your data in Excel look pretty good. The 1PPS has the expected noise level, so your GPS is not the culprit. The ns band is significantly below +/- 20ns, with only a wobble in the middle of the data, which is acceptable.
The DAC follows the 1PPS jitter lead, but the excursions are a little high.
The temperatures look very stable too.
So this looks very good, and offers no explanation for loosing the lock at higher TC's.
However, when you look at the DAC values in TimeLab, it shows a very different story.
Look at the MDEV chart. The curve looks great, but look at the left axis. This is rubbish.
Note that to import the DAC data into TimeLab, you have the convert the DAC values back to frequency. You do that by dividing 1E-9 by the gain. In your case, with a gain of 590, that results in a value of 1,69492E-12 and that is used to convert the DAV values inside TimeLab.
I suspect that there is something not quite right with the way you calculated your gain, or the method that you used to obtain it. Otherwise your hardware that drives the OCXO adjustment has issues. This would explain the weird loss of locks at higher TC's, and also the weird TimeLab results.
The way I adjusted my OCXO's was by setting the DAC at mid-range (h32767) and while looking at the Lars' report, adjust the OCXO DAC by a trimmer so the diff_ns reads an average of 0ns over a page of data or so.
Now set the DAC to the minimum with h1 and again look at the diff_ns report for a page of data. Take the average of that data and write it down.
Now set the DAC to the maximum with h65535 and again look at the diff_ns report for another page of data. Take that average too and write it down. One of them will be below 0, and one above. Add the two averages together without using the sign.
Divide 65535 by that result and that is your gain.
If the gain is significantly below 500, adjust the trimming resistors for the DAC adjustment to make it larger. If it's significantly above 1.000, make it a bit smaller. I suggest a range between 600 - 900, but in the end, it all depends on the drift and aging of your OCXO.
If your OCXO has aged enough and the DAC results are no longer drifting up or down over a longer period, replace the trimmer with fixed resistors to remove temperature effects.
I hope this helps...
-
Paul, thanks for looking at that for me but I think something went wrong with your MDEV chart. Here is what I get from the same data, and the parameters I used to import it.
I replaced the trimmer pot with fixed resistors before starting my aging run. My resistor values are:
R104 = 20k, R105 = 5k1, R110 = 2k7, R111 = 12k, R109 = 100k.
The diff_ns values averaged over a page of data were 51.6 for h1 and -59.5 for h65535, so a total of 111ppb. 65535/111 = 590 and 1E-9/590 = 1.6949E-12 so I think I got that right.
Mike
-
Well I'll be d...
I tried to import your data several times with the same results, even after closing and restarting TL.
I just tried it three more times, same results.
I de-installed TimeLab en re-installed it.
Same result. :-//
Tried earlier data from one of my own GPSDO's, same bad results. :-// :-//
:wtf: is going on?
De-installed TL again and removed all remnants I could find.
Installed it again.
Tried my own data, works!
Tried your data, works!
|O
The net-net is that it seems your GPSDO is (now?) working as expected. Why don't you try to increase the TC and see if it stays locked after getting a lock?
Be on the watch-out for the swings in the ns values. If you see it starting to drift slowly and regularly, it means that your TC is getting too high.
-
The net-net is that it seems your GPSDO is (now?) working as expected. Why don't you try to increase the TC and see if it stays locked after getting a lock?
Be on the watch-out for the swings in the ns values. If you see it starting to drift slowly and regularly, it means that your TC is getting too high.
Thanks I will do that.
Glad you got TL sorted!
Mike
-
Have a look: https://www.instructables.com/id/GPSDO-YT-Disciplined-Oscillator-10Mhz-Reference-Fr/ (https://www.instructables.com/id/GPSDO-YT-Disciplined-Oscillator-10Mhz-Reference-Fr/)
Any comments?
These GPSDO work with a FLL not with a PLL. The lock is very fast and stable. Are there any further experiences with this type? Unfortunately there is no source code from the project.
Hi 0xFFF0,
I just released my code on github https://github.com/YannickTurcotte/GPSDO-YT (https://github.com/YannickTurcotte/GPSDO-YT)
If the pps is accurate, yes it's fast and very stable.
Regards
Yannick
-
Yannick was so kind to develop a special counter version of his own GPSDO project for me, to tailor it to GPSDO's in general.
I have extensively tested it over the past couple of weeks, and it works really well.
The latest version has a programmable gate time that can be set to 1.000s with 3 decimal digits of resolution, or 10,000s for a 4 decimal digit resolution and it sends the results to a serial port. It does not need an LCD display and needs only a few components.
Just displaying the result on a display has little benefit with high precision and stable OCXO's, but logging the results to track them over time does. As a minimum, it's a poor mans high resolution counter that gives you another look at the GPSDO precision and stability.
I will post my development for the Lars project on my own blog to not pollute this one too much.
-
Yannick was so kind to develop a special counter version of his own GPSDO project for me, to tailor it to GPSDO's in general.
I have extensively tested it over the past couple of weeks, and it works really well.
The latest version has a programmable gate time that can be set to 1.000s with 3 decimal digits of resolution, or 10,000s for a 4 decimal digit resolution and it sends the results to a serial port. It does not need an LCD display and needs only a few components.
Just displaying the result on a display has little benefit with high precision and stable OCXO's, but logging the results to track them over time does. As a minimum, it's a poor mans high resolution counter that gives you another look at the GPSDO precision and stability.
I will post my development for the Lars project on my own blog to not pollute this one too much.
It was a pleasure Paul.
Source code for this counter available here: https://github.com/YannickTurcotte/GPSDO-Counter
Like Paul said, more info on his blog.
Yannick
-
I need some more help please guys.
I've been running my GPSDO with tc=100s and it has lost lock three times in under 24 hours. The out of lock periods are remarkably consistent: 525s, 523s and 514s.
I've posted some pictures and the log. Any ideas what's going on please?
Mike
-
Did you do the TIC linearization?
-
Did you do the TIC linearization?
No I haven't done that. Is it essential to maintain lock?
Mike
-
Did you do the TIC linearization?
No I haven't done that. Is it essential to maintain lock?
Mike
I haven't analyzed your data, but if you have discontinuities between the fine and coarse TIC parts, that will cause jumps in the phase measurements. Remember you changed the resistor in the interpolator part, so 1 microsecond might not correspond to 1000 fine TIC units. It also didn't with the original resistor value since you got overruns, remember? The "10MHz missing" messages...
I'd say, doing the TIC linearization is essential for a Lars GPSDO.
-
@ Thankfat:
I'd say, doing the TIC linearization is essential for a Lars GPSDO.
I searched this forum for "TIC linearization" and can only find references to that use in TimeLab.
Can you please enlighten us on how to do what your asking us to do?
-
I haven't analyzed your data, but if you have discontinuities between the fine and coarse TIC parts, that will cause jumps in the phase measurements. Remember you changed the resistor in the interpolator part, so 1 microsecond might not correspond to 1000 fine TIC units. It also didn't with the original resistor value since you got overruns, remember? The "10MHz missing" messages...
I'd say, doing the TIC linearization is essential for a Lars GPSDO.
You have a good memory! However, the resistor change was in my first GPSDO, which followed the Lars design.
My current experiments are with Dbldutch's modified design, which didn't have that problem.
Mike
-
I decided to eliminate possible problems with the satnav signal by replacing the Chinese U-blox NEO-7M with a genuine M8T (curse this addiction :'().
I'm running it again at tc=100s. After gaining lock, it unlocked 95 minutes later then locked again after 547 seconds (same interval as before). It's still locked 8 hours after that. You can see the DAC value taking a dive when it lost lock.
Is it OK to feed the 3.3V logic level from the U-blox to the 5V HC4046 without a level shifter?
Mike
-
Mike, you are supplying a 3V3 level output signal to a 5V input, so there will be no smoke and the 3V3 is safely above the 5V signal threshold level.
-
@ Thankfat:
I'd say, doing the TIC linearization is essential for a Lars GPSDO.
I searched this forum for "TIC linearization" and can only find references to that use in TimeLab.
Can you please enlighten us on how to do what your asking us to do?
Page 12 in Lars original documentation.
-
I decided to eliminate possible problems with the satnav signal by replacing the Chinese U-blox NEO-7M with a genuine M8T (curse this addiction :'().
I'm running it again at tc=100s. After gaining lock, it unlocked 95 minutes later then locked again after 547 seconds (same interval as before). It's still locked 8 hours after that. You can see the DAC value taking a dive when it lost lock.
Is it OK to feed the 3.3V logic level from the U-blox to the 5V HC4046 without a level shifter?
Mike
What is the "ppb" graph?
-
What is the "ppb" graph?
It's the diff_ns readings.
Mike
-
@ Thankfat:
I'd say, doing the TIC linearization is essential for a Lars GPSDO.
I searched this forum for "TIC linearization" and can only find references to that use in TimeLab.
Can you please enlighten us on how to do what your asking us to do?
Page 12 in Lars original documentation.
Yes I read that when I started out, but I didn't understand it and I thought it was only needed when using the first method to get optimum tc.
Am I right that the TIC offset should be 500? For some odd reason mine is 68.
Mike
-
The TIC offset should be 500, yes, because that puts it smack center in the most linear region of the ADC, and provided you did the TIC linearization properly, you should have +/- 500ns of "drift space" before the fine TIC wraps.
-
@ Thinkfat:
The second paragraph on page 12 is confusing to say the least, at least for me.
However, I looked again at the data Mike provided earlier, the one where he used a TC of 4, and there his filtx10 values are in a band of about 570-800.
I looked at a run of my Trimble also with a TC of 4, and there the filtx10 values are centered around 5,000 +/- 100 which seems to be more correct.
I looked at his provided f2 and f4 data and I totally missed his offset, which is indeed wrong.
Sorry Mike!
-
@ Thinkfat:
The second paragraph on page 12 is confusing to say the least, at least for me.
However, I looked again at the data Mike provided earlier, the one where he used a TC of 4, and there his filtx10 values are in a band of about 570-800.
I looked at a run of my Trimble also with a TC of 4, and there the filtx10 values are centered around 5,000 +/- 100 which seems to be more correct.
I looked at his provided f2 and f4 data and I totally missed his offset, which is indeed wrong.
Sorry Mike!
I'm glad some of the experts find it confusing too! I have no idea why my TIC offset was 68. I have never set a value for it so I presume it loaded as a default when I erased the EEPROM and saved the data? Anyway it is now 500 and locked again so we'll see what happens. I'll play with the linearisation when (if) I undrestand how to do it!
Mike
-
@ Thinkfat:
The second paragraph on page 12 is confusing to say the least, at least for me.
However, I looked again at the data Mike provided earlier, the one where he used a TC of 4, and there his filtx10 values are in a band of about 570-800.
I looked at a run of my Trimble also with a TC of 4, and there the filtx10 values are centered around 5,000 +/- 100 which seems to be more correct.
I looked at his provided f2 and f4 data and I totally missed his offset, which is indeed wrong.
Sorry Mike!
Well, the linearization is necessary for using the GPSDO electronics for timestamping, however, for all the graphs to make sense, you need to make sure that the interpolator values are indeed covering a range of 1000ns. For this, you need to see where the ADC wraps, find the min and max and provide this input to the software.
-
@thinkfat:
I must admit that I never bothered to deal with the linearization, because I didn't understand it, nor the implications.
Please help us to understand.
For both my OCXO's, the f2 reports shows the TIC_offset = 500, the TICmin = 12.0, the TICmax = 1012, Square comp = 0.100
I believe these are the default values.
Below are the graphs for the filtx10 and the DAC values.
How do I figure out the values to set the min/max parameters for the linearization correctly, and what is the intended effect?
-
@thinkfat:
I must admit that I never bothered to deal with the linearization, because I didn't understand it, nor the implications.
Please help us to understand.
For both my OCXO's, the f2 reports shows the TIC_offset = 500, the TICmin = 12.0, the TICmax = 1012, Square comp = 0.100
I believe these are the default values.
Below are the graphs for the filtx10 and the DAC values.
How do I figure out the values to set the min/max parameters for the linearization correctly, and what is the intended effect?
You need to set the points where filtx10 wraps. Otherwise you have no correspondence between raw ADC values and phase difference in nanoseconds. How you do that is explained on page 12 of the manual.
-
@Thinkfat
Sorry, I don't understand what you mean with "wraps".
Do you mean the "band" around the mean? This would mean for the Trimble +60 and -90 and for the Bliley +30 and -30?
Does this mean a min of 90 and a max of 60 for the Trimble and 30:30 for the Bliley?
If I understand Lars, we need to set the right span of the TIC. Which is linearization min and max.
With the command "l" min can be set with values 0.1-50 and max can be set with values 800-1023
So how does that work with above values?
-
@Thinkfat
Sorry, I don't understand what you mean with "wraps".
Do you mean the "band" around the mean? This would mean for the Trimble +60 and -90 and for the Bliley +30 and -30?
Does this mean a min of 90 and a max of 60 for the Trimble and 30:30 for the Bliley?
If I understand Lars, we need to set the right span of the TIC. Which is linearization min and max.
With the command "l" min can be set with values 0.1-50 and max can be set with values 800-1023
So how does that work with above values?
It's not about the "band" around the mean. It's about the raw ADC range covered by the phase difference range of the interpolator.
Please, read the instructions on page 12 and recall how the interpolator works. Think about the phase difference range it can display with its 1MHz input frequency.
-
Paul, my understanding of what Lars wrote is that you set the TIC Offset to 1,000 and watch the variation in the filtx10 values. Mine went from a minimum of 9810 to a maximum of 10220 over a short period. I used the l command to store these as 98 for TICmin and 1022 for TICmax. The default values I had were 120 and 1012.
I have no idea what the "squared" value is or how to establish it.
Mike
-
Hi Mike,
I have set the TIC offset to 1,000 for both of my units as well.
In the first sentence of the 3rd paragraph on page 12, Lars wants you to set the TIC offset from 500 to 1,000 when the system is locked, but when you do, you loose the lock immediately. Which makes sense because the ns values go down by 500. What does not make sense to me is what numbers from the filtx10 column to take, and when.
My filtx10 values are jumping up and down, but also steadily going up. I'm not sure if you can just take the min/max out of whatever number of minutes your sample is, or if you have to wait for the unit to lock again.
My min max numbers out of the first 7 minutes were 5450 and 6650 for the Bliley.
Because these are unfiltered values (no lock), you should take off the last digit, so that would be 545 and 665. However, the maximum number for the min setting is 500 (to get 50). So I still don't get it if that's the procedure.
My units are getting closer to a lock now (ns < 100) and the min/max values for the Trimble are now 10590 and 10960, so I still can't make heads or tail out of these numbers.
I'm waiting for a lock to see what the filtx10 numbers will report then.
Unfortunately, it will take a while for my units to lock because of the long tc's of 800 and 1,500.
Stay tuned, we'll figure it out somehow unless somebody gives us clearer instructions.
-
With the TIC_offset at 1,000, it's never locking, even with a tc of 4.
No matter what I do, I can't get it to produce viable numbers. |O
-
I set my TIC offset to 1,000 with a tc of 4s and didn't lose lock. I don't have any numbers I can show you but the filt10x value cycled up and down repeatedly between the minimum and maximum in a fairly short time.
I'll try and capture some numbers later to show you.
Mike
-
Paul, my understanding of what Lars wrote is that you set the TIC Offset to 1,000 and watch the variation in the filtx10 values. Mine went from a minimum of 9810 to a maximum of 10220 over a short period. I used the l command to store these as 98 for TICmin and 1022 for TICmax. The default values I had were 120 and 1012.
I have no idea what the "squared" value is or how to establish it.
Mike
Another (better) way would be to go into "hold" mode and then set the DAC to a value that slowly lets filtx10 drift upwards (or downwards), then record filtx10. The slower the drift the better, like 1 digit per second so that you can see what is going on. At a point it should "jump" from 10000-ish to (I think?) 9000-ish, then look for the highest and the lowest value you find and enter that as min/max.
-
I set my TIC offset to 1,000 with a tc of 4s and didn't lose lock. I don't have any numbers I can show you but the filt10x value cycled up and down repeatedly between the minimum and maximum in a fairly short time.
I'll try and capture some numbers later to show you.
Mike
OK I was wrong about losing lock, but it appears to work. The attached log shows filt10x moving between high and low values 1 minute after setting TIC_Offset to 1,000. I'd run it for longer and take averages.
Mike
-
Let's first stick to the procedure Lars described and see if we can figure out what he meant.
In principle, he is trying to create a better linearization for the ADC TIC input values.
I think that the first part of the procedure should be to set the tc to 4, the TIC_offset to 500 and wait until you have a lock. I think that the tc at 4 is important because it eliminates the filtering in the control loop. A tried a higher tc but that takes hours to settle.
Now set the TIC_offset to 1,000.
I think this means that the ADC will now be forced to work at the top of its 8-bit 1,024 max range, rather than in the middle (at 500).
The ns data will therefore jump from around 0 to -500, the inverse of the additional offset from +500.
The controlling loop will now try to get the ns numbers back to around 0 again.
Wait for the ns and filtx10 data to stabilize. With a tc at 4, this should not take more than a minute or so.
The ns values should on average be around 0 again, and the filtx10 should now be around 10,000. (1,000 x 10)
Save the data from a minute or so after the data stabilized and put it in a spreadsheet.
Lars writes that "With a TIC_offset of 1,000, the GPSDO will go between min and max if the max ADC is less than 1,000. The filtx10 values will give you the min and max."
I interpreted that as follows.
Record all numbers below 10,000 (the min) and all numbers above 10,000 (the max).
These numbers are at the highest range of the ADC, and so in the most linear region.
Obtain the average of the two sets.
In my case for the Trimble, the average number below 10,000 was 9,889, for my Bliley 9,878
The average of the numbers above 10,000 was 10,181 for the Trimble and 10,146 for the Bliley.
I calculated Mike's numbers to be 9895 and 10194.
So far so good I think.
The challenge is to convert these numbers to the valid min and max values.
The min values can only be between 1-500 to become 0.1 to 50.
The max values can only be between 800-1023.
I tried it several ways, but I can't figure it out how to massage the obtained numbers so I can put them in as min/max.
Because filtx10 is multiplied by ten when there is no lock, you could divide the numbers by 10. This would than be a true representation of the ADC input at an offset of 1,000. However, the min numbers will already be divided by 10.
The Trimble number for min would then become 988, but you can't input that.
The max number would become 1,018 and that would only just fit.
You could take 10,000 as the mid point, in which case the min numbers become 10,000 - 9889 = 122.
The max number would then be 10,146 - 10,000 = 146, but that number cannot be used.
Another thought (very far fetched!) I have is that Lars maybe meant to get the min value with a TIC-offset of 500. The lowest filtx10 value would then always be below 500, which is the valid min range. You should then only obtain the max value with a TIC_offset of 1,000, in which case the max will always be in the valid max range.
Anybody? :-//
-
I'd like to echo Paul's request - has anyone succeeded in establishing a value for TIC_min?
In the meantime I'm using the TIC values in Lars' report (120 and 1012) and have done a few short runs with time constants up to 1,500s and had no problems with locking.
I've attached some plots below. Any comments on the performance please? Any obvious issues?
Mike
-
I found this on time-nuts. Does it shed any light on how to get the min and max TIC values?
https://www.mail-archive.com/time-nuts@lists.febo.com/msg00947.html (https://www.mail-archive.com/time-nuts@lists.febo.com/msg00947.html)
Mike
-
I don't think so Mike, but thanks for digging this up.
There is some interesting stuff in this thread.
-
My M8T does not have the required firmware and although I found it and tried, I can't load it due to communication errors with the device. Upgrading the fw for the M8T apparently is not without risks. In any case, that's why I don't have access to Galileo.
Paul, are you sure it's because you weren't exceeding the maximum number of satellite systems the M8T can track? If you already had three selected then it would deselect Galileo.
Mike
-
Hi Mike,
No that was not the problem. My M8T had old firmware that would not let me select Galileo.
I finally figured out where to find the new version and how to upload the new firmware and that solved the problem.
-
Finding the min and max should be really easy if you supplement the logging, printing the raw ADC values in addition, then setting up the GPSDO like described in the time-nuts posting.
-
Well, with the hint from thinkfat, I finally figured it out. Although the time-nuts postings did not help or clarify.
I indeed added a column in the status report to show the "raw" ADC-TIC values. When you apply the offset of 1,000, this extra column reveals what Lars had in mind with the filtx10 data. Unfortunately he did not elaborate what to do with the numbers which had us totally confused.
First of all, I used the procedure I outlined in my post just above. Set TC=4, wait for a lock. Then set the offset to 1,000 and wait until the ns numbers stabilize about around zero again. This will only take a minute but there will be no lock indication. In my software, this is shown as "****" in the sample below.
Now remember that when there is no lock, filtx10 shows the numbers x10. So the offset of 1,000 becomes 10,000 in the filtx10 column.
If you now look at the filtx10 data, all values above 10,000 "represent" the minimum value. To get that value so you can enter it into the system, you need to subtract 10,000. So as an example, if the value is 10,120, take off 10,000 to get 120. When you enter this value into the system, it will be divided by 10 to become 12 which is the intended value.
All values below 10,000 are the maximum values, divided by 10. So as an example, if the value is 9,950, the maximum value is 995.
I would capture at least a page or so of data in a spreadsheet and then calculate the average of the min and the max values.
These values can now be added into the system with l120 for min and l995 for max and then saved with s1 in the EEPROM.
The numbers in the added column with the ADC TIC values, are spot on to those calculated numbers above, so that must be it!
Here is a small abbreviated sample of my modified log: (excuse the formatting, I did my very best...)
Timestamp ADC pwm time ns dac temp status diff_ns filtx10
15:31:20.015 -> 995 134 4283 -6 35478 50.4 **** 10 9950
15:31:20.994 -> 997 135 4284 -3 35873 50.4 **** 2 9970
15:31:21.977 -> 995 138 4285 -6 35328 50.4 **** -2 9950
15:31:23.007 -> 994 141 4286 -7 34990 50.4 **** -1 9940
15:31:23.989 -> 12 132 4287 14 39274 50.4 **** 21 10120
15:31:25.018 -> 992 138 4288 -9 34614 50.4 **** -23 9920
15:31:26.006 -> 989 141 4289 -13 33731 50.4 **** -3 9890
15:31:26.987 -> 32 132 4290 31 44028 50.4 **** 44 10320
15:31:27.973 -> 16 142 4291 17 40721 50.4 **** -14 10160
15:31:29.002 -> 10 139 4292 12 39556 50.3 **** -5 10100
15:31:29.984 -> 991 130 4293 -10 35102 50.3 **** -23 9910
Mystery solved.
-
Mystery solved.
Nice work sir! I would never have figured that out.
Now, can I raise the enthusiasm to get hold of a PD26 to calculate x2?
Also, what is "k" and how is it entered? Lars has a value of 6 in his example while mine is 63.
Mike
-
Also, what is "k" and how is it entered? Lars has a value of 6 in his example while mine is 63.
Mike
k is the Now acquiring value: of the Three hour averages: TIC+DAC+temp
-
My M8T had old firmware that would not let me select Galileo.
I finally figured out where to find the new version and how to upload the new firmware and that solved the problem.
Can you post some info about this? I have a bunch of M8Ts that I would like to upgrade and I can’t find the FW.
-
Miti,
That process was described in post 482 on page 20.
-
Miti,
That process was described in post 482 on page 20.
Great, thanks! I have over 20 genuine M8T modules. If anyone is interested, I offer some for sale. They are salvaged from boards that were not working properly (other issues, not GNSS issues) but were conformal coated so hard to repair, and were scraped.
-
It worked like a charm! And it did take about 30 - 40 seconds for me. I can see Galileo now but my question is, and I bet it is answered somewhere here but TLDR, does it have any benefit in the GPSDO? I'm very pleased with my Lars GPSDO, it stayed locked since spring and actually all I need is a reasonably accurate 10MHz source, and I think it does this. My time/volt nutness is still under control.
-
Hi miti
I'm glad it worked!
The only benefit I see is that if you have a limited view of the sky, the additional constellation(s) and satellites will help to get a more stable 1PPS, and that will reflect directly on the GPSDO stability and precision. This worked sort of miracles in my particular situation.
What do you charge for an M8T?
-
Hi miti
I'm glad it worked!
The only benefit I see is that if you have a limited view of the sky, the additional constellation(s) and satellites will help to get a more stable 1PPS, and that will reflect directly on the GPSDO stability and precision. This worked sort of miracles in my particular situation.
That's my case as well. I have a small magnetic patch antenna that's installed in my basement window on top of a biscuits box to have a ground plane, so I only see sky on the west side of the house. Upgrade may help a bit.
What do you charge for an M8T?
As Italians would say, tutto mezzo prezzo. Half price of what it is in Mouser, Digikey, etc. so $45 + shipping, tested and upgraded.
-
Hi miti
I'm glad it worked!
The only benefit I see is that if you have a limited view of the sky, the additional constellation(s) and satellites will help to get a more stable 1PPS, and that will reflect directly on the GPSDO stability and precision. This worked sort of miracles in my particular situation.
That's my case as well. I have a small magnetic patch antenna that's installed in my basement window on top of a biscuits box to have a ground plane, so I only see sky on the west side of the house. Upgrade may help a bit.
What do you charge for an M8T?
As Italians would say, tutto mezzo prezzo. Half price of what it is in Mouser, Digikey, etc. so $45 + shipping, tested and upgraded.
Is it a bare module, or mounted on some breakout board?
-
Just the module. As I said, salvaged from some boards.
-
Newbie Question:
I received my Skytraq Venus838LPx-T timing PCB from Tindie, and I have finally put up my outdoor GPS antenna on a mast with
a 360 degree sky view. The GPS module puts out NMEA sentences and after a short time gets lock and starts blinking the PPS LED.
When I see you guys talking about jitter and stability of the GPS module, what are you using to measure the 1 PPS output?
Are you using Timelab? (The home page does not say anything about docs, but I assume they get installed when you install
the software?) Or, is there any point in trying to measure the GPS module, rather than the full GPSDO project stability?
Or are you using some other method to look at the stability of the GPS module output?
Also, are there specific settings that should be made to this GPS timing module using the GNSS Viewer Software?
(I realize I am kind of circling around the edge of this project, sort of starting in parallel with my GPS receiver module
and also with the wiring of the OCXO unit. The middle will fill in after I learn more about these edge parts.)
Thanks for any guidance/mentoring,
Neal
-
Paul, many thanks for looking at this for me. I have trouble producing those graphs because I use LibreOffice Calc and it is very slow and crashes frequently on large files. I also have Excel 2003 but that has a limit of 65k rows and 32k points for a chart.
Mike, take a look at Matlab or Octave (free Matlab clone). It's definitely worth it and gets things done much faster than messing with apreadsheet. Takes some getting used to, but handles big data sets much easier than Excel/Calc.
I just found a great open source program for plotting my GPSDO graphs:
https://veusz.github.io/ (https://veusz.github.io/)
It's easy to use (just follow the 5 minute tutorial) and handles large csv files easily. Here's an example.
Mike
-
My GPSDO will lock with tc=1500s (eventually!) and remain locked, but that's too long for my purposes so I've been doing some 24 hour tests with shorter time constants. Do the plots of diff_ns with increasing tc look a bit odd?
Mike
-
Newbie Question:
I received my Skytraq Venus838LPx-T timing PCB from Tindie, and I have finally put up my outdoor GPS antenna on a mast with
a 360 degree sky view. The GPS module puts out NMEA sentences and after a short time gets lock and starts blinking the PPS LED.
When I see you guys talking about jitter and stability of the GPS module, what are you using to measure the 1 PPS output?
Are you using Timelab? (The home page does not say anything about docs, but I assume they get installed when you install
the software?) Or, is there any point in trying to measure the GPS module, rather than the full GPSDO project stability?
Or are you using some other method to look at the stability of the GPS module output?
Also, are there specific settings that should be made to this GPS timing module using the GNSS Viewer Software?
(I realize I am kind of circling around the edge of this project, sort of starting in parallel with my GPS receiver module
and also with the wiring of the OCXO unit. The middle will fill in after I learn more about these edge parts.)
Thanks for any guidance/mentoring,
Neal
There are multiple ways to see the jitter in the 1PPS. I'm using the DSO, one way is to trigger from 1PPS on one channel while looking at a 10MHz signal from a GPSDO on another channel. Set the trigger mode to Normal, turn persistence to maximum and you'll get 1.png after awhile. Another way is to set the PPS output to 10MHz, trigger one channel from the GPSDO 10MHz output while the second channel displays the 10MHz from the GPS module, see 2.png. The jitter is the same in 1PPS and in 10MHz. I'm not sure if your GPS module can output 10MHz on the PPS though, Ublox can. Of course, both, the GPSDO and the GPS module under test, must be locked, otherwise they will drift.
-
The jitter is the same in 1PPS and in 10MHz.
Are you sure about that? 10MHz is not an exact division of the u-blox clock frequency, doesn't that introduce additional jitter?
Mike
-
The jitter is the same in 1PPS and in 10MHz.
Are you sure about that? 10MHz is not an exact division of the u-blox clock frequency, doesn't that introduce additional jitter?
Mike
Lots of that, yes. But of course you can use the 10MHz as a reference input to a PLL to clean up the jitter.
-
The jitter is the same in 1PPS and in 10MHz.
Are you sure about that? 10MHz is not an exact division of the u-blox clock frequency, doesn't that introduce additional jitter?
Mike
If your reference is a stable, in phase, GPSDO 10MHz, you don’t see that jitter, which is basically a pulse of a significantly different length every now and then. Or if you’re unlucky and your scope triggers exactly when that pulse happens, you’ll always see it (I guess, to be validated) but the edge jitter that we’re talking about is the same. See my scope screen shot or try it yourself.
-
I spent a lot of time with this circuit as well as another that changed out Lars' simple DAC for a two stage DAC system and used a TDC7200 for the TIC. But prior to going that route, I had a number of issues that were pretty basic. Your mileage may vary.
1) Make sure your PPS isn't overdriving the 4046. If it is, and probably will be, use a simple voltage divider or variable resistor to bring it down below the 5V (if using 5V logic) and then use a 100 ohm resistor to help reduce the ringing. There is usually a big spike on the 1PPS signals a that slew from zero to 5V pretty quickly. That helped a lot for me.
2) Same thing with your 10Mhz input. Square it up if needed using a two-transistor or other circuit from Wentzel. Go here https://wenzel.com/library/ (https://wenzel.com/library/) and search for squaring circuits. I've always used the two-transistor as it was called. You can also look at the TAPR TADD or TADD-2 or TADDD-2, can't remember all the 'D's in it, ha, input schematic. Again. make sure it isn't under or overdriving your logic. This is on the return signal coming from the oscillator.
3) On circuits like Lars that use saw-tooth correction, again, make sure you have the logic levels correctly in phase and aren't overdriving the Arduino. I had to use a voltage divider again.
4) Breadboards that have been used a few times start to loosen-up. After a lot of prompting, I changed most of my little colored jumpers to single strande, tinned, 20 gauge wire. I then doubled-up the key connections. This took a lot of little jumps out.
5) One of the tests it to put it in hold so that initially the TIC is counting around 400 and then watch the output. It should smoothly go or or down with the tic_max and tic_min close to tic_average. ( I think Lars exposes these fields). You can see the jumps caused by poor PPS conditioning, poor Oscillator return, etc pretty easily. Bang on the table a little to see if it jumps. Better yet, if you don't have a PCB, get a few of the solder-type breadboards from Amazon, EBay, Ali, etc and use them. I think Lars circuit costs less than $20 so if you solder it up and need to throw it away a few times, so what. It's easier than fighting breadboard noise and ground loops.
6) If still using a breadboard, take a 20gauge wire, strip it off and slip it down the center channel. Then mark where you need grounds, solder little wires to it, pull the chips, put the wire in the channel and use that as a single point of ground.
7) Alternatively, take a piece of PCB stock and pull the stickum off the bottom of the breadboard on the ground channels. Mark and solder the channels to the PCB. You might need to put little solder bumps on the PCB to lift the channels up so you can keep the stickum on the rest of the breadboard. You can do this for the ground runs from the bus lines as well. Then put the breadboard back onto the channels for the rest of the circuitry. You can also do this with a solder type board. The large ground plane will help while maintaining flexibility.
8) Use a good oscillator or it really isn't going to work well. Something that floats all over the place is just never going to do much for you. The GPS and TC can only do so much. I used an HP 10811 and X72 Rubidium successfully and it took just a few hours to get the first lock and then a couple of weeks to keep it locked.
9) You need bypass caps everywhere. Especially diagonally across the 4046, HC390 and any other chips. The diagonal was a great idea from a friend.
10) back to the oscillator return. Use an isolation transformer like an MCL T1-6T. You don't ground the input side to anything. You can bend the pins on one side and stick it down in a breadboad (if using one). Make sure the input ground isn't grounding to the rest of the circuitry.
11) Power supply. I had one for the GPS, another for the oscillator, another from the PC USB driving the Arduino, etc. This is a bad idea and I had ground loops all over the place. Some GPS have a 5v output but you need to minimize the number of supplies. The isolation transformer helps with the oscillator because you need a ground to the EFC and if you have a long wire coming back from the oscillator output, that can cause a ground loop.
12) Wrap the oscillator in styrofoam to keep air currents from causing sudden shifts.
Hope it helps.
Jerry
-
https://wenzel.com/library/time-frequency-articles/waveform-conversion-part-i-sine-to-square/
(https://wenzel.com/wp-content/uploads/diffsqr.gif)
/Bingo
-
Some sine wave OCXOs produce a distorted (and jittery) output if you don't terminate them right across the output and ground pins with a resistor that approximates to their output impedance as I eventually discovered with a set of CQE 10MHz OCXOs (DOC1478 - exactly the same as used by Symmetricom).
I'd previously run a very basic impedance test on the 6 spare ones I had to hand and 'measured' Zo values ranging from a low of 74 to a high of 90 ohms. I compromised and soldered a 100 ohm resistor across the output pins which cured the peculiar jitter on the output of the 74HC14 Schmidt trigger gates I'd not been able to eliminate by adjustment of the 5K bias trimpot feeding the input via a 33K ohm resistor.
Once I'd added the 100 ohm terminating resistance, I was able to get a jitter free 1:1 ratio square wave to feed the divide by 100 stage feeding the PLL and the buffer circuit driving the LPF feed to the 10MHz out BNC socket.
I'd only noticed this 'distorted sine wave' output from the OCXO itself when I probed it with my DSO. I'd checked it and its siblings early on and hadn't noticed this issue the first time round (AFAICR, they'd all looked like perfect sine wave outputs) but when I retested the rest of my "Fleet", they all showed the same effect. I can only assume I must have had some sort of resistive loading in circuit the first time round. :palm:
Coincidentally, I'm testing the Vref voltages on my spares right now to pick a replacement for the one in my updated James Miller version GPSDO after seeing the EFC voltage wandering up and down between a low of 2.282 and a high of 2,287 volts over the past week or two with an unexpected excursion to 2.288 volts and a sudden plummet to 2.243 after drumming my fingers on top of the GPSDO just prior to inverting it to apply the full 2G tipover treatment. The output shifted some 2 or 3 cycle's worth against my RFS before the PLL output caught up and restored stability, eventually settling at 2.2865v where it had been hovering about +/- 0.5mV an hour or so earlier.
Despite it responding as expected to the next 2GT effect test with no weird response to my finger drumming vibration test, I've decided to change it out since its ageing trend has been so dominated by these up and down excursions, it's been impossible to determine whether it is following an ageing trend of any sort.
The 13MHz CQE OCXO I'd used in my MK I had exhibited a positive EFC aging trend of around 1mV per week within the power off/power on induced retrace events where the EFC would slowly drop to a mV or two below the previous high tide value before getting back on track and resume its upward trend a day or two later.
Although I'm mindful of the possibility of it being an intermittent fault elsewhere, I'll go after the most likely culprit and swap out the OCXO first before trying to prove the existence of an intermittent fault that may or may not actually be present. It's not the easiest of components to swap out but I have to start somewhere. :(
John
-
Some sine wave OCXOs produce a distorted (and jittery) output if you don't terminate them right across the output and ground pins with a resistor that approximates to their output impedance as I eventually discovered with a set of CQE 10MHz OCXOs (DOC1478 - exactly the same as used by Symmetricom).
I'd previously run a very basic impedance test on the 6 spare ones I had to hand and 'measured' Zo values ranging from a low of 74 to a high of 90 ohms. I compromised and soldered a 100 ohm resistor across the output pins which cured the peculiar jitter on the output of the 74HC14 Schmidt trigger gates I'd not been able to eliminate by adjustment of the 5K bias trimpot feeding the input via a 33K ohm resistor.
Once I'd added the 100 ohm terminating resistance, I was able to get a jitter free 1:1 ratio square wave to feed the divide by 100 stage feeding the PLL and the buffer circuit driving the LPF feed to the 10MHz out BNC socket.
I'd only noticed this 'distorted sine wave' output from the OCXO itself when I probed it with my DSO. I'd checked it and its siblings early on and hadn't noticed this issue the first time round (AFAICR, they'd all looked like perfect sine wave outputs) but when I retested the rest of my "Fleet", they all showed the same effect. I can only assume I must have had some sort of resistive loading in circuit the first time round. :palm:
Coincidentally, I'm testing the Vref voltages on my spares right now to pick a replacement for the one in my updated James Miller version GPSDO after seeing the EFC voltage wandering up and down between a low of 2.282 and a high of 2,287 volts over the past week or two with an unexpected excursion to 2.288 volts and a sudden plummet to 2.243 after drumming my fingers on top of the GPSDO just prior to inverting it to apply the full 2G tipover treatment. The output shifted some 2 or 3 cycle's worth against my RFS before the PLL output caught up and restored stability, eventually settling at 2.2865v where it had been hovering about +/- 0.5mV an hour or so earlier.
Despite it responding as expected to the next 2GT effect test with no weird response to my finger drumming vibration test, I've decided to change it out since its ageing trend has been so dominated by these up and down excursions, it's been impossible to determine whether it is following an ageing trend of any sort.
The 13MHz CQE OCXO I'd used in my MK I had exhibited a positive EFC aging trend of around 1mV per week within the power off/power on induced retrace events where the EFC would slowly drop to a mV or two below the previous high tide value before getting back on track and resume its upward trend a day or two later.
Although I'm mindful of the possibility of it being an intermittent fault elsewhere, I'll go after the most likely culprit and swap out the OCXO first before trying to prove the existence of an intermittent fault that may or may not actually be present. It's not the easiest of components to swap out but I have to start somewhere. :(
John
That's very interesting. I've been looking at the output of my GPSDO with my DSO running an FFT, I use a sine wave OCXO (brand new Taitien NA-10M-2503 bought via Digikey) and I generate the 10MHz output by first squaring up the OCXO, then feeding it into a 74AC04 and from there into a low pass filter to get back to a sine wave. I noticed a very, very slight "hump" in the spectrum, at +/- 1.6MHz off of the carrier and down around -95dBc. At first I suspected an amplitude modulation through the power distribution network, but it turned out it came out of the sine-to-square block already, so it was a phase modulation, not AM, in other words jitter.
The OCXO is not terminated properly, its output more or less goes directly into a tank circuit and from there into a biased inverter gate. Now that you mention jitter I'll try adding some termination resistor on the PCB, the OCXO data sheet says the output impedance is 50 Ohms, so that's what I'll add. I'll see if that noisy hump is gone afterwards.
-
Gave it a try and soldered a 49.9 Ohm resistor between ground and OCXO output. It did improve the situation somewhat, the phase modulation is attenuated a bit more, it's now almost down in the noise. The output gained a few more harmonics, though, but that is not really a concern.
-
Well, I was partially wrong about how the 10MHz is generated in the Ublox modules but I think the statement that the jitter is independent of the output frequency, is valid, but please correct me if I'm wrong. The 10MHz is made of three types of pulses, all multiple of the 20.833ns, the period of the 48MHz internal clock of the module. One is 5 x 20.833ns with a duty cycle of 60%, a 5 x 20.833ns with a duty cycle of 20% and one with 4 x 20.833ns with a duty cycle of 50%, at least that's what I see on the scope. These must be combined in such a way that in the end, there are 10 million pulses in a second. So since the source of the jitter is the same for the PPS and for the 10MHz, the jitter of the rising or falling edge must be the period of the 48MHz clock. Is my logic correct?
Also, 1MHz and 100KHz seem to follow the same logic, the jitter seems to be the same. In my case it is about 22ns, probably the signal level is not ideal.
-
Some ocxos cant drive 50 ohms directly; some require it. Good example is my HP 10811. It likes a 50 ohm load. I get a larger signal with a high impedance load but the signal is cleaner with 50ohms.
Check your DSO setting If you see a large change when probing to make sure you dont have it in 50ohm mode with a high impedance probe on it.
Something else to consider. If you are using an oscillator that has 1PPS output in addition to 10Mhz, some Rubidiums are like that, make sure it is divided down from the oscillator if you plan to use it in timing, as it will be more stable, generally. At least that is my findings. I tested my X72 PPS output vs the 10Mhz divided down with a wentzel two transistor followed by a PICDIV chip. So if you plan to provide 1PPS output from your GPSDO package, I suggest you divide it down from the disciplined oscillator like that. Or provide both.
-
Some ocxos cant drive 50 ohms directly; some require it. Good example is my HP 10811. It likes a 50 ohm load. I get a larger signal with a high impedance load but the signal is cleaner with 50ohms.
Check your DSO setting If you see a large change when probing to make sure you dont have it in 50ohm mode with a high impedance probe on it.
Something else to consider. If you are using an oscillator that has 1PPS output in addition to 10Mhz, some Rubidiums are like that, make sure it is divided down from the oscillator if you plan to use it in timing, as it will be more stable, generally. At least that is my findings. I tested my X72 PPS output vs the 10Mhz divided down with a wentzel two transistor followed by a PICDIV chip. So if you plan to provide 1PPS output from your GPSDO package, I suggest you divide it down from the disciplined oscillator like that. Or provide both.
50 Ohm for this particular OCXO might be a bit too harsh, though the data sheet says the output impedance is 50 Ohms, the signal quality definitely isn't great. The data sheet specifies the 3rd harmonic with < 30dBc, it still keeps this spec, but that's not very demanding.
Regarding the 1PPS output: not enough to just divide down the 10MHz, you also need to align the pulse to UTC top-of-second.
-
Same thing with your 10Mhz input. Square it up if needed using a two-transistor or other circuit from Wentzel.
For those who like to experiment, here are a couple more ways to do it:
http://www.ko4bb.com/getsimple/index.php?id=clock-shaping (http://www.ko4bb.com/getsimple/index.php?id=clock-shaping)
Mike
-
Gave it a try and soldered a 49.9 Ohm resistor between ground and OCXO output. It did improve the situation somewhat, the phase modulation is attenuated a bit more, it's now almost down in the noise. The output gained a few more harmonics, though, but that is not really a concern.
I'm glad to hear my observation regarding the need to terminate some types of OCXO came in useful for you. :)
From my own experiments with frequency injection locking with my collection of CQE 10MHz OCXOs, I'm guessing that most of these sine wave output types are unbuffered, presumably to keep phase noise performance as high as the end user can achieve with careful design of the circuitry it will be driving into. Appealing to the OCXO manufacturer on the basis of "It's not our problem chum, it's yours! (to deal with as you see fit)".
Trying to figure out the best route to inject my reference frequency into these OCXOs eventually proved to be via the output pin rather than via the Vref or EFC pins (I had even considered the Vcc pin) in the hope that sufficient energy would 'pollute' the oscillator circuit in order to obtain a result that's often all too easy to achieve by accident of bad circuit layout. ::)
In my case, I suspect the absence of the expected loading had caused the oscillator to overdrive itself into saturation and recover every other cycle, hence the distinct 2ns jitter on the edges before and after the triggered edge (and every alternate edge before and after).
I never did ever track down any datasheets for any of the CQE OCXOs, hence my playing safe with my very first 13MHz cmos square wave acquisition by powering it off a 5 volt rail on the off chance of it being a 5 volt only part that would otherwise emit its magic smoke when subjected to a 12v rail. When I purchase my first three of the 10MHz units of the seven in total I landed up buying, I felt I could afford to risk a fiver's worth of OCXO on a 12v test.
Although the original 13MHz unit looked physically identical (and drew the same 280mA initial warm up current which for the 12v 10MHz units remained the same regardless of whether they were being powered from a 5 or 12v rail), I decided to stick with a 5v setup in the very first (MK I) GPSDO just to keep to a single power rail and prove I could create a 10MHz GPSDO using a 13MHz OCXO 'just because I could'.
Anyway, the upshot of all that being that I can only guess that the recommended loading impedance, despite my basic output impedance testing showing a range from 74 to 90 ohms for the 10MHz units, is likely to have been the classic 50 ohm figure. The output of a signal source in a unidirectional system is more or less irrelevant with regard to matching a load provided the load matches whatever the chosen impedance of its connecting length of transmission line happens to be.
In the absence of any meaningful length of transmission line, the choice tends to be a little more arbitrary and since the "transmission line" in my case consisted of 15mm or so of a wire link, largely comprised of a 1nF capacitor and 150 ohm resistor in series, I compromised by using a 100 ohm resistor directly across the output pins in order not to bog down the 1.5v pk-pk sine wave output feeding the input of a 74HC14 inverter driving the 74HC390 and another inverter driving the remaining 4 inverters feeding the 10MHz LPF through 150 ohm resistors.
They were all dc coupled so I could use the one bias trimpot to optimise the effective switching threshold for the 10MHz output buffer stage which was ac coupled to the LPF. I'd added an extra 1.6uH 10MHz peaking inductor across the middle cap in the classic 5 element Butterworth LPF which also neatly ties the filter to the ground reference point.
BTW, I did swap the OCXO out that evening and had it up and running for initial tests after checking the 'other usual suspects' I'd had in mind as possible contenders for the sudden EFC transient and 3% phase shift in the PLL's 100KHz input that I'd provoked with my finger tapping test.
However, after letting the EFC voltage settle to its new value of 2.4210, I did another finger tapping test and got an unpleasant surprise as it suddenly shifted half a cycle or so at 10MHz before stabilising. It hasn't responded to the many vibration tests over the past two days since, so I suspect I may simply have relieved some pent up stress in the "Stress Compensated Cut" crystal inside my "NOS" OCXO. I guess only time will tell but apart from that little 'surprise', it seems to be behaving itself just fine.
The EFC has dropped another 8mV and I'm expecting it to come to a halt and start going up again based on my previous experience with the 13MHz unit. I'm assuming that the 13MHz unit's retrace behaviour is typical - it may well not be. I'm just going to have to keep my eye on the EFC voltage (as I normally do) for the next few days and see what happens before I start running any power cycle tests.
John
-
Just a quick update on my OCXO swap out "repair".
In the intervening 6 days since my previous post, the EFC has dropped by another 3mV with still no sign of it "bottoming out". It's now hovering around the 2.4097 to 2.4100 volt mark. The reducing EFC trend has slowed down but there is still no sign of any reversal as I'd experienced with the 13MHz "Five Volt" OCXO (which btw, did well and truly prove itself to be a 12 volt unit after all!).
I could simply be observing an upward frequency ageing effect (reducing EFC voltage) that will continue unabated, albeit one that gets slower and slower over time. Also worth noting is that thus far, I've not been able to provoke any more frequency jumps with my finger tapping vibration tests - so far, so good (until it isn't). ::)
John
-
I wished I'd looked at this forum some years ago. I have designed a low cost GPSDO, really to see just how basic a functional system can be. The cost of the prototype was less than $20 AU (excluding power supply - from the bit box). I use a different approach to most designs, basically (1) the microprocessor uses the oscillator output as its clock (2) the output PWM providing the control voltage is dithered (mark/space ratio varied by 1 bit) every 250uS which, averaged over less than a second gives equivalent of 24 bit DAC (3) correction to the control voltage is calculated and applied at intervals, small deviations of the input 1ppS have no effect. The results of the prototype are modest, to be expected as it is a very basic circuit making no attempt at refinement. However the software is written to be dynamic and my next prototype will try to use the same software in a more sophisticated circuit to prove the point. Software is written in PIC assembler, not sure if it could be done any other way but my bent is writing software. The averaging algorithm uses 32 bit signed arithmetic to calculate a linear least squares fit of the 1ppS information to derive an average. The minimum averaging period is 5 seconds, the maximum is 2048. Correction is applied if the average deviation exceeds a dynamic limit (the more measurements made, the more reliable the average becomes. It is actually beneficial to work with a GPS having some jitter!)
The actual performance varies between about 3 x 10^9 frequency deviation to 3 x 10^10. There are a number of factors - (1) poor viewing - the GPS doesn't see much of the sky (2) the power supply is a switch mode 5V supply of unknown quality, originally powering a superseded piece of equipment (3) the oscillator was chosen on price rather than performance. The next prototype will address all of these - (1) using an external antenna to acquire a better signal (2) control voltage to be derived from a MAX6350CPA+ Voltage Reference (3) oscillator to be a Morion MV89. Items on order at the moment.
I've attached the circuit. It omits the 5V supply and 2 bypass capacitors. The actual circuit has the 3 active components, power supply, 6 capacitors, 4 resistors, 1 LED. Can it be simpler than that?
-
I'm confused and need some advice please :-//.
I have aged my "new old stock" Vectron OCXO for 2 months, improved the location of my outdoor GPS antenna and surveyed-in the accuracy of my NEO-M8T to 0.75 metres.
Now I'm trying different time constants for the GPSDO and when I plot the MDEVs they appear to be upside down compared to what I've seen on here. The stability is gradually getting worse.
Here's one such plot, together with graphs from the log. Time is measured in seconds from when it acquired lock.
Any suggestions please?
Mike
-
There are a number of factors - (1) poor viewing - the GPS doesn't see much of the sky
This is crucial, as I discovered. I bought an NEO-M8T timing receiver thinking I would get a stable 1pps with my active antenna on the house wall under the eaves. It was facing north and could see less than half the sky, but I thought having 12 good satellite signals would be OK - wrong! The best positional accuracy I could get was 8 metres and the M8T requires 1 metre or better for a stable timing signal.
I extended the mounting bracket to give the antenna an overhead view of the sky and the difference was dramatic. It didn't bring in many more satellites but the accuracy improved to 0.75 metres.
Here are pictures of the before and after antenna mounts.
Mike
-
I'm confused and need some advice please :-//.
I have aged my "new old stock" Vectron OCXO for 2 months, improved the location of my outdoor GPS antenna and surveyed-in the accuracy of my NEO-M8T to 0.75 metres.
Now I'm trying different time constants for the GPSDO and when I plot the MDEVs they appear to be upside down compared to what I've seen on here. The stability is gradually getting worse.
Here's one such plot, together with graphs from the log. Time is measured in seconds from when it acquired lock.
Any suggestions please?
Mike
There's still a fair amount of drift visible in the DAC data. The MDEV result reflects that. Your TIC data looks good, though. Nothing to worry about.
You have roughly one day of data in your logs (close to 80,000s ?) What you see might be a diurnal effect due to temperature changes. Plot the temperature data alongside and see if there's a correlation.
Apart from that, let me repeat: the DAC data tells you a lot about your overall system, and only very little about your output stability and accuracy.
The only independent reference you have is the GPS, so plot the TIC data instead, properly scaled (times 1e-9), imported into TimeLab as phase data. For larger "tau" you'll see it approaching the 1e-13 ranges. You have enough data to see tau=20000. MDEV should approach and maybe cross the 1e-12 line and maybe even get into high 1e-13 territory.
There are a number of factors - (1) poor viewing - the GPS doesn't see much of the sky
This is crucial, as I discovered. I bought an NEO-M8T timing receiver thinking I would get a stable 1pps with my active antenna on the house wall under the eaves. It was facing north and could see less than half the sky, but I thought having 12 good satellite signals would be OK - wrong! The best positional accuracy I could get was 8 metres and the M8T requires 1 metre or better for a stable timing signal.
I extended the mounting bracket to give the antenna an overhead view of the sky and the difference was dramatic. It didn't bring in many more satellites but the accuracy improved to 0.75 metres.
Here are pictures of the before and after antenna mounts.
Mike
If you're on the northern hemisphere, an antenna facing north is the worst option. The further north you are, the less satellites you will have available. Find a spot with at least some visibility towards the south. A window facing to the west or east is not too bad in a pinch.
-
This is crucial, as I discovered. I bought an NEO-M8T timing receiver thinking I would get a stable 1pps with my active antenna on the house wall under the eaves. It was facing north and could see less than half the sky, but I thought having 12 good satellite signals would be OK - wrong!
Free sight to the north does not bring a lot. Looking at the map displayed
by Lady Heather, you see that the sats don't go that far north.
http://www.ke5fx.com/heather/readme.htm (http://www.ke5fx.com/heather/readme.htm)
cheers, Gerhard
-
There's still a fair amount of drift visible in the DAC data. The MDEV result reflects that. Your TIC data looks good, though. Nothing to worry about.
You have roughly one day of data in your logs (close to 80,000s ?) What you see might be a diurnal effect due to temperature changes. Plot the temperature data alongside and see if there's a correlation.
Apart from that, let me repeat: the DAC data tells you a lot about your overall system, and only very little about your output stability and accuracy.
The only independent reference you have is the GPS, so plot the TIC data instead, properly scaled (times 1e-9), imported into TimeLab as phase data. For larger "tau" you'll see it approaching the 1e-13 ranges. You have enough data to see tau=20000. MDEV should approach and maybe cross the 1e-12 line and maybe even get into high 1e-13 territory.
Thank you, that's just the nudge I needed to make some sense of it :-+.
Here are the plots you suggested. The GPSDO is enclosed in a box but the OCXO is not insulated yet and I'm not using temperature compensation (understanding that will be another question later on ;)).
Mike
-
Free sight to the north does not bring a lot. Looking at the map displayed
by Lady Heather, you see that the sats don't go that far north.
http://www.ke5fx.com/heather/readme.htm (http://www.ke5fx.com/heather/readme.htm)
cheers, Gerhard
Apologies I suffered from a brain fade. The antenna is facing east.
Mike
-
If you're on the northern hemisphere, an antenna facing north is the worst option. The further north you are, the less satellites you will have available. Find a spot with at least some visibility towards the south. A window facing to the west or east is not too bad in a pinch.
Yeah, this is my coverage, still a test setup and has to be improved with a timing antenna mounted in a better position.
[attach=1]
The satellites dont go much further north, this is 53.7N
-
Yes I found the view of the sky is important. This is not my first GPSDO, the previous one had an external antenna, but lived in the garage. If I had to update the software the CPU was pulled out, put in the programmer in the house, then back out to the garage. This one is still being refined but I am using in circuit programming permanently connected to the computer so it is in the house running off an antenna next to a window. Wonderful for rapid development but woeful for stability. I think I've nailed the control system, the refinements are to the "user interface" i.e. what the one LED is doing, and what gets logged via the serial port. I am trying for the most basic system that is still usable. So far the LED does single flash at startup, external oscillator working. Fast flashing at startup, running off internal oscillator because no external oscillator. If on external oscillator will go dead until NEMA messages are being decoded (usually a second or two) then at two second intervals flash the satellites in view. One long flash, none. One short flash, 1-3. Two flashes 4-9, three flashes 10 or more. Once the NEMA messages says the data is valid then the system enters run mode, which is where the current refinement is needed. At present it is a short flash for each valid 1ppS (received and NEMA says valid) but no indication of lock. Getting there.
-
Yes I found the view of the sky is important. This is not my first GPSDO, the previous one had an external antenna, but lived in the garage. If I had to update the software the CPU was pulled out, put in the programmer in the house, then back out to the garage. This one is still being refined but I am using in circuit programming permanently connected to the computer so it is in the house running off an antenna next to a window. Wonderful for rapid development but woeful for stability. I think I've nailed the control system, the refinements are to the "user interface" i.e. what the one LED is doing, and what gets logged via the serial port. I am trying for the most basic system that is still usable. So far the LED does single flash at startup, external oscillator working. Fast flashing at startup, running off internal oscillator because no external oscillator. If on external oscillator will go dead until NEMA messages are being decoded (usually a second or two) then at two second intervals flash the satellites in view. One long flash, none. One short flash, 1-3. Two flashes 4-9, three flashes 10 or more. Once the NEMA messages says the data is valid then the system enters run mode, which is where the current refinement is needed. At present it is a short flash for each valid 1ppS (received and NEMA says valid) but no indication of lock. Getting there.
An unobstructed all round sky view is very important for getting the best results out of any GPSDO setup. ::)
The first 5 images, attached below, show a series of u-centre sky maps after upgrading my best M8N fake module to a genuine M8T. The first is the last of a series where I'd followed the perceived wisdom of sticking to just a single constellation (GPS in this case) with the remaining four showing the GPS and Galileo constellations after I'd run tests to compare the discrepancy of the time-pulse arrival times (indirectly in my case) between the GPS and the Russian Glonas (18ns) and then the European Galileo (2 or 3 ns) constellations.
Whilst the Russian SVs offer an extra 2dB boost over the GPS signal strengths and shrink the hole in the northern sky, the larger discrepancy in the timepulse does seem to compromise the performance of the GPSDO (a modern respin of the James Miller design BTW), the Galileo constellation having more closely aligned time pulse seemed to offer an improvement so I decided to leave it setup that way for a day or two before deciding whether to stick with the perceived wisdom of using only a single constellation for best results or carry on and gain more reliable coverage out of an increased elevation filter mask angle of 30deg.
After finally getting the M8T to complete a survey in operation (I'd had to slacken my optimistic 10cm variation setting to 17cm to force it to complete the process), I'd finally been able to prove I could still get valid timing data from just a single SV alone and had initially set the elevation filter mask to 42 deg. However, with just GPS SVs, I could be left with only a single SV above the elevation mask angle setting which was a little worrying since the M8T could land up seeing only a single GPS SV that could quite easily be one marked out of service, hence a loss of 'lock' and my lowering the elevation mask setting to 30deg to avoid such an eventuality.
Adding the Galileo SVs into the mix considerably reduces the risk of having only out of service SVs above the elevation mask angle setting. Since there doesn't seem to be any degradation of timing stability over that of using only the GPS SVs alone, I've stuck with that configuration ever since.
One of the main issues with using a navigation centric GPS module like the M8N in a DIY GPSDO (whether it's a "basic" James Miller design or a properly built and configured Lars type) is the subsonic (3mHz or so) 30 to 50ns phase modulation due to the effects of the ionosphere on propagation delay. Switching to the M8T reduced such subsonic phase modulations by around an order of magnitude (a 5 to 7 ns pk to pk phase shift around the nominal 10MHz output frequency of the GPSDO).
For a very long time, I'd been trying to more accurately quantify this subsonic 'phase wobble' by using the 2G tipover effect to fine tune the OCXO in my much modified FY6600-60M AWG to simulate the stability of a RFS for an hour or two given a stable room temperature. All this "micro-management" effort eventually 'broke me' into spending almost 200 quid on an Efratom LPR101 some two months ago (not quite soon enough to test the MK I GPSDO with its M8N receiver module) and I've since been able to verify my initial guesstimate of 6 to 7ns Pk-Pk subsonic phase modulation using the M8T in the MK II design I'm currently running. One of these days, I'll resurrect that MK I on a solderless breadboard lashup to confirm my 30 to 50ns subsonic phase wobbles guesstimate .
Anyway, all of that is by way of a preamble to what the next 17 images are demonstrating (take note of the date/time shown in the bottom RH corner). I started that test run at 21:30 and only thought to start capturing screenshots some 16 minutes later. Although the sequence covers a span of 110 minutes, the whole run time amounted to 121 minutes before I quit due to the dropping room temperature resulted in a drift of frequency in the RFS which I have yet to mount into a thermostatically controlled enclosure.
CH1 is the 'wobbly' GPSDO output. CH2 is the AWG proxy for the more stable RFS which I'm triggering from to emphasise that I'm looking at the way the GPSDO is wobbling compared to an atomic reference free of the ionospheric effects afflicting the GPSDO.
Holding an independent frequency reference to within a nanosecond or two of the average frequency of a GPSDO for more than an hour at a time is a very tall order even for a temperature (and pressure) stabilised Rubidium oscillator, never mind my own setup at the mercy of room temperature variations.
Even so, I had to make good use of the FY6600-60M's external reference feature that allowed me to fine tune the RFS output in uHz increments by using the AWG as its proxy to save wearing out the RFS's trimpot. I won't be trying to fine tune the RFS any further until after I've got it safely housed in its own thermostatically controlled enclosure - the use of the AWG as a proxy, is a rather neat way to get round this, hopefully temporary, situation.
Although my initial motivation for the RFS purchase had been to provide a secondary atomic standard reference, free of the destabilising effect of the ionosphere (and by an order of magnitude less, that of the troposphere) on GPS (GNSS) derived timing and frequency standards by which to quantify these deficiencies built into the GPS/GNSS systems, I do plan to ultimately use it in this Lars based design (or something very similar).
As most of you seem to be discovering, this business of disciplining an OCXO against the flawed timing and frequency reference of a GNSS based time and frequency transfer setup, has rather too much of the "Catch 22" element to be truly trustworthy.
Even the best DOCXOs can "go rogue" from time to time and any microcontroller based setup, based on the assumption that the only variables are OCXO ageing and the effects of the ADC's tempco is almost certain to fall foul of the unpredictable behaviour of the OCXO (and room temperature on critical internal voltage rails). I plan to be as fully cognisant of the many factors that can trip up such microcontroller based solutions. Using the Lars design to control an RFS should let me neatly bypass the "rogue OCXO" issue (effectively cheating the limitations of an OCXO based solution and taking full advantage of the extremely long time constants that can be realised using a microcontroller :) )
If you haven't already tried building a basic GPSDO and examined its limitations in some detail before embarking on this Lars DIY GPSDO project, you're going to leave yourself at a disadvantage. The attached images should help demonstrate the limitations of a GPSDO based on a single frequency timing receiver. You can cheat the worst limitation by spending 200+ quid on a ZED9 module which should eliminate the ionospheric effects, leaving you just the tropospheric moisture content mediated errors to contend with (about an order of magnitude less than the ionospheric effect).
I've just hit the new reduced from 25 to 10 attachments limit (along with the reduced from 5000KB to 4000KB individual size - not an issue in this case). It seems I'll have to make another two supplementary posts to send all 22 images (1.9MiB in total).
John
-
Another ten images >:D
-
Last two images >:D >:D >:D
-
Even the best DOCXOs can "go rogue" from time to time and any microcontroller based setup, based on the assumption that the only variables are OCXO ageing and the effects of the ADC's tempco is almost certain to fall foul of the unpredictable behaviour of the OCXO (and room temperature on critical internal voltage rails). I plan to be as fully cognisant of the many factors that can trip up such microcontroller based solutions. Using the Lars design to control an RFS should let me neatly bypass the "rogue OCXO" issue (effectively cheating the limitations of an OCXO based solution and taking full advantage of the extremely long time constants that can be realised using a microcontroller :) )
I don't know if I am missing something somewhere, but the majority of designs I've seen use a phase locked loop in hardware or software. I thought this is a flawed approach because the OCXO has to follow deviations of the GPS signal to some extent. A short time constant catches the rogue but wobbles about. The long time constant wobbles less (but still does to some extent) but can't catch the rogue. The approach I use is to let the OCXO 'free run' with a fixed control voltage and collect the second to second deviations of the 1ppS from expected. The particular design I outlined above measures arrival to within 25nS and the software attempts to steer the OCXO such that half the 1ppS arrive early and half late on average. The arrival times are averaged using least squares linear interpolation to arrive at an estimated deviation from desired, and if this is too great a correction is applied to the control voltage to reverse the drift. The calculation is done every second from 5 to 8 seconds, then every 2 seconds from 10 to 16, every 4 seconds from 20 to 32 and so on up to every 256 seconds from 1024 to 2048 seconds. If the OCXO is still within limits a correction is applied anyway (unless there is no deviation at all).
As the calculation period extends, the allowable deviation is reduced. This presumes that the statistical average of many measurements is more accurate than one measurement. This tactic catches rogue events, and for changes of less than 1Hz will adjust the control voltage accordingly. That is a programming consideration mainly due to needing more arithmetic precision to cater for huge changes and not lose detail for tiny adjustments.
I had assumed (make an ass of u and me) that the GPS averaged over 2000 seconds would be highly accurate but talk of a 3mHz subsonic wobble worries me. I thought the design of the GPS system was such that this didn't happen - a spatial fix estimated from 3 satellites and compensation applied by using more satellites. The software uses a diminishing error limit, in testing so far (i.e real life) it has managed a few times to run to 64 second testing intervals (which starts after 256 seconds) with a limit of 1/16th cycle deviation. That's getting below 1 x 10^-10 deviation, not bad for such a cheap setup. And that is the intent of this exercise, a usable system with the least components.
Another thing I can't get my head around is Allan deviation. If the phase of the oscillator is locked in the long term to the GPS (mine is), the plot seems almost meaningless except for the first few seconds. Of course the long term plot shows that the oscillator is following the GPS faithfully. Or is there something more meaningful.
Regarding temperature stability, I found this to be the limiting factor with my first attempt. The OCXO was a Morion MV89 and I believe it was not affected by temperature. However, the control voltage was buffered through an op amp and I think it was a problem. Note the current design derives the control voltage directly from the PWM through a fairly low resistance network. For the next effort I intend to buffer this through a 2N7000 BF250 (I think that's the one) pair, sourcing their voltage from a MAX6350CPA+ which claims to be stable to 1ppm/C. I have the MAX6350CPA+ on order, costs more than all the components of the circuit above put together. We shall see.
-
@MIS42N
That issue with subsonic phase shifts due to ionospheric disturbances is the main (and inescapable) problem with GNSS based GPSDOs relying on single frequency receivers regardless of whether they're microcontroller based or a simple hardware PLL setup. Dual frequency GPS timing receivers such as that ZED9 I mentioned can all but eliminate the ionospheric errors but that still leaves the effect of the precipitable moisture content in the troposphere (rain clouds?) which, fortunately is about an order of magnitude lower.
Given a long enough time constant and a stable enough oscillator (a DOCXO or a RFS), it becomes possible to average out these short term perturbations. If you can average over a full 24 hour period, you can get very close to the 1E-14 limit of the GNSS ground based master clocks. This is where a microcontroller based system using Kalman filtering comes into its own but care has to be taken to account for every contingency that the traditional basic hardware PLL designs can effortlessly take in their stride (at least over time constants in the range 100 to 5000 seconds, given a stable enough oscillator to discipline).
When it comes to disciplining a RFS, a microcontroller based solution is the only viable way to obtain the full benefit which is why I'm keeping a close eye on this topic thread. I'm not sure why a 3mHz 6 to 7ns wobble should be a worry since that represents a cycle time between a pk to pk excursion and back of around 5 minutes or so. It's rather random in nature but the higher frequency components of this phase wobble have much lower amplitude and the lower frequency components disappear into the 'noise floor' of the system anyway.
They're only a problem when you're trying to calibrate a free running 10MHz OCXO in less than half an hour or if you plan on using it as a reference to drive transverters beyond the 1GHz mark to operate in the microwave bands using slow data rate narrow band digital communication modes. Slow rate 5Hz deviations of carrier frequencies can be readily tolerated when using SSB voice communications, allowing operation in this case up to 10GHz and beyond.
Choosing the optimum time constant depends entirely on the stability of the oscillator's behaviour. You might expect an OCXO to be pretty immune to external temperature variations but once you start chasing after parts per trillion accuracy, you soon discover the effect of temperature on the humble OCXO leaving you hankering after a high quality DOCXO upgrade or even a suitable RFS. ::)
You mentioned the expense of a good voltage reference (MAX6350CPA+) so, despite the fact that you've already got one on order, I think it's worth considering the temperature stabilised voltage reference available from the better quality OCXOs which provide this on their Vref pin. Even if this comes from a humble LDO supplying the oscillator and the oven controller, it's worth considering that, once warmed up to temperature, it's supplying a constant current and its internal reference is temperature stabilised making it only second in stability to that of an expensive lab standard (at least for use with a low constant current external load such as the 1mA of my reference voltage supply).
I'm taking advantage of the Vref pin on the CQE 12v 10MHz OCXO to provide a DC offset voltage in 1v steps via a string of matched 1K resistors fed via a 120ohm resistor from the Vref pin to allow me to monitor the EFC voltage in tenths of a millivolt using a cheap (13 quid) Mestek 9999 counts meter to measure the 408.7mV difference between the 2 volt tap and the EFC pin, effectively saving me the expense of a 5 1/2 digit bench meter costing around 450 quid. It's not so much the absolute accuracy of this 2v dv offset so much as its stability. The important aspect of this measurement being that I can monitor the variations in 100uV increments and be able to trust that the only changes are due solely to the variation in EFC voltage with very little to none at all from my 2v offset reference.
I'm only using it as a means of saving the need for an expensive bench meter to monitor the EFC pin voltage but if I needed an extremely stable 5 or 3.3 volt rail to supply a DAC or a buffer to a PWM DAC signal, I could simply use a cheap cmos RRO opamp as a voltage follower to drive sub 50mA loads in this case.
I've set the buck converter, which allows my GPSDO to run off cheap wallwarts over an input voltage range of 6.8 to 24 volts at 1.4W (warmed up), to output 5.17v onto the Vcc rail. This slightly higher Vcc voltage was chosen primarily to allow a cmos RRO opamp to buffer the EFC input over the range 0.1 to 5 volts but could also allow the use of another such opamp to supply sub 50mA loads at a regulated 5 volt if such a need where to ever arise. In the case of a maximum of 100nA meter current, there simply was no need to buffer the multitapped potentiometer supplying dc offsets in one volt steps (0, 1, 2, 3 and 4 volt taps).
Any modest dc offsets and temperature drift effects in the buffer amp driving the EFC line are totally irrelevant in a basic hardware PLL controlled OCXO design since the negative feedback mode of such a basic PLL automatically compensates for any such offsets. The only effect visible when I forced the GPSDO to be raised in temperature by some 7 degrees was a modest 1mV drop in the EFC voltage, leaving the frequency output untouched. Undoubtedly the combined effect of an external temperature increase upon the OCXO and changes to the opamp's dc offset causing it to reduce the EFC voltage to maintain lock with the 100KHz output on the PPS line from the M8T module.
When you're trying to use very long integration times in a microcontroller based design to reduce the phase shift wobbles of the GNSS system, you need to compensate for any such external temperature shifts to maintain stability and this is often easier said than done. However, the rewards for getting this right is not only better performance given a decent oscillator worthy of such effort but also a more effective hold-over performance in the event of loss of GPS lock compared to the more limited hold-over performance, if any, of a basic hardware PLL design.
Those screenshots I posted represent the actual performance compared to a RFS free of the effects of ionospheric disturbances which effect all GPSDO designs to a greater or lesser degree. In effect it's "a cut to the chase" bypassing all the trivia of Adev and Mdev plots typically used to describe the performance. Basically, it's a "No Frills" representation of how a GPSDO is actually performing, given an accurately calibrated reference. It would be interesting to see how some of these Lars based GPSDOs compare using this same "No Frills" approach. :)
John
-
May I jump in with a quick question about temperature compensation?
I know how to calculate tempCoeff, but what's the best way to establish the number of DAC steps per degC?
I've been studying my logs and can't get a consistent answer.
Thanks,
Mike
-
A linear regression. Plot DAC output vs. temperature, feed it into a linear regression solver, this gives you the coefficient. make sure your correlation "r" is high enough, > 0.9 would be perfect.
-
A linear regression. Plot DAC output vs. temperature, feed it into a linear regression solver, this gives you the coefficient. make sure your correlation "r" is high enough, > 0.9 would be perfect.
Perfect, thank you :-+.
Since I optimised the time constant (now 300 seconds) the DAC is much better behaved which should make it easier.
Mike
-
Choosing the optimum time constant depends entirely on the stability of the oscillator's behaviour. You might expect an OCXO to be pretty immune to external temperature variations but once you start chasing after parts per trillion accuracy, you soon discover the effect of temperature on the humble OCXO leaving you hankering after a high quality DOCXO upgrade or even a suitable RFS. ::)
You mentioned the expense of a good voltage reference (MAX6350CPA+) so, despite the fact that you've already got one on order, I think it's worth considering the temperature stabilised voltage reference available from the better quality OCXOs which provide this on their Vref pin. Even if this comes from a humble LDO supplying the oscillator and the oven controller, it's worth considering that, once warmed up to temperature, it's supplying a constant current and its internal reference is temperature stabilised making it only second in stability to that of an expensive lab standard (at least for use with a low constant current external load such as the 1mA of my reference voltage supply).
By going down the non PLL route, there is no optimum time constant. The processor collects noisy error information every 1ppS, averages it, and determines if the error is 'big enough' to require a correction. 'Big enough' starts off large (my current version starts at around 1Hz error from 5 samples) and becomes smaller as more samples are collected (down to .0003Hz from 2000 samples). This is consistent with applying statistics to the short term jitter of the 1ppS from a cheap GPS module. Any misbehaving by the oscillator is caught in the process.
As I mentioned in previous post, I will be using a used Morion MV89 DOCXO in the next version. It was used in my first attempt at a GPSDO. Its performance is way better than OSC5A2B02 as you would expect. The whole point of the circuit I published was to show how few low cost components could still make a working GPSDO. I have no real interest in using a GPSDO, I like the technical challenge of trying different strategies to see what can be achieved.
I couldn't find any details of the stability of the Vref pin on the Morion. The MAX6350CPA+ claims "Ultra Low, 1ppm/°C Max Tempco". The sensitivity of the OSC5A2B02 is determined as approx 0.1V/Hz with a lock voltage of around 2V. The Morion is advertised as 1V/Hz and its lock voltage was around 2V also. So the MAX6350CPA+/MV89 combo should have a sensitivity of around 2*10^-13/°C which may be good enough. I don't have the equipment to determine if this is better or worse than using the Vref.
-
I have some questions for the experts please. Sorry if they are a bit basic :-[
I insulated my OCXO with closed cell foam and ran the GPSDO for 5 days, results below.
(The glitch at 1.35x105 seconds occurred when I fired up my 100 watt HF transmitter in close proximity :palm:).
Here are my questions:
- The MDEV and Frequency Difference plots were derived from diff_ns. Is that correct?
- Any comments on the performance (good/average/try again)?
- I presume the downwards DAC drift is due to aging?
- It looks to me as if the swings in diff_ns might be inversely proportional to temperature but there's no correlation with the DAC, so how do I determine tempCoeff?
Thanks!
Mike
-
I have finally started building my first unit (after being FAR too busy at work for several months).
QUESTION: Has anyone else built a unit with sinewave 10MHz output? I wanted to use the Morion MV85 that @Thinkfat suggested might be a good first choice.
But since it is sine instead of square, I can't use a digital output buffer like the 74HC14 or 74AC04. I am guessing I need a high speed op-amp buffer circuit?
Does anyone have an example output buffer for sine that is known to work well?
[If not, I also have several sqaure wave OCXO, so I could start there if needed]
Opinions, ideas?
Thanks,
Neal
-
I have finally started building my first unit (after being FAR too busy at work for several months).
QUESTION: Has anyone else built a unit with sinewave 10MHz output? I wanted to use the Morion MV85 that @Thinkfat suggested might be a good first choice.
But since it is sine instead of square, I can't use a digital output buffer like the 74HC14 or 74AC04. I am guessing I need a high speed op-amp buffer circuit?
Does anyone have an example output buffer for sine that is known to work well?
[If not, I also have several sqaure wave OCXO, so I could start there if needed]
Opinions, ideas?
Thanks,
Neal
http://www.wriley.com/A%2010%20MHz%20OCVCXO%20and%20PLL%20Module.pdf (http://www.wriley.com/A%2010%20MHz%20OCVCXO%20and%20PLL%20Module.pdf)
Take a look at some of the buffers in the doc above.
-
- The MDEV and Frequency Difference plots were derived from diff_ns. Is that correct?
- Any comments on the performance (good/average/try again)?
- I presume the downwards DAC drift is due to aging?
- It looks to me as if the swings in diff_ns might be inversely proportional to temperature but there's no correlation with the DAC, so how do I determine tempCoeff?
Thanks!
Mike
Use TIC data instead of diff_ns for the MDEV. I cannot say a lot about the performance until I see that graph. The diff_ns MDEV indicates though that it's in a very acceptable range regarding long-term stability. Nice straight descend into the 1e-13 range with not much ripple. TIC value range looks good, too, +/- 20ns is absolutely normal with a timing receiver, which I believe you are using.
The DAC curve indicates still accelerated aging, yes. OCXO has still not settles, I think, but keep in mind that you have a very sensitive instrument to measure it.
I cannot see first glance a temperature dependency between the DAC and the temperature. Maybe it's still shadowed by the OCXO aging/settling curve. At least it is not very pronounced.
-
I have finally started building my first unit (after being FAR too busy at work for several months).
QUESTION: Has anyone else built a unit with sinewave 10MHz output? I wanted to use the Morion MV85 that @Thinkfat suggested might be a good first choice.
But since it is sine instead of square, I can't use a digital output buffer like the 74HC14 or 74AC04. I am guessing I need a high speed op-amp buffer circuit?
Does anyone have an example output buffer for sine that is known to work well?
[If not, I also have several sqaure wave OCXO, so I could start there if needed]
Opinions, ideas?
Thanks,
Neal
I'm using the attached circuit derived from discussions with @imo. Basically a biased inverter gate with a tuned tank circuit. R6 is 49.9 Ohm actually, not 0 Ohm.
-
Use TIC data instead of diff_ns for the MDEV. I cannot say a lot about the performance until I see that graph. The diff_ns MDEV indicates though that it's in a very acceptable range regarding long-term stability. Nice straight descend into the 1e-13 range with not much ripple. TIC value range looks good, too, +/- 20ns is absolutely normal with a timing receiver, which I believe you are using.
The DAC curve indicates still accelerated aging, yes. OCXO has still not settles, I think, but keep in mind that you have a very sensitive instrument to measure it.
I cannot see first glance a temperature dependency between the DAC and the temperature. Maybe it's still shadowed by the OCXO aging/settling curve. At least it is not very pronounced.
Thank you! :-+ :-+ :-+
Yes I am using a NEO-M8T. Here's the MDEV plotted from TIC.
Mike
-
OK, it seems like the TIC data is smoothed, is that correct? So it makes the curve look better than expected, for small "tau". But nevertheless, the long-term stability looks pretty good. diff_ns looks worse for small tau; I guess it isn't as heavily filtered. It's closer to the GPS.
Of course the proof will be measurement against a very stable external source, with an instrument that has a noise floor in the 1e-12 range @1s at least. If you want to go that route, look into DMTD systems. If not, it's probably the end of the journey for you ;)
-
I have finally started building my first unit (after being FAR too busy at work for several months).
QUESTION: Has anyone else built a unit with sinewave 10MHz output? I wanted to use the Morion MV85 that @Thinkfat suggested might be a good first choice.
But since it is sine instead of square, I can't use a digital output buffer like the 74HC14 or 74AC04. I am guessing I need a high speed op-amp buffer circuit?
Does anyone have an example output buffer for sine that is known to work well?
[If not, I also have several sqaure wave OCXO, so I could start there if needed]
Opinions, ideas?
Thanks,
Neal
Take a look at replies # 70, 73 & 131 in this thread and here:
https://gerrysweeney.com/build-a-10mhz-rubidium-frequency-standard-and-signal-distribution-amp-for-my-lab/
-
No I didn't apply any corrections to the MDEV.
Mike
-
OK, it seems like the TIC data is smoothed, is that correct? So it makes the curve look better than expected, for small "tau". But nevertheless, the long-term stability looks pretty good. diff_ns looks worse for small tau; I guess it isn't as heavily filtered. It's closer to the GPS.
Of course the proof will be measurement against a very stable external source, with an instrument that has a noise floor in the 1e-12 range @1s at least. If you want to go that route, look into DMTD systems. If not, it's probably the end of the journey for you ;)
Sorry I meant to Quote instead of Reply!
I didn't apply any correction to the MDEV.
My use for this is occasional calibration of a frequency counter and HF radio equipment, so perhaps it's good enough?
Mike
-
====snip====
My use for this is occasional calibration of a frequency counter and HF radio equipment, so perhaps it's good enough?
Mike
Seeing as how nobody bothered to answer this (and I'm now at a bit of a loose end awaiting the imminent delivery of an SSA3021X+), I'll chuck in my tuppence worth:
If you're only going to use it as a calibration test signal, even just the 10MHz output on the PPS pin of a u-blox M8N will more than suffice on its own.
For calibrating an HF receiver or transceiver, even better would be to tune into the third harmonic of the 10MHz square wave output onto the PPS pin which will be of much better quality, despite the non-integer divide jitter from the M8N's 48MHz clock and the sawtooth correction clicks that afflict the raw PPS signal, than what you can ever hope to get from WWV 10MHz in the UK and Europe during this period of low sunspot activity (2020AD).
For that matter, it'll provide a better calibration source even during sunspot maxima simply because the jitter/sawtooth noise is a much better trade off against the random skywave propagation delays and associated phase cancellation effects inherent to all such long distance HF broadcast reference standards.
You only need to bother disciplining an OXCO with a timing GPS receiver module when you need an accurate and stable lab reference to lock T&M kit clocks to or when using transverters to work the GHz bands using SSB or the even more critically narrower BW data modes (or when partaking of the simple pleasure of time nuttery :) ).
John
-
If you're only going to use it as a calibration test signal, even just the 10MHz output on the PPS pin of a u-blox M8N will more than suffice on its own.
For calibrating an HF receiver or transceiver, even better would be to tune into the third harmonic of the 10MHz square wave output onto the PPS pin which will be of much better quality, despite the non-integer divide jitter from the M8N's 48MHz clock and the sawtooth correction clicks that afflict the raw PPS signal, than what you can ever hope to get from WWV 10MHz in the UK and Europe during this period of low sunspot activity (2020AD).
For that matter, it'll provide a better calibration source even during sunspot maxima simply because the jitter/sawtooth noise is a much better trade off against the random skywave propagation delays and associated phase cancellation effects inherent to all such long distance HF broadcast reference standards.
You only need to bother disciplining an OXCO with a timing GPS receiver module when you need an accurate and stable lab reference to lock T&M kit clocks to or when using transverters to work the GHz bands using SSB or the even more critically narrower BW data modes (or when partaking of the simple pleasure of time nuttery :) ).
John
Thanks for that John.
I can receive WWV in the early hours of the morning, but as you say the atmospherics limit its usefulness.
I'm aware that the u-blox timing signal can be reprogrammed to 10MHz but was put off by the reports of jitter which is when I came across the GPSDO concept, and was taken by the simplicity of the Lars design. I proceeded to ignore the warnings about how addictive the search for perfection would become ...
So yes, it's more than I need but it's been an interesting and educational experience. I shall stop when I've cracked the temperature compensation :)
Mike
-
By definition, if you cannot "see" the GPSDO instability or accuracy with the test equipment you have, it's axiomatically good enough.
-
I have finally started building my first unit (after being FAR too busy at work for several months).
QUESTION: Has anyone else built a unit with sinewave 10MHz output? I wanted to use the Morion MV85 that @Thinkfat suggested might be a good first choice.
But since it is sine instead of square, I can't use a digital output buffer like the 74HC14 or 74AC04. I am guessing I need a high speed op-amp buffer circuit?
Does anyone have an example output buffer for sine that is known to work well?
[If not, I also have several sqaure wave OCXO, so I could start there if needed]
Opinions, ideas?
Thanks,
Neal
In my first attempt at a GPSDO, I used a sine wave output OCXO, and wanted to use the output as a clock to the microprocessor. This circuit worked because there's no input hysteresis. The 74LS04 switches around 1.1V and for a 50/50 duty cycle the output should average around 2.5V. Hence the string of resistors.
-
I posted a circuit a few days back, maybe people would like to know how it performs. Better than I expected. The OCXO is allowed to drift in the short term but the control voltage is altered to bring it back into phase at intervals. I've attached a days worth of adjustments, a lot of the time it jumps around (due, I think, to GPS having a poor view of the sky) but sometimes (e.g. 172518 UTC to 182501 UTC) it doesn't need adjusting and one assumes is accurate to 10 digits. I have an external antenna on order, see how it goes with that fitted. The 1ppS is captured by a comparator and timer latch in the PIC16F1455, it is good to 25nS. The timer is 16 bit so captures any reasonable frequency swing. The software steers the phase to try and see jitter in the 1ppS, and cheap GPS modules oblige. The processor decodes all the NEMA messages from the GPS, mainly to see if the GPS data is valid. But it also allows the output to be timestamped. The control voltage is dithered at 40kHz so emulates a 24 bit DAC, The output impedance is low (12k \$\Omega\$) which should be low enough to minimise noise pick up and drive most OCXOs.
The adjustment list is a sample of the output from the serial port. It actually logs a lot more data, I extracted the adjustments. The method used requires that the sensitivity of the OCXO to changes of control voltage be known. This is achieved in a calibration run of a couple of hours then written to permanent memory for use on subsequent starts. Knowing the sensitivity means the logged adjustments can be reported by the processor in ppb (1 part in 10^-9).
This is still a work in progress. I hope to interest some local radio amateurs who may come up with a PCB design. And a scheme to output the 10MHz.
-
I have attached two sets of results, first for the GPSDO with no temperature compensation, the second with an initial stab at compensation.
The second certainly looks more stable apart from during the overnight temperature drop. Any suggestions for improving this?
Mike
-
I highly recommend you use a small PID controlled fan to control the temperature of the enclosure as I described many posts ago now.
It can keep the inside temperature within fractions of a degree, thereby removing room temperature effects on the OCXO. With that, there is no need to embark on the compensation, which I found rather cumbersome and indirect.
Details can be found on my own blog : http://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html (http://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html)
The modifications for the Lars firmware to do that are available on my Github, the link is on the bottom of that Blog.
Enjoy!
-
Hi Paul, I have read your blog and I thought you might pop up with this advice :)
However given that my needs for this device are not too onerous I'd like to avoid further complication, power consumption and fan noise if possible.
Maybe I'll just avoid using it during the hours of darkness ;D
Mike
I highly recommend you use a small PID controlled fan to control the temperature of the enclosure as I described many posts ago now.
It can keep the inside temperature within fractions of a degree, thereby removing room temperature effects on the OCXO. With that, there is no need to embark on the compensation, which I found rather cumbersome and indirect.
Details can be found on my own blog : http://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html (http://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html)
The modifications for the Lars firmware to do that are available on my Github, the link is on the bottom of that Blog.
Enjoy!
-
I know you did Mike ;)
My advice was more for those that didn't go through the whole Blog (yet).
-
The second certainly looks more stable apart from during the overnight temperature drop. Any suggestions for improving this?
I noted somewhere in your previous comments you were looking for "good enough". I have played with this for a few years now, my conclusion is just about any reasonable setup will lock the frequency within 1 part in 10^-9 (or 1Hz/GHz). I talked to some amateur radio people and they said that was good enough for digital working at GHz frequencies. The next step is 1 part in 10^-10 and with a bit of care and decent oscillator is not too hard. This is equivalent to +- 360 degrees phase shift in about 17 minutes. A cheap GPS module will claim most 1ppS within 100nS (equivalent to a spatial fix within 30m) so not unreasonable. And most reasonable OXCO will show negligible drift in that time.
Getting below 1 part in 10^-10 is not so easy. Temperature plays a part and I found that different components appeared to react differently to the rate of change of temperature. So compensating for a particular temperature was partially successful but not the whole story. The answer of course is to ensure the whole kit runs at constant temperature. Then there's the power supply. In my previous rig I used a 17V switch mode supply (old laptop supply) then linear regulators from that to feed various sections of the circuit. Also careful earth wiring, there was a single earth connection between the oscillator and its 12V supply and the microprocessor and its supply. This seemed pretty stable. The rig I described above uses a 5V switch mode but was never intended to be a high performing device - 10^-9 territory.
And unless you have the capacity to average a day's worth of GPS data, a special GPS is highly desirable. My understanding is the same satellites are in the same position in 1 sidereal day (about 23 hours 56 minutes) so one day should be similar to another.
My current thinking is if something consistently better than 1 part in 10^-11 is desired, then run 3 oscillators and have an arbitration system to pick up oscillator glitches. It is unlikely two oscillators glitch at the same time so it should be clear if a glitch is due to the GPS or the oscillator. Glitches occur in the first few months of running a really good double oven OCXO, changes in the mounts, lost mass from the crystal etc. After that they have a fairly consistent ageing which requires a tweak of the control voltage at intervals. I had the job of correcting a standards laboratory oscillator, every week it was calibrated for an hour against a cesium beam. Each day an adjustment was applied on the basis of known drift. The difference at the start of a new week between the adjusted oscillator and the beam was usually below 10^-13.
So that's my thoughts. What's your target? what are you going to be happy with?
-
Hi Paul, I have read your blog and I thought you might pop up with this advice :)
However given that my needs for this device are not too onerous I'd like to avoid further complication, power consumption and fan noise if possible.
Maybe I'll just avoid using it during the hours of darkness ;D
Mike
I highly recommend you use a small PID controlled fan to control the temperature of the enclosure as I described many posts ago now.
It can keep the inside temperature within fractions of a degree, thereby removing room temperature effects on the OCXO. With that, there is no need to embark on the compensation, which I found rather cumbersome and indirect.
Details can be found on my own blog : http://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html (http://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html)
The modifications for the Lars firmware to do that are available on my Github, the link is on the bottom of that Blog.
Enjoy!
What I do as a sanity check is run the DAC values through timelab and check the ADEV or MDEV. While this doesn't yield "real" stability values for the output, it gives some kind of "noise floor" for your system. In other words, whatever comes out of the GPSDO, it will never be _better_ than what you see in the DAC ADEV. So, if you have something in the 10-10 range @1s, you know that your output will never reach 10-11.
-
So that's my thoughts. What's your target? what are you going to be happy with?
I'm using a timing receiver and external antenna which give me a positional accuracy of better than 1 metre. The OCXO is a new old stock Vectron that has been running for about 3 months. It claims +/-10ppb stability over 0-70degC and +/-1ppb aging per day.
The most accurate piece of kit I have is a 9-digit Racal 1991 frequency counter, so calibrating that would be my ultimate goal. I would then be using that to calibrate HF transmitters and receivers, so nothing too demanding.
Mike
-
So that's my thoughts. What's your target? what are you going to be happy with?
I'm using a timing receiver and external antenna which give me a positional accuracy of better than 1 metre. The OCXO is a new old stock Vectron that has been running for about 3 months. It claims +/-10ppb stability over 0-70degC and +/-1ppb aging per day.
The most accurate piece of kit I have is a 9-digit Racal 1991 frequency counter, so calibrating that would be my ultimate goal. I would then be using that to calibrate HF transmitters and receivers, so nothing too demanding.
Mike
If you are feeding your output to the Racal, after it has had an hour or two to warm up, I would expect the reading to be stable, maybe varying the last digit by 1, no more. It may not be accurate, but it should be stable. What you describe is capable of 10 digit accuracy and if you aren't getting it then something is wrong. But sorting out if it is instability in the Racal, or something else, might require another frequency counter. Sounds like you are where you want to be. Congrats.
-
If you are feeding your output to the Racal, after it has had an hour or two to warm up, I would expect the reading to be stable, maybe varying the last digit by 1, no more. It may not be accurate, but it should be stable. What you describe is capable of 10 digit accuracy and if you aren't getting it then something is wrong. But sorting out if it is instability in the Racal, or something else, might require another frequency counter. Sounds like you are where you want to be. Congrats.
Thanks :-+ All due the the excellent assistance from the experts on this forum.
My default position is "near enough is good enough" but unfortunately I have a streak of perfection and the shift due to the overnight drop in temperature annoys me.
Mike
-
I have a streak of perfection and the shift due to the overnight drop in temperature annoys me.
Mike
Could it be variation in supply voltage? It may be non linear so simple temperature compensation wouldn't work. I think someone previously said plot the average DAC against temperature. I did it with my last rig, fed the dac/temp into a spreadsheet, created a plot. You may see a trend. To make sense of it, I asked for least squares linear interpretation. Might be an exercise in frustration, it was for me. Good luck.
-
So that's my thoughts. What's your target? what are you going to be happy with?
I'm using a timing receiver and external antenna which give me a positional accuracy of better than 1 metre. The OCXO is a new old stock Vectron that has been running for about 3 months. It claims +/-10ppb stability over 0-70degC and +/-1ppb aging per day.
The most accurate piece of kit I have is a 9-digit Racal 1991 frequency counter, so calibrating that would be my ultimate goal. I would then be using that to calibrate HF transmitters and receivers, so nothing too demanding.
Mike
Those temperature stability figures seem outrageously high for any OCXO of worth to my mind. Quite frankly, I'm surprised no one else has picked up on those figures. TBH, those figures look more in line with that of a TCXO than an OCXO.
The CQE 10MHz OCXOs I'm using (going by the temperature and ageing stability of the one used in my FY6600) are at least an order of magnitude better on temperature stability (admittedly only a guesstimate) and a good two orders better on ageing.
I installed a small 12v 6W smpsu board removed from a Linksys wallwart into the AWG to power the OCXO independently of the power up/down state of the AWG itself in order to keep retrace and protracted power on warm up at bay (it takes just 1.3W off the mains supply to keep it at temperature), versus the 5 to 6 watts 'standby power' of an 8 watt AWG switched into 'standby mode').
I've got it wrapped in a sponge rubber overcoat to protect it from cooling fan turbulence and to knock about 100mW off its naked 850 to 900mW consumption. Even so, it still surprisingly shows a two or three hour warm up drift of circa 150ppt due to powering the AWG up from stone cold.
When I was trying to use it as a substitute RFS by micromanaging its small shifts in frequency due to changes of room temperature using the 2GT effect by altering the tilt angle. Whatever daily ageing it had, seemed to be swamped by the room temperature variations. There was no discernible change of an average angle of dangle requirement from day to day over periods of a week or more. I rather suspect it had been a matter of pure dumb luck that I'd picked out that single OCXO from a collection of seven which happened to have a very low ageing rate. :)
Now that I have a real RFS to test my basic GPSDO against (essentially a modern respin of the James Miller design taking advantage of an M8T to simplify the design a little more), I no longer obsess about the stability of the FY6600's OCXO upgrade which now includes an external 10MHz reference input socket to injection lock the OCXO, specced to lock within +/-10ppb of the OCXO's frequency (I consider an error of 1ppb to be 'beyond the pale', requiring an immediate recalibration to get it back within 100ppt of my GPSDO reference).
From casual observation of the GPSDO's behaviour during the ten or so minutes post OCXO warm up, these CQE OCXOs look to have a 2 to 3 Hz per volt tuning rate equating to a 3mHz per millivolt change in the VFC voltage. Making some basic test measurement with my current MK II GPSDO, I see a VFC voltage change of roughly 100uV per degree C change in external case temperature equating to an uncorrected variation of some 2 or 3 ppb for a 70 deg C room temperature delta.
In the case of a James Miller respin, such external temperature variations are of no to little consequence in frequency stability even under the more extreme ambient temperature variations typical of a home environment. Of greater significance in a GPSDO relying on a single frequency GPS receiver such as the M8T, are the minutes to minutes variation in phase due to variations in the electron density of the ionosphere, typically +/- 3 to 5ns over periods of 5 to 15 minutes or so.
I had been running my setup using both the GPS and the Galileo constellations in recent weeks where the phase variation would keep within +/- 3ns for hour long periods before ambient temperature changes took their toll on my naked, yet to be installed in a thermally regulated enclosure, RFS. About a week ago, I decided to remove the Galileo constellation to see whether there would be any improvement using only the GPS constellation. My impression so far is that, if anything, there has been a slight but definite deterioration in regard of ionospheric induced phase variations.
I'll be trying the effect of using the Galileo constellation on its own but it has now become obvious that I really need to stabilise the base plate temperature of my RFS before I can get more reliable data on this issue of ionospheric perturbations which leaves me pondering the best way to achieve such thermostatic control... I'm still pondering. ::)
John
-
Could it be variation in supply voltage? It may be non linear so simple temperature compensation wouldn't work. I think someone previously said plot the average DAC against temperature. I did it with my last rig, fed the dac/temp into a spreadsheet, created a plot. You may see a trend. To make sense of it, I asked for least squares linear interpretation. Might be an exercise in frustration, it was for me. Good luck.
I'm running the GPSDO off a 15V linear power supply that came with a GPS amplified splitter unit. The GPSDO itself contains the usual assortment of LM7805/LM7808/LM78L05/REF02EZ regulators.
I didn't see a trend when I plotted DAC vs temp but I'm doing another uncompensated run and will try again shortly.
Mike
-
Those temperature stability figures seem outrageously high for any OCXO of worth to my mind. Quite frankly, I'm surprised no one else has picked up on those figures. TBH, those figures look more in line with that of a TCXO than an OCXO.
Well, it's marked MC2001X4-046W and I found the attached data sheet which I presume is applicable.
I measured the tuning range from 0 to 4V as 1.8ppm which according to the data sheet denotes an SC cut crystal.
That's pretty much all I know about it.
Mike
-
Those temperature stability figures seem outrageously high for any OCXO of worth to my mind. Quite frankly, I'm surprised no one else has picked up on those figures. TBH, those figures look more in line with that of a TCXO than an OCXO.
Well, it's marked MC2001X4-046W and I found the attached data sheet which I presume is applicable.
I measured the tuning range from 0 to 4V as 1.8ppm which according to the data sheet denotes an SC cut crystal.
That's pretty much all I know about it.
Mike
I downloaded that document and compared it to other OCXO datasheets. It seems comparable to other makes, reminding me just how generously wide a tolerance the "OCXO Club" gives its products to forestall any customer complaints of the product failing to meet specifications.
I think you'll find it'll more than exceed its given specification in actual use simply because those specifications are so far from being 'Stellar'. I daresay the specifications for my collection of CQE 10MHz OCXOs will show similarly wide tolerance figures should I ever track down any datasheets for these now obsoleted by successive changes of manufacturing ownership. Still, if they were deemed good enough to go into Symmetricom GPS time and frequency reference kit, then that's good enough for me. :)
John
-
I downloaded that document and compared it to other OCXO datasheets. It seems comparable to other makes, reminding me just how generously wide a tolerance the "OCXO Club" gives its products to forestall any customer complaints of the product failing to meet specifications.
I think you'll find it'll more than exceed its given specification in actual use simply because those specifications are so far from being 'Stellar'. I daresay the specifications for my collection of CQE 10MHz OCXOs will show similarly wide tolerance figures should I ever track down any datasheets for these now obsoleted by successive changes of manufacturing ownership. Still, if they were deemed good enough to go into Symmetricom GPS time and frequency reference kit, then that's good enough for me. :)
John
I also have an NDK END3032A which came out of an IFR2025 signal generator but it's impossible to find any data for it other than what's quoted in the signal generator manual, which is:
Aging rate: Less than±2.5 in 107 per year, less than ±5 in 109 per day after 2 months’ continuous use.
Stability: Better than ±5 in 108 over the temperature range 0 to 50°C.
Mike
-
I've just discovered something interesting ...
All my previous measurements were taken with the NEO-M8T tracking three satellite systems: GPS, Galileo & Glonass.
I ran the GPSDO for 2 days with no temperature compensation and only GPS enabled and the results appear to be much better.
Why would that be?
Mike
-
I suspect mainly on account you dropped the glonass constellation from your bouquet of SVs. >:D
If you add the Galileo constellation to the GPS one, you may find a slight improvement over just the GPS alone. However, that's just the impression I get after switching to GPS only a week or two back after running with both Galileo and GPS for about a month or so.
It could simply be the greater room temperature variations afflicting my Rubidium reference by which I've been monitoring the ionospheric induced phase shifts on the GPSDO's 10MHz output which arose when I decided to go solo with the GPS constellation - bad timing on my part and I'm now more actively interested in giving my RFS a thermostatically controlled enclosure to eliminate the effect of room temperature variations. ::)
John
-
I suspect mainly on account you dropped the glonass constellation from your bouquet of SVs. >:D
If you add the Galileo constellation to the GPS one, you may find a slight improvement over just the GPS alone. However, that's just the impression I get after switching to GPS only a week or two back after running with both Galileo and GPS for about a month or so.
It could simply be the greater room temperature variations afflicting my Rubidium reference by which I've been monitoring the ionospheric induced phase shifts on the GPSDO's 10MHz output which arose when I decided to go solo with the GPS constellation - bad timing on my part and I'm now more actively interested in giving my RFS a thermostatically controlled enclosure to eliminate the effect of room temperature variations. ::)
John
I agree about GLONASS. Any configuration that included it had degraded timing stability. GPS and Galileo are quite acceptable especially if you don't have perfect clear sky view.
-
Funny, I tried to get a decent 10MHz and 1PPS for my lab.
I have a symmetricon GPS shooting the PPS in a PRS10. I then use the disciplined 1PPS and 10MHz out from the PRS10 for my systems and triggers.
Even this has some jitter between the PPS and 10MHz...
-
I agree about GLONASS. Any configuration that included it had degraded timing stability. GPS and Galileo are quite acceptable especially if you don't have perfect clear sky view.
Thanks guys :-+. In my ignorance I had assumed that more satellites would give a better result.
I've disabled GLONASS and run survey-in again and my positional accuracy has improved from 0.75 metres to 0.2 metres.
So as someone said a few posts back it looks like my work here is done. Except ...
What I need now is another GPSDO so I can compare results. I think I'll build Yannick's design next.
Curse this addiction >:D >:D >:D
Mike
-
Hi Mike,
Last night/this morning, I finally got round to rerunning an experiment I did a few months ago to compare the timing offsets between the GPS, the Glonass and Galileo constellations where I discovered (but didn't make hard copy notes of) the offsets involved. I seem to recall that the Galileo offset from GPS had been in the 3 to 5 ns region whilst that of the Glonass had been a massive 18ns or so.
I reran only the GPS versus Galileo experiment (the Glonass had been so far out, I didn't see any point in repeating that experiment ::)) and my best estimate of the offset this time round was that it was somewhere around the 1 to 2ns mark.
Since I'd gained the impression that using the GPS on its own had definitely, if only slightly worsened the VFC variations to circa 600uV pk-pk versus the 300 to 400uV when using both GPS and Galileo together, I decided to go back to that combination after running this test.
The daily room temperature mediated VFC voltage excursions are around the the 1mV at present - not an issue as far as a basic James Miller styled GPSDO design is concerned. Quite frankly, a basic, microcontroller free GPSDO can deal with this sort of temperature variation (a half to one degree per hour rate of change) without any measurable detriment to its phase stability. With a single frequency timing module like the M8T, the biggest issue is that of the ionospheric induced phase shifts at rates of 1 to 5ns per 5 to 15 minutes and longer time periods which totally swamp the slower room temperature variations which are almost totally compensated for by being part of the PLL error correction process anyway.
The upshot of this being that I'm not at all surprised at your improved stability and tighter positional survey in results after ditching the GLONASS constellation. :)
John
-
What I need now is another GPSDO so I can compare results. I think I'll build Yannick's design next.
Mike
I had a look at Yannick's schematic https://www.instructables.com/GPSDO-YT-10-Mhz-Lcd-2x16-With-LED/ (https://www.instructables.com/GPSDO-YT-10-Mhz-Lcd-2x16-With-LED/)
Some things to think about:
(1) It looks like he is using the 10MHz clock as the clock for the processor (which I think is a good idea) which is therefore the base clock for the PWM. Using the PWM with a period of 65536 counts (16 bits) gives a frequency out of 10,000,000/65,536 = approx 153Hz. That's rather low and I tried using LTspice to figure the response of the 10K ohm + 100 uF capacitor and I got a figure of about 7mV p-p (very rough, but ballpark). Perhaps someone better at number crunching can verify this. That may modulate the frequency with an unwanted 153Hz tone.
(2) The control voltage is only as stable as the power supply to the processor
(3) I think 16 bits may limit the Allen Deviation (which I still struggle to understand) - assume a sensitivity of the OCXO to the control voltage of 1V/Hz. 1 bit change of the control yields a 1 cycle difference in less than 4 hours. I think if I understand it right that means the system can't fix the frequency to better than 1 part in 10^-11. Of course, that is not big deal unless you want better.
So I'm not sure there's any benefit over Lars solution (actually the 153Hz tone would make it worse if it is a real thing).
A simple solution is to use a stable voltage reference (the higher priced OCXOs have it) and a potentiometer to provide 99% of the control voltage (which will need manual adjustment) and let the output of the processor provide the other 1%. If you already have one reference it shouldn't be too hard to set up - fix the PWM to a 50% duty cycle and feed the output of the OCXO to your referenced frequency meter. Fiddle the pot until as close to 10MHz as you can get, then unleash the PWM to make the finer adjustment.
More theoretical speculation. May not be right but worthy of thought?
-
I had a look at Yannick's schematic https://www.instructables.com/GPSDO-YT-10-Mhz-Lcd-2x16-With-LED/ (https://www.instructables.com/GPSDO-YT-10-Mhz-Lcd-2x16-With-LED/)
Some things to think about:
(1) It looks like he is using the 10MHz clock as the clock for the processor (which I think is a good idea) which is therefore the base clock for the PWM. Using the PWM with a period of 65536 counts (16 bits) gives a frequency out of 10,000,000/65,536 = approx 153Hz. That's rather low and I tried using LTspice to figure the response of the 10K ohm + 100 uF capacitor and I got a figure of about 7mV p-p (very rough, but ballpark). Perhaps someone better at number crunching can verify this. That may modulate the frequency with an unwanted 153Hz tone.
(2) The control voltage is only as stable as the power supply to the processor
(3) I think 16 bits may limit the Allen Deviation (which I still struggle to understand) - assume a sensitivity of the OCXO to the control voltage of 1V/Hz. 1 bit change of the control yields a 1 cycle difference in less than 4 hours. I think if I understand it right that means the system can't fix the frequency to better than 1 part in 10^-11. Of course, that is not big deal unless you want better.
So I'm not sure there's any benefit over Lars solution (actually the 153Hz tone would make it worse if it is a real thing).
A simple solution is to use a stable voltage reference (the higher priced OCXOs have it) and a potentiometer to provide 99% of the control voltage (which will need manual adjustment) and let the output of the processor provide the other 1%. If you already have one reference it shouldn't be too hard to set up - fix the PWM to a 50% duty cycle and feed the output of the OCXO to your referenced frequency meter. Fiddle the pot until as close to 10MHz as you can get, then unleash the PWM to make the finer adjustment.
More theoretical speculation. May not be right but worthy of thought?
Thaks for those insights, I will give them some thought. However, this is an addiction remember, so facts and logic have little to do with what happens next ... >:D
Seriously, though, I don't need spectacular accuracy. Plus I have a spare OCXO and all the bits I need to build it so it will make for an interesting project during the dark winter evenings. And it has a display :)
My Lars GPSDO uses a stable voltage reference and potential divider to trim the gain.
Mike
-
Season's greetings to one and all.
=====snipped=====
BTW, I did swap the OCXO out that evening and had it up and running for initial tests after checking the 'other usual suspects' I'd had in mind as possible contenders for the sudden EFC transient and 3% phase shift in the PLL's 100KHz input that I'd provoked with my finger tapping test.
However, after letting the EFC voltage settle to its new value of 2.4210, I did another finger tapping test and got an unpleasant surprise as it suddenly shifted half a cycle or so at 10MHz before stabilising. It hasn't responded to the many vibration tests over the past two days since, so I suspect I may simply have relieved some pent up stress in the "Stress Compensated Cut" crystal inside my "NOS" OCXO. I guess only time will tell but apart from that little 'surprise', it seems to be behaving itself just fine.
The EFC has dropped another 8mV and I'm expecting it to come to a halt and start going up again based on my previous experience with the 13MHz unit. I'm assuming that the 13MHz unit's retrace behaviour is typical - it may well not be. I'm just going to have to keep my eye on the EFC voltage (as I normally do) for the next few days and see what happens before I start running any power cycle tests.
John
Following up on my OCXO swap out just over six weeks ago (how the time just flies by!), here's an update on how the replacement has performed in that time.
From my experience with my MK I GPSDO build using the 13MHz OCXO which had exhibited a rising VFC trend, indicating a reducing frequency with age, I had assumed the replacement 10MHz OCXO I'd used in the MK II GPSDO might follow a similar trend (both being CQE units) with the initial reducing VFC being simply a retrace effect similar to what I'd seen with the MK I,
It would seem that ageing can go in either direction, even with same brand units. In this case, the replacement OCXO has relentlessly continued its downward VFC trend to the point where it slowly settled to 2.4018v from an initial 2.4210v just over six weeks back (I never did get round to power cycling it since I was hoping to see the trend halt and finally reverse). However, early this afternoon, It had suddenly dropped to 2.3998v +/-100uV or so.
After confirming my meter connections were still ok and that I was observing a real VFC reading which was behaving as if the PLL was still in control (I was in the middle of my RFS boxing up project so decided to forgo the half hour or so to set it up to compare the GPSDO output against), I tapped the GPSDO with my fingers and observed an immediate upward change in the VFC voltage (by around 10mV or so) before it eventually settled down around the 2.4010v mark where it has been hovering ever since, +/- the usual 2 or 3 tenths of a millivolt due to ionospheric effects.
So, after some six weeks of monitoring the replacement OCXO's behaviour without any untoward 'events' other than that initial response to my finger tapping at the start of the test run, I got to see a less dramatic repeat of the instability I'd experienced with the original OCXO, leaving me in a similar situation I'd had to start with.
The only thing I can say this time is that it does seem to be an OCXO issue rather than some obscure intermittent fault elsewhere (dry joint or whatever). I guess 'll just have to accept this as the downside of disciplining an OCXO which can't truly be guaranteed to be completely free of such anomalous behaviours no matter how good the quality is supposed to be. The only thing to be said in this case is that there isn't a microcontroller algorithm to be 'caught on the hop' since, for a start, there isn't a microcontroller to begin with.
The "Take Away" for those of you struggling with the Lars design, is that any odd events you might see in your data may well simply be down to your OCXO 'being an OCXO, unruly behaviour from time to time included". At the current rate of ageing, it seems to have settled to around 1mV drop per week in the average VFC voltage so I'll keep it powered until the new year when I expect it to finally drop below the 2.4000 volt mark before I try power cycling it to observe its retrace behaviour.
My own 'Take Away' from this is that these OCXO based GPSDO's need a little TLC to help with their disciplining. I'm pretty much resigned now to the need to administer a 'gentle love tap' every other day or so as part of its routine (percussive) maintenance to forestall any sudden frequency jumps (I'd been a little lax of late in providing the required TLC).
John
Update 2021-02-13 :-
The above speculation turned out to be completely off the mark (i.e. a load of "Bullshit" :-[ ). Those rogue phase shifts had started to become more frequent over the past few weeks, indicating that a second 'jumpy' OCXO showing identical behaviour to the first would be unlikely in the extreme, therefore pointing the finger of suspicion to a dry joint or a bad connector contact elsewhere.
I opened it up to check, specifically, for a dry joint between the centre pin of the PCB mount SMA socket and the ref input pin on the 74HC74046. I couldn't provoke the symptoms other than for the briefest of responses to finger pressure stress testing (which in hindsight points to insufficient spring contact pressure in the SMA socket itself).
I'd had great difficulty through difficult access to get a fine tipped soldering bit onto the pin to effect a good solder joint and this had been my prime suspect. Thorough and careful examination with a jeweller's loupe and varying angles of illumination revealed an almost text book perfect joint, much to my surprise. Careful examination of the socket contacts however, suggested the lack of contact pressure as the most likely issue so I used the tip of a pin to close the two contact fingers up.
Further vibration testing before sliding the board back into the enclosure failed to provoke a response but immediately after sliding it back in and temporarily fitting a couple of the screws to test the virtually fully assembled unit, resulted in a slow climb of VFC voltage free of the normal PLL variations seen during a normal startup. It seems I had disturbed a very weak solder butt joint between the adjacent PC1 output pin and the one and only 2M resistor I had to make up the 1200s TC filter. I resoldered this joint, adding additional solder to give it the much needed structural strength it had lacked from my initial soldering.
Whilst this makes it another possible source of trouble, I think it's an unlikely rank outsider since I don't think it became an intermittent solder joint until after I'd disturbed it when pushing it slightly to one side to gain better access to the adjacent ref input pin. Besides which, the symptoms hadn't exactly matched the original symptoms I'd experienced. My money is still on it being a low spring contact pressure in that SMA socket which, provided I don't disconnect it again, should now no longer cause any further trouble (fingers crossed ::) ).
-
Happy New Year everyone (better late than never :)).
I have now built two GPSDOs. Does that make me a timenut?
The Lars/Paul unit uses a NEO-8MT timing receiver while the Yannick one has a 7M. Both read exactly the same freqency on my 9-digit counter.
I've also perfected making my own double sided PCBs using a laser printer, toner transfer paper and a laminating machine.
Happy days.
Mike
[attachimg=1]
[attachimg=2]
-
Next you'll need a distribution amplifier for the 10 MHz. I made one over the holidays. I'll post a link if anyone is interested.
-
@Thinkfat:
Yes, I'd be interested in learning about the distribution amp.
Happy New Year.
Neal, N6YFM
-
@Thinkfat:
Yes, I'd be interested in learning about the distribution amp.
Happy New Year.
Neal, N6YFM
I've started a topic here: https://www.eevblog.com/forum/projects/my-10mhz-distribution-amplifier/ (https://www.eevblog.com/forum/projects/my-10mhz-distribution-amplifier/)
Github repository with the design files here: https://github.com/thinkfat/dist-amp (https://github.com/thinkfat/dist-amp)
-
I also build a kind of 10MHz "distribution amplifier".
It's actually only two isolated channels to avoid ground issues with non-earth connected equipment (which I have).
The PCB fits inside my GPSDO enclosure.
The description is at the end of my blog describing my version of the Lars GPSDO.
http://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html (http://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html)
Files are available on my Github, link is in the Blog
-
@Dbldutch: interesting reading your blog!
My similar experience while experimenting is the system is pretty sensitive to EMI. For example switching on/off a lamp or any other device unlocked my XOR based loop such I had to wait the entire time constant (aprox 20 minutes) to get it "locked" again.
I think you have to isolate galvanically the system completely off the environment, ie:
a) optocouplers for serial,
b) 1pps pulses from NEO via an optocoupler too, and
c) the 10MHz output via a broadband transformer. I would not connect the BNC socket to the pcb ground via that RC as you did.
The power supply must resist the EMI and the mains noise pulses as well (linear one with a transformer with very good filtering, capacitive multipliers). Thus complete galvanic isolation, no common grounds.. And a metallic box too..
Would be interesting to see how the operation of this GPSDO changes with such an isolation!
-
An update on my experiments. I had a disconnect between the need to have a GPS receiver with a good view of the sky, and the need to have the GPSDO in a friendly environment. This was solved by putting the GPS antenna on a roof about 6 meters up. The GPS receiver is cable tied to a roof rafter. The 1ppS and NMEA serial data is pushed through a UA9638 differential line driver down 16 meters of Cat 5 Ethernet cable to a UA9639 receiver then to the GPSDO. This works well.
I have trouble reconciling the measurements bandied about in this topic and the results I get from my methods. In my setup the microprocessor sets a fixed control voltage on the OCXO then monitors the difference between the OCXO and the incoming 1ppS. When they diverge by some limit (currently about 100nS) a correction is applied to the voltage to bring the two back in synchronisation. The setup now has a good signal and the OCXO is in a reasonably stable temperature, and the time between adjustments is typically between 20 minutes and several hours. The change in control voltage can be interpreted as a change in frequency (the relationship is about 0.1V/Hz), the frequency changes are now less than +-0.002 Hz so I assume the OCXO frequency is always 10 MHz +- 0.002 Hz. How do I interpret that as an MDEV or ADEV or any of the other acronyms?
I note people plot their DAC values against time and they are continually changing. Doesn't that cause larger short term frequency variations? Is it a natural outcome of using a PLL (real or simulated in software). I believed so (and still do) and decided that a PLL is not the answer. The OCXO could not be reliably said to be any particular frequency as it is affected by the instantaneous DAC value. I don't see how this is useful - e.g. if used as a method of locking a 49.152MHz signal for an ICOM receiver. It would be forced to follow the DAC swings too.
I conclude that for best results, maximum effort should go into building a very stable OCXO. Then really loosely couple it to the GPS system. For example if an OCXO could be guaranteed to run uncorrected for 24 hours and not lose or gain more than a couple of cycles, then a burst of 1ppS for a minute a day would be enough to work out a correction for the next 24 hours. It wouldn't matter if the 1ppS was out by 100nS, it represents an error of little more than 1 part in 10^-12 over a day. Any cheap GPS module would deliver that sort of result, all the effort to get 1ppS accurate to 10nS is unnecessary.
Something to discuss?
-
Hi IMO,
Thank you for the comments, I always appreciate your insights.
To clarify some of your questions and remarks, also for others reading this, the following:
The GPSDO circuit itself is completely isolated inside my metal enclosure. Nothing connects to the metal. Only the already isolated outputs of the distribution amp are connected through the SMA chassis parts to the enclosure.
The 12VDC going in (coming from a charging lead battery) is not connected to earth ground and the negative is isolated from the enclosure.
The SMA cable from the antenna is not connected to earth ground.
The BNC connectors for the 1PPS and 10MHz out on the front-panel are isolated from the chassis, although the ground of the BNC is connected to the GPSDO ground, of course.
The serial connections to the Neo and to the Nano are fed to the measuring and logging enclosure (all plastic) that sits on top of the GPSDO is also isolated from earth ground and fed by the same 12V supply as the GPSDO. The serial leads go to a Raspberry Pi Nano that is also not connected to earth ground.
I have been using my three at first, and now two GPSDO's for almost a year now and I never experienced an EMI issue that I didn't cause myself. That only happened when I connected other floating (not connected to earth ground) instruments to the not yet isolated 10MHz output. That's why I added the isolated outputs.
My Bliley based GPSDO is now permanently connected through the isolated outputs for the 10MHz signal to my Function Generator and my Frequency Generator for a few weeks now and I have not had a single issue so far. As of interest, I look and graph the Lars, NMEA and Counter logs daily. No issues whatsoever.
-
..
I conclude that for best results, maximum effort should go into building a very stable OCXO. Then really loosely couple it to the GPS system. For example if an OCXO could be guaranteed to run uncorrected for 24 hours and not lose or gain more than a couple of cycles, then a burst of 1ppS for a minute a day would be enough to work out a correction for the next 24 hours. It wouldn't matter if the 1ppS was out by 100nS, it represents an error of little more than 1 part in 10^-12 over a day. Any cheap GPS module would deliver that sort of result, all the effort to get 1ppS accurate to 10nS is unnecessary.
Something to discuss?
The short term drift of an [good] OCXO is _much_ lower than the short term drift of the GPS'es 1pps signal, afaik.
Long term "averaged" GPS phase diff info may improve the long term drift of the OCXO.
A few second long burst of GPS 1pps will not help you. You need to average many phase differences between GPS'es 1pps edge and the edge of the OCXO signal to get some useful information for driving the DAC. Usually it takes at least 500-1000 seconds, or more..
PS: have a look into the NEO (for example) modules datasheets - the jitter of the GPS 1pps output is XXns at each edge..
-
A few second long burst of GPS 1pps will not help you. You need to average many phase differences between GPS'es 1pps edge and the edge of the OCXO signal to get some useful information for driving the DAC. Usually it takes at least 500-1000 seconds, or more..
PS: have a look into the NEO (for example) modules datasheets - the jitter of the GPS 1pps output is XXns at each edge..
I disagree. Imagine a really good DOXCO that is good for 1 part in 10^-12 stability but its frequency is off a fraction. For argument, 1 part in 10^-9 (pretty bad) - a drift of 1 cycle per 100 seconds. The GPS is turned off when the 1ppS and OCXO agree, then on again 86,400 seconds (1 day) later. ONE 1ppS is received and noted that it is 86.5uS from when it was expected if the oscillator was exactly 10MHz. Even though there is just one reading it can be deduced (from the know jitter of the GPS) that an accurate 1ppS would arrive somewhere between -100nS (86.4uS) and +100nS (86.6uS). The oscillator may also have drifted by 1 cycle (add another 100nS). If the sensitivity of the oscillator to control volts change is known, a correction can be applied knowing the error is 1 part in 10^-9 +- less than 3 parts in 10^-12 (200nS/86,400S).
Is there something wrong with this logic? it is why I thought this is worth discussing.
-
The jitter of the 1pps signal is random. You cannot predict what happens next 1pps edge.
Therefore - the adjusting the OCXO against each 1pps edge would create jumps of 0.XXX Hz based on the actual jitter.
Also the OCXO drifts (1/f noise, other noises too, aging, temperature fluctuations, etc.).
Make ADEV or MADEV of your free running OCXO and you will get the picture how much it drifts within a day. The spot value of the phase after 86400 secs will be random too.
Afaik, the ADEV of a high stability free running OCXOs starts to climb up after a few/several minutes..
You have to average the phase differences - clean up the RMS of the 1pps jitter and OCXO with low pass filter - to get the "GPS quality". The time constant of the filter (digital, analog) is set usually from 500secs up, based on the setup, afaik (you may see the optimal time constant on the ADEV plot).
It does not mean the OCXO is locked in 500secs (an example) perfectly. The low pass is within a control loop, it takes many time constants to "lock". My double ovenized Trimble OCXO took min ~20-30 minutes to "lock" with the time constant calculated around 500 secs (XOR type analog control loop).
-
The jitter of the 1pps signal is random. You cannot predict what happens next 1pps edge.
You can't predict *exactly* what will happen, but you can say within almost 100% certainty it will arrive within +-XnS of when it should. If I set X to 200nS then I would suggest it is so close to 100% that it doesn't matter. In a short period, 200nS is big deal. In a day, not so much. The point of my previous post.
Therefore - the adjusting the OCXO against each 1pps edge would create jumps of 0.XXX Hz based on the actual jitter.
Nobody would want to do that in real life. My imagined scenario was for illustration, and assumed a DOXCO that may not be within the financial resources of most people.
Also the OCXO drifts (1/f noise, other noises too, aging, temperature fluctuations, etc.).
In the longer term (say a day) isn't it just ageing (assuming temperature can be controlled). I worked in a laboratory (over 50 years ago) that had a 5MHz DOXCO that was calibrated every Monday morning against a cesium beam. Its ageing was so predictable after 3 months that we could do a daily adjustment of the control voltage, and at the next weekly calibration required only a little adjustment.
Make ADEV or MADEV of your free running OCXO and you will get the picture how much it drifts within a day. The spot value of the phase after 86400 secs will be random too.
Afaik, the ADEV of a high stability free running OCXOs starts to climb up after a few/several minutes.
And this is what I'm having trouble understanding. What are ADEV and MDEV and what is their relevance. I would think what is important to people is knowing that their oscillator is within +-0.X Hz of the target. Or for period measurement that it completes X number of cycles in that period. With an oscillator that adjusts its phase to agree with the GPS, the second is a given and only the first is relevant
You have to average the phase differences - clean up the RMS of the 1pps jitter and OCXO with low pass filter - to get the "GPS quality". The time constant of the filter (digital, analog) is set usually from 500secs up, based on the setup, afaik (you may see the optimal time constant on the ADEV plot).
It does not mean the OCXO is locked in 500secs (an example) perfectly. The low pass is within a control loop, it takes many time constants to "lock". My double ovenized Trimble OCXO took min ~20-30 minutes to "lock" with the time constant calculated around 500 secs (XOR type analog control loop).
I have gone off on a tangent. I use a limit strategy. I allow the OCXO to 'free run' until it is about 1 cycle out of sync with the GPS average. Then I apply a change to the control voltage to bring the two together again. I've attached a log from the microprocessor of nearly a day's running. In that time it applied changes on average at more than hourly intervals.
The control volts assumes an exact 5V supply and I'm pretty sure the actual 5V changes with temperature and is the main reason it needs adjusting. The last reading was in the morning when the temperature was on the rise (overnight 19C, expected top over 30C). The ppb figures are calculated knowing the V/Hz relationship of the OCXO. The voltage is quoted to 7 figures as it is derived from a synthesized 24-bit (almost) DAC. The last digit is rubbish but the rest are significant.
The circuit is ridiculously simple, I attached it to my first post https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/msg3334250/#msg3334250 (https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/msg3334250/#msg3334250). It relies heavily on software. The control is dynamic and will apply corrections at a minimum of 5 second intervals if needed, but once it settles it uses the last 2048 seconds of 1ppS to calculate the difference between GPS and OCXO. This is an artificial limit due to limitations on the arithmetic. Is this is equivalent to a self adjusting low pass filter? I don't know.
The only 'tuning' I've done is on the limit. I tried a few different strategies and a +-1 Hz deviation seems to work OK.
-
I'm surprised nobody replied to my question - I am genuinely perplexed. What are MDEV and ADEV and how are they relevant to GPSDOs? Are they more important than knowing your oscillator is within +-so much of the target frequency. Does the strategy I use (free run the oscillator until it is 'out of phase' by eg 360 degrees (one cycle) then adjust the control voltage to bring it into phase again) have MDEVs and ADEVs?
My design criteria was the cheapest useful GPSDO. I chose 10MHz+-0.01Hz (1 part in 10^-9) as being 'useful'. Is this a useful value?
I also wondered what is a realistic target for a more precise oscillator. I thought 1 part in 10^-11 as this is better than an uncalibrated rubidium clock. Using the free run strategy this is 1 cycle deviation in 3 hours. I think that is doable.
-
I might suggest a useful article:
http://www.stable32.com/MDEV%20Versus%20ADEV.pdf (http://www.stable32.com/MDEV%20Versus%20ADEV.pdf)
Cheers,
Neal
-
I might suggest a useful article:
http://www.stable32.com/MDEV%20Versus%20ADEV.pdf (http://www.stable32.com/MDEV%20Versus%20ADEV.pdf)
Cheers,
Neal
Thanks but it didn't make much sense. I followed a few of the references and they were equally unhelpful. I guess I need to find someone who does understand it to explain the concepts without Greek letters and references to formula.
-
Measurement, analysis and specification of jitter (frequency stability if you wish) of frequency source is done by using statistical math.
You cannot talk about it without some math involved. In fact, all measurement and measurement science are a statistical discipline.
Frequency of any oscillator will not be constant. It will vary all the time, by different amounts, influenced by many factors in the real world. So your oscillator will newer have exact frequency.. Piloted on graph frequency won't be just one point. It will be interval, a "cloud" of possible values, so not a single point but more of circle,where somewhere inside your frequency will be wondering around...
Alan deviation ( and its variation MDEV ) is one of statistical measurements that is meant to look at stability of frequency as the time passes....
If you quickly search on internet, you will find introductory texts on this topic, that are not very math heavy but explain it conceptually.
-
@MIS42N: your design may work fine provided your ocxo works fine and the measurement and averaging of the phase differences is consistent. Btw., my gpsdo system is even simpler than yours, it is just a NEO module, a fixed divider by 500, a simple XOR gate and 3 resistors and 2 capacitors. No MCU involved in the phase measurement, averaging and setting the ocxo's control voltage :)
Would be great if you may start a new thread with details on your design and with some measurements you have done with your new MAX6350 voltage ref and Morion MV89 ocxo.
-
Measurement, analysis and specification of jitter (frequency stability if you wish) of frequency source is done by using statistical math.
You cannot talk about it without some math involved. In fact, all measurement and measurement science are a statistical discipline.
Frequency of any oscillator will not be constant. It will vary all the time, by different amounts, influenced by many factors in the real world. So your oscillator will newer have exact frequency.. Piloted on graph frequency won't be just one point. It will be interval, a "cloud" of possible values, so not a single point but more of circle,where somewhere inside your frequency will be wondering around...
Alan deviation ( and its variation MDEV ) is one of statistical measurements that is meant to look at stability of frequency as the time passes....
If you quickly search on internet, you will find introductory texts on this topic, that are not very math heavy but explain it conceptually.
Maybe I understand more than I think. I get that an oscillator is slightly unstable no matter - probably an outcome of Heisenburg's uncertainty principle. But I can't figure out how that relates to a GPSDO, except to characterise the oscillator. And that is usually provided in the specifications. Stability is not accuracy and I thought the purpose of a GPSDO was to provide accuracy to something that is intrinsically stable.
My perhaps naive thinking is the ideal is to build an oscillator that when compared with 1ppS today and then compared again in a week shows no deviation. In practice, this is statistically unlikely and any measurement has uncertainties as well. I thought the quality of the oscillator was measuring how far it had deviated. Maybe that is expressed as an ADEV? I know it is possible to build an oscillator that would gain or lose less than a cycle in a week, such were at one time the frequency standard for the world before cesium beam was perfected.
As pointed out by someone previously, just one 1ppS is not that great and it is better to average over a period. So maybe take a day's worth and average them. That reduces the uncertainty of the comparison.
The technique I am currently using is based on those thoughts. The uP uses the oscillator clock as its clock, has an internal x4 PLL so is able to determine arrival time of the 1ppS to within 25nS. I am using a cheap NEO with good viewing, the 1ppS are fairly consistent. The 1ppS readings are grouped (arithmetic averaged) into between 5 and 8 groups. The group size starts as single readings but as time passes are grouped in powers of 2 (2 readings, 4 readings ... up to 256 readings). Then a least squares linear fit is calculated. This then is used to calculate a slope (rate at which the frequency is changing compared to the 1ppS), a calculated current deviation, and if the slope is converging (deviation going down) how long until deviation is around zero. Nothing is done unless the deviation hits some limits.
Because of the simplicity of the circuit, the design frequency target is 10MHz +- 0.01Hz (Is this an ADEV of 10^-9 ?). It is assumed this is achieved if after 100 seconds running the deviation is less than 100nS. Also using the known V/Hz slope of the oscillator (about 0.1V/Hz) a change of control voltage is less than 10mV. Much of the arithmetic is based on the design target, the maximum set of readings used for calculations is 8 groups of 256 averages, just over 2000 seconds. It is more than sufficient to do calculations to achieve the design, but not good enough for 10MHz +- 0.0005Hz.
So I think I understand the physics, but not the mathematics. I shall see if I can find that introductory text and thanks for taking the time to reply.
-
Would be great if you may start a new thread with details on your design and with some measurements you have done with your new MAX6350 voltage ref and Morion MV89 ocxo.
A good idea. It may be a month or two away. I am working on the current design to make it user friendly. It now has a primitive user input. It can control what gets logged on the serial output, and an option to pass thru the NMEA data instead of logging. It also logs date and time on request. I want to add a history log of the last n (probably 10) control adjustments, a reset, a recalibration, and if the average control voltage is written away at intervals to speed the next startup (it is written after calibration but not updated after that). Also I'd like the single LED to be meaningful. At the moment it has a variety of flash patterns to indicate status. The nicest one I think is when it gets control of the oscillator (a few minutes needed for warm up) it double flashes every second, and continues to do so until the estimated frequency is within +-0.01Hz (another 3 or 4 minutes) when it goes to a single flash per second. I think that's what an average user would find useful.
I'm also working on a PCB design.
-
@MIS42N: The 1pps RMS jitter of an NEO-8 module, for example, according to the datasheet, is 30ns. That is something like 180ns peak-peak, imho.. That is more than 1 clock period of your ocxo.
And sure, do start a new thread with your design when ready, people will comment there then..
-
@MIS42N: The 1pps RMS jitter of an NEO-8 module, for example, according to the datasheet, is 30ns. That is something like 180ns peak-peak, imho.. That is more than 1 clock period of your ocxo.
And sure, do start a new thread with your design when ready, people will comment there then..
I do averages. The control logic is a bit complex. It allows the average deviation to grow to a limit, currently +- 5 of the measurement periods of 25nS (a phase error of 450 degrees?). So a 250nS span. This handles the NEO jitter OK (I'm using NEO-6, the cheapest I could find). When the limit is reached (which can be anywhere from a few seconds when warming up, to hours after running for days), a correction is applied that *should* reduce the deviation. At the same time, the limit is changed from +-5 to either 0,+10 or -10,0 depending which limit was reached. Ideally the correction reduces the deviation so it eventually hits 0, when another correction is applied that supposedly keeps it at zero and the +- limits are reinstated. There's some extra bits to deal with the possibility that the correction that should reduce the deviation doesn't work. This happens because the correction is proportional to the time it took to deviate - if the limit was hit after 500 seconds, then the correction should bring it back to zero in another 500 seconds. If it was 50 seconds, then take 50 to bring it back. If the time to hit the limit is thousands of seconds then the correction is tiny and may be insufficient. If this isn't dealt with sympathetically the algorithm can get vicious and forces a very rapid correction by altering the frequency by many ppb for a short time. I think I've got that covered now, it hasn't done it for many days
-
Hi everyone, I'd like some OCXO advice please.
I've just bought two Blileleys from this seller:
https://www.ebay.co.uk/itm/USED-Bliley-NV47A1282-10MHz-Sinewave-OCXO-Crystal-Oscillator-5V-EFC/253708936206?hash=item3b123b240e:g:u0EAAOSwTfdbL7qA (https://www.ebay.co.uk/itm/USED-Bliley-NV47A1282-10MHz-Sinewave-OCXO-Crystal-Oscillator-5V-EFC/253708936206?hash=item3b123b240e:g:u0EAAOSwTfdbL7qA)
They arrived in just 10 days in good condition, undamaged and marked with connections (and a free teddy bear :-+)).
These are NV47A models. I have the data sheet for NVG47A - does anyone know the difference?
Is it possible to tell the date of manufacture from the serial numbers?
Thanks,
Mike
-
0443 = year 2004, 43rd week..
NV47A - see datasheet below..
-
0443 = year 2004, 43rd week..
NV47A - see datasheet below..
Thank you, that's very helpful. The other device is 2008 then. They should be either nicely aged or worn out (but they seem to work very well).
The NV47A data sheet is interesting as it says TTL or HCMOS output whereas these devices are sinewave into 50 ohm (as per the NVG47 data sheet).
Confusing!
Mike
-
NV47A datasheet says standard is "sinewave", cmos/ttl is "optional"..
-
The NV47 has a common failure mode where the output coupling capacitor solder joints fail amd the output signal drops to very low levels.
-
NV47A datasheet says standard is "sinewave", cmos/ttl is "optional"..
Sorry, my mistake for reading too quickly. :-[
The NV47 has a common failure mode where the output coupling capacitor solder joints fail amd the output signal drops to very low levels.
Thanks for the warning! So far these two look very good. The measured output is +8dBm into 50 ohms.
Mike
-
The NV47 has a common failure mode where the output coupling capacitor solder joints fail amd the output signal drops to very low levels.
Long time No Hear :D
-
By definition, if you cannot "see" the GPSDO instability or accuracy with the test equipment you have, it's axiomatically good enough.
Apology for the rather tardy response (Yeah, two whole months! ::) ) but I'd had cause to review the last 4 pages of this thread and it had occurred to me that I should have responded to this with:-
Yeah, that's why I landed up blowing some 200 quid on an LPRO-101 ;D
Thereby explaining just how easy it is to become a (small) Timenut without even trying! :palm:
I'm now currently (and very slowly) converting that LPRO-101 into a proper temperature and barometrically stabilised RFS which means I'll be using my Nano3 collection, not for this Lars project (at least not straight away) but to apply barometric compensation since the only barometric sensors that provide an analogue output are all too bloody expensive, leaving the most cost effective option as a cheap BMP280 module and Nano3 (and a logic level converter board) to apply a control signal to the Rb's external C field terminal.
The room ambient temperature sensor input signal can still be dealt with purely in the analogue domain, the same as my existing baseplate temperature PWM fan speed controller setup but it might be easier to let the Nano3 monitor the temp sensor on the BMP280 for this task. In principle, if not in practice, I should be able to completely null out the residual ambient temperature effect on my existing fan controlled baseplate temperature regulator by monitoring the incoming room air.
At the moment, I've reached the stage where the RFS is keeping within +/- 50 to 70ns over a 24 hour period of my GPSDO's 10MHz output. That is to say, having given up micromanaging the RFS 10uHz increments at a time to compensate the more gross room temperature variations (1 deg C or over) and leaving it alone for more than 12 hours, I can now observe what looks like a diurnal variation over a 60 to 70ns range centred around the GPSDO output. The weather has been obliging in that the barometric readings have been hovering within the 985 to 990 millibar range over the past few days of late.
With room ambient compensated thermal control of baseplate temperature, topped off with barometric compensation, I have high hopes of actually seeing the ageing drift rate which may allow me to stabilise my RFS to 1x E-13 or better. Well, that's my RFS project's target. Whether I can hit that target is something else altogether but every project needs some end point to aim for and it's always best to aim high rather than low (the ordnance has less of a tendency to 'fall short' :)).
John
-
edit : side question : does any1 know if stuff like GPS RF LNA amp have any help in aiding stability? those that come in +18 +21dB? eg : NXP BGU8019X?
I think the stability of receivers is from the number of satellites they see with adequate signal. Also of course the design of the receiver itself. If the receiver is getting adequate signal, more signal isn't going to improve matters.
From my experience, an unobstructed view of the sky is the most important factor. I was struggling to get a 1ppS within a +-100nS window with the receiver in the house, and adding an antenna with supposed amplification made little difference. Moving the antenna outside improved things a bit, but that still had a limited view due to fences, nearby buildings, and the house itself blocking a fair bit of the sky.
The antenna is now on top of my balcony roof, a clear of view of the sky down to about 30 degrees above the horizon. The 1ppS is normally within a 50nS window which is pretty much all I could expect of a cheap GPS unit. I average the readings over a long period (256 seconds) and the averages rarely vary by more than a few nS.
From what I've read I'd say 1e-14 is out of the reach of all but a few. Rubidium is affected by variables like barometric pressure. Cesium is more stable but affected by magnetic fields (like changes to the earth's field due to passing trucks). Aim for 1e-12, 10MHz+-0.00001. Once that is in hand, shoot for the moon.
-
The stability is not so much from the number of satellites, but from the unobstructed view towards them. Especially multipath reception adds a lot of uncertainty to the derived time, hence if will massively influence the stability of the timing signal. Good receivers, especially those with overdetermined clock mode, can go with as little as one satellite to give a good timing signal, because they don't need to calculate a position.
-
The stability is not so much from the number of satellites, but from the unobstructed view towards them. Especially multipath reception adds a lot of uncertainty to the derived time, hence if will massively influence the stability of the timing signal. Good receivers, especially those with overdetermined clock mode, can go with as little as one satellite to give a good timing signal, because they don't need to calculate a position.
That's true enough as I confirmed to my own satisfaction several months back when I finally figured out that my suspicions of a firmware bug in my cheap M8T modules corrupting the antenna settings every time I tried to configure the elevation mask angle, disabling the active antenna option, completely cutting off all signals with the external GPS antenna (yet strangely only reducing signal levels from another active antenna with a 6 foot coax feeder I had set up a few feet from my office window), had actually been down to a faulty FTDI-232 module which seemingly only afflicted the NAV5 commands and corrupting the antenna configuration options.
Once I'd replaced that weirdly faulty FTDI-232 module, I was finally able to experiment with different elevation mask angles rather than be forced to accept only the 5 deg default. Whilst testing with a mask angle of 42 deg, I eventually observed just one GPS SV above this mask angle with, gratifyingly, no loss of the timing signal (the M8N modules needed a minimum of 3 (or was it 4?) SVs to avoid losing lock), thus verifying beyond any doubt that what I'd purchased so cheaply (£41 for the first unit and £24 each for the next two) were indeed the genuine and defect free article.
Pondering this result, it occurred to me that if this one and only GPS SV that had met this elevation mask criteria had happened to have been marked 'Out of Service' as they so often are (usually just two or three at a time out of the whole constellation but I had seen on at least one occasion almost half of the constellation being marked out of service :wtf:), I'd have been "Dead in the water" for possibly an hour or two as far as my basic, no frills GPSDO was concerned.
As a consequence of this worrying observation, I reduced the mask angle to 30 deg to make sure I'd rarely, if ever, see less than two GPS SVs above the mask angle at any one time and, more often than not, have three or more GPS SVs available. It's also why I chose to experiment with multiple constellations (GLONAS and Galileo being added to the mix) before discarding the GLONAS on account of its deleterious effect on timing (some 18ns adrift by my reckoning) and retaining the Galileo constellation which, despite my estimated 2ns discrepancy against the GPS constellation, seemed to endow some improvement in taming the ionospheric ToF variations which account for the 6ns or so of pk-pk variation that afflicts my single frequency GPS module's timing calculations.
Adding the Galileo constellation provides insurance against a repeat of having half of the GPS constellation being marked out of service, leaving me without a single working SV in view and totally disrupting operation of my GPSDO, allowing the reference output to drop by half a Hertz or so simply by accident of the effect of my "Start from cold 'Tme to PLL lock' accelerator" add-on-circuit. This drop in frequency would have been even greater but for this add-on-circuit.
Of course, an hour or two of total loss of GNSS timing data due to the use of a large elevation mask angle is readily shrugged off by any microcontroller based GPSDO design which can simply 'freeze' the DAC value at the last valid one as a minimal response if not otherwise capable of applying an ageing trend to reduce the holdover drift even further.
Of course, a basic hardware PLLed GPSDO has no such luxury feature, hence the need to take extra care in choosing an elevation mask angle when maximising the benefit of a surveyed in GPS timing module. However, now that I've recruited the Galileo SVs, I may be able to use a larger elevation mask angle value without undue risk of losing lock.
I'd like to use a larger elevation mask angle to tame the ionospheric effects on the ToF but the only effective way to achieve a basic freezing of the last valid EFC voltage that immediately springs to mind involves cascading an ADC with a DAC between the PLL buffer amp and the EFC terminal on the OCXO which strikes me as being as much trouble as using a microcontroller to perform the PLL function in software and abandon the simplistic charms of the basic hardware PLLed design altogether.
I suspect there may be simpler analogue solutions that can offer better than my current "Half Hertz drop holdover" performance which may be worth expending time on a duckduckgo research project (and another look at the James Miller circuit for a possible clue by four).
For home lab hobbyist use, a good holdover performance is merely a nice but nonessential luxury to guard against the occasional loss of satellite lock for the odd half hour or so once in a blue moon event. Figuring out a way to improve the holdover performance will be, essentially, simply a matter of self satisfaction which is the essence of most hobby activities, If you can't achieve some level of satisfaction or, better yet, a feeling of smugness, then you just ain't doin' it right! ;D
John
-
In case anyone's interested, I've gotten hold of a small stash of Ublox LEA-M8T modules. They're all pulled from old equipment and still mounted on PCB cut-outs. I'm in the process of mounting them onto custom breakout boards I designed for the purpose. Depending on yield, I'll have some for sale. Contact me by PM if you're interested.
-
I'd like to use a larger elevation mask angle to tame the ionospheric effects on the ToF but the only effective way to achieve a basic freezing of the last valid EFC voltage that immediately springs to mind involves cascading an ADC with a DAC between the PLL buffer amp and the EFC terminal on the OCXO which strikes me as being as much trouble as using a microcontroller to perform the PLL function in software and abandon the simplistic charms of the basic hardware PLLed design altogether.
John
If you go for a software solution, it opens up a whole lot of control options that may be very difficult in hardware. It also allows one to ignore the second to second quality of the timing signal and just work from averages.
I am using a NEO-6 GPS module cost me less than $10AU, I feed the 1ppS directly into the uP no intervening circuit. The uP can time that to the nearest 25nS. Over 256 seconds it is rare to see variance of more than 10nS and that could be temperature drift.
I then run a least squares linear interpolation over 8 x 256 second averages, which yields two figures - the slope (i.e. the amount the frequency is off from 10MHz) and the average. It is then possible to calculate a current phase error and from that correct for two things - the phase error + the slope. (This needs a calibration when setting the system up, to determine the actual control voltage/frequency change value. The uP is programmed so if this is not in non-volatile memory, it does a long run to work it out then swings over to disciplining mode).
The control voltage is only altered if the phase error gets to a certain point. For the 8 x 265 seconds averages that is 1Hz (360 degrees) and the uP changes the voltage to bring it back in phase 2048 seconds later. So if nothing is amiss, the maximum frequency error is 10MHz +- 0.001 Hz. Holdover is not a problem because I'm not that fussy about the quality of the 1ppS and I correct at long intervals. Lost cycles are registered as 1ppS arriving at the correct time which dilutes the stats a bit. However since I set up the antenna to see most of the sky I'm not aware of it dropping out.
The innovation that is difficult to be duplicated in PLL is when the phase error drops to zero but there is a slope (frequency error), the uP just compensates for the frequency error. If the system is stable (temperature wise) it can then run for several hours before the phase error gets to 1Hz. This effectively stops any hunt in the control.
The other thing hardware may have trouble with is the software will jump on any large deviation and correct it. The algorithm is (arbitrarily) set up to kill off any deviation in the same time it took to detect the deviation. That can be as short as 5 seconds. It isn't designed to lock in as quickly as a PLL, at startup the frequency has to come within 2Hz of 10MHz before control kicks in. This is also catered for on the calibration where a fairly good startup control voltage is stored in non-volatile memory. It is applied at startup and usually the control kicks in about 30 seconds later. As long as the frequency is within 2Hz it doesn't take long to get it under control. The 'lock' indication is delayed until the frequency is verified to be 10MHz +- 0.01 Hz. - takes about 5 minutes.
This was never intended as a timenuts quality project. It was aimed to get 1e-9 accuracy at minimum cost (I think all up about $50AU at this time, less than $40US). It does that, and surprising to me manages 1e-10 most of the time. It is tempting to improve it but I think it's back to the drawing board for a timenuts solution. I am currently working on committing this design to a PCB so it is easy for someone else to build. When I understand KiCad, I'm halfway there.
A note about DACs - I think the Lars design as I understand it uses 2 x 8-bit PWM to emulate a 16 bit DAC. The oscillator I use has a V/Hz slope of 0.1V/Hz (roughly). A 16 bit DAC producing 5V has quite large voltage steps (just under 1mV) so will set the frequency to the nearest 0.00076Hz which is not very accurate. I use a 10-bit PWM dithered to emulate a 24-bit DAC, eliminating the DAC from the equation (accuracy wise. temperature is another matter).
-
@MIS42N
With great power (of all those opened up control options) comes great responsibility. The charm of a simple James Miller design is that most of those responsibilities are lifted from your shoulders by a near foolproof hardware solution, assuming the deficiencies of the GNSS itself allow sufficient accuracy and stability to meet your needs.
It seems to me that the bulk of the control algorithms exist purely to overcome the GNSS's inherent deficiencies as a time transfer medium. If you look at this comparison here:-
http://www.leapsecond.com/pages/gpsdo/ (http://www.leapsecond.com/pages/gpsdo/)
It would seem that the other three microcontroller based contemporaries to that James Miller example are just nicely managing to 'stand still' despite all their microcontroller goodness. One of them at least is managing to do a little better and the other two aren't performing noticeably worse (probably an achievement in itself for the state of the art in microcontroller based GPSDO design way back in February 2008 ;)).
I think the main reason for the James Miller GPSDO's astounding performance was his choice of a special ultra low phase noise AXIOM40 OCXO. As I've already mentioned, the LO (normally an OCXO) is the key component in any GPSDO design.
Developing and building (or even just building from a published design) a microprocessor alternative to the foolproof hardware PLL setup puts you in a whole new world of pain regarding voltage stability issues (multiple LDOs) and thermal management (temperature control or compensation) over individual temperature sensitive components.
The good old fashioned hardware PLL neatly sweeps all of this under the carpet to be dealt with on mass by the PLL's feedback loop, leaving only the critical thermal management issue as a bought in solution, aka, that all important OCXO (or DOCXO).
It's true enough that a well implemented microcontroller based design can do so much more than that basic design of James Miller's GPSDO. Just be prepared to put a lot more work into such a project than you ever imagined it would take. >:D
Your own strategy is but a variation of this Lars DIY GPSDO design using much longer time scales to gather data by which to gently nudge, rather than whip, your LO into submission. It has merit but I think the time scales you propose are more suited to disciplining a well temperature stabilised Rb oscillator than any OCXO, including even high quality DOXCOs.
The only thing that I found a little confusing at first in your description was the use of the expression "1Hz" where, after careful re-examination, I think you really meant to say "1 full cycle". This made it look as though you were correcting at offsets of 1Hz, a horrifyingly large error at first glance. ::) :palm: Anyway, I look forward to seeing your new topic thread on this project once you're ready to announce its birth. :popcorn:
I'm in the middle of turning my LPRO-101 Rb oscillator into an RFS capable of staying within +/-50ns or better of GPS time over 24 hour periods. I've gotten as far as stabilising the base plate temperature to within 0.1 deg which made a definite improvement over its frequency stability when it had simply sat on top of a large quarter inch thick aluminium heatsink plate on my workbench. It's only an improvement because the room temperature still has some influence due to uncontrolled thermal leakage paths in the current test setup. I'll be using a room air temperature sensor in the finalised project to null out this effect.
I've got it resting in the metal instrument case I was intending to mount it in with the lid off to allow the PWM controlled fan access to fresh air. I still haven't brought myself to despoil this virgin project case with ventilation holes since it doesn't give me quite enough clearance to wrap all but the heatsink fins in thermal insulation to minimise uncontrolled heat leakage that would dilute the thermal control by the cooling fan. I'm now thinking a cheap plastic project case might be my best alternative to continue this project after all. ::)
It had taken a Herculean effort to dismiss all the plastic enclosures being offered by ebay and Amazon sellers in favour of suitably sized extruded aluminium project boxes that weren't ridiculously over-priced even by Chinese vendors before I found a suitably sized one at a reasonable price. It now sits, perched on top of other junk er, useful bits, assembled but unused.
Gah! If I'd only realised back then, the need for such exquisite thermal regulation (and ultimately barometric compensation), I could have saved all that Herculean effort and picked out a cheap plastic instrument case straight from the get go :palm: Never mind, I might have this 'little' project done and dusted by August (only a year after purchasing the LPRO-101).
The main reason for my investing in a Rb oscillator had been to allow me to quantify the 6ns or so pk-pk subsonic phase wobble I'd gotten a glimpse of when micro-managing the frequency calibration of the OCXO I'd installed into my FY6600 by varying its case tilt angle to fine trim it using the 2G Tip over effect and hope the room temperature remained constant for the next hour or two to bring the frequency drift to a halt long enough to pick out these ionospheric induced phase shifts that could otherwise only be guessed at against a moving background frequency drift.
During the late summer months before heating season kicked in, the initial bench setup proved sufficient for the task, relieving me of the unenviable job of micromanaging the AWG's OCXO's calibration. However, once the luxury of stable room temperatures had been swept aside at the start of the heating season, I soon realised the need to install it in a thermally stabilised enclosure, hence this current project.
I've now reached a state where my goal looks to be quite attainable. I've been monitoring the GPSDO and RFS waveforms with my SDS2504XPlus over the past 48 hours or more with persistance set to infinity to show the accumulated drift over 12 hour or longer periods. I've been taking screenshots every so often to record the drift and the GPSDO's 'wobble' over the past 6 hours or so. I've picked out a small selection from the 27 I recorded which I'll attach to this post. Also attached are a couple of photos showing the hand drawn schematic of the MK II GPSDO and a view of the part built project to give you all a flavour of my own modest efforts.
The schematic is laid out to largely mirror the physical component layout. It omits stuff like the buck converters and the five matched 1K resistors with 120 ohm resistor link to the OCXO's Vref pin and the 50K trimpot across the resistor divider chain to trim their volt drops to precisely 1v each. The GPS module was unmounted at that stage of the project, simply being connected by short but unshielded wires (critcal in the case of the PPS when I tested PLL frequencies above the 100KHz it's currently running at - now that it's installed with a short coax link, I might retest at 1 and 10MHz to see if I can gain any performance improvement).
John
-
@Johnny B Good
Most interesting. I am not sure what I am looking at with the 'scope traces. Or what to make of the leapsecond link. I am still coming to terms with this stuff.
You say "...assuming the deficiencies of the GNSS itself allow sufficient accuracy and stability to meet your needs." - 100% right, but there are two ways to get the accuracy and stability. One is to pay a lot of money for a dual frequency receiver specifically designed to compensate for ionic disturbances and (if used for mapping or similar) capable of centimeter accuracy. It is not the actual GNSS that is deficient, it is the transfer of that information to a distant receiver through an unruly signal path and the capability of the receiver to render the received data faithfully.
The second way is to accept that neither the path or receiver are reliable in the short term, but any perturbations from ideal behaviour can be reduced to insignificance if sufficient samples are collected. For example, if arrival of 1ppS is +-100nS and has normal distribution then collecting 10,000 samples and averaging them should give a much better indication of the true arrival time of the 1ppS. Unfortunately some aspects of the system don't follow a normal distribution but collecting samples is still effective.
The first solution then makes the choice of oscillator fairly trivial. As long as it has the required stability, PLL imposes the required accuracy.
The second solution is much more dependent on the quality of the oscillator, as it needs to be better than the vagaries of the 1ppS. And an el cheapo GPS module is not correcting for diurnal ionospheric conditions. So the oscillator ideally has predictable behaviour for a day (predictable being an error of less than your design target). If that target is (say) 1e-11 then setting a control voltage and letting the oscillator run should result in loss or gain of no more than 8 cycles per day. If the target is 1e-12 then less than a cycle.
Assuming an oscillator of the required quality (after controlling or the environmental variables like voltage stability, temperature etc) one then has to decide when to discipline the oscillator. Do you let it wander the 8 cycles or do you let it wander 1 cycle then pull it into line?
As stated in the last post, my aim was a modest 1e-9, a deviation of 1 cycle in 100 seconds. [as an aside, apologies for calling it 1Hz, clearly the wrong term. I've been wrapped over the knuckles all my life for not using the correct terminology]. To cater for short term GPS madness, I decided to go with 2 cycles over 256 seconds. If the 1ppS average arrival time has shifted less than 2 cycles, I claim (but without an better external reference, cannot prove) that we are within 1e-9 of the correct frequency.
I liked the photo of the actual circuit. I tried to take one of mine, the light was too poor for a good one. It has only the GPS module, a uP, an oscillator and some passive components (still working on providing a BNC output, haven't decided yet how to do it). I put the circuit in my first post - Reply #785 on: November 19, 2020
I'm in the process of adding a "user interface" to the uP. Originally it just output logging data but I now get it to store the last 24 control voltage adjustments and send them out the serial interface on request (via serial input). Unfortunately another change I've made stops the processor receiving data if I ask for history. Here's the last data (starting with a warmed up oscillator). The first 15 minutes are dealing with the fact that startup control volts is not perfect so there's a bit of bouncing around. After that there's 6 corrections in 12 hours and an imputed frequency error of less than 1e-10. This is a log of the 'conversation' with the uP, the AT to get attention might stir memories of early modems. This the actual output of the uP, it isn't edited.
ATt
Time Stamp: Date 090221 Time 101157 UTC.
ATh
Time 214851 UTC. Ctrl 2.0495521 -0.897 ppb
Time 215306 UTC. Ctrl 2.0500885 0.510 ppb
Time 215825 UTC. Ctrl 2.0492578 -0.789 ppb
Time 220240 UTC. Ctrl 2.0498134 0.528 ppb
Time 225351 UTC. Ctrl 2.0497313 -0.078 ppb
Time 231926 UTC. Ctrl 2.0497774 0.044 ppb
Time 002325 UTC. Ctrl 2.0498604 0.079 ppb
Time 005316 UTC. Ctrl 2.0498061 -0.052 ppb
Time 053035 UTC. Ctrl 2.0498677 0.059 ppb
Time 060026 UTC. Ctrl 2.0498110 -0.054 ppb
The current programming in the uP is at its limit, I have to rewrite the arithmetic modules to get better results. But I think the lack of temperature of voltage control means the circuit as a whole is near its limits also, so next step is a complete redesign.
As an afterthought, I didn't understand " It has merit but I think the time scales you propose are more suited to disciplining a well temperature stabilised Rb oscillator than any OCXO, including even high quality DOXCOs." - could you clarify?
-
@MIS42N
I meant to explain the scope traces - sorry! I'm triggering from CH1 (yellow trace) which is monitoring the GPSDO's 10MHz output. CH2 (magenta trace) is monitoring the output from my very much modified cheap Chinese "toy" FY6600-60M AWG into which I'd fitted a 10MHz OCXO (plus a 5 times clock multiplier chip) to replace the original and rather crap 50MHz smd XO Feeltech had cheaped out on as a clock reference source and, more importantly, had added an external reference input socket to let me injection lock the OCXO to an external atomic clock derived 10MHz frequency reference such as a GPSDO or Rubidium atomic clock.
In this case, I have it locked to my LPRO-101 Rubidium oscillator so that I can dial in calibration adjustments in increments as small as 1uHz (in practice, I'm using 10uHz steps). Basically, the AWG is acting as a proxy for the RFS, allowing me to precisely trim the Rubidium locked frequency without my having to struggle with the RFS's own frequency trimpot, putting unnecessary wear and tear on it just to cater for room temperature variations that will stop being a problem once I've finally completed my RFS project.
In short, CH2 is the Rubidium reference. When their frequencies match exactly, both traces will remain stationary. CH1 being used as the trigger signal will remain fixed whilst any frequency/phase shifts of the Rubidium frequency on CH2 relative to the triggering signal on CH1 will produce a drift or change in phase offset. The use of the word "relative" in the above statement is a vital part of the description since you will observe the same effect (only with an opposite drift direction to the former case) if the triggering signal on CH1 is varying whilst that on CH2 remains rock steady. BTW, in case you missed it, the bottom right hand corner shows the date and time, effectively time stamping each of these screen shots.
What you choose to trigger from, from out of two or more signals being displayed on a CRO, or in this case a DSO, is entirely arbitrary but the general rule is to trigger from the most stable and accurate frequency source (normally a frequency source locked to a lab standard reference such as a GPSDO or RFS).
In this case, there is some conflict over which is the best choice, On the one hand, the GPSDO is frequency stable in the long term but it suffers subsonic phase modulation from the imperfectly corrected electron density of the ionosphere (ionosphere correction data is a standard part of the GNSS message packet payload) whilst on the other hand, the RFS is free of such subsonic phase modulations but suffers a temperature induced frequency drift that is yet to be fully mitigated.
Once I have gotten my LPRO-101 fully stabilised against temperature (and ultimately pressure) variations, I would make this the reference in order to observe the GPSDO's 5ns or so pk-pk phase shifts in rather more detail than I can do right now. Since I'm currently working on improving the RFS's long term frequency stability against variations of ambient temperature, I'm using the GPSDO as the reference, "Warts and all". ::)
By using infinite persistence", I can record not only the subsonic phase shifts which are reflected onto the RFS (magenta trace) but also the hours long drift in frequency of my less than perfect RFS (at least until it slips one whole cycle out of phase with the GPSDO - then I have to clear the traces and start over). I'm aiming to extend this time from some ten hours or so out to two or more days worth before it completes a full cycle of drift. ::) From my results so far, this does look rather doable, given enough time and effort to get everything just right.
In view of the many sources of error (residual errors after applying the ionospheric correction data being a major one in a single frequency setup) such as tropospheric propagation delay errors, orbital position errors, on board clock timing errors and a few other error sources besides that I can't recall right now, even with a dual frequency setup, it's a bloody minor miracle that it's even possible to achieve metre scale accuracy let alone the centimetre scale accuracy you mentioned. I know it's all based on sound scientific principles but to me, it's verging on it all being an exquisite magic trick. :)
You mentioned the use of a (damn bloody expensive) dual frequency timing module (not forgetting the additional expense of a dual frequency timing antenna) to eliminate this source of error. However, that still leaves all the other smaller error sources to be dealt with.
The only problem with the hardware PLL is that it lacks the sophistication to do anything more than integrate anywhere from the last 100 to 1000 (and in some cases a little more) second's worth of PWM output to control the EFC voltage whereas the microcontroller can run sophisticated PID algorithms with Kalman filtering capable of dealing with the much longer time scales that can benefit a Rubidium based LO along with logging data to monitor performance and permit post mortem analysis of any rare and unusual events that may pop up. This leaves the microcontroller faced with a game of "Whack-A-Mole" dealing with the issue of temperature effects on the LDO(s) and DAC's voltage references which makes assembling and refining the required algorithms a rather interesting exercise to say the least.
Your last question, in regard of my comment about the correcting adjustment time scales being better suited to a Rb oscillator were based on my perception that you were allowing for a rate of as long as just one adjustment every two hours which few to no OCXOs can sustain the required one cycle drift accuracy for, other than by pure chance. A high quality DOCXO just might manage the required stability with reasonable repeatability but for the two hour and longer time scales I thought you'd had in mind, only a Rb oscillator could reliably meet this requirement, assuming its base plate temperature is kept closely tied to a fixed temperature against ambient temperature variations.
If you also apply barometric compensation as well as maintain tight temperature control of a Rubidium oscillator's base plate, the microcontroller will land up effectively compensating largely for the daily ageing drift rate of <1.67E-12 (one thirtieth of the <5E-11 per month figure quoted by the manufacturer of the LPRO-101).
I'm aiming to create an RFS free from temperature and barometric induced frequency errors, leaving only the ageing drift to contend with. When I've completed those parts of my RFS project, the next obvious step to take will be the addition of a suitable microcontroller based GPSDO to compensate even that small error component. I could land up using a variant of the Lars design or even yours if you manage to reach a successful conclusion. >:D
The barometric compensation part of this project will require the use of a Nano3 anyway just to interface the BMP280 pressure/temperature sensor module and, once I've added that to the mix, I'll be just one small misstep away from falling down the rabbit hole that is microcontroller based GPSDO territory. |O :palm:
Regards, John
PS I started writing this reply several days back but it got hijacked by "Real Life" events in the form of a fuse blowing fault with our 40 year old central heating electrics (a shorted out 47nF 250vac filter cap in the boiler - a free standing cast iron lump heat exchanger model destined to outlive by an order of magnitude longer than all of these new fangled aluminium based condensing types that need replacing every seven years on the average, eating up those modest savings on the gas bill and then some! ::)).
The original fault was further compounded by a dicky motor in the 3 port mid position diverter valve assembly going into complete failure requiring a second visit by our tame British Gas engineer a couple of the very coldest days of the year later before we could once more enjoy the benefit of a fully functioning central heating system.
-
Hello all, I have read some of the posts regarding this design and have seen a few other GPSDO designs. To date my understanding of these designs is a GPS receiver tracks SV's and provides a 1PPS signal. A local ref, TCXO/OCXO ,etc is divided down to 1pps and phase compared to derive a steering signal to the ref. The steering signal is typ a DAC.
Assuming that is how most all ( all?) GPSDO have been done I have question: Has anyone done a GPSDO by directly injecting the reference osc into the GPS receiver? FOr example, the UBLOX 5T/6T/8T timing rec use a 26 MHz clock interal clock, all GPS measurements made r wrt to this clock. I have removed this clock, a tiny thing, attached a coax and fed the time rec of a 5T and a 6T rec.
The result is a DIRECT reading in UCenter software ( UBLOX) of the rate error on the 26MHz applied clock. I have used a external SG, hp 8642B to supply this 26Mhz to the UBLOX rec. The 8642B I supplied a 10MHz from a Trimble Thunderbolt. The idea being to provide a near perfect 26MHz to the Ublox rec and see what it claimed the rate error was ( in ns/sec). My exoperments have confirmed the UBLOX indeed did report near zero rate error when fed that 26Mhz that was tied to my trimble GPSDO. I observed near zero mean data and noise around a few parts in 10^-11.
Its not hard to replace the 8642B with a 26MHZ xtal osc / PLL to 10MHZ from a TCXO/OCXO etc . And using data from Ucenter drive a DAC ( to 10MHz OCXO/TCXO...) to drive UCENTER reported rate error data to near zero. IN fact one can also add the UCENTER reported phase error data to the control method , properly averaged. ( if u reset the rec it can wake up with phase error near zero and if the rec clk s near perfect it dont move)
It seems to me such a method relieves the GPSDO of the need to accurately measure phase between two 1PPS signals. Uceneter ALREADY does this wrt to its own internal ref clock. In addition rate and phase data from Ucenter SW seem to be of quite high fidelity , esp with rec in time mode AND I think it may be possible to get increased measurement fidelity as the receiver is now measuring AGAINST a high quality OCXO ( assuming that is used) rather than a cheesy tiny TCXO?
I have been aware of this method for over a decade and yet have not seen an implementation of it by any manufacture. Perhaps the fear of replacing the UBLOX clock stops that. ( same trick can be done with Trimble Res T etc, diff freq of ref clk) But for DIY its not a problem . So , I am wondering if this has been done and if so by who ?
I am attaching a paper I wrote regarding this method.
Dan D.
-
I know this design came up on the time-nuts mailing list end of last year. It has been implemented at least once, though in a slightly convoluted manner using a configurable delay line to do a sawtooth correction in hardware.
-
Your last question, in regard of my comment about the correcting adjustment time scales being better suited to a Rb oscillator were based on my perception that you were allowing for a rate of as long as just one adjustment every two hours which few to no OCXOs can sustain the required one cycle drift accuracy for, other than by pure chance. A high quality DOCXO just might manage the required stability with reasonable repeatability but for the two hour and longer time scales I thought you'd had in mind, only a Rb oscillator could reliably meet this requirement, assuming its base plate temperature is kept closely tied to a fixed temperature against ambient temperature variations.
Thanks for the comprehensive reply. Including the battle of the heater. I live in Newcastle Australia so heating is optional, cooling is desirable. We were previously living 1000m above sea level, frosts at least 100 days a year. Heating was by wood fire, lit in Autumn and let go out late Spring. Now we are 6m above sea level, only 4km from the sea so get the benefit of a coastal climate.
I think you underestimate OCXOs. My last project built some years back used a second hand Morion MV89 DOCXO, and I had the perception that all the problems I had with it were due to the external circuit and the underpowered processor (I was using a PIC16F628A). This may have been compounded by a bad environment and not ideal GPS reception. I am certain it was drifting less than 1 cycle in 3 hours when conditions were right.
The current OCXO (OSC5A2B02 - used, cost about $4AU) is much better than I expected. If you look at the figures in my last post, it ran from 005316 UTC to 053035 UTC before correction (over 4-1/2 hours) and at the time stamp of 101157 UTC. had been running uncorrected since 060026 UTC. (over 4 hours). Although the corrections applied are around the 0.05 ppb (i.e. 5e-11) this is an artifact of the arithmetic, which aims to make the one cycle correction in 2048 seconds (which works out to 0.05ppb). The change in those 4 hour periods is 1 cycle which implies a drift of less than 1e-11.
I've noticed the reported control volts is lower at night. This is probably due to changes in supply voltage. A 7805 can have a temperature coefficient up to 1mV/°C. The 2V control would then have a change of around .4mV/°C. With a sensitivity of 0.1V/Hz that causes a change of 0.004Hz/°C which would be dominant. I am seeing less than that, so I assume the supply is more stable (it is a 5V switch mode salvaged from an old piece of networking equipment). My next improvement is to address this, then we shall see if an OCXO is as good as I believe it to be.
My belief comes from working in a laboratory many years ago that had a 5MHz DOCXO that was calibrated against a cesium beam once a week. After several months it had a completely predictable ageing and by tweaking the control voltage before calibration was usually 'spot on'. Had we at that time a uP that could apply the ageing correction continuously I think that oscillator would be better than a rubidium standard.
On the "user interface" side, reading history no longer affects the reception. I've also added some counters - up time in seconds, number of seconds the GPS unit reports invalid data, number of missed pulses, number of rejected pulses (both caused by interference). These are diagnostic, I haven't seen bad data unless I deliberately turn off the GPS unit for a few seconds. Also a sanity checker that resets the uP if signal is lost for a time (30 seconds at the moment). Getting close to a finished product.
-
Assuming that is how most all ( all?) GPSDO have been done I have question: Has anyone done a GPSDO by directly injecting the reference osc into the GPS receiver? FOr example, the UBLOX 5T/6T/8T timing rec use a 26 MHz clock interal clock, all GPS measurements made r wrt to this clock. I have removed this clock, a tiny thing, attached a coax and fed the time rec of a 5T and a 6T rec.
Perhaps the reason not many people try this is that it doesn't appear to give any advantage. Most people conventionally want a stable 10MHz oscillator that is disciplined according to information provided by a GPS receiver. The receiver you use provides a 1ppS signal and tells you how inaccurate it is. If hardware can measure the (inaccurate) 1ppS to the degree of accuracy required, then software can calculate when an accurate 1ppS should arrive and discipline on the basis of that. No need to have an accurate oscillator in the GPS. The hardware to measure arrival time is simpler than that required to lock a 26MHz oscillator to a 10MHz reference signal and inject it into the GPS.
Did I miss something?
-
Assuming that is how most all ( all?) GPSDO have been done I have question: Has anyone done a GPSDO by directly injecting the reference osc into the GPS receiver? FOr example, the UBLOX 5T/6T/8T timing rec use a 26 MHz clock interal clock, all GPS measurements made r wrt to this clock. I have removed this clock, a tiny thing, attached a coax and fed the time rec of a 5T and a 6T rec.
Perhaps the reason not many people try this is that it doesn't appear to give any advantage. Most people conventionally want a stable 10MHz oscillator that is disciplined according to information provided by a GPS receiver. The receiver you use provides a 1ppS signal and tells you how inaccurate it is. If hardware can measure the (inaccurate) 1ppS to the degree of accuracy required, then software can calculate when an accurate 1ppS should arrive and discipline on the basis of that. No need to have an accurate oscillator in the GPS. The hardware to measure arrival time is simpler than that required to lock a 26MHz oscillator to a 10MHz reference signal and inject it into the GPS.
Did I miss something?
Indeed, supplying the GPS receiver with an external reference clock will require a low-jitter PLL. Si5351 seems to be popular. That means replacing a low-complexity frequency divider with a more complex integrated PLL.
What I envision being a low-complexity GPSDO architecture would be in using the "time marking" feature of the Ublox receivers, which should provide nanosecond-accurate UTC timestamps for events received on an EXTINT input. I've not tried that myself yet, but it would just take a low-jitter divider to feed a 1Hz signal into an EXTINT and some DAC to control the EFC voltage of an OCXO.
-
I posted this elsewhere and have been made aware there is a UBLOX product that steers its VCTCXO via DAC: LEA-M8F, I have attached an image of it .
It does not produce a super clean 10MHz. You would have to lock a clean 10MHz to it to get that to happen.
Its pretty clear that UBLOX saw an advantage to steering their local clock, other wise why the LEA-8MF.??
I can think of a few::
UBLX Time error resolution/accuracy of local 1PPS to GPS 1PPS measurement: Sub nano second. (Not what u see on 1PPS pin of rec, see below) ( this leve of resolution/precisions diff to do when roll ur own counter, which designs that compare 1PPS with local via hrdwr, a counter is not used as it falls out of curve fit in PVT solution of receiver)
Rate Error of local clock: Resolution 0.001ns/sec, accuracy around 10 times that? There is no DIRECT rate error information provided by roll your own 1PPS compare designs. The rate also SHOULD be based on Carrier phase observations inside the receiver, which have orders or magnitude lower noise than CODE PHASE observations as MUST be used in correcting LOCAL 1PPS from rec. No external 1PPS method can incorp Carrier Phase directly in its steering method as it can only "see" the 1PPS provided at the rec pin.
UBLX and nearly all low cost timing rec produce a 1PPS pulse that has QUATIZATION jitter ( in addition to CODE PHASE NOISE) , This comes about as they use a digital method to steer the external 1PPS signal. If you PROPERLY design the control loop this jitter , often 20ns or so, can be eliminated by using RATE steering to nearly stop 1PPS movement wrt 1PPS GPS AND then adding a bit of the high res phase error data discussed above. Thus very low jitter EXT 1PPS pulse results ( the quan jitter is defeated) My understanding is the UBLX design does this.
From a control system point of view I will always take the lowest noise measurements I can get. In addition If there is way to get even MORE information about the controlled target ( here a 10MHz target clock) I would ALWAYS want that, And that extra info( that no ext method can deliver easily) is Extreme fidelity clock RATE error! The most important thing to control in the loop is not PHASE its RATE!( iE 1ST STEER RATE ERR TO ZERO then PHASE ERR TO ZERO) To be blunt when you see the sheer QUALITY of the rec generated clock error terms , as provided by UBLOX for free via UCENTER, there is no comparison what EXTERNAL measurements/comparison can provide via 1PPS phase observations using ext 1PPS .
As for ADDING a 26MHZ PLL...that is two parts of cost: 26MHZ VCXO ( available thru DK, not a custom part) and a ADF4002 PLL chip that will lock the 26MHz to 10MHz. The spectral purity req of GPS rec is not stringent as at best there is at most 50dB carrier to noise ratio of SV signal at earths surface. The locked 26MHz to 10MHz is not a challenge from design, cost , complexity point of view.
I am not sure anyone read the attached paper to my original post. But in that paper I outlined how I used my existing HP 8642B SG as the 26MHz to a LEA5t rec I bought on ebay for $13. The UBLx now provides direct read out of the rate/freq error of the 8642B , which is based on an internal reference. When I locked 42B to another 10MHz, from my 8566B Spectrum Analyzer ( its a vry high end 10M OCXO inside) , the UBLOX displayed the new error now from my 8642B as its ref was from 66B SA. The displayed error happens every second. You would need a 12 digit freq counter to compete with the freq err data from UBLOX lea5T, that wd very likely struggle to make the a similar precision measurement inside a second?
SO here is what you get for $13 and a small amount of effort: A 12 digit Freq counter that produces a measurement every one sec( maybe faster even?( I think 6T does sub second updates))
A atomic clock via the GPS/GNSS system of SV's that the above internal "virtual" rec counter is referenced to.
And if you steer the 10MHz ref you get get a SMOOTH 1PPS ext pulse MINUS the quantization error
With this system I can easily "set" any of 10Mhz reference I have in my SG's , SA's etc. I can also check Ruby Osc. rate error quickly and easily. All for $13.
-Dan D.
GPS/GNSS engineer , 1990 to present
-
@dandober
I did read your paper. Twice. Once late at night and I was struggling a bit to get my head around it. So again in the morning when I'd had the morning coffee.
I was rather amused that $13 and a small amount of effort left out the cost of a HP 8642B SG ($2K?).
It depends on the purpose of your GPSDO. Is it a frequency source? I would suggest that most amateurs are not looking for anything more than 10MHz+-0.01Hz. The 10MHz can feed into a PLL to synthesise other frequencies as required. This allows them to run SSB at GHz frequencies, or the digital signals that occupy a few Hz bandwidth (I've forgotten what that mode is called). My el cheapo GPSDO (second hand $4 OCXO, PIC16F1455, NEO-6 GPS) does that easily, and with a stable temperature it will hold +-0.001Hz.
If the purpose of the GPSDO is to calibrate other equipment, then your approach looks good. I am not sure how well a single frequency GPS deals with atmospherics, it is suggested by others that in the region of 10^-11 it isn't great, and at that point one has to resort to very high quality oscillators and long averaging periods. However, it seems (on a quick read of the specs) that the LEA-M8F is already doing what you propose, it has inputs for external frequencies and can report phase errors. It also has the ability (it says) to discipline an external oscillator. I didn't read in too much depth but it seems they have pinched your idea.
-
@MIS42N: plz be so kind and do start to elaborate your design in a new thread (as recommended to you twice already). This thread is about Lars' design..
-
Lars;
the 8642B is overkill to make the 26Mhz ..plenty others out there that cost less, weight less, etc that could produce a "clean enough" 26MHz to do the job...key req for general purpose use in this app is for SG to accept an external 10MHz. Then u can lock the SG and measure all the ref u wish..
I left out the SG as Rf types typ have one already. But yes, its good u laughed at my joke.
Yes atmosphere is a big issue ..esp for phase...less so for Phase Rate .
I hope to do some experiments soon to determine the fidelity of the UBLOX 6T reported carrier phase data.
As for pinching the idea..its old one...I worked on a high end timing rec, years ago. that steered its own clock to zero out phase error. But it was primitive by todays standards.
I see the powers that be wish me to bow out of this conversation, see comment by IMO.
Color me gone.
-Dan
-
I now have two working GPSDOs that read the exact same freuency on my 9 digit counter - good enough for HF radio I think.
My solution to providing the 1PPS was to buy these modules:
https://www.ebay.co.uk/itm/Neo-6M-NE0-7M-GPS-Mini-Satellite-Positioning-Module-51-SCM-MCU-For-Arduino/142760332765?hash=item213d2dcddd:g:U6oAAOSwXeJawafs (https://www.ebay.co.uk/itm/Neo-6M-NE0-7M-GPS-Mini-Satellite-Positioning-Module-51-SCM-MCU-For-Arduino/142760332765?hash=item213d2dcddd:g:U6oAAOSwXeJawafs)
I removed the fake ublox chips with a hot air gun and soldered in genuine ones from Digikey. One GPSDO has a NEO-8M, the other an M8T.
Mike
-
I now have two working GPSDOs that read the exact same freuency on my 9 digit counter - good enough for HF radio I think.
My solution to providing the 1PPS was to buy these modules:
https://www.ebay.co.uk/itm/Neo-6M-NE0-7M-GPS-Mini-Satellite-Positioning-Module-51-SCM-MCU-For-Arduino/142760332765?hash=item213d2dcddd:g:U6oAAOSwXeJawafs (https://www.ebay.co.uk/itm/Neo-6M-NE0-7M-GPS-Mini-Satellite-Positioning-Module-51-SCM-MCU-For-Arduino/142760332765?hash=item213d2dcddd:g:U6oAAOSwXeJawafs)
I removed the fake ublox chips with a hot air gun and soldered in genuine ones from Digikey. One GPSDO has a NEO-8M, the other an M8T.
Mike
Just out of curiosity, how'd you figure those were fake?
-
I see the powers that be wish me to bow out of this conversation, see comment by IMO.
Color me gone.
-Dan
Dan
I doubt the comment was meant for you , or any design providing an accurate 1PPS that could be used in Lars design (the thread here).
It was probably meant for the PIC based design the MIS42N has done , and described in this thread.
That design is not based on Lars design , and ought to get a thread of it's own.
Btw: Dan's paper is in this entry , thank you
https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/msg3463482/#msg3463482 (https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/msg3463482/#msg3463482)
I have some quite good 26MHz Pletronics OCXO's , that i got for cheap's ~$5 , and a Lea5T ... hmmm.....
/Bingo
-
Just out of curiosity, how'd you figure those were fake?
They wouldn't respond to UBX commands to change the settings.
EDIT: not quite true. They did respond to the commands but wouldn't save the settings, so the modules reverted to Portable mode when they were switched on, which is no good for a GPSDO.
They cannot possibly sell them at such a low price with genuine ublox modules, although IMHO they are worth the money just to get the PCB. It's not one I could make at home.
https://portal.u-blox.com/s/question/0D52p00008HKEEECA5/psa-fake-ublox-modules-and-potential-ways-to-identify-them (https://portal.u-blox.com/s/question/0D52p00008HKEEECA5/psa-fake-ublox-modules-and-potential-ways-to-identify-them)
Mike
-
Bingo;
Well I am back , we will see if they get upset. I checked out the 26 ocxo xcel file , looks like a perfect candidate for driving lea6/5T.
If u have a 16 bit DAC and Aurdino , read the rate and phase error from Ucenter , drive the DAC with scaled rate err and u have a GPSDO. U can also add a small bit of ublx reported phase err avg w long tc, ~5min, this now makes UBLX 1pps phase smooth...if dome roght, no more jumps. To make 10Mhz locked to GPS, ! Just lock a 10MHz to 26MHz and now u have a 10MHz that is tied to GPS rate as close as your CAREFUL steering by DAC allows.
Now use that same PLL AGAIN, except now lock 26MHz to your XTAL source of choice:::
For generic freq err meter, lock the 26MHz to source u wish to find freq err wrt GPS time. I like the ADF4002 for this...easy PLL. Just set the dividers up for the freq of interest, now 26ocxo is locked to that. Err in ucenter is now the source to the 26 is locked to, so any rate erros are due to source u are locked to. . The source in question should be off by less than 20ppm?? ( not sure when ublx will be unhappy with rate err of its clock)
any more of the 26MHz VCOCXOs around??
-Dan
-
any more of the 26MHz VCOCXOs around??
-Dan
Dan
Most of the info regarding these OXCO's , incl. the exce , was made by J.Beale - Credit goes to him.
I doubt there are more of these on e-bay, they were sold back in 2011 by an e-bay seller petlor
I think they were surplus GSM stuff.
/Bingo
-
@MIS42N: plz be so kind and do start to elaborate your design in a new thread (as recommended to you twice already). This thread is about Lars' design..
I didn't want to do that until it was bulletproof. But you have a point.
The new thread is https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/ (https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/)
-
After my Vectron OCXO died I fitted my Lars/PaulV GPSDO with a Bliley NV47A, followed by a differential amp to square up the sinewave. The 10MHz output is isolated with a Mini-Circuits 50 ohm transformer.
Performance isn't brilliant (see attached) but the spike in the TIC is particularly interesting. It happens consistently when I connect the 10MHz output to test equipment (scope, counter etc.). I suspected an earth problem, and after a while realised that the Raspberry Pi that I use to monitor the data is powered from a wall wart, while everything else is connected to mains earth. The Pi is in a metal case which is not earthed, and using a DVM I measured 1.5V rms of 50Hz between the Pi case and the GPSDO earth.
Some tidying up is needed ...
Mike
-
Just out of curiosity, how'd you figure those were fake?
They wouldn't respond to UBX commands to change the settings.
EDIT: not quite true. They did respond to the commands but wouldn't save the settings, so the modules reverted to Portable mode when they were switched on, which is no good for a GPSDO.
..
My current understanding is the ublox module needs a battery backup to remember the settings, or am I mistaken?
-
You can save settings to flash, too. If the module has flash.
-
You can save settings to flash, too. If the module has flash.
Indeed you can, on the versions of the genuine modules that have flash memory.
These boards come with external memory and battery/supercap backup but it doesn't last very long.
Mike
-
Afaik for example the 7"M" is rom-based (an needs battery backup) and 7"N" has got the flash (provided it is not fake)..
https://portal.u-blox.com/s/question/0D52p00008HKCbDCAX/how-update-firmware-for-ublox-7-by-ucenter
-
Afaik for example the 7"M" is rom-based (an needs battery backup) and 7"N" has got the flash (provided it is not fake)..
https://portal.u-blox.com/s/question/0D52p00008HKCbDCAX/how-update-firmware-for-ublox-7-by-ucenter
Yes, that is correct. I replaced the modules with 8M and M8T which both have flash memory.
Mike
-
Unfortunately Lars is not among us anymore, but I just wanted to express my sincere admiration for the brilliant engineering in his DIY GPSDO project. The more I examine his circuit (which is apparently very simple) and the more I read his source code (well... not so simple), the more I understand the long hours and sheer dedication poured into this masterpiece project.
I have browsed through the dozen or so DIY GPSDO projects published on the net, and two projects really standout:
1. Brooks Shera's original project from 1998, which was the precursor to all other DIY GPSDO projects.
2. Lars' DIY GPSDO, which was inspired by Shera's design.
Both are based on a PLL control loop, but it's interesting to see how they differ in the way they implement it, and how each project tried to maximize the functionality of the MCU used (a PIC 16C73 in Brooks Shera's design, an ATmega 328P in Lars' design).
-
Hi Mike,
Last night/this morning, I finally got round to rerunning an experiment I did a few months ago to compare the timing offsets between the GPS, the Glonass and Galileo constellations where I discovered (but didn't make hard copy notes of) the offsets involved. I seem to recall that the Galileo offset from GPS had been in the 3 to 5 ns region whilst that of the Glonass had been a massive 18ns or so.
I reran only the GPS versus Galileo experiment (the Glonass had been so far out, I didn't see any point in repeating that experiment ::)) and my best estimate of the offset this time round was that it was somewhere around the 1 to 2ns mark.
Since I'd gained the impression that using the GPS on its own had definitely, if only slightly worsened the VFC variations to circa 600uV pk-pk versus the 300 to 400uV when using both GPS and Galileo together, I decided to go back to that combination after running this test.
The daily room temperature mediated VFC voltage excursions are around the the 1mV at present - not an issue as far as a basic James Miller styled GPSDO design is concerned. Quite frankly, a basic, microcontroller free GPSDO can deal with this sort of temperature variation (a half to one degree per hour rate of change) without any measurable detriment to its phase stability. With a single frequency timing module like the M8T, the biggest issue is that of the ionospheric induced phase shifts at rates of 1 to 5ns per 5 to 15 minutes and longer time periods which totally swamp the slower room temperature variations which are almost totally compensated for by being part of the PLL error correction process anyway.
The upshot of this being that I'm not at all surprised at your improved stability and tighter positional survey in results after ditching the GLONASS constellation. :)
John
Regarding the above, I now have what may be news to everyone. I'd put my RFS project in hiatus for lack of a suitable enclosure to accommodate the additional 2cm thick polystyrene foam all around the LPRO-101 and just recently decided to resume the project sans case but with the LPRO-101 insulated as above to continue testing - with that much insulation, an actual enclosure becomes somewhat redundant when running thermal stability tests.
Anyhow, the news is that including the Galileo constellation now seems to be degrading the timing as I eventually discovered after trying to syntonise the RFS to my basic GPSDO over the past three or four days. Instead of the 6ns pk-pk wobbles on the GPSDO's output, along with the corresponding 300μV variation on the VFC pin that I had been typically observing some eight months back, I was now seeing some 10 to 12ns pk-pk (along with 600μV variations in the VFC voltage) which was making my attempts at syntonising the RFS an all but impossible task.
I'd started monitoring the M8T's performance through the u-centre app the day after starting this current round of testing to see if there was any obvious reason for the degraded stability. Everything looked normal so I carried on struggling and monitoring for a few more days until this afternoon when I decided to exclude the Galileo SVs to see whether sticking only with the GPS SVs would have any effect.
After the initial 50ns phase excursion transient such configuration changes cause, there was an immediate improvement in the phase stability of the GPDSO's output. I'm still seeing variations but they now seem to be back to what they had been some eight months ago.
I'm now fine tuning the RFS after having forced the fan to run full tilt off its current 12v supply (I'm going to use 15 v in the final design) to bring the baseplate temperature down to just 3.2 deg C above room temperature to get a better idea of the max room temperature margin for my current 36 deg baseplate temperature setting. I expect to have a slightly lower delta T at that setting on account of it being closer to the physics package set temps with less heat energy being pumped in by the heaters (and a bit more whoomph courtesy of the 15v supply). I'm aiming for a max room temperature rating of 32 deg or better with a minimum room temperature limit around the 15 deg mark.
The lower limit will be defined by the level of passive heat leakage when the fan is at a standstill. To this end I'm mounting the LPRO-101 on its edge with the fan cooled heatsink fins parallel to the base to minimise convective cooling from the plenum intake mounted to draw in cooling air via a large vent in the base of the enclosure which will be raised by 10mm rubber feet. The exhaust air vents will be low down on the rear panel to kill off any convective air flow to minimise heat loss at the lower temperature extreme. However, I will be testing the current uncased assembly outdoors in the cool night air to determine whether I actually need to go to quite such an extreme with the ventilation layout (or, Heaven forfend! add a "cold weather" heating circuit).
Anyhow, it does look as though using both GPS and Galileo constellations together is now no longer the good idea it once was. :( The chances of getting the RFS to keep within half a cycle or better over a 24 hour test run are now looking a lot better since I dropped the Galileo constellation. Only time will tell.
-
I have the results for my "24 hour" test run, comparing my RFS project's frequency stability against a modern day respin of the rather worthy James Miller GPSDO (essentially just a GPS rx module update using a u-blox M8T instead of the original Jupiter GPS engine).
The "24 hour" test run was more like a 26 to 28 hour run, hence the quotes. Anyhow, I didn't manage to achieve the half cycle in 24 hours target I'd hoped to hit but did manage to better the one cycle drift limit in 24 hours which I'd not been able to manage in any of my earlier tests over six months ago.
One of the issues being the question of the sensitivity of the LPRO-101 to barometric pressure variations which in my location, showed up as a drop from 1003 to 983 mBars during the past three days, over half of which occurred in just the last 24 hours. According to this Dec 1975 NIST document https://tf.nist.gov/general/pdf/82.pdf I would have expected the RFS to have dropped in frequency rather than show the increase revealed by my test run.
That NIST document whilst getting on for half a century old offers some interesting insights into Rb lamp atomic clock technology which remains essentially unchanged between then and when my LPRO-101 had been manufactured circa 1998 with some 23 years worth of technological refinements (eg the unnamed unit they'd used was twice the volumetric size of the LPRO).
I'd started this test run yesterday, just before teatime (6pm BST or 1700 hrs UTC - the scope date/time being 4 minutes behind UTC makes this a relevant point), possibly even an hour earlier but it hadn't occurred to me to take a screenshot or two to mark the event. If I had, it would have looked a dead ringer for the final screenshot of the sequence I took over the final 5 hours or so of the run.
I've archived them into two 7z files to stay within the EEVBlog 5MB server limit and attached the first 7z file plus the first 9 images uncompressed to this post with the second 7z file plus the last 9 uncompressed images to the follow up post for anyone the least bit curious in my RFS v GPSDO stability contest. I've included the uncompressed images as a common courtesy to those, who like me, find it a bit of an imposition to have to actually download an attachment before you get the chance to view its contents.
I've chosen to trigger from the GPSDO (CH2) even though that's the source of the 6ns pk-pk wobble simply because long term it remains within a few ns of the World's Atomic Time reference (effectively 'zero drift'). The RFS (CH1), otoh, can and will drift even if that drift is some 2 or 3 orders of magnitude less than a typical OXCO, hence the need to calibrate it against a World Atomic Clock derived standard such as that offered by the GPS system.
-
As per the preceding post, here are the second lot of attachments.
-
Hope there is someone here that understands the calculation routine
Somewhere at the beginning there is this line
timer_us = timer_us + 50000 - (((timer1CounterValue - timer1CounterValueOld) * 200 + TIC_Value - TIC_ValueOld)+50000500)/1000;
and later
diff_ns = (timer_us - timer_us_old)*1000 + long (TIC_ValueCorr - TIC_ValueCorrOld + 0.5); // = Frequency in ppb if updated every second! Note: TIC linearized
Where TIC_ValueCorr is the quadratic corrected TIC_Value
So why is the phase used twice? Once with the uncorrected value and once with the corrected value?
-
Hope there is someone here that understands the calculation routine
...
So why is the phase used twice? Once with the uncorrected value and once with the corrected value?
Hi Erik,
I have little knowledge of the Lars' source code, but from my limited understanding:
1. The TIC is very much non-linear, so you want the linearized (corrected) phase values when they are used to calculate the OCXO frequency.
2. On the other hand, the non-linearity does not seem to affect the timer calculation, so the non-linearized (uncorrected) values can be used.
-
Hello,
I would like to upload Lars' code to GitHub, so I wanted to know if anybody here is aware of what open source license would be applicable (of course the copyright is and will remain Lars Walenius, over the software and hardware design).
Also if there is any member of the family or friends I should ask for permission and how to get in touch?
Thank you all for your help regarding this matter.
Andrew
-
You may contact forum member HighVoltage, he may be in contact with his family. See below.
https://www.eevblog.com/forum/metrology/farewell-to-our-friend-lars/ (https://www.eevblog.com/forum/metrology/farewell-to-our-friend-lars/)
-
You may contact forum member HighVoltage, he may be in contact with his family. See below.
https://www.eevblog.com/forum/metrology/farewell-to-our-friend-lars/ (https://www.eevblog.com/forum/metrology/farewell-to-our-friend-lars/)
Thank you. :-+
PM sent to HighVoltage.
-
After receiving a kind answer from HighVoltage, I have created a repository on GitHub for Lars' DIY GPSDO with copyright 2017 Lars Walenius on all files, under a GPL V3 Open Source license.
This I believe respects Lars' wishes for his project, before he passed away.
The files are unchanged from Lars' first post in this thread.
The repository is here: https://github.com/AndrewBCN/Lars-DIY-GPSDO
The README in the repository points back to this thread.
-
After receiving a kind answer from HighVoltage, I have created a repository on GitHub for Lars' DIY GPSDO with copyright 2017 Lars Walenius on all files, under a GPL V3 Open Source license.
This I believe respects Lars' wishes for his project, before he passed away.
The files are unchanged from Lars' first post in this thread.
The repository is here: https://github.com/AndrewBCN/Lars-DIY-GPSDO
The README in the repository points back to this thread.
Very nice of you and very respectful of late Lars. Thank you.
Regards,
Sinisa
-
Hi,
I have undertaken the long term project of refactoring Lars' code / Arduino sketch for his GPSDO. My objective is to keep Lars' code mostly intact without any changes or adding any new features, but add comments, rearrange the code, correct the indentation and other formatting details, etc to improve readability and maintainability. Note that this is in no way a criticism of Lars' elegant code.
I guess I'll spend around an hour per week for the coming months working on this.
If any of you have read or worked on Lars' code and would like to comment or discuss any parts, please feel free to chime in. There are many parts that are still a black hole for me, and unfortunately Lars is not among us anymore to answer any questions.
To give you an example of the mostly trivial changes I am making to the original code:
Lars used
Serial.println("");
which I replace with
Serial.println();
Attached what I have done until now. I'll probably post on my progress around once per month.
EDIT: I forgot to add that I am currently building a version of Lars' DIY GPSDO to be able to test the refactored code for regressions. I'll post a few pics once I have it working.
-
Hi,
I have undertaken the long term project of refactoring Lars' code / Arduino sketch for his GPSDO. My objective is to keep Lars' code mostly intact without any changes or adding any new features, but add comments, rearrange the code, correct the indentation and other formatting details, etc to improve readability and maintainability. Note that this is in no way a criticism of Lars' elegant code.
I guess I'll spend around an hour per week for the coming months working on this.
If any of you have read or worked on Lars' code and would like to comment or discuss any parts, please feel free to chime in. There are many parts that are still a black hole for me, and unfortunately Lars is not among us anymore to answer any questions.
To give you an example of the mostly trivial changes I am making to the original code:
Lars used
Serial.println("");
which I replace with
Serial.println();
Attached what I have done until now. I'll probably post on my progress around once per month.
EDIT: I forgot to add that I am currently building a version of Lars' DIY GPSDO to be able to test the refactored code for regressions. I'll post a few pics once I have it working.
Isn't the first print case used to print string data and the second to print a value of a variable?
Edit: OK, I looked at your code and then read https://forum.arduino.cc/t/serial-print-f-hello-world/411623
I wanted to add the ability to print to OLED and read GPS NMEA data, and I think I needed more program space than the 328 has to do so.
Thanks!
-
...
Lars used
Serial.println("");
which I replace with
Serial.println();
Isn't the first print case used to print string data and the second to print a value of a variable?
What this code does in both cases is simply print a linefeed character to serial. Adding the empty double quotes "" (an empty string) as a parameter changes strictly nothing so is redundant.
It's a very tiny change in Lars' code but it's the sort of thing that improves the readability, imho.
And indeed, Lars' code is very dense, because he had to work with the ATmega328P's limited 32kB of flash and 2kB of RAM. I haven't tried it myself but I don't think there is enough program space left to add code for a display or a GPS library to parse NMEA messages.
I do have an OLED and I do parse NMEA messages in my STM32 GPSDO, but I am using 130kB of flash. 8)
-
That is what I figured so it seemed I would use a second 328p to read both the GPS and the serial out of Lars' 328p controller.
-
Use assembler for 8 bit processors. C is OK when there's plenty of memory. PIC16F1455 has 14kbyte program memory and 1kbyte RAM. My GPSDO program occupies about half the program and most of the RAM. Fully decodes NMEA messages to get date, time, validity of fix. 32 bit signed arithmetic. Could use less RAM, it keeps a history of control voltage changes. I was going to use a nano but it didn't have the right peripherals. Driving a display would be tricky with 14 pin package, would need to go to 20 pin PIC16F1459.
-
That is what I figured so it seemed I would use a second 328p to read both the GPS and the serial out of Lars' 328p controller.
Use assembler for 8 bit processors. C is OK when there's plenty of memory. PIC16F1455
...
There are probably various different solutions, it really all depends on what family of processors and programming tools you feel more comfortable working with.
-
Hey all - I got inspired to pull out my lars GPSDO project. I didn't have a good GPS and recently came across the Condor C1919C module (PPS +/-25ns). It's still a navigation GPS but much better than what I had. Even so, I was not getting stable lock status even at low TC. One thing I wanted to try was to generate the PPS from a 10M OCXO using PICDiv, and here I have set that up, but I still do not get good lock status.
The ns stabilizes at large offsets. I think Lars said somewhere that the system needs some instability, but it's been a while so not sure. I'd expect this setup to drift, but rather slowly, and still keep very good lock.
Here is plot of ns and DAC after initiating run mode (after a day of warm-up). tc=4. ns settles in at ~-1500. I am monitoring both 10M reference and 10M disciplined OCXO on scope and see it tune in fairly quickly. The routine always starts at top end of dac and seems to stop when it gets the signal stable in phase rather than tune in to a low ns value. Lars says that Lock will occur when the TIC value is within 100ns for five time constants. He mentions TC=16s so maybe with tc=4 that is different?
(https://i.imgur.com/3ve05Vp.png)
Here is 3000 seconds plot of ns and lock status. tc=4. I am not sure why it goes in/out of lock when it does.
(https://i.imgur.com/N25aBmp.png)
I have not had success acquiring lock with higher tc, but these runs above were latest after tinkering with tuning pots and voltage regulator circuit so will try again now.
Another thing that might be plaquing my project is the OCXO. I've noticed some spikes or frequency jumps. When I see a 60ns spike, the same DAC line has a spike. Then I'm not sure if the DAC made the spike or it's reacting to change in frequency, or maybe the flip-flop missed a cycle. I suspect some frequency jumps I was seeing, where the ns value suddenly changed 200ns might have been due to flakey tuning pot on ref xo.
Update:
Here is plot of run after changing tc=16. It stabilizes quickly around ns=4100. It will run like this but never get lock.
(https://i.imgur.com/exIaa6B.png)
-
I didn't have a good GPS and recently came across the Condor C1919C module (PPS +/-25ns). It's still a navigation GPS but much better than what I had. Even so, I was not getting stable lock status even at low TC. One thing I wanted to try was to generate the PPS from a 10M OCXO using PICDiv, and here I have set that up, but I still do not get good lock status.
...
From the charts you posted it seems to me like your GPS module is frequently loosing good satellite acquisition, which causes the PLL to lose lock, then when the GPS reacquires enough satellites, the PLL (with a short time constant) reacquires lock, and the cycle repeats erratically. AFAIK some GPS modules will continue to output a 1PPS signal even when they have marginal satellite reception and their accuracy is all over the place. The PPS +/-25ns specification assumes ideal conditions.
Lars' DIY GPSDO like many other DIY GPSDOs was not designed to monitor the GPS module satellite reception, you have to rely on an external device (a PC, another MCU, or an SBC such as a Raspberry Pi) reading the serial output stream from the GPS module to understand what is happening. If you were using a u-blox module I would advise you to check your GPS module with u-blox ucenter, otherwise there is the excellent Lady Heather software.
All the above assumes you are using the 1PPS from the GPS module as an input to Lars' TIC. You should not use the 1PPS from a picDIV connected to a second 10MHz OCXO, as an input to Lars' TIC. Otherwise what you'll get is exactly what you got: a fixed, more or less constant phase difference that never gets reduced to <100ns (you never get a PLL "locked" status).
-
I didn't have a good GPS and recently came across the Condor C1919C module (PPS +/-25ns). It's still a navigation GPS but much better than what I had. Even so, I was not getting stable lock status even at low TC. One thing I wanted to try was to generate the PPS from a 10M OCXO using PICDiv, and here I have set that up, but I still do not get good lock status.
...
From the charts you posted it seems to me like your GPS module is frequently loosing good satellite acquisition, which causes the PLL to lose lock, then when the GPS reacquires enough satellites, the PLL (with a short time constant) reacquires lock, and the cycle repeats erratically. AFAIK some GPS modules will continue to output a 1PPS signal even when they have marginal satellite reception and their accuracy is all over the place. The PPS +/-25ns specification assumes ideal conditions.
Lars' DIY GPSDO like many other DIY GPSDOs was not designed to monitor the GPS module satellite reception, you have to rely on an external device (a PC, another MCU, or an SBC such as a Raspberry Pi) reading the serial output stream from the GPS module to understand what is happening. If you were using a u-blox module I would advise you to check your GPS module with u-blox ucenter, otherwise there is the excellent Lady Heather software.
All the above assumes you are using the 1PPS from the GPS module as an input to Lars' TIC. You should not use the 1PPS from a picDIV connected to a second 10MHz OCXO, as an input to Lars' TIC. Otherwise what you'll get is exactly what you got: a fixed, more or less constant phase difference that never gets reduced to <100ns (you never get a PLL "locked" status).
I went back to using my Condor GPS and monitored status using Trimble time lab. It only locks to 9 SVs but showed to be fully locked. From what I can tell, it's actually locked as the diff_ns numbers wander around low values like usual (mostly under 10 with periodic 20-30ns jumps + or -). For some reason it settles in a few thousand ns low.
I'm not sure why a 10M OCXO divided down to 1Hz would not be a suitable PPS for testing? I certainly expect a free-running OCXO to drift, but wouldn't the drift, especially divided down, be very small and take years to show in any significant way? I've had a free running OCXO that I tuned to another GPS reference a couple years ago. I measure that one periodically and the long term drift has been trending in the same direction and is +3.5 Hz over the two year period (using a counter referenced to GPSDO). That is just within its aging spec. The short term drift of the ÷10M should be on the order of ps.
This is the same project board and setup I was using with a +/- 100ns GPS a couple years ago and it used to at least lock in around 0 ns. I think something is wrong but cannot figure out what. The 1M, 5M, and 1us decay are all there.
-
...
I'm not sure why a 10M OCXO divided down to 1Hz would not be a suitable PPS for testing?
...
Because unless you are disciplining the OCXO, the 10MHz from the OCXO divided down to 1 Hz does not really get you 1Hz, it gets you a 1s period +/- a fixed bias. That is not a problem per se, but (if I have understood Lars' "calculation" routine correctly) Lars' DIY GPSDO does various calculations based on the assumption that the 1PPS from a GPS has an exact 1s period with a statistically zero bias (which is a very reasonable assumption, I think). I believe this is why you get: "... The routine always starts at top end of dac and seems to stop when it gets the signal stable in phase rather than tune in to a low ns value..."
You can check if I am right or wrong by simply switching back the 1PPS to that from a GPS, and verifying whether or not you get a low ns value.
Note that all the above is from the little I managed to understand of Lars' code, and maybe I am completely wrong.
-
...
I'm not sure why a 10M OCXO divided down to 1Hz would not be a suitable PPS for testing?
...
Because unless you are disciplining the OCXO, the 10MHz from the OCXO divided down to 1 Hz does not really get you 1Hz, it gets you a 1s period +/- a fixed bias. That is not a problem per se, but (if I have understood Lars' "calculation" routine correctly) Lars' DIY GPSDO does various calculations based on the assumption that the 1PPS from a GPS has an exact 1s period with a statistically zero bias (which is a very reasonable assumption, I think). I believe this is why you get: "... The routine always starts at top end of dac and seems to stop when it gets the signal stable in phase rather than tune in to a low ns value..."
You can check if I am right or wrong by simply switching back the 1PPS to that from a GPS, and verifying whether or not you get a low ns value.
Note that all the above is from the little I managed to understand of Lars' code, and maybe I am completely wrong.
Hm, as far as I understood Lars' code, the control loop will align the disciplined LO to whatever source provides the 1PPS. If that's a separate divided-down 10MHz OCXO, the disciplined LO will be phase aligned with it. I've frequently used a 1PPS signal out of an AWG for testing and it always worked within reason, so long as the 1PPS was somewhat close to 1 second. Within reason means that the target frequency for the LO must be within its pull range, of course. But that's the only limitation, AFAICS. The control code will take the LO frequency as gospel. So the ns readings may be indeed a bit off against an external, accurate time source, but that's about it.
-
...
I'm not sure why a 10M OCXO divided down to 1Hz would not be a suitable PPS for testing?
...
Because unless you are disciplining the OCXO, the 10MHz from the OCXO divided down to 1 Hz does not really get you 1Hz, it gets you a 1s period +/- a fixed bias. That is not a problem per se, but (if I have understood Lars' "calculation" routine correctly) Lars' DIY GPSDO does various calculations based on the assumption that the 1PPS from a GPS has an exact 1s period with a statistically zero bias (which is a very reasonable assumption, I think). I believe this is why you get: "... The routine always starts at top end of dac and seems to stop when it gets the signal stable in phase rather than tune in to a low ns value..."
You can check if I am right or wrong by simply switching back the 1PPS to that from a GPS, and verifying whether or not you get a low ns value.
Note that all the above is from the little I managed to understand of Lars' code, and maybe I am completely wrong.
Hm, as far as I understood Lars' code, the control loop will align the disciplined LO to whatever source provides the 1PPS. If that's a separate divided-down 10MHz OCXO, the disciplined LO will be phase aligned with it. I've frequently used a 1PPS signal out of an AWG for testing and it always worked within reason, so long as the 1PPS was somewhat close to 1 second. Within reason means that the target frequency for the LO must be within its pull range, of course. But that's the only limitation, AFAICS. The control code will take the LO frequency as gospel. So the ns readings may be indeed a bit off against an external, accurate time source, but that's about it.
That's what I expect. Time is a relative thing, so the system has no reference to absolute time. I expect the reference OCXO primary phase drift to be less than 0.1rad/day, and 10 million times less on the PPS.
My second plot above shows phase wander between -1110ns to -1120ns (10ns total) over more than 600 seconds. I think I could say that is the noise of the system, but I the fact it's locked in so far off I cannot say. I cannot even toss out wild ideas of why it's behaving this way.
Any suggestions? I'm going to reload the Arduino code in the off chance I was monkeying around with it a couple years ago (unlikely).
-
I figured out the problem!
My tempcoeff was set to max dac. I bet I fat fingered a dac setting (d vs c). I was absolutely going bonkers. Top it off, this new PC had to have everything set up again. I could not get the Arduino IDE to program (had to set tools>processor>old bootloader), and then I was not aware that EEPROM data is not erased when uploading a new "sketch". That is what gave me a clue - to look for f2 defaults.
Actually, I have a new theory how this happened. A high energy, OMG cosmic particle came from deep space, scattered through our atmosphere, and one of the secondary particles hit my Arduino and flipped the tempcoeff value's msb. It's happened before, and it coulda happened to me too... :P
Thanks everyone who chimed in. Please continue the normal discussion...
-
Hey everyone! It's been a while since I last posted in this thread, but I was working on a schematic/PCB for my version of the GPSDO and got sidetracked with life, the pandemic, etc.
Anyway, I'm hoping to finally get my boards sent off to the fab, but I'd love for the community here to take one more look at my schematic & board to make sure nothing looks majorly out of place. I'll be using the Bliley NV47M OCXO since I have a couple used ones on hand. Had to make a decent amount of changes to account for the current chip shortage, but everything should be in stock with this version and the total comes into around $60 which is fantastic for a GPSDO in my book.
(https://i.imgur.com/4MY1Amzl.png) (https://i.imgur.com/4MY1Amz.png)
(https://i.imgur.com/kPkqRvbl.png) (https://i.imgur.com/kPkqRvb.png)
Let me know what you think! Made some definite compromises, went for a single 5V regulator instead of dual analog/digital 5V rails, could maybe use some more filtering, but eh. I'm not going for a precision lab instrument or timenutz street cred. I just want a cheap GPSDO for aligning some radios.
-
Hey everyone! It's been a while since I last posted in this thread, but I was working on a schematic/PCB for my version of the GPSDO and got sidetracked with life, the pandemic, etc.
Anyway, I'm hoping to finally get my boards sent off to the fab, but I'd love for the community here to take one more look at my schematic & board to make sure nothing looks majorly out of place.
...
Hi Axel, and first: thank you. A question: it seems you are connecting the MCU serial port to the GPS module, unlike Lars' original schematic. But there is no provision in Lars' original code to communicate with the GPS, or to indicate a status on any of the extra LEDs you have included. Do you have an extended version of the Lars' GPSDO firmware to go with your schematic?
Two more little details: OSC_CTRL from the DAC is drawn as an input but it is really an output, ditto for the LEDs and the MCU UART Tx; and the RST(inverted) bus is not connected to anything (as far as I can tell).
The PCB looks very well laid out, with just one little detail that I would change if possible: TP1 (GPS PPS) would be under the GPS module if the module is mounted horizontally, can it be moved someplace else?
-
Hey everyone! It's been a while since I last posted in this thread, but I was working on a schematic/PCB for my version of the GPSDO and got sidetracked with life, the pandemic, etc.
Anyway, I'm hoping to finally get my boards sent off to the fab, but I'd love for the community here to take one more look at my schematic & board to make sure nothing looks majorly out of place.
...
Hi Axel, and first: thank you. A question: it seems you are connecting the MCU serial port to the GPS module, unlike Lars' original schematic. But there is no provision in Lars' original code to communicate with the GPS, or to indicate a status on any of the extra LEDs you have included. Do you have an extended version of the Lars' GPSDO firmware to go with your schematic?
Two more little details: OSC_CTRL from the DAC is drawn as an input but it is really an output, ditto for the LEDs and the MCU UART Tx; and the RST(inverted) bus is not connected to anything (as far as I can tell).
The PCB looks very well laid out, with just one little detail that I would change if possible: TP1 (GPS PPS) would be under the GPS module if the module is mounted horizontally, can it be moved someplace else?
Expanded firmware is something I'm planning on doing. Hoping to allow for some kind of passthrough from the GPS module through the 32u4's USB serial port. And adding in the status LEDs as well. Of course, I could also just break out the RX/TX lines of the GPS if needed down the road.
Good call on the PPS test point. Super easy to move so I'll do that.
As far as the flag direction, that's just the default KiCad flag. It doesn't differentiate between an input and an output. Just a minor schematic detail. But thanks for mentioning it.
EDIT
Alright, boards and parts have been ordered. This is right about the time someone replies and points out a glaring error in my design :P
-
Had to make a decent amount of changes to account for the current chip shortage, but everything should be in stock with this version and the total comes into around $60 which is fantastic for a GPSDO in my book.
:
:
I just want a cheap GPSDO for aligning some radios.
When you say total $60 is that GPS antenna, GPS module, OCXO, populated PCB, power supply, suitable enclosure? I costed out my GPSDO design (which BTW decodes all NMEA and can do NMEA passthru) for an OCXO and populated PCB at less than $12US. But once you add GPS antenna $12, GPS module $6, enclosure $4, wall wart (will work off a $5 USB charger so say $5 although usually there's a better spare one somewhere) and serial/USB converter the total blows out to nearer $40.
-
Had to make a decent amount of changes to account for the current chip shortage, but everything should be in stock with this version and the total comes into around $60 which is fantastic for a GPSDO in my book.
:
:
I just want a cheap GPSDO for aligning some radios.
When you say total $60 is that GPS antenna, GPS module, OCXO, populated PCB, power supply, suitable enclosure? I costed out my GPSDO design (which BTW decodes all NMEA and can do NMEA passthru) for an OCXO and populated PCB at less than $12US. But once you add GPS antenna $12, GPS module $6, enclosure $4, wall wart (will work off a $5 USB charger so say $5 although usually there's a better spare one somewhere) and serial/USB converter the total blows out to nearer $40.
BOM cost (minus OCXO and enclosure): $42 + $5 shipping
PCB: $25/5 from JLCPCB so $5/ea
OCXO (Bliley NV47 series): $30/3 = $10/ea
Enclosure (Hammond 1455K1201): $15
So for a complete GPSDO minus antenna and power supply (I already have both on-hand) it comes out to a little under $80. I had already bought the OCXOs and the enclosure so my goal was to get PCB + parts under $60, and I did.
-
I'm surprised nobody pointed out that my amplifier design for the 10MHz output was totally incorrect :) oh well - I bodged it into a unity gain buffer and all is well.
I've got the board assembled and it's up and running. Next plan is writing up the software. Is there a "recommended" arduino sketch for the GPSDO, or is everyone pretty much rolling their own based on the original document?
-
I'm surprised nobody pointed out that my amplifier design for the 10MHz output was totally incorrect :) oh well - I bodged it into a unity gain buffer and all is well.
I've got the board assembled and it's up and running. Next plan is writing up the software. Is there a "recommended" arduino sketch for the GPSDO, or is everyone pretty much rolling their own based on the original document?
I think most are starting with the "original code" from Lars first post.
He had to name the upload extension .ino.txt , to get the forum to accept it.
/Bingo
-
I'm surprised nobody pointed out that my amplifier design for the 10MHz output was totally incorrect :) oh well - I bodged it into a unity gain buffer and all is well.
I've got the board assembled and it's up and running. Next plan is writing up the software. Is there a "recommended" arduino sketch for the GPSDO, or is everyone pretty much rolling their own based on the original document?
Check out Lars' first post in this thread, it has his original Arduino sketch attached. Or you can check the GitHub repository I created for Lars' files, here: https://github.com/AndrewBCN/Lars-DIY-GPSDO
I would be grateful if you would fork this GitHub repository and add your files to your fork, then make a pull request for all your work. You can also change the README file which I wrote, to include as much information as you want about your work.
Finally: I got started on editing Lars' Arduino sketch for improved formatting and comments (essentially no changes to the code itself), if you want I can send it to you in a PM.
On a side note: I was shipped a bunch of fake LM35DZ temperature sensors from a vendor on AliExpress; they are just NPN transistors. I opened a dispute and was promptly refunded.
-
The software in Lars first post is not bound to GPL v3.
Could be used as ie. lgpl or the like
/Bingo
-
The software in Lars first post is not bound to GPL v3.
Could be used as ie. lgpl or the like
/Bingo
Lars did not specify any open source license for any part of his work before he passed away, and very modestly did not even reserve any copyrights. I had to assume his wish was to make all parts of his GPSDO design, including the firmware, available to any other person without any restrictions apart from retaining the "openness" and the fact that he is the original author, as the name of the project clearly indicates ("Lars' DIY GPSDO"). Hence the choice of the GPLV3 license for the files on GitHub. I believe this respects most closely the spirit with which Lars posted the project files here on the EEVblog forum.
The LGPL is a different license primarily used for software libraries. It's not really suitable for a project such as Lars' DIY GPSDO.
Btw now that Lars' files are on GitHub under a GPL V3 license and under his copyright, I would question the ethics of anybody claiming the copyrights of the same or modified files or any change in the applicable open source license (in other words, changing from GPL V3 to any other license).
If anybody here is in doubt about what all this means or wants to know the nitty-gritty, please check: https://opensource.org/licenses
-
Btw now that Lars' files are on GitHub under a GPL V3 license and under his copyright, I would question the ethics of anybody claiming the copyrights of the same or modified files or any change in the applicable open source license (in other words, changing from GPL V3 to any other license).
Nobody would be claiming anything, they're just not bound to adhere to your gpl v3 license invention , if using Lars original sources.
I have downloaded & used that software back when Lars posted it here, and have been using it long before you made that repos.
Must be a bit like prior art.
And while i agree that Lars meant it should be usable for all as in free to the public, I can't see anywhere where it even suggests it should be GPL.
It could just as easy have been a beerware , MIT , apache or BSD license, and that has nothing to do with ethics.
/Bingo
-
Got my GPSDO board assembled, and it's up and running. For the most part at least. OCXO is alive, the MCU is programmable via USB, and nothing has let the smoke out yet.
However, it looks like the 32u4 with the Pro Micro bootloader doesn't like the interrupt that Lars used for the PPS signal. His original arduino code hangs after startup waiting for the PPS to trigger, but it never fires despite having a good PPS signal. I'll have to look into why that is. I'm guessing there's some annoying conflict with that interrupt and the USB bootloader causing things to go wrong.
Days like this I wish I knew more about embedded programming.
-
The software in Lars first post is not bound to GPL v3.
Could be used as ie. lgpl or the like
/Bingo
Lars did not specify any open source license for any part of his work before he passed away, and very modestly did not even reserve any copyrights. I had to assume his wish was to make all parts of his GPSDO design, including the firmware, available to any other person without any restrictions apart from retaining the "openness" and the fact that he is the original author, as the name of the project clearly indicates ("Lars' DIY GPSDO"). Hence the choice of the GPLV3 license for the files on GitHub. I believe this respects most closely the spirit with which Lars posted the project files here on the EEVblog forum.
The LGPL is a different license primarily used for software libraries. It's not really suitable for a project such as Lars' DIY GPSDO.
Btw now that Lars' files are on GitHub under a GPL V3 license and under his copyright, I would question the ethics of anybody claiming the copyrights of the same or modified files or any change in the applicable open source license (in other words, changing from GPL V3 to any other license).
If anybody here is in doubt about what all this means or wants to know the nitty-gritty, please check: https://opensource.org/licenses
The nitty-gritty is that Lars didn't specify a license, and if his action of posting it on this website isn't considered a release into the public domain, then factually his next-of-kin now own the copyright. I would not dare making any assumptions on his intentions. I consider the GPLv3 very restrictive and demanding. Knowing nothing about what the original author intended, this is not the license I'd have chosen.
-
MEGA32U4
DS. pg. 79
Uses Pin D4 (avr pin) for Timer1 ICP (Input capture) - M328 uses PB0 (Avr pin)
ICP1/ADC8 – Port D, Bit 4
ICP1 – Input Capture Pin 1: The PD4 pin can act as an input capture pin for Timer/Counter1.
/Bingo
-
Nobody would be claiming anything, they're just not bound to adhere to your gpl v3 license invention , if using Lars original sources.
....
/Bingo
Seems like I have to dot the i's and cross the t's in this matter.
As we all know, unfortunately Lars passed away before he could choose and specify any license for his project, and as I mentioned, he did not even reserve the copyright for his work. From a licensing and copyrights point of view, his work was in a sort of limbo until now.
For the record, at the end of September (around a month ago) I announced here in this thread that I was creating a repository on GitHub for Lars' project, that I was reserving the copyright over the files in the repository in Lars' name and that I was choosing the GPL V3 (GitHub asks you to choose a license for any repository created there). I asked for comments at the time.
Now you are objecting to that choice? A little bit late, isn't it?
You seem to not understand (or not want to understand) that an Open Source license is there to protect YOUR freedom as well as the freedom of every single EEVblog forum member. What would happen if somebody in this thread or elsewhere claimed the copyright over Lars' work for himself, and/or decided to change the license to a restrictive one, with royalties and fines?
So yes, it is very much a question of ethics, and I believe I made the ethically correct decisions to protect Lars' work, to respect his wishes, and to protect everyone's freedom to use his design and source code with the very few and very reasonable restrictions that are spelled out in the GPL V3, which you can read here: https://www.gnu.org/licenses/gpl-3.0.en.html (https://www.gnu.org/licenses/gpl-3.0.en.html)
I consider the GPLv3 very restrictive and demanding. Knowing nothing about what the original author intended, this is not the license I'd have chosen.
That's your personal opinion, and you are fully entitled to it, and of course you are free to choose whatever license you want for your own projects or not even specify any. That is, of course, if you have developed and published any projects at all.
Now let's be clear: there are literally millions of software projects licensed under the GPL V3, and in fact it is the 4th most popular software license worldwide (the older GPL V2 is the second most used).
A few examples:
1. The Arduino IDE, which Lars used, is licensed under the GPL.
2. The gcc toolchain, which is used by the Arduino IDE and hence which was used by Lars, is licensed under the GPL.
I must say I am rather shocked that some of you who have been following this project since the early days when Lars was still alive, have never bothered to check with him what license he was willing to apply to his design and code. Or even after he passed away, have never bothered to clarify this matter with his family and friends.
And now, one month after I asked for comments, you are objecting to the choice of the perfectly adequate GPL V3, which apparently you have not even bothered to read? :--
-
Seems like someone already made a github repos 10+ month ago , and made his version of Lars GPSDO licenced with MIT.
https://github.com/paulvee/Lars-GPSDO
So why should your GPLV3 be the chosen one.
paul's repos came before you, and he made a lot of experiments with Lars code.
I do agree that paul didn't publish Lars unmodified sources in his name, but just because you put Lars files on github,
does not give you the right to chose what license Lars original files belongs to.
What would happen if somebody in this thread or elsewhere claimed the copyright over Lars' work for himself, and/or decided to change the license to a restrictive one, with royalties and fines?
You just did
/Bingo
-
You just did
NO.
More than one month ago, I created a repository on GitHub for Lars' files, after consulting with the person that was closest to him and to his family that I could get a hold of. Lars' work was in license limbo and I chose the latest version of the same license that the tools he used to create his project are under, as a license for his work. I asked for comments on this thread and as the records show, you did not object at the time. In fact nobody objected in any way.
Had you or anybody objected at the time we could have had a sensible discussion over the finer points of various open source licenses. But now I just feel nauseated having to discuss this with you.
-
Regarding the MIT license, and an important difference compared to the GPL V3 license:
"The MIT License is short and to the point. It lets people do almost anything they want with your project, like making and distributing closed source versions."
I don't think Lars would want to see people making and distributing closed source ("black box") versions of his project.
So GPL V3 it is. And why V3 and not V2? Because V3 is the latest version of the GPL.
-
Got my GPSDO board assembled, and it's up and running. For the most part at least. OCXO is alive, the MCU is programmable via USB, and nothing has let the smoke out yet.
However, it looks like the 32u4 with the Pro Micro bootloader doesn't like the interrupt that Lars used for the PPS signal.
...
Sorry for not noticing this before, but apparently the 32u4 alternate function pin assignments are very different from those of the 328. So not only the PPS has to be input on a different pin, but also the 5MHz (the OCXO 10MHz divided by 2 by the 74HC390). And you'll probably have to change some of the pins you are using to drive the LEDs too.
No smoke, but a few traces to cut and a few wires to solder here and there, and a few lines of code to edit. You should get it working in a couple of hours! :-+
-
Let he who has made a perfect board in one attempt cast the first stone
(https://i.imgur.com/NLFAwTMl.jpg)
Looks like things are working! Log prints are running, I ran through a basic calibration with Lars' guide, and my diff_ns is slowly approaching 0. We'll see if the thing actually locks properly. Fingers crossed!
Is there a guide or a link to a post in this thread with instructions on how to set up Timelab for monitoring the various parameters? I'm still reading to learn exactly what ADEV and MDEV are, but Lars had nice plots of them in Timelab and I have no clue what I'm doing on that front. Found the handy appendix in Lars' documentation. It helps to read. :)
Looks like I need to do some more calibration. Still haven't gotten a lock after 10 minutes, and my diff_ns value has been going from -30 to +30, with occasional jumps to -160 or so.
-
Here's where I'm at after 45 minutes
3248 -431 41681 6.3 NoLock 6 360 32 1 28109 56 1103 0 0 0
3249 -427 41680 6.3 NoLock 4 400 32 1 28109 59 1104 0 0 0
3250 -422 41681 6.3 NoLock 5 460 32 1 28109 63 1105 0 0 0
3251 -418 41682 6.3 NoLock 4 510 32 1 28109 65 1106 0 0 0
3252 -413 41682 6.3 NoLock 4 560 32 1 28109 69 1107 0 0 0
3253 -407 41684 6.3 NoLock 6 630 32 1 28110 74 1108 0 0 0
3254 -404 41684 6.3 NoLock 4 670 32 1 28110 78 1109 0 0 0
3255 -399 41684 6.3 NoLock 4 720 32 1 28110 80 1110 0 0 0
3256 -395 41684 6.3 NoLock 4 770 32 1 28110 83 1111 0 0 0
3257 -390 41686 6.3 NoLock 5 830 32 1 28110 88 1112 0 0 0
3258 -387 41685 6.3 NoLock 3 860 32 1 28110 90 1113 0 0 0
3259 -382 41685 6.3 NoLock 4 910 32 1 28110 93 1114 0 0 0
3260 -375 41688 6.3 NoLock 7 990 32 1 28110 98 1115 0 0 0
3261 -373 41688 6.3 NoLock 3 1020 32 1 28111 101 1116 0 0 0
3262 -368 41688 6.3 NoLock 4 1070 32 1 28111 104 1117 0 0 0
3263 -364 41689 6.3 NoLock 4 1120 32 1 28111 107 1118 0 0 0
3264 -360 41689 6.4 NoLock 4 1160 32 1 28111 110 1119 0 0 0
3265 -355 41691 6.4 NoLock 5 1220 32 1 28111 114 1120 0 0 0
3266 -351 41691 6.4 NoLock 4 1260 32 1 28111 117 1121 0 0 0
3267 -347 41692 6.3 NoLock 4 1310 32 1 28111 120 1122 0 0 0
3268 -343 41692 6.4 NoLock 4 1350 32 1 28111 123 1123 0 0 0
3269 -339 41693 6.3 NoLock 4 1400 32 1 28111 127 1124 0 0 0
3270 -334 41694 6.3 NoLock 4 1450 32 1 28112 129 1125 0 0 0
3271 -331 41694 6.4 NoLock 4 1490 32 1 28112 133 1126 0 0 0
3272 -326 41695 6.3 NoLock 4 1540 32 1 28112 136 1127 0 0 0
3273 -322 41697 6.3 NoLock 5 1590 32 1 28112 138 1128 0 0 0
3274 -319 41696 6.4 NoLock 3 1620 32 1 28112 142 1129 0 0 0
3275 -314 41698 6.3 NoLock 5 1680 32 1 28112 146 1130 0 0 0
3276 -310 41699 6.3 NoLock 4 1720 32 1 28112 149 1131 0 0 0
3277 -306 41699 6.3 NoLock 4 1760 32 1 28112 151 1132 0 0 0
3278 -304 41699 6.3 NoLock 3 1790 32 1 28113 154 1133 0 0 0
3279 -298 41701 6.3 NoLock 5 1850 32 1 28113 159 1134 0 0 0
Here were my calculations for the gain I ended up with using the Bliley OCXO:
h1 diff_ns: 1550 ppb average
h65535 diff_ns: -990 ppb average
VCO Range (ppb) = 2540 ppb
Gain = 65535 / VCO Range = 25.80
Two problems I'm running into:
- The darn thing still won't lock! My diff_ns gets pretty close to zero, but the TIC value stays around -200 to -400 and never gets below +/- 100 ns.
- For whatever reason my LM35 is reporting a temperature of 6.3C which is absolutely not correct. I set the temperature mode to j1 which should be LM35 mode.
-
Read the voltage output by the LM35 with a multimeter, it should be 10mV x ambient temperature. If the voltage is correct, then check that the firmware is reading the correct analog channel, and what is the ADC value.
-
Figured the LM35 part out at least. INTERNAL reference on the 32u4 is 2.56V instead of 1.1V, so I'll have to go into the code and change the reference voltage. At least that was a simple fix. Perhaps the invalid temperature was also causing issues with the main TIC loop?
EDIT
Interestingly it appears on the 32u4 that the analogReference() function does nothing. The raw ADC reading is still referenced to 5V instead of the expected internal 2.56V. Will have to figure out why that is.
EDIT 2
It's because I have an external AREF connected. Whoops. Hopefully I didn't kill the internal VREF by doing that. Either way I'm stuck with the external AREF since the trace for that runs under the MCU. No cutting that one without lifting the proc, which I can't do. |O
More investigation needed to figure out why my GPSDO still won't lock!
-
Yes, for the 32u4 you have to use INTERNAL1V1 instead of INTERNAL. That will also affect the TIC readings, obviously.
https://www.arduino.cc/reference/en/language/functions/analog-io/analogreference/ (https://www.arduino.cc/reference/en/language/functions/analog-io/analogreference/)
Also you have your LM35 connected to ADC5, the 32u4 does not have an ADC2 input pin, so you also have to change that in Lars' code.
EDIT: AFAIK you don't need to cut the trace from 5V to AREF, just set the reference voltage to INTERNAL1V1.
-
Unfortunately not so.
From page 313 of the 32u4 datasheet:
The internal voltage reference options may not be used if an external reference voltage is being applied to the AREF pin.
So I'm stuck with my ~5.2V supply for this board revision. Definitely going to have a new revision in the works.
Still looking for suggestions on how to get this darn thing to lock in the first place. I'm still seeing the TIC value hovering around -300 to -400. On this last boot it started up at 650 or so and worked its way down. I'm now about 40 minutes or so into this cycle and still no closer to a lock.
2111 -405 42168 29.6 NoLock 2 660 32 1 24262 80 10 0 0 0.0
2112 -405 42164 29.6 NoLock 0 660 32 1 24262 79 11 0 0 0.0
2113 -403 42162 29.6 NoLock 2 680 32 1 24262 81 12 0 0 0.0
2114 -402 42159 29.6 NoLock 1 690 32 1 24262 81 13 0 0 0.0
2115 -400 42157 29.1 NoLock 2 710 32 1 24262 83 14 0 0 0.0
2116 -400 42154 29.6 NoLock 0 710 32 1 24262 83 15 0 0 0.0
2117 -399 42151 29.6 NoLock 1 720 32 1 24262 83 16 0 0 0.0
2118 -398 42149 29.6 NoLock 2 740 32 1 24262 85 17 0 0 0.0
2119 -396 42147 29.6 NoLock 2 760 32 1 24262 85 18 0 0 0.0
2120 -394 42145 29.6 NoLock 2 780 32 1 24262 87 19 0 0 0.0
2121 -395 42141 29.1 NoLock -1 770 32 1 24262 87 20 0 0 0.0
2122 -393 42139 29.6 NoLock 2 790 32 1 24262 88 21 0 0 0.0
2123 -393 42135 29.6 NoLock 0 790 32 1 24262 89 22 0 0 0.0
2124 -391 42133 29.6 NoLock 2 810 32 1 24262 89 23 0 0 0.0
2125 -391 42130 29.1 NoLock 0 810 32 1 24262 90 24 0 0 0.0
2126 -390 42128 29.6 NoLock 2 830 32 1 24262 90 25 0 0 0.0
-
I'm thinking what might be going wrong with my setup is the AREF of 5.2V. I'm assuming once the voltage of the TIC gets low enough, there's too much noise in the ADC at those low levels and the PI loop can't reliably control things.
My diff_ns has plenty of jitter in it, with big outlier values popping up every 8 seconds or so. Thinking I may need to pull the MCU and cut that AREF trace to get things working again (assuming I didn't blow the internal 2.56V reference voltage by having it connected originally)
-
Okay, pulled AREF off and it's now using the internal 2.56V reference. Things are better, but I still have some issues.
I'm still seeing big jumps of several hundred ns in my TIC/diff_ns values every so often. These throw off the control loop pretty badly and prevent it from stabilizing at +/- 100ns and locking.
794 -124 41704 31.5 NoLock 7 3720 32 1 25040 326 1045 0 0 0
795 -114 41719 31.5 NoLock 11 3830 32 1 25040 334 1046 0 0 0
796 -108 41726 31.5 NoLock 6 3890 32 1 25040 338 1047 0 0 0
797 -98 41740 31.5 NoLock 10 3990 32 1 25040 345 1048 0 0 0
798 -90 41753 31.5 NoLock 9 4080 32 1 25040 351 1049 0 0 0
799 -85 41759 31.5 NoLock 5 4130 32 1 25040 354 1050 0 0 0
800 -75 41774 31.5 NoLock 10 4230 32 1 25040 363 1051 0 0 0
801 -71 41779 31.5 NoLock 4 4270 32 1 25040 365 1052 0 0 0
802 -448 41129 31.2 NoLock -377 160 32 1 25040 85 1053 0 0 0 <<<<<<<<<<<<<<<<<<<<<<<<<
803 -432 41151 31.5 NoLock 17 350 32 1 25041 95 1054 0 0 0
804 -415 41173 31.5 NoLock 17 540 32 1 25041 110 1055 0 0 0
805 -395 41202 31.5 NoLock 20 770 32 1 25041 121 1056 0 0 0
806 -377 41227 31.5 NoLock 18 970 32 1 25041 138 1057 0 0 0
Not sure where to go from here. I'm open to any ideas. Going to pack things up for the evening and head to bed. Sorry for spamming the thread so much, I'm just a bit flustered because I originally thought this would be an easy project to get working. That's what I get for making assumptions...
-
That jump looks like a TIC roll-over.
-
Lars' 1ns resolution TIC is designed around the 1.1V ADC voltage reference available in the 328P and a few other AVR MCUs, but unfortunately not in the 32u4. To use a 2.56V AREF you would have to change a number of values in the calculation() routine, and you would probably lose some resolution and linearity. Also you can change the resistor that charges the 1nF capacitor to get a voltage swing of approximately 2.5V instead of 1.1V in Lars' original schematic.
Another solution is to use an external 1.1V voltage reference, but that requires a PCB redesign to add the cicuitry for the external 1.1V voltage reference circuit.
In the worst case, abandon the 32u4 and switch back to the original 328P that Lars used.
I did mention the AREF pin when you asked for comments early on, but I didn't check the 32u4 datasheet for its internal voltage references. My bad. :(
Edit: Lars' GPSDO schematic is quite simple but the complexity lies in the source code and how everything is tied together. If you have an oscilloscope do check what happens at the 1nF capacitor in the TIC, triggered by the PPS. It's very interesting!
-
I don't think Lars would want to see people making and distributing closed source ("black box") versions of his project.
But that is the whole issue ... It is not about what you think.
As per Lars post here to Nick.S
https://febo.com/pipermail/time-nuts_lists.febo.com.March2021/2018-September/094086.html
I have no problem you have ”stolen” the phase detector design from me. I have no intention at all to make it commercial as you have done. Of course due credits to relevant persons are always good.
He seems to have no problem with Nick.S had "stolen" his phase detector design , and use it in a commercial product. as long as due credits are given.
IMHO this points more to a MIT License as you described above, than a GPLV3
Maybe you should rethink your license choice.
Well enough of this ... Apparently you think you can apply whatever license that fits you, to Lars Code ....
I will use Lars original code , and based on his answer to Nick.S , i will assume it's ok to use it with a MIT or other non GPLV3 license.
Edit: Basically my guess is that Lars didn't care much about licensing , he just wanted his design & code to be used by the public.
/Bingo
-
Since (I believe) absolute accuracy of the ADC isn't that important, I might just bodge up a voltage divider to bring ~ 1.1V to the AREF pin for this board. We'll see if that makes things any better.
Like I said, I'm going to be making a second hardware revision and I'll absolutely include a true 1.1V reference in that.
-
...
IMHO this points more to a MIT License as you described above, than a GPLV3
...
That's because you have zero understanding of open source licenses.
And I don't want to discuss this matter with you anymore, in this thread or elsewhere.
-
Since (I believe) absolute accuracy of the ADC isn't that important, I might just bodge up a voltage divider to bring ~ 1.1V to the AREF pin for this board. We'll see if that makes things any better.
Like I said, I'm going to be making a second hardware revision and I'll absolutely include a true 1.1V reference in that.
Absolute accuracy is indeed irrelevant. Stability under environmental changes though, very much relevant. While you're hunting problems, go for it, just be advised that you want that ADC reference voltage be stable over temperature and independent of your supply voltage.
-
Since (I believe) absolute accuracy of the ADC isn't that important, ...
I agree. In Lars' GPSDO, I think stability of ADC operation is probably more important than absolute accuracy.
I might just bodge up a voltage divider to bring ~ 1.1V to the AREF pin for this board. We'll see if that makes things any better.
That should at least make the TIC and LM35 readings work with Lars' code without modifications. Definitely worth a try.
Like I said, I'm going to be making a second hardware revision and I'll absolutely include a true 1.1V reference in that.
:-+
-
Well I bodged in a 100k resistor to +5V to create a very crude voltage divider with the internal resistance of AREF (supposed to be ~32k, but looks like it's closer to 37k). Getting 1.414V at the AREF pin right now. Good enough? I suppose we'll see.
I'm still seeing those occasional large negative jumps in diff_ns - thinkfat said it looks like a TIC rollover - what's that mean exactly? Is that something else that needs to be fixed with more hardware changes?
We'll see if I get any closer to a lock this time. This PCB is becoming more bodge wires than traces ;D
EDIT
849 32 42322 27.2 Locked 2 5296 32 16 25029 511 1101 0 0 0
850 26 42322 27.1 Locked -6 5295 32 16 25028 510 1102 0 0 0
851 27 42322 27.1 Locked 1 5293 32 16 25028 508 1103 0 0 0
852 28 42323 27.2 Locked 1 5293 32 16 25029 510 1104 0 0 0
853 32 42323 27.2 Locked 4 5295 32 16 25029 512 1105 0 0 0
854 24 42323 27.1 Locked -8 5292 32 16 25029 506 1106 0 0 0
855 26 42324 27.2 Locked 2 5291 32 16 25029 512 1107 0 0 0
856 23 42324 27.2 Locked -3 5288 32 16 25029 504 1108 0 0 0
857 23 42324 27.2 Locked 0 5285 32 16 25029 509 1109 0 0 0
858 20 42323 27.2 Locked -3 5280 32 16 25029 502 1110 0 0 0
859 21 42323 27.2 Locked 1 5276 32 16 25029 503 1111 0 0 0
860 22 42323 27.2 Locked 1 5273 32 16 25029 505 1112 0 0 0
861 17 42323 27.2 Locked -5 5267 32 16 25028 501 1113 0 0 0
862 19 42322 27.2 Locked 2 5263 32 16 25028 506 1114 0 0 0
863 21 42322 27.2 Locked 2 5260 32 16 25028 504 1115 0 0 0
864 15 42322 27.2 Locked -6 5254 32 16 25028 504 1116 0 0 0
865 18 42322 27.2 Locked 3 5250 32 16 25029 503 1117 0 0 0
866 13 42321 27.2 Locked -5 5243 32 16 25028 497 1118 0 0 0
867 12 42320 27.2 Locked -1 5236 32 16 25028 504 1119 0 0 0
Finally!
-
...
Finally!
:clap:
Indeed, and well done! Also it's a tribute to how well designed/coded Lars' TIC + software PLL was, that despite having various parts of the circuit off specs, lock (stabilization of the OCXO frequency at a precise 10MHz +/- a fraction of a Hz) is still achieved.
-
Well I started plotting MDEV based on the DAC value in column 3 and here's where I'm at after 10 minutes
(https://i.imgur.com/Rq0KfXk.png)
Something tells me that's not right...
-
Well, I'd say the form of the graph looks OK for DAC MDEV, the scale is whatever you made out 1 DAC digit to be. It is of course not representative of the actual output stability, at least for small "tau". You're supposed to get a "hump" in the graph at time intervals of "maximum disturbance", typically it corresponds with your integration time constant. To see the graph dive "down", you need much longer observation time (some thousands of seconds).
-
...
Something tells me that's not right...
There is very obviously a problem. For any GPSDO the slope of the curve is supposed to be negative (variance decreases with increasing tau) until the crossover point where the variance of the GPS time signal takes over. On page 3 of Lars' PDF documentation you have the correct plot for a few of his GPSDOs, which I am attaching.
Are you sure you plotted the correct column of data?
If you did indeed plot the correct column of data I would investigate if the OCXO is being properly "disciplined". Simply use a multimeter or DSO and measure the frequency control voltage at the OCXO. Is it what it's supposed to be?
Also you can check the two PWM outputs.
-
As far as I know I'm plotting the correct value. In Lars' screenshots for Timelab he used column 3 (the DAC output value) and that's what I'm using. Everything is set up the same per his screenshots.
The DAC is definitely working. The Bliley OCXO I'm using has an internal bias voltage which prevents a full 0-5V scale, but it still swings between ~1V and ~4V when commanded to its extremes. Should be more than enough I'd think.
I'm at work now but I've got an 8 hour plot running back home. We'll see what it looks like when I get back. I would've expected what you said - a slowly decreasing MDEV value. Could be the low amount of data (< 1 hr) causing it to look funny.
-
6 hours in and it's coming back down. Here's the new run compared to the previous run that I let go for 50 minutes.
(https://i.imgur.com/srXoxlBh.png)
Still interesting that it starts off in both cases close to 1E-12. Not sure why that would be - I'm not enough of a statistician to be able to explain it. I'm still buried deep in the wikipedia entry for Allan deviation.
-
The DAC MDEV graph is only a measure of how often the regulation corrects the DAC voltage and how much the difference is between observation intervals, on average. What parameters did you use when importing into Timelab? Is your scaling correct? Did you import it as a frequency series?
The 1.22e-12 @1s basically tells you that the second-to-second corrections applied to the OCXO are causing a change of 1.22e-12 * 10e6 Hz, and 3.03e-11 * 10e6 Hz when looking every 100s. Whether this has anything to do with reality depends on your actual frequency change per DAC LSB, and of course with a 1ns TIC your regulation is blind below 1e-9s of phase change. Also, for small Tau, the OCXO stability will dominate the output and those values are not worth much.
But from the shape of the curve I can see that the GPSDO is working and is keeping the OCXO in sync with the GPS clock. Well done!
-
Alright, I've done some more reading of the earlier pages of this thread. I probably wasn't using the correct scaling in Timelab for my gain (100). I'm running a new plot now.
On the topic of gain, I've noticed that with my OCXO the calculated gain I "should" be using is 26 (65535 / 2500ppb tuning range), but it seems like when the loop actually starts running it doesn't use nearly enough correction to tune in the TIC value. For example my TIC measurement could be +7000 and it would take forever to reach a DAC value that would actually be applying negative correction. Perhaps that's something that needs to be tuned in the PI loop, I'm not sure.
With a gain of 100 it obtains a lock just fine and seems to be pretty stable. But - would I use that value of 100 in my scaling calculations for Timelab, or should I use the calculated gain of 26?
-
You can save the DAC value and use the calculated gain, so that when you start the GPSDO, it reaches a lock very quickly.
-
Alright, I've done some more reading of the earlier pages of this thread. I probably wasn't using the correct scaling in Timelab for my gain (100). I'm running a new plot now.
On the topic of gain, I've noticed that with my OCXO the calculated gain I "should" be using is 26 (65535 / 2500ppb tuning range), but it seems like when the loop actually starts running it doesn't use nearly enough correction to tune in the TIC value. For example my TIC measurement could be +7000 and it would take forever to reach a DAC value that would actually be applying negative correction. Perhaps that's something that needs to be tuned in the PI loop, I'm not sure.
With a gain of 100 it obtains a lock just fine and seems to be pretty stable. But - would I use that value of 100 in my scaling calculations for Timelab, or should I use the calculated gain of 26?
Use the calculated gain.
-
8 hours and 3 minutes into my next Timelab run. I set the gain back to the calculated 26 and set up the plot to use (what I think is) the proper scaling factor for my setup. This is using the DAC column with a scaling factor of 3.84E-11 (1E-9 / 26)
Looks like the ideal TC for my setup would be ~ 4000s if I'm reading the chart right? That seems excessive. Addionally my overall scale seems to be pretty high. Looks like most other MDEV plots get down to the 1E-12 range, while I'm barely scraping below 1E-10.
-
8 hours and 3 minutes into my next Timelab run. I set the gain back to the calculated 26 and set up the plot to use (what I think is) the proper scaling factor for my setup. This is using the DAC column with a scaling factor of 3.84E-11 (1E-9 / 26)
Looks like the ideal TC for my setup would be ~ 4000s if I'm reading the chart right? That seems excessive. Addionally my overall scale seems to be pretty high. Looks like most other MDEV plots get down to the 1E-12 range, while I'm barely scraping below 1E-10.
1. Looks good to me.
2. I wouldn't worry too much about the MDEV absolute values. As thinkfat wrote, you are measuring variations in DAC voltages, not variations in frequency or phase.
3. You can easily experiment with different TC, IIRC. But (again IIRC) in principle, the longer the better.
-
So here's another design question. I've got a square wave OCXO and I'd love to make a nice pretty sine wave at my outputs. Currently I've got a pretty simple unity gain buffer followed by a lowpass which gets me the sine, but I'd like to get some more amplitude out of it.
The big challenge I've found with amplifying the resulting sine is the lack of a negative supply. Every single-supply amp I've designed has failed pretty miserably, even following the nice TI application note on single supply designs here: https://mil.ufl.edu/4924/docs/TI_SingleSupply_OpAmp.pdf
-
There are quite a few 10MHz distribution amplifier projects described on the Internet, here is one:
https://www.briandorey.com/post/10mhz-frequency-standard-distribution-project (https://www.briandorey.com/post/10mhz-frequency-standard-distribution-project)
And here is another:
https://github.com/kf4mot/10mhz_distributor (https://github.com/kf4mot/10mhz_distributor)
-
@axel
Here's what I used to get a +14dB sine wave output (assuming the 3.2v pk-pk 'scope trace is accurate) in my own humble DIY GPSDO project (I'm currently working on an Efratom LPRO 101 based frequency standard that I plan on ultimately locking to the GPS timing signals). Although it's only a single channel output, it neatly avoids the need for any bi-polar HF opamps. I suppose you could duplicate the 3 inverter buffer (I used four simply to give mine a little more oomph) with an LPF each if you only need two channels.
The 'scope traces show the resulting sine wave outputs from the GPSDO and the LPR 101 (yellow CH1 and magenta CH2 respectively). I'm using infinite persistence to monitor the GPS signal's short term (hour to hour) phase wobbles against the temperature stabilised Rb oscillator's steady 30 to 60ns drift per day.
The filter is based on a 5th order butterworth using this calculator:
http://leleivre.com/rf_butterworth_LPF.html (http://leleivre.com/rf_butterworth_LPF.html)
I think I used an Fco value of 12MHz and added a peaking inductor (L3) across C3 to maximise its output at 10MHz and neatly tie the output to ground. It's important (as I discovered when trying to re-purpose PC MoBo ferrite toroid cores to make up the inductors) that you use low loss at HF ferrite inductors in order to come anywhere near the theoretical frequency curve plots typically shown for these filters.
-
Thanks for the advice everyone! I actually tweaked my original design and added in a wilkinson divider for the dual outputs. Looks like I get ~2.4 Vpp into 50 ohms which should be more than enough.
I do have another question though. I logged the output of my GPSDO over 12 hours and plotted the TIC value, DAC value, and diff value:
(https://i.imgur.com/v1ba98Vh.png) (https://i.imgur.com/v1ba98V.png)
To me, it looks like the control loop isn't doing a good regulating the TIC value. Quite a few excursions above +/- 100ns. There's quite a bit of noise and swing too, which might explain the MDEV plots I was getting earlier. Notice that the diff_ns value never changes by very much in response to the quite large TIC jumps. Seems like maybe some increased gain is needed? Right now I'm using G=26 and a time constant of 32.
Additionally, I checked the logs and the only PPS losses occurred at 15:45 and 17:21 which probably explains the big jumps at those times. But it doesn't explain the overall lack of stability.
-
Aditionally, I checked the logs and the only PPS losses occurred at 15:45 and 17:21 which probably explains the big jumps at those times. But it doesn't explain the overall lack of stability.
Why are you getting PPS losses at all? Have you connected your GPS module to a survey program to see signal strength, sky view, etc. If you are getting deviations above +-30ns in PPS it hints you may have a poor signal and GIGO principle applies.
I have had some success with a GPS program on a mobile phone, just wander around looking for good signals. In the end I mounted the Gps antenna on the roof.
-
I'm probably not in the best location - I live in an apartment with a balcony that faces roughly east-northeast. Decent view of all of that part of the sky, but a large building blocking my view west.
I've been using a cheap magnetic GPS puck as my outdoor antenna, and it seemed to be working well enough. Just now I replaced my original outdoor antenna with a (theoretically) better one (https://buy.garmin.com/en-AE/mena/p/7650), so we'll see if that helps things out at all. But I've looked over most of my logs and very rarely do I loose PPS. Not sure how much better I can make things in my current location without moving.
Attached is a U-center plot from the old small antenna. Doesn't look super bad, but not amazing either. I need to work in the GPS serial passthrough into my current code so I can get data for the new installation.
EDIT
One other thing - I've noticed with my 32u4 setup that the code execution will hang whenever I disconnect the serial console. I've never seen that before and I have no clue what would be causing something like that to happen. Anyone ever experienced any strange issues like that? I'm using the Sparkfun Pro Micro bootloader if that helps. It's probably some goofy quirk of the USB serial implementation not working totally right with Lars' original code.
-
Attached is a U-center plot from the old small antenna. Doesn't look super bad, but not amazing either. I need to work in the GPS serial passthrough into my current code so I can get data for the new installation.
That looks OK to me. The dB plot shows plenty of satellites over 30dB and that's regarded as adequate. Your PDOP is a little high (Positional Dilution of Precision). I wonder if you are getting reflected signals, I don't know how you would find out (or what to do about it). Doesn't explain why you get lost PPS. My GPSDO design keeps stats, can go a week without losing a PPS. And the code looks at the $GPRMC status field which is more reliable than the PPS. Many GPS units keep pumping out PPS signals even though they lost fix. The $GPRMC status is more reliable.
Can't help with the Arduino problem. My last was an ATmega328P.
-
Thanks for the great chart!
It's difficult to correlate the performance of Lars' DIY GPSDO with GPS reception because the design does not have the AVR MCU connected to the GPS serial TX and RX at all. What you can do to circumvent this limitation is to simultaneously connect the GPSDO and GPS module to a PC using two separate USB serial line interfaces.
There are two parameters that are reported by the u-blox receiver every second, that are easy to monitor and give you a very good idea of the jitter in the PPS* : no. of satellites being tracked and HDOP. My anecdotal experience is that in my STM32 GPSDO with 11 or more satellites tracked and an HDOP<0.9, I get a low enough jitter to stabilize my OCXO within +/- 1ppb (10E-9) or better. IOW under these conditions I achieve my target OCXO accuracy/stability.
Ideally you would plot the no. of satellites tracked and the HDOP in the chart that you posted and it would definitely give you a clear idea of how Lars' PLL loop performs.
Note that you may find that the 32u4 and similarly the original 328P 8-bit, 16MHz MCUs simply do not have enough flash and/or processing power to simultaneously monitor the GPS and run Lars' GPSDO code, using for example the TinyGPS++ library.
*: the jitter in the PPS is really what we are interested in, because it's the noise "floor" that the PLL has to deal with in any PLL-based GPSDO such as Lars' GPSDO.
-
Eventual plans for my version of the code is to have a toggleable "passthrough" mode or something along those lines that would let me run bidirectional serial to and from the UBlox module for programming and monitoring. But you're right in that it may cause issues with the limited program and flash in the MCU.
However for now I can probably hack in a listener for the GPGGA message that spits out # of satellites and HDOP to the running log.
EDIT
Alright, I now have sats and HDOP being logged. Looks like I'm averaging 6-7 sats and an HDOP of ~ 1.2 with this current antenna setup. Probably can't ask for much better than that with my current location.
-
...
However for now I can probably hack in a listener for the GPGGA message that spits out # of satellites and HDOP to the running log.
EDIT
Alright, I now have sats and HDOP being logged. Looks like I'm averaging 6-7 sats and an HDOP of ~ 1.2 with this current antenna setup. Probably can't ask for much better than that with my current location.
Well done! :-+
-
@axel
Assuming your GPS module is a navigation type such as the u-blox M8N that many in this thread are using, the most cost effective upgrade would be an M8T based module (or any of u-blox's earlier timing modules). It doesn't sound like you have the option of installing a rooftop GPS antenna which would likely be an even costlier upgrade than blowing a 100 dollars or more on an M8T based module.
Your situation is eloquently described as being in an "Urban Canyon" where not only do you have a limited sky view but also the problem of signals being bounced off adjacent buildings which will only serve to reduce the stability of the time pulse. The C/No reports might look good enough but a strong delayed signal is worse than no signal at all.
You can reduce this interference from reflected signals by increasing the elevation angle filter from its 5 deg default but this will likely cut down the number of good signals to below the 3D fix threshold of 4 required by navigation modules to stay locked to the PPS time pulse long before it can filter out these rogue reflections.
A timing module can maintain a valid PPS pulse with only a single SV in view once it has been surveyed in and running in 'over-determined mode'. In theory you can raise the elevation filter value to maybe as high as 65 deg but this risks having only a single out of service SV being visible above this elevation angle, leaving the receiver unable to provide a locked PPS pulse until the next working SV comes into view maybe as much as an hour or two later.
I'm in the privileged position (finally!) of being able to raise my mag mount patch antenna a few inches above the ridge tiles for a full 360 degree view of the horizon where I'd very often observe SVs falling off the edge of the sky plot at elevation angles of -1 degree (on rare occasions, even -2 deg!). I'm using an M8T module and this allows me to increase the elevation angle to 35 degrees (I don't have unwanted signal reflections to contend with) to guard against as many as three out of service SVs becoming the only ones above the elevation filter angle -an important consideration with a basic hardware only PLL based GPSDO design.
This, of course, is the very situation where an mcu based design can really shine since it can ride out such short term outages that may well repeat two or more times a day depending on how much of the GPS constellation is in the out of service state. It's not unusual to see the odd GPS SV remain out of service for days to weeks at a time, so if your mcu based GPSDO can routinely cope with this situation, all the better for you.
Although you can mitigate this problem by using additional constellations (Galileo and GLONAS for example) this does compromise the stability of the timing pulse (GLONAS being the worst offender in this case) so either way, you're going to have problems, less so if your mcu based GPSDO provides good holdover performance.
Since you're working on an mcu based GPSDO, upgrading to a timing module in your situation would seem to be your best solution imo.
I've attached some screenshots for you to compare. I don't often bother to monitor the GPS with u-centre since I have to trail a 5 metre USB lead across my hobby room floor to reach the test bench behind me from the PC desk. They represent the past 2 1/4 hours u-centre run time.
-
Good info!
Here's a question - are the NEO-M8T modules pin-compatible with the NEO-6Ms? I'm using the little 5 pin breakout boards with 6M modules, and I'd love to keep that form factor since I've kinda designed the whole board around them. From the datasheets it looks like almost all the pins are the same. Only differences I see are some extra functions on the M8T that are reserved on the 6M, and the SPI & UART are combined. But otherwise I think I might be able to get away with a chip swap, assuming the little modules do well with a hot air gun.
I can get used M8T modules from China on cutout boards for not too much, so I'd like to go that route if possible since I'm trying to stick with the "barebones budget" approach.
-
Are you sure those are NEO? I know one eBay vendor who has LEA-M8T modules on cut-outs and I have in fact bought quite a big number of them in the past, but they are LEA and will not fit a breakout board for NEO modules. I haven't found anyone selling NEO-M8T modules in quite a while.
EDIT: Okay, I found the vendor of the NEO-M8T modules, it's the same one I bought the LEA-M8T from. Hint: try haggling for the price, especially if you plan to buy in bulk ;)
-
In a DIY GPSDO such as Lars', upgrading to a timing module is simply a waste of time and money.
Please check this very interesting article which compares the performance of various u-blox receiver modules.
https://hamsci.org/sites/default/files/publications/2020_TAPR_DCC/N8UR_GPS_Evaluation_August2020.pdf by John Ackermann N8UR
What the data in the article shows is that all the tested u-blox GPS receiver modules perform more or less the same, when they are used to provide a 1PPS signal in a stationary GPSDO application.
Under ideal conditions (very good rooftop antenna), the PPS from the timing modules have one extra bit of resolution compared to the non-timing modules, and I doubt one extra bit would make any difference at all in a Lars' GPSDO. As far as I can tell Lars himself did not see the need for a timing module.
-
I agree, mostly.
If you're not doing "sawtooth correction", the noise from the GPS is anyway mostly getting drowned by the aliasing, and if you have a perfect view of the sky, little can be gained from using a timing receiver. But, it doesn't hurt, either. So if you have an opportunity to get a timing receiver like an M8T, go for it.
-
Good info!
Here's a question - are the NEO-M8T modules pin-compatible with the NEO-6Ms? I'm using the little 5 pin breakout boards with 6M modules, and I'd love to keep that form factor since I've kinda designed the whole board around them. From the datasheets it looks like almost all the pins are the same. Only differences I see are some extra functions on the M8T that are reserved on the 6M, and the SPI & UART are combined. But otherwise I think I might be able to get away with a chip swap, assuming the little modules do well with a hot air gun.
I can get used M8T modules from China on cutout boards for not too much, so I'd like to go that route if possible since I'm trying to stick with the "barebones budget" approach.
The hardware integration manual for the NEO-M8 series has a migration guide (chapter 3.2)
https://www.u-blox.com/sites/default/files/NEO-8Q-NEO-M8-FW3_HIM_UBX-15029985.pdf (https://www.u-blox.com/sites/default/files/NEO-8Q-NEO-M8-FW3_HIM_UBX-15029985.pdf)
-
@axel
I'm afraid I can't help you with that question. I did briefly look into that aspect (footprint compatibility) between the navigation and timing variants about two years ago when I was searching for an economically priced timing module, preferably on a daughter board rather than just a bare module. I wasn't up to speed with designing and laying out smd boards back then. I'm still not. I've only just recently bought myself a cheap hot air rework station as a prelude to taking this next step.
After some 6 to 12 months of only finding 2nd hand overpriced boards blessed with timing modules being offered for sale on Amazon and Ebay, I chanced upon an Amazon dealer who happened to be offering a "GY-GPSV3-M8T NEO-M8T GLONASS GNSS GPS Antenna Module" exactly like the one pictured here:
https://www.amazon.co.uk/Antenna-Module-GY-GPSV3-M8T-NEO-M8T-GLONASS/dp/B07VWLMS2R/ref=sr_1_3?keywords=GY-GPSV3-M8T&qid=1636382803&sr=8-3 (https://www.amazon.co.uk/Antenna-Module-GY-GPSV3-M8T-NEO-M8T-GLONASS/dp/B07VWLMS2R/ref=sr_1_3?keywords=GY-GPSV3-M8T&qid=1636382803&sr=8-3)
https://tinyurl.com/yk639d2p (https://tinyurl.com/yk639d2p)
Obviously a stock photo since the actual module I bought had a later version and unique serial number.
What had caught my attention, especially considering I was looking at a dealer on Amazon, was the very low price of just over 41 quid for a complete ready to go module. Since the dealer had fully described its timing feature set, I took a chance and ordered one. I'd only ever paid a maximum of 22 quid for a genuine NEO M8N Arduino/RPi module so this represented a considerable investment in what might turn out to be yet another fake.
It duly turned up and proved itself to be exactly as advertised, making it the bargain of the past two years. However, that accolade swiftly shifted to the next two M8T modules a couple of weeks later when that very same dealer decided to reduce the price to just over 24 quid each.
Despite some slight misgivings I'd had over a possible minor firmware bug in the original (a weird issue with the FTD232 module I was using in my GPSDO as it turned out), I immediately snapped up another two before the price soared into the stratosphere (as indeed it did a fortnight later when he started asking 61 quid each). Just for once, I had touched lucky in my search for a cost effective M8T module, made all the more amazing by the fact that it had come from a seller on Amazon, famed more for exorbitant rather than bargain pricing.
Unfortunately for most of us hobbyists who like to build 'on the cheap', the pricing of anything with a GPS timing module has gone the way of those 20 dollar drone navigation units sporting LEA6T modules for some unfathomable reason about 5 or 6 years ago once the sellers discovered the real reason why they were selling so much better than the later 30 dollar "superior" M8N versions.
In jewellery shop terms, it would have been the discovery that they'd been selling silver plated gold bars for their weight in silver, hence the dramatic 100 dollar price increase on the older "inferior" (from a navigation performance PoV) LEA6T versions.
If it weren't for the fact that I'd lucked out some 13 months back and was only now looking for a 'cheap' timing module, I'd snap up that 90 quid module without batting an eyelid. It's amazing how much two years of upgrading to better T&M kit and some 3 or 4 grand's worth of investment can effect such a radical "attitude adjustment" with regard to the cost of such components. :palm:
Given your situation, investing in a timing module, however you implement it, seems a no-brainer option in this case.
Just to satisfy anyone's curiosity, I've attached another three u-centre screenshots to reveal an almost complete sky plot survey.
-
I have been using VisualGPS to view NMEA data. I'm looking at the u-center plots and wondering if they give more or less information. The presentation is more flashy, but that's not necessarily a good thing.[attachimg=1]
-
I've now got a 26 hour plot of a whole bunch of parameters, including new HDOP and # of sats.
Looks like the moral of the story is, with my current location I can't expect amazing regulation of the TIC. Seems like most of the time it's within +/- 50ns but occasionally gets out to +/- 150ns. The spikes in TIC value seem to correspond pretty well to the lowest number of satellites in view, so I'm guessing that's definitely the root cause.
I think this will probably be "good enough" for now. I don't expect to be in an apartment much longer (fingers crossed) but this should get the test equipment I've got today reasonably locked.
-
@MIS42N
If you're using a u-blox gps module, you can try u-centre for yourself (I think it only works with u-blox receivers BICBW).
What VisualGPS calls the survey window, u-centre calls its version the deviation map. Right now, since my M8T has long since been 'surveyed in' all it shows is a rather boring single dot in the centre which is why I no longer include it. Back in the days before I acquired my M8T modules, it offered a bit of idle entertainment that I referred to as "The Dance Floor" (effectively a 5 by 5 metre patch of ground).
Since it included my location co-ordinates, I either arranged it so the C/No reports window occluded this information or else edit the screen capture image to blank it out so I don't miss it one little bit since it saves me having to deal with keeping my co-ordinates hidden when attaching these images to any postings I might make here.
The sky map plots show the same data but in different ways, I prefer u-centre's colour patchwork scheme but I guess it's what you get comfortable with. There are plenty more display options including histograms and so on but I'm only showing the more informative and visually appealing such as the last 20 seconds signal C/No history on the right hand side with the clock showing the date and time (using the illogical yankee date format, I've just noticed BTW >:().
The windows I'm showing are all I need to see the status of the SVs at a glance. Incidentally, I'm running an ancient version of u-centre since the latest versions as of a couple of years ago aren't compatible with winXP (running in a Vbox VM under Linux Mint) and, although later versions had retained winXP compatibility, u-blox (bless their cotton socks) don't archive these previous versions... at all! >:( and I wasn't able to track down alternative archive sources to get my hands on the last winXP compatible version they'd created so I'm stuck with version 8.16 for the time being.
The only problem with v8.16 is that it makes it very difficult or impossible to flash update the NEO M8T's firmware (I wasn't able to figure out which was the case). Luckily for me, I have no urgent need to reflash my M8Ts right now but that could all change at some point in the future. I suppose I could always install a later version of windows in a VM in the event that such a requirement ever arises, so I'm not overly concerned of what may or may not happen in the future.
I've just searched for older versions of u-centre and came across a request for version 8.25 in a u-blox customer forum where he'd been given a link to https://www.u-blox.com/en/product/u-center#tab-documentation-resources (https://www.u-blox.com/en/product/u-center#tab-documentation-resources) and advised to scroll down the list until he found what he wanted.
I followed the link and scrolled down the list until I saw a "show legacy documents" button which revealed a long list of vista to win 10 compatible versions v19.02 through to v21.09 with this last one having been revised as recently as Oct 2021 with version 8.16 identified as the last winXP compatible version. This is at odds with the implied existence of a v 8.25 and my own vague recollection that the winXP versions had extend all the way to v18.xx.
I do have an installation CD for the later version of Vista which wasn't the omnishables of the initial release (either that or the original and a service pack update that made it tolerable enough to use) so I suppose I could try installing it into a VM for a giggle. I've already downloaded all those versions for possible future use.
It just seems rather odd that u-blox seem to have removed all winXP compatible versions later than 8.16. With that request for version 8.25, I feel pretty sure now that I had actually seen mention of even later winXP compatible versions rather than just imagined I had. At the end of the day, if push comes to shove, I suppose I can always try setting up a Vista VM to get round this issue.
I've added the last 7 screenshots. The first shows a completed sky survey plot with the rest showing the various combinations of data that can be applied to the sky plot.
PS I almost forgot to mention that the first image shows in the history window (RHS) GPS13 reporting an elevation angle of -1 just a few seconds before it dropped off the edge of the plot. This isn't unusual and If I care to observe such stats on SVs about to drop off with a -1 deg elevation, I'll sometimes see a final report of -2 deg just seconds before it disappears completely.
-
I've now got a 26 hour plot of a whole bunch of parameters, including new HDOP and # of sats.
Looks like the moral of the story is, with my current location I can't expect amazing regulation of the TIC. Seems like most of the time it's within +/- 50ns but occasionally gets out to +/- 150ns. The spikes in TIC value seem to correspond pretty well to the lowest number of satellites in view, so I'm guessing that's definitely the root cause.
I think this will probably be "good enough" for now. I don't expect to be in an apartment much longer (fingers crossed) but this should get the test equipment I've got today reasonably locked.
This is where a timing receiver can be beneficial, since it can derive time even from one visible satellite after you have given it the position of the antenna.
-
I've now got a 26 hour plot of a whole bunch of parameters, including new HDOP and # of sats.
Looks like the moral of the story is, with my current location I can't expect amazing regulation of the TIC. Seems like most of the time it's within +/- 50ns but occasionally gets out to +/- 150ns. The spikes in TIC value seem to correspond pretty well to the lowest number of satellites in view, so I'm guessing that's definitely the root cause.
I think this will probably be "good enough" for now. I don't expect to be in an apartment much longer (fingers crossed) but this should get the test equipment I've got today reasonably locked.
I find your plot a bit mystifying. The HDOP figures are not good, anything over 5 is regarded as very marginal. Yet the bad HDOP doesn't correspond to minimum satellites or to the larger tic figures. I think there's other factors here, probably reflections. Not worth investigating if you are moving soon, if it works don't fix it.
-
I've now got a 26 hour plot of a whole bunch of parameters, including new HDOP and # of sats.
Looks like the moral of the story is, with my current location I can't expect amazing regulation of the TIC.
...
All DIY GPSDO designers/builders/users eventually reach a similar conclusion that a GPSDO's performance essentially depends on good, stable GPS signal reception, which in turn essentially depends on antenna placement and a clear view of the sky.
...
I think there's other factors here, probably reflections. Not worth investigating if you are moving soon, if it works don't fix it.
Reflected signals will definitely throw off the GPS receiver calculations and translate into higher HDOP figures and much higher PPS jitter. And of course the best way to avoid reflected signals is to have a proper antenna placement with a clear view of the sky, so that the GPS receiver can prioritize the stronger signals from the satellites at a higher elevation to reach a more accurate timing solution for the PPS.
-
I've now got a 26 hour plot of a whole bunch of parameters, including new HDOP and # of sats.
Looks like the moral of the story is, with my current location I can't expect amazing regulation of the TIC.
...
All DIY GPSDO designers/builders/users eventually reach a similar conclusion that a GPSDO's performance essentially depends on good, stable GPS signal reception, which in turn essentially depends on antenna placement and a clear view of the sky.
...
I think there's other factors here, probably reflections. Not worth investigating if you are moving soon, if it works don't fix it.
Reflected signals will definitely throw off the GPS receiver calculations and translate into higher HDOP figures and much higher PPS jitter. And of course the best way to avoid reflected signals is to have a proper antenna placement with a clear view of the sky, so that the GPS receiver can prioritize the stronger signals from the satellites at a higher elevation to reach a more accurate timing solution for the PPS.
Which was the whole point of my suggestion to use a timing grade receiver such as the NEO M8T to achieve this goal with minimal risk of total loss of timing lock. :)
The problem with using a navigation only grade receiver in cases like this is that if you increase the elevation filter angle too much, it will lose the timing signal as soon as the SV count drops below 4. The timing grade receivers will carry on generating a valid PPS right down to the moment the SV count drops to zero, hence the suggestion in this case, that this would be a relatively cost effective solution.
Even assuming axel could get permission to install a rooftop GPS antenna (or install such by stealth) I'd be very surprised if the costs alone of the feeder and antenna and mounting hardware (and possibly a line powered LNA module to boot) would come to less than the price of a NEO M8T.
Anyway, regardless of my opinion on this, I followed the link you gave a little earlier to that N8UR article and had a quick skim through it before downloading it only to discover that I'd already downloaded it back at the end of August. However, whilst looking in that folder of useful GPSDO related articles, I spotted an earlier thesis paper I'd download back in February by Joseph Paul Gauthier, entitled "Achieving Synchronization and Syntonization Using GPS Receivers" which covers this issue of GPS reception in more detail. After a DDG search I managed to locate a downloadable copy here:
http://unsworks.unsw.edu.au/fapi/datastream/unsworks:11967/SOURCE02?view=true (http://unsworks.unsw.edu.au/fapi/datastream/unsworks:11967/SOURCE02?view=true)
So, yet another pdf worth looking at for anyone who hasn't already managed to add it to their GPS and GPSDO related document collection. :)
-
Two NEO-M8T modules are on the way, slow boat from China. Knowing my luck they'll show up a few days before I'm moving out...
-
Two NEO-M8T modules are on the way, slow boat from China. Knowing my luck they'll show up a few days before I'm moving out...
You can rest assured that they won't go to waste. They'll still offer an improvement over the M8N even where the antenna has a clear all round view of the horizon. :) Besides which, if that's how it pans out, consider it a minor investment to have Sod's Law work in your favour for once. I can't imagine you'd want to delay your move any more than you can help it. :)
-
Even assuming axel could get permission to install a rooftop GPS antenna (or install such by stealth) I'd be very surprised if the costs alone of the feeder and antenna and mounting hardware (and possibly a line powered LNA module to boot) would come to less than the price of a NEO M8T.
I put the GPS receiver on the roof, with a line driver into Ethernet cable. Sending the 1pps and NMEA data down the cable with power going up. Only a handful of parts, about $5, plus Ethernet cable. I haven't measured the distance, about 12 meters I'd guess. I've tested this with a 20 meter cable and it works. I am worried it will get fritzed by lightning but so far no problem after several storms in a period of over 6 months.
To be precise, the antenna is on the roof and the receiver just under. I recently bought a (probably fake) neo7 with a patch antenna, with the intent of mounting in a waterproof enclosure (probably plastic drainpipe) to see if I can save the cost of an active antenna. Previous tests swapping modules with patch antenna (a 5 year old neo6) with an active antenna setup showed a difference in signal strength but no noticeable change in performance.
-
Got the laser cut end panels made for the GPSDO. Enjoy some photos!
(https://i.imgur.com/kP0fBzKl.jpg) (https://i.imgur.com/kP0fBzK.jpg)(https://i.imgur.com/BsUHKuZl.jpg) (https://i.imgur.com/BsUHKuZ.jpg)
(https://i.imgur.com/r2FkIBLl.jpg) (https://i.imgur.com/r2FkIBL.jpg)(https://i.imgur.com/8XTwUf2l.jpg) (https://i.imgur.com/8XTwUf2.jpg)
(https://i.imgur.com/YG2y38Ll.jpg) (https://i.imgur.com/YG2y38L.jpg)
Plus a bonus 28ish hour plot. I upped the gain to 100 which seems to have pulled in the regulation of the TIC even better.
-
That looks very nice!
Note though, when you increase the "gain", you will adversely affect the short term stability. You will get a faster convergence but the higher the gain and the lower the integration time constant of the regulation, the closer the OCXO frequency will follow the GPS, which is exactly _not_ what you want.
-
Nice chassis :-+
Makes the end product look prof.
/Bingo
-
That looks very nice!
Note though, when you increase the "gain", you will adversely affect the short term stability. You will get a faster convergence but the higher the gain and the lower the integration time constant of the regulation, the closer the OCXO frequency will follow the GPS, which is exactly _not_ what you want.
Good point. I'll do another run with the gain back to 27. Maybe 30 just for a nice round number. I'm also planning on adding in a trimmable opamp setup to the control line for the OCXO so I can up the precision a bit. Right now my ppb swing is a little ridiculous going from 1 to 65535. Anyone have any example circuits for that? I tried a simple voltage divider by itself, but the internal bias voltage on the Bliley OCXO control line was causing all kinds of issues keeping the voltage centered with that setup. Thus the need for a little more "force" with an opamp output.
-
Alright, time for more concrete numbers.
I've brought the GPSDO into work and set it up with a frequency counter logging absolute frequency to a CSV. The counter is connected to a big-boy 58503A GPSDO so hopefully I'll get some good data.
-
...
a big-boy 58503A GPSDO...
A great instrument some 20 years ago. Nowadays, the $10 u-blox Neo-M8N module in your Lars' DIY GPSDO runs rings around the obsolete GPS receiver in the HP.
In any case it could prove useful to "tune" the parameters of your Lars' DIY GPSDO (gain, time constant, temperature correction, etc) assuming you have good GPS signal reception at your workplace.
I suggest you explore thoroughly the performance of Lars' DIY GPSDO in its present minimally modified form before you add any further complexity (an op-amp, a higher-resolution DAC, a timing receiver, etc). You may find that it performs just fine as it is (when properly "tuned"), and that adding complexity has no effect at all on its performance.
-
To be fair, I'm not Timenutz-level obsessed with accuracy. If my GPSDO can match the 58503A then I'll be beyond pleased.
And for those wondering if bad satellite view was part of the issue, you're probably right. With our roof GPS antennas I'm averaging 11-12 satellites and an HDOP of below 1 most of the time. ^-^
Attached is a plot of the first hour and half on this setup. Not sure what happened at around 15:30 to cause the big dip, but it's working its way back to 10meg slowly. Notice after the initial loop lock it's been within +/- 3 mHz for the most part which I think is pretty darn okay for a cheapo GPSDO. Even the transient at 15:30 only dipped down to -9 mHz or so.
Again this is all trusting the 58503A to be accurate. It's been on for a couple weeks now and just came back from our cal lab recently. So probably decent enough.
-
Well now you just need one more GPSDO. ;D
APPLICATION OF THE 3-CORNERED HAT METHOD TO THE ANALYSIS OF FREQUENCY STABILITY
http://www.wriley.com/3-CornHat.htm (http://www.wriley.com/3-CornHat.htm)
-
22 hour plot, measured with the HP 53131A + HP 58503.
(https://i.imgur.com/dMkHyXTl.png) (https://i.imgur.com/dMkHyXT.png)
Sure, it's not the proper 3-cornered hat measurement. But it tells me that my GPSDO is definitely well within my definition of "good enough"
-
22 hour plot, measured with the HP 53131A + HP 58503.
I think your GPSDO is following the short term variations of the PPS too faithfully. You can verify this if the DAC shows a similar pattern (otherwise it could be a measurement artifact). I don't know how Lars system works but there is probably some variable you can fiddle with to reduce the effect. My very cheap GPSDO is usually within .001Hz.
-
22 hour plot, measured with the HP 53131A + HP 58503.
...
Thanks for the excellent chart. The problem however is that you are measuring the frequency of one GPSDO using a counter + reference frequency of a second, much older GPSDO.
So all we can say is that the sum of the noise of the two GPSDOs is what the chart shows us (and it's quite good enough since its < 0.01Hz, in other words, < 1ppb).
But it is impossible to tell which GPSDO is the main source of the noise in the frequency readings: it could be Lars' GPSDO, or it could be the 25-year old HP GPSDO.
There are two possible solutions: either use a much better clock (IOW requires access to a properly calibrated atomic clock) or use the three cornered hat method (requires access to a 3rd GPSDO).
Or if you are content with good enough (1ppb), you can leave it at that.
Even if you decide to leave it at that, I would still however consider the advice from thinkfat:
That looks very nice!
Note though, when you increase the "gain", you will adversely affect the short term stability. You will get a faster convergence but the higher the gain and the lower the integration time constant of the regulation, the closer the OCXO frequency will follow the GPS, which is exactly _not_ what you want.
In summary, you want low gain and higher integration time constant. Which is also what MIS42N is hinting at btw.
-
Now I see what you guys are getting at.
I'm going to run another test overnight tonight. I've upped the TC to 96 (from 32) and my gain is back down to the original calculated 27.
I think we also have one of those fancy rubidium counters somewhere around here. Perhaps I could use that for the third corner of my hat...
-
So I upped the TC to 96 for an overnight run, and it brought in the noise even more (first attachment). Again, like others have said at this low resolution the noise could easily be the frequency counter / HP GPSDO combo instead of my GPSDO under test.
I then upped the TC to 128, to see if I could get things to smooth out even more. Evidently that's a little too long for my GPSDO to find a good lock (second plot). So I'm trying out a TC of 100 tonight to see how that looks.
I also found the Dana-Racal counter I was thinking about. Unfortunately it's the standard 1992 model as opposed to the 1998 rubidium model I was hoping it was. Oh well.
-
Thanks for the nice plots. TC of 96 vs TC of 100 is unlikely to make any difference, it seems you are already at the noise "floor" of your DUT and measuring setup.
And you'll probably notice when you get to try the u-blox M8T GPS timing module that it too makes absolutely no difference.
-
...
a big-boy 58503A GPSDO...
A great instrument some 20 years ago. Nowadays, the $10 u-blox Neo-M8N module in your Lars' DIY GPSDO runs rings around the obsolete GPS receiver in the HP.
The GPS is only one part of a GPSDO, and back in that era they did everything they could to minimize that part, such as using a good oscillator and the HP SmartClock. They had Selective Availability to deal with back then too.
Some of these old GPSDOs work much better - or worse - than others, and they do need a good antenna setup and view of the sky, but they can be very good indeed.
The quoted timing pulse accuracy for the old Motorola Oncore VP timing receiver was 50ns.... with SA on!
It would be interesting to see a comparison between different generations of GPS receivers. Something else for the to do list.
-
A word of warning
Don't buy these M8T modules: https://www.ebay.com/itm/334056332149 (https://www.ebay.com/itm/334056332149)
I've spent the last half hour trying to desolder one and I've come to the conclusion that module is actually glued to the PCB it's attached to. I was hitting it with progressively hotter air for a good five minutes, and even 360C wasn't enough to separate it. The module's shield had popped off several times during the attempt as well, and the solder on the castellations was visibly flowing, but the unit itself was firmly planted onto the PCB. At this point the module is probably dead, so I may try some more invasive cutting and grinding just to confirm my suspicions.
Just to make sure it wasn't operator error causing my issues, I tried reworking one of the donor NEO-6M boards I've got and was easily able to get it off within a minute without any hassle, and at only 300C air temp.
Pretty scummy of that seller. Unless they're not even aware of the fact and are lying about the 100% tested claim.
-
I bought about 20 or so LEA-M8T on cut-outs from the same seller. They came off just fine, but they were not NEO, which are a smaller footprint overall.
The trick is not to go too hot, but to give it time. Those cut-outs are 6 layers with several ground planes in them, they can take a lot of heat. Backheating might help, maybe use a hotplate if you have one. I think my temperature was 330C with a lot of airflow, it still took a while to get the modules off. Give it time, allow even heating.
-
Did you run into issues with the shielding can popping off? That was the main issue I was facing. I don't want to shoot heat at all the delicate components inside the can and risk blowing them away.
I'll give it another shot tonight. Still, I'm fairly confident all the pads were liquid and yet the module wasn't budging.
EDIT
Alright, I was finally able to get the module off. You weren't kidding, I had to dump a surprising amount of heat into the board before it came loose. Ended up putting a thermocouple probe on the solder joints to find out that even at 340C air temp, the board was barely above 225C. Cranked up the heat to 380C and was able to get it off. Threw it onto one of the donor NEO-6M boards and it's working great so far.
We'll see if it makes my lock issues any better. The GPSDO does great with a full view of the sky, but I'm getting frequent unlocks back here at the apartment with a diminished view. Does anyone know if I have to configure any options for timepulse holdover, or does the M8T module just do that automatically?
-
It needs to be "Surveyed in" or else enter the exact co-ordinates manually before it can change into over-determined mode to keep locked to the time pulse with only a single satellite. You can set the unlocked mode to match locked mode in TP5 (Timepulse 5) (see attached image where I've used it to signal loss of satellite lock with a 4Hz 50% duty cycle pulse - I'm using a 100KHz 50% pulse to drive my PLL). As far as can remember, it defaults to 0Hz 0% duty cycle when not locked onto the required minimum number of satellites.
When I 'surveyed in' my very first M8T, I assumed I could use the sub 0.01m deviation I'd observed from the deviation map's average position I'd been getting with the M8N as a target condition to complete the survey in operation along with the recommended 24 hour run time (both conditions need to be met to successfully complete survey in operation).
Of course, the deviation map only shows a 2D plot, leaving the altitude ranging up and down by some ten metres or so. I'd set the target deviation to a 'generous' 0.1m and the time to 24 hours. After 24 hours had elapsed, the survey in operation was still waiting for the deviation to reach my 'generous' 0.1m target so I let it run another 12 hours before giving up and trying a new deviation value just slightly above what I'd first used.
The deviation had shrunk to just under 0.17m by then so I reset it to 0.17m, expecting to have to wait another day or two for the process to complete but, to my surprise, that change was used directly with what it had achieved at that point and successfully completed the survey in operation.
The lesson I learnt here was that you could set a reasonably tight deviation value to start a 24 hour survey in operation and, if it looks like it's going to take several days to get anywhere close, you can always reset this to just above the currently achieved deviation value to force a successful survey in with the tightest deviation value possible within the constraints of your chosen survey time and current reception conditions.
In short, set it for 24 hours and 0.1m and see where the reported deviation value drops down to after this period and just reset the deviation target value a fraction higher than that to force it into over-determined mode with the best achievable deviation value within the time and reception conditions you are working with. Given your current setup though, I suspect you'll be doing well to achieve less than a one metre deviation value (but you never know until you try).
Even if you only manage a 2m deviation, you'd still be far better off simply by losing reliance on having to depend on locking to a minimum of four satellites with any navigation only qualified GPS/GNSS receiver such as the M8N.
-
Well after a day of trying to get a good survey-in value, I've found that the lowest my StdDev goes is about 8.5m. Not great at all.
Curious if that's enough to get a somewhat-decent timepulse holdover. Guessing the reflections from the surrounding buildings are still making my fix less-than-great.
-
Well after a day of trying to get a good survey-in value, I've found that the lowest my StdDev goes is about 8.5m. Not great at all.
Curious if that's enough to get a somewhat-decent timepulse holdover. Guessing the reflections from the surrounding buildings are still making my fix less-than-great.
I've been rather preoccupied with a couple of projects, hence the late reply. I did give your problem some thought but felt I couldn't offer anything more useful than the obvious one of experimentation using your best positional fix estimate to set the M8T into overdetermined mode which I assume you've already tried by now.
Specialist GNSS timing/geodetic antennas can improve this situation but cost considerably more than a basic puck antenna. The expense being further compounded by the universal use of TNC connectors and 5/8 inch UNC threaded mounts (even more obscure than the 1/4 inch UNC tripod mount system common to cameras). A common feature with these timing/geodetic antennas is their ability to discriminate against unwanted reflections from "ground clutter" but in this case, it would seem your problem is more about "Sky Clutter" than ground clutter. :(
With your current (hopefully soon to be remedied) situation, such an antenna upgrade didn't seem appropriate, hence my silence on the subject. However, since there haven't been any other replies over the past couple of days (it seems longer than that), curiosity impels me to ask whether you've had enough time to experiment further with the M8T sufficiently to have some initial test results to report.
Also, of course, I've had time to consider how a timing receiver could overcome the effect of reflected signals when placed into overdetermined mode. If you're only interested in obtaining a stable frequency standard, absolute time accuracy doesn't matter just as long as the 'error' remains a fixed and constant one so setting the position to a 'best guess' value, even if it's tens of metres in error, to put the receiver into overdetermined mode is not necessarily going to be a bad option.
The real issue with unwanted reflections arises when the direct signal is totally blocked, leaving only the main reflected signal as the signal source (the most likely scenario in an urban canyon environment). I'm no expert on how timing receivers deal with such grossly delayed signals (think hundreds of nanoseconds!) but I should imagine the impossibility of a very early arrival of a single direct line of sight received signal being 'outvoted' by a bunch of very much delayed reflected signals would be processed correctly by the receiver's navigation computation engine when running in overdetermined mode.
You're not forced to fix the position by a "Survey in" operation, you're quite at liberty to manually fix the position to a best guess value, even if that turns out to be several metres (perhaps even tens of metres) adrift from the true position, so well worth giving this option a go.
Anyway, that's my "Two cent's worth". :)
-
You can evaluate the DOP values. The smaller they are, the better. Values smaller than 1 are excellent. Larger 3 it will be damn bad.
-
Well after a day of trying to get a good survey-in value, I've found that the lowest my StdDev goes is about 8.5m. Not great at all.
Curious if that's enough to get a somewhat-decent timepulse holdover. Guessing the reflections from the surrounding buildings are still making my fix less-than-great.
You can constrain the precision and time during the survey-in. The receiver will then complete the survey-in automatically when both constraints are satisfied. I usually set the maximum time to half an hour and the precision to 0.5m (or even lower). The survey-in then usually stops once the desired precision is met. What also helps is to decrease the measurement interval so that the receiver computes the position more frequently. The M8T can do 4 measurements per second, this reduces the time for survey-in significantly.
Anyway, you need to have an antenna position that has a decent sky view. If you can only receive the satellites from reflected signals, forget it. Find a position that has a decent view southwards (if you're on the northern hemisphere).
Or, tell the receiver a somewhat accurate position. You can use Google maps, the precision is good to 1-2 meters or maybe better.
-
I've had it sitting for a few days now after setting up overdetermined mode. I used 1 day & 10m as my constraints and it seems to have helped significantly. I haven't lost lock a single time compared to the multiple times a day I was seeing with the 6M receiver.
I've also been adding more to Lar's code. It now processes and logs number of satellites and HDOP, as well as GPS time. I'm getting dangerously close to max program size however (97%), so I'm not sure how many more features I can add. I would've loved to have added in a function to enable survey-in and overdetermined modes from the serial console without having to remove the GPS module, but I don't have nearly enough space left to implement a UBX encoder/decoder system.
Has anyone tried porting Lars' code to an STM32? Seems like the next logical step.
EDIT
Hah, I answered my own question. I'll have to check this out at some point Thinkfat - https://www.eevblog.com/forum/projects/diy-gpsdo-project-w-stm32-tdc7200/. (https://www.eevblog.com/forum/projects/diy-gpsdo-project-w-stm32-tdc7200/.) Too bad STM32 cores are unobtainium these days.
-
Hi,
I will be assembling a prototype of Lars' DIY GPSDO using an Arduino Uno clone and the TIC circuit, OCXO, u-blox NEO-M8N GPS, etc on a breadboard.
I have gathered the minimal set of components and right now this is what things looks like. The separate PCB is a LM317T regulator set to output 5.05V and it powers the OCXO separately. Also I am using a slightly different TIC circuit, proposed by Erik Kaashoek. I'll post some DSO captures of the TIC readings when I get the GPSDO working.
-
Hi, I just finished the Qw3rtzuiop v2 gspdo with Bliley oxco. I am having the "missing 10mhz" and "no lock" issue. I added 100k resistors to HC390 from vcc to clock input and ground and increased R3 to 4.7k as suggested in the blog. No help at all. Since I have exactly the same build as the Qw3rtzuiop v2, are there any other mods I might need to make (hardware or software) to get it working? Is the issue my Bliley? I can measure the gpsdo output at 10mHz, so I think the Bliley is working. However, when I try to use command h1 to see the vco range I get 0. Any troubleshooting help is welcome.
-
Hopefully some people are still monitoring this blog!
I have fully built the minimum design but I realized my (authentic) neo-7m is not capable of putting out a 1ns pulse. The lowest it will go is 1us which is 1000ns. From what I understand, my GPS needs to be putting out a pulse of 1ns or less, correct? I saw a post where Lars said 5ns was acceptable, but somehow I doubt this extends to 1000ns.
When I try to change the TP or TP5 to .001us it automatically jumps to 0 and no pulse is sent at all. The lowest it allows really is 1us.
I have confirmed these pulses with the oscilloscope. They are consistent, I will give them that. EXACTLY 1us for as many pulses as I can detect, but I just can't get the 1ns quick pulse and it is cause then whole system to never lock.
Any of you pros out there have any advice for me? I would be very grateful :) |O :) |O :)
-
...
From what I understand, my GPS needs to be putting out a pulse of 1ns or less, correct?
...
No. There is no limitation on the 1PPS pulse duration and certainly not a 1ns limit. The 1PPS pulse put out by default by the GPS is usually 10ms or 100ms long and that works quite well. In any case it is not a critical value.
In Lars' GPSDO design, the 1ns refers to the theoretical resolution of the phase detector in the PLL (phase-locked-loop), not to the duration of the 1PPS pulse from the GPS module.
EDIT: Let me expand a little bit on Lars' "1ns theoretical resolution TIC (Time Interval Counter)".
Basically Lars' TIC translates the phase difference (in ns) between the OCXO and the 1PPS leading edges into a voltage that is read by the AVR MCU. The range of the TIC/phase detector is approximately 1000ns, and the resolution of the AVR MCU ADC (analog to digital converter) is 10 bits (0 to 1024), so basic math tells us that 1000ns/1024 is more or less 1ns.
Now this is a theoretical resolution, because in practice both the OCXO and 1PPS signals have a certain amount of jitter, so the actual resolution of Lars' TIC is much lower, my guess is on the order of 15 to 25ns depending on the OCXO and the GPS satellite reception. Also the TIC precision (different from the resolution) is on the order of a few percent due to various reasons. But the repeatability is quite good and with proper processing (averaging of measurements), it does the job.
Despite all these problematic considerations, Lars' ingenious circuit works quite well for the intended purpose (the PLL achieving a "lock"), and it requires a minimal number of low cost and easy to find components, so I personally think Lars did a great job.
-
Haha oh wow that makes this much easier on me, thank you Andrew! I was racking my brain for the last day trying to figure out why my pulses were "so fat" lol.
I have another question (surely won't be my last):
After leaving this setup with my calculated gain of 22 overnight, I noticed I get what seem like pretty stable/low TIC values, and then it finally locks, but when it locks the numbers change quite a bit and it only lasts for a few seconds then it loses it and says "restarted" on the right. The low and stable TICs last for a pretty long time, but then that lock hits and everything changes. This cycle repeated many times throughout the night.
Admittedly, I need to spend a little more time combing through Lars' PDFs again. Oh, and I should mention that the diode I am using is not the same one (ordered them, will be here next week), so I am using a 1N4148 in the meantime. Might be causing problems.
I am not as savvy with this subject as you all seem to be. This is my first GPSDO, and my first time really working with timing and references and all of this is a learning experience for me. I'm not an engineer or anything, just a hobbyist. I say that just to say anything you say will not hurt my feelings or offend my intelligence or anything, so hammer away with any advice you can give! I do know how to use my scope though, so if you need me to probe any points and see what is happening just let me know.
Thank you!!!
-
Haha oh wow that makes this much easier on me, thank you Andrew! I was racking my brain for the last day trying to figure out why my pulses were "so fat" lol.
No problem. GPSDO concepts are not easy to grasp, it took me more than 6 months to get a basic understanding of how it all works.
I have another question (surely won't be my last):
Ask away! That's the reason this forum exists.
After leaving this setup with my calculated gain of 22 overnight, I noticed I get what seem like pretty stable/low TIC values, and then it finally locks, but when it locks the numbers change quite a bit and it only lasts for a few seconds then it loses it and says "restarted" on the right. The low and stable TICs last for a pretty long time, but then that lock hits and everything changes. This cycle repeated many times throughout the night.
Admittedly, I need to spend a little more time combing through Lars' PDFs again. Oh, and I should mention that the diode I am using is not the same one (ordered them, will be here next week), so I am using a 1N4148 in the meantime. Might be causing problems.
I have no idea what exactly could be causing this problem, but indeed the 1N4148 is quite different from the recommended Schottky diode. After you change it, do tell if it makes any difference.
I am not as savvy with this subject as you all seem to be. This is my first GPSDO, and my first time really working with timing and references and all of this is a learning experience for me. I'm not an engineer or anything, just a hobbyist. I say that just to say anything you say will not hurt my feelings or offend my intelligence or anything, so hammer away with any advice you can give! I do know how to use my scope though, so if you need me to probe any points and see what is happening just let me know.
Thank you!!!
Don't worry, this is a learning experience for me too! 8)
-
Ask away! That's the reason this forum exists.
Sounds like a plan to me!!!
Btw, right after I posted last I suddenly got a lock that seems stable! It's been locked for about an hour now so I am very excited! My 1N4148 must be better than the 1N5817 I had in yesterday. Looking forward to my 1N5711's to arrive.
So I do have a couple more questions before I go power through Lars' .pdf more thoroughly:
1. Now that I have a lock, this means that the 10Mhz coming out of my oscillator should be pretty dang accurate now, right? I ask because my scope still reads the same 9.99995 Mhz that it did without disciplining the oscillator. (screenshot attached). Does this mean my scope is reading a bit low? That 10Mhz is coming out of the "10M" pin on my OXCO board.
2. I would like to see if I am understanding the precision and accuracy concept correctly:
ppm literally means parts per million. So if I had a perfect 1Mhz signal, that is 1 million hertz. If my scope read ".999999 Mhz" then that would mean it was reading 1ppm low, because out of the million hertz it is reading one less than it should. Assuming that is correct, if I had a perfect 10Mhz signal and the scope read "9.999999 Mhz" then it is still 1 hertz low, however now it is TEN million hertz instead of one million, so I would divide that single "missing hertz" it by 10 and say it is now "0.1ppm low" (or 100ppb low). Is that correct?
So, if my scope had a perfect 10Mhz signal but it read "9.999950 Mhz" (my scope isn't as precise as the example above requires), then it means it is reading 50 hertz low @ 10 Mhz, or stated in ppm it would be reading 5ppm low (or 5000ppb low?).
Am I on the right track or is there a gap in my understanding? I am a CS major so we don't really work with this sort of thing in school much haha.
I also put a couple pics of my setup to give you an idea of what I'm working with. If you see anything glaringly wrong lmk lol.
(Angry side note...)
NOOOOOO! I MOVED THE SETUP LESS THAN AN INCH TO TAKE A PICTURE AND I LOST MY LOCK LOL DANGET!!!! Clearly the breadboard and wires are not very well connected lol. Maybe it's time to move this to some perf board with solder lol. What a bummer! :-//
-
A few comments:
1) You have a very nice and clean workspace. I wish I had the same!
2) Yes, in principle if you have a lock then your OCXO is at 10MHz +/- 0.01Hz or so.
3) Any DSO is much less accurate than a GPSDO. So yes, indeed it is measuring low.
4) Resolution is how many digits your measurement instrument can resolve. Accuracy is the difference between what is measured and what should be measured with a "perfect" instrument.
Taking the example of a ruler: if the smallest hash marks it has are 1/16" apart, then that's that ruler's resolution. Now if you measure for example a piece of metal that you know for sure is exactly 10" long, but your ruler says it's 10.5" long, then your ruler's accuracy is only 5%.
Also: since it seems you have a 4-channel DSO, I would suggest you measure on each channel:
1) 1PPS leading edge (trigger)
2) Leading edge of the output of the 74HC390 divider that is fed to the TIC
3) OCXO 10 MHz output.
4) And most importantly: the TIC output (that goes to the MCU ADC input)
This will really show you how Lars' GPSDO works.
-
Excellent comments, thank you!
And haha, I was thinking how messy it currently was with all my diode kits laying all over. Messy enough that I almost didn't upload the photo lol. I'm a bit of a clean freak around the house though. Just wanted to show my 'wider view' of the bench to give you an idea of what I do or don't have to work with. Like the 4-chan scope! Great recommendation! I will definitely set up the other three probes. I've always seen people have multiple signals up at once but whenever I do it it only seems to focus on one signal and the rest become a blur. I only got the scope 3 or 4 months ago and it's my first, so I am slowly learning. I imagine I need to change the trigger settings on a per-channel basis? Haven't had a chance to play with that but might as well do it now.
Good to know that all DSO's are a bit off like that. I am guessing there is some oscillator in there (maybe an OCXO?) that is used as the reference for it's measurements. Can I GPS discipline that to make the scope more accurate? Not that I want to crack that thing open while it's under warranty lol, but just out of curiosity.
Anyways, thank you again for the tips! I have to go do my real job for a bit now, but hopefully tonight or tomorrow I will be able to hook those four probes up and really see the beauty of this thing in action! I might move it from the breadboard to a more stable, soldered board with sockets for the chips or something first. I had such a great lock there but if I so much as breath on a wire wrong it loses its mind lol.
-
...
Good to know that all DSO's are a bit off like that. I am guessing there is some oscillator in there (maybe an OCXO?) that is used as the reference for it's measurements.
Yes, there are a number of crystal oscillators inside every DSO, but no DSO that I know of uses an OCXO, most inexpensive ones use a simple quartz and possibly the more expensive ones use a TCXO.
Can I GPS discipline that to make the scope more accurate? Not that I want to crack that thing open while it's under warranty lol, but just out of curiosity.
Not that I know of.
Anyways, thank you again for the tips! I have to go do my real job for a bit now, but hopefully tonight or tomorrow I will be able to hook those four probes up and really see the beauty of this thing in action! I might move it from the breadboard to a more stable, soldered board with sockets for the chips or something first. I had such a great lock there but if I so much as breath on a wire wrong it loses its mind lol.
Just for experimenting a breadboard is good enough in my experience, but if you want this kind of assembly to last a little longer then it's a good idea to solder some components onto a perforated board or a proper PCB.
-
Some mid-range DSO have an input for an external reference clock. If you have one of these, you can connect them to your GPSDO.
-
Pretty much anything that is not rubidium oscillator (or better) is worse than GPSDO.
Fact that scope that new costs less than decent OCXO has less frequency accuracy than said OCXO should not be a surprise.
Scopes use TCXO, in different grades. TCXO cover wide specifications range and come in ppm and ppb grades.
Scopes that have few ppm accuracy across whole temperature range have darn good clock sources...
For a scope, that is.
And it is more than enough for absolute accuracy and orders of magnitude better than old CRT scopes had with timebase specified in percents, not ppm or ppb...
Scope is not exactly the frequency analyzer.
Scope timebase should have a good low term stability (low jitter, low phase noise).
Scope measurements of relative timing of events are different story though. They can be extremely precise and accurate.
Most modern scopes interpolate trigger point into picosecond range and can resolve much shorter time periods than sampling rate of ADC, with good accuracy and precision.
two pulses at 1PPS, 50ns wide, 277ns apart... measured with 8,9ps RMS noise...
And that includes all source errors...
On a scope with just good TCXO.
-
2N3055, thank you for the info, that is all very good to know. Your scope looks very nice too, such a pretty looking interface there!
Some mid-range DSO have an input for an external reference clock. If you have one of these, you can connect them to your GPSDO.
Dang, mine doesn't seem to have one. I have the 1104X-E but unlocked to be 200Mhz (as if I need that haha), and it seems I'm stuck with the internal reference. Based on what 2N3055 said though I shouldn't have any issue with that.
Also: since it seems you have a 4-channel DSO, I would suggest you measure on each channel:
1) 1PPS leading edge (trigger)
2) Leading edge of the output of the 74HC390 divider that is fed to the TIC
3) OCXO 10 MHz output.
4) And most importantly: the TIC output (that goes to the MCU ADC input)
This will really show you how Lars' GPSDO works.
Alright, I finally got it all set up! I had a medical procedure last week which glued me to the couch so I had to take a week off this project, but I am back now!
Also, I got my diodes (1N5711) and results seem to be basically the same, but at least I have the recommended piece now.
SO, I have my four probes hooked up the way you recommended. Here is the way they are arranged on the screen:
Blue: 10Mhz (obviously haha)
Yellow: 1pps from GPS (trigger)
Green: Pulse out from HV4046 Pin 15 (hooked up right after diode, before resistor so it was easier to see on the screen. Is that ok?)
Purple: 1Mhz out from HC390 pin 7
That was super helpful for me to see what was really happening! So my understanding now is that the 1pps from the GPS sets the HC4046 high on pin 14, then as soon as the 1Mhz hits pin 3 it drops it back down. That cycle determines the TIC pulse width of the pulse going to the ADC (A0) on the Pro Mini.
Here are a couple questions that I now have:
1. I THINK that the TIC pulse width stability indicates whether or not the 1PPS and 1Mhz are synced, and the Pro Mini is using that TIC pulse width CHANGE to determine the DAC value to send to the VCO to make them synchronized... so if the width stops varying then it means they are synced and if it keeps changing then the VCO voltage is slightly adjusted till it stops changing... is that correct?
2. Take a look at the falling edge of my green line (the TIC to the ADC). Does it fall off slowly like that because of the 1nf cap? If so, is that a reasonable looking falling edge there or should I try a different capacitor?
3. I asked this one before and you weren't sure, but I was hoping that now that I have the correct diode and better screenshots that you might have a better idea: My setup seems to stabilize well, and the TIC values get down to like <20ns for a couple cycles, then it locks, and immediately the "pre-filter" changes from 1 to 16 and everything goes haywire and it loses its lock. This keeps repeating. As soon as that lock is lost (couple seconds), the filter changes from 16 back to 1 and within a few seconds my TIC values are back to <40ns, and eventually back to <20ns. What is that 1 and 16 filter value and why does it change? It seems to be the reason I can't maintain a lock for more than 10 seconds. In the time it has taken me to type this post, the locked/unlocked cycle has repeated probably 10 times. What is that pre-filter? I read Lars' pdf but I don't fully understand some of the more advanced parts.
4. I attached some GPS signal screenshots. I have an active antenna hanging in my window on the blinds. Are these GPS signal strength strong enough? Sometimes I get only 2 or 3 above 30dB, but have a ton in the high 20's. Is that sufficient?
As always, thank you so much for your help. This is a really fun project. It is absolutely unnecessary for me to have this level of accuracy for the work I do (fixing vintage audio equipment) but it is such a fun side-project that I just can't stop! I want a super accurate reference just for the pleasure of having it lol.
P.S. That was so cool hooking up all four probes and actually getting the trigger setup to capture all four like this. I tried this in the past (only had a scope for a couple months now) and couldn't get it. I'm glad I gave it another shot here because I feel like my scope skills doubled just from this little "exercise" you gave me. So thank you for that.
P.P.S. I got a couple NEO-8M modules for a decent deal. I will swap for one of them once I get the 7M working and see if there is much difference.
-
...
Green: Pulse out from HV4046 Pin 15 (hooked up right after diode, before resistor so it was easier to see on the screen. Is that ok?)
...
Thank you, this is a very, very good setup, except for one little thing: the scope probe for the pulse out from 74HC4046 (your Green channel) should be hooked after the resistor (where it connects to the capacitor), not before. This is because we want to observe how the capacitor charges, and the voltage measured by the MCU ADC.
-
Andrew,
Here is what it looks like after moving that probe. I put the probe basically right by the arduino A0 so we can see it right as it's going into the ADC. I had to adjust the voltage scale for that channel just to see it. Looks pretty crazy... is it supposed to look like that? If I zoom out far enough (second screenshot) on the horizontal/time scale I can see the rising edge. I imagine this weird view (first view) is due to my lack of knowledge with the scope.
I'm actually very confused about something else now too... When I set the time division to 20ms I can see the 1Mhz and 10Mhz waveforms nicely. Then if I zoom that time division in I start to lose them, but if I keep zooming and zooming and zooming all the way to like 100ns division, I can suddenly see all the 1Mhz and 10Mhz again! Only the green TIC trace looks way different. Is the scope like automatically adjusting the time division for each channel or something? Or am I seeing some weird harmonic frequencies when I zoom way in?
EDIT: I think I was seeing harmonics cause when I zoomed out the "10Mhz" was showing as like 40Hz. I set up the measure function to show the frequency of all four channels to make sure I was zoomed to the correct level. Attached is a screenshot at 200ns timescale. Can you see how my green trace barely rises there and then doesn't really fall much? Is that how that green trace should look? I kept the vertical division at 5v to match the other three channels. I mean, I get a lock and all, it just immediately drops as soon as the 1 changes to a 16.
EDIT 2: Well, I just decided to randomly change the time constant from 32 to 16 and the pre-filter from whatever the default is to 4... It locked right away and seems to be staying locked now. It was a random adjustment, I don't actually understand what I did. Any ideas why this fixed the "pre-filter change lock breaking issue" that I was experiencing?
-
The green trace looks very noise at first glance, but for most of the time it is not relevant because the ADC is not sampling. It only samples just right after the rising edge of the 1MHz trace. Absolute value then represents the time between the rising edge of the 1PPS pulse and the next rising edge of the 1MHz clock derived from the LO. The control software steers this towards 1µs, if I'm not mistaken (it's a configurable value).
There was a modification around that connects A0 to another GPIO that would then actively discharge that capacitor of the time-to-voltage converter, but I think it brought no relevant improvement.
The pre-filter is an exponential moving-average (EMA) digital filter with a variable time constant. When lock is achieved, the time constant is increased to smooth out the phase difference over a longer period of time. The merit of this is doubtful, increasing the integration time of the PI loop would be equivalent. Anyway, what this filter does is slow down the regulation. If the GPSDO then "breaks out of lock" it just means the regulator is now too slow to compensate the drift of the LO.
Usually, this is a problem with the stability of the LO. The OCXOs we have commonly access to, we don't know about their service life and how they were handled (or abused). When powered up after a long period out of service, they might take a while to "find their bearing". You should just give it some time. Keep the device powered, observe what it does, especially temperature changes. Realize that completing the circuit is not the end, it's the beginning of a long journey of tinkering and optimizing.
-
Andrew,
Here is what it looks like after moving that probe. I put the probe basically right by the arduino A0 so we can see it right as it's going into the ADC. I had to adjust the voltage scale for that channel just to see it.
...
Well done :-+ , but there is just one more thing that you would need to adjust again, and please share with us another scope capture of what you'll get:
- The green trace now shows the voltage at the Arduino A0 pin. This voltage rises from zero to a maximum of 1.1V, so you should adjust that channel for 1V/division vertical.
- In the previous scope captures, the 3rd one is the one that is relevant: you can see the capacitor charging. So that's the one with the correct horizontal (timebase) setting, 200ns/division and zoomed in at the right place.
About the noise on the green trace: that, unfortunately, is one of the shortcomings of Lars' design. Lars' software deals with it with a smoothing algorithm (as thinkfat explained), but indeed it doesn't look very good on a scope capture. But it doesn't matter: we can still see the charging of the capacitor, and that's what we want.
-
If you look at the frequency of the noise on A0, it's really quite high, looks like a good deal above 10 MHz. You can see it drop significantly in amplitude once the sampling capacitor inside the STM32 is connected to the input, and then increase again when the sampling period is over.
It is not inherent to Lars' design though. I suspect that the typical makeshift build-up on a breadboard, with wires flying everywhere and no special care taken about decoupling and signal returns, is mostly responsible. I believe you could reduce it significantly if you provided better filtering for the OCXO supply, better decoupling for the digital components and a cleaner build.
-
Have I mentioned yet how awesome you guys are? Thanks for the replies :)
You should just give it some time. Keep the device powered, observe what it does, especially temperature changes. Realize that completing the circuit is not the end, it's the beginning of a long journey of tinkering and optimizing.
I have had the OCXO plugged in and hot for a week or two, but I haven't actually measured its temperature or anything. I've also moved and rearranged the breadboard and probes a lot so I probably have messed with its stability a bit. You are definitely right about the circuit only being the first step. I am definitely enjoying the tinkering though. I'm getting better with the scope, with oscillators in general and soon (tomorrow maybe) I will be drafting up a simple PCB in Diptrace and using the magazine paper laser printer trick which I used years ago and am excited to try again.
I suspect that the typical makeshift build-up on a breadboard, with wires flying everywhere and no special care taken about decoupling and signal returns, is mostly responsible. I believe you could reduce it significantly if you provided better filtering for the OCXO supply, better decoupling for the digital components and a cleaner build.
Definitely lots of wires! My first setup was using the standard, cheap, crappy little thin jumper wires that you get on eBay, but it was so sensitive that if I so much as looked at it wrong it lost it's mind. So I yanked it all out and used these much nicer solid core copper wires that are much thicker gauge and shorter too. (picture attached). It got much more stable after that. But now I have scope probes flying all over, probably also interfering a bit just by nature of taking measurements in general. Looking forward to the PCB. I am going to put some test points in it to to make probe setup simpler.
About the noise on the green trace: that, unfortunately, is one of the shortcomings of Lars' design. Lars' software deals with it with a smoothing algorithm (as thinkfat explained), but indeed it doesn't look very good on a scope capture.
I had actually adjusted that green trace to 1 volt division right after making my last post. Now I went and change that probe from 10x to 1x and it looks significantly better. I even added some fancy new labels to my traces. Feelin like a pro now! 8) lol
So, all that said, I guess I'm not sure where to go from here... I seem to have a pretty solid lock (about a day now with no drops), but it's only cause I changed my time constant to 16, which if I read the .pdf correctly means I am getting much lower accuracy, right? I've never used TimeLab or ADEV/MDEV or any of this stuff before. Would you guys recommend I shift gears to that now? Now that I have at least gotten a lock with a 16 second time constant? Or do you think there is something else I should tinker with first? I noticed the .pdf mentions that an oscillator with a lot of "jumps" means the TC will need to be lower. Do I use TimeLab and do this ADEV analysis stuff to see if I have "jumps"?
EDIT: I forgot all the attachments.
On a side note, check out the signal strength on the new NEO-M8N units I got. That's just the default little puck antenna stuck to the PCB too, dangling in my window blinds. Not bad!
-
Excellent! :-+
So now, please allow me to comment on your latest scope capture.
From top to bottom:
1. The 10MHz squarewave from the OCXO.
2. The 1PPS pulse from the GPSDO.
3. The charging of the TIC capacitor. Note that the capacitor gets charged almost linearly, and the charging starts at the rising edge of the 1PPS pulse and stops at the rising edge of the 1MHz clock.
4. The 1MHz, which is in fact the 10MHz from the OCXO divided by 10.
Lars' program reads the voltage across the capacitor once per second, just after the capacitor gets charged. This voltage, as the scope capture shows, is proportional to the phase difference between the rising edges of the 1PPS from the Neo-M8 GPS module and the 1MHz from the (OCXO + 74HC390).
If we keep that phase difference constant and we know that we have counted exactly 10,000,000 clock cycles between two 1PPS pulses, then the GPSDO will have stabilized the OCXO frequency at exactly 10MHz, +/- the jitter/accuracy of our entire circuit (1ppb (0.01Hz) or so).
I am going to suggest one last addition to your scope capture and you might learn something new: could you please add two vertical lines ("cursors"), one at the rising edge of the 1PPS and a second one at the rising edge of the 1MHz clock? This will make obvious how the capacitor charges. Also you can even decrease the setting of the green channel to 0.5V/division, so we can "eyeball" the voltage across the capacitor.
-
Excellent! The more additions the better!
I went ahead and added a Y cursor too to make the cap voltage easier to see, changed it to 500mv division, and zoomed the time scale in a notch as well. Looks like it is smack dab in the middle of the 1.1v maximum, coming in at 550mv. Is this related to the fact that my DAC values are right around the middle too, coming in around 31000?
My time cursor from the rising edge of the 1PPS to the rising edge of the 1Mhz is about 500ns (keeps moving around though, just a tad). That is half the length of the PPS signal too. I'm thinking that's just a coincidence though, since the 1PPS pulse length seems to be somewhat arbitrary.
Those are just my guesses as to what these values mean. I'm excited to see what they actually mean now, especially how these scope readings relate to the serial printed information from the Pro Mini.
EDIT: Small correction to my setup; my TC is at 28, not 16. And prefilter is at 7.
-
The ADC input voltage being in the middle of the input range is good. This is where the control loop is steering it to, because supposedly this is the most linear region of the ADC. The DAC output being in the middle of the range is just a coincidence, it only depends on the OCXO. You can take it as a measure of how much the OCXO has aged. It seems your OCXO has quite some life left in it.
An OCXO to "retrace" its aging curve after being switched on after long downtime can take months.
Don't spend time on TimeLab yet. Just record the debug output, make some graphs. This will help you understand the system behavior better.
Back to the noise on the A0 pin. It is obviously correlated with the 10MHz. I suggest you add some ceramic caps to the supply pins of your divider and phase comparator ICs. 100nF MLCCs on short leads from supply to ground should reduce the 10MHz noise significantly.
-
The ADC input voltage being in the middle of the input range is good. This is where the control loop is steering it to, because supposedly this is the most linear region of the ADC. The DAC output being in the middle of the range is just a coincidence, it only depends on the OCXO. You can take it as a measure of how much the OCXO has aged. It seems your OCXO has quite some life left in it.
That is good! Looks like I got a reasonable OCXO then. It was an ebay purchase, complete in an IC with power regulator and what not. Cost like $20 or so.
An OCXO to "retrace" its aging curve after being switched on after long downtime can take months.
wow.. looks like it will be a while for that test then lol. I will do my best to keep it warm and running 24/7.
Back to the noise on the A0 pin. It is obviously correlated with the 10MHz. I suggest you add some ceramic caps to the supply pins of your divider and phase comparator ICs. 100nF MLCCs on short leads from supply to ground should reduce the 10MHz noise significantly.
Is this the same as the caps that the "Minimum working schematic for GPSDO controller" jpg image from Lars had? If so, I do already have 100nf caps between VCC and Ground at the inputs for pin 16 on the HC390, and on pins 5 & 16 on the HC4046. If you look at my picture in the earlier post you can see the type of caps I used. Does this look correct? Or should I change them up?
-
@salomonsk8r2003
Your last scope capture summarizes in a single image exactly how Lars' GPSDO works. It's just amazingly good. Thank you. :-+
It also shows how a DSO can be used at its best to analyze the workings of a relatively hard to understand circuit.
I hope it all makes sense to you, and I would suggest if you want to gain some further understanding of Lars' GPSDO, that you spend some time reading Lars' code.
You can find Lars' original code here: https://github.com/AndrewBCN/Lars-DIY-GPSDO/tree/main/Software
And my refactored version (warning: WIP) here: https://github.com/AndrewBCN/Lars-DIY-GPSDO/tree/main/Software/lars_gpsdo_AndrewBCN_refactored
Oh, one last thing: Lars' PDF has hints about using TimeLab with his GPSDO to generate some nice plots. The PDF is also in the same GitHub repository, here: https://github.com/AndrewBCN/Lars-DIY-GPSDO
EDIT:
One more thing that I just noticed: it appears the 1PPS pulse length for your Neo-M8 GPS module is still set at 1µs, you can change that back to its default value (100ms if I remember correctly).
-
I built a GPSDO based on the Lars minimum circuit and Arduino program. NEO-7M, CTI OCXO, HC390, HC4046, Arduino Nano.
Close to minimum working schematic but multiple 7805's 78L05's to isolate power. After much fiddling, it minimally works.
Lots of weirdness. If I load the "...30_170801.ino' sketch it will start, if there is no PPS , it just sets there with only the header.
Never says, "No PPS'. When I connect PPS then it may run for a few seconds (5 to 100 or so) and then restart.
If I load Paul's sketch that includes LCD, It will run, complete 'warm up' and then get 'lock' about 60 to 400 seconds after 'warm up'.
It may stay locked for anywhere from a few to 1000's of seconds and then reboot. Additionally, sometimes it will stop
serial printing the averages, usually after 10000 seconds or more. The gain is about 50, but it will lock at 12 up to 500 or more.
When it is locked, it appears very stable at 25 Mhz (5th harmonic of 5 Mhz) using my Icom 706MKII as a receiver.
I have tried three different Nano's, similar problems with all. I also tried to use an Uno, but for some reason, after a short period,
the A0 input goes to around +5 volts, even when disconnected from the TIC circuit. When that happens the DAC out goes way off.
Are all of my Nano's and the Uno I tried bad?
Is the Nano not suitable for this purpose?
Is there something special about the Nano, that I don't understand?
Has anyone else had this weirdness?
Is there a sketch that will test the hardware functionality of an Arduino?
Ding, KA8BRK
-
I have tried three different Nano's, similar problems with all.
Lars' design calls for a Pro Mini, not a Nano. I use a Pro Mini and don't have any of these issues, but I will say when googling things throughout the process I constantly kept searching "nano" on accident and it kept messing me up. I had bad drivers a few times because of it, kept getting weird pinouts, etc.
Your last scope capture summarizes in a single image exactly how Lars' GPSDO works. It's just amazingly good. Thank you. :-+
Thank you! All I did was follow your setup advice!
Sorry for the radio silence here, I had to go back to working in the office so I have not had much fun time at home on the GPSDO.
I should have a little more time to play with it over the next month now. I am starting by making a little home-made PCB to get it off the breadboard and to refresh my PCB etching skills (or lack thereof). After that I will dive into TimeLab and start learning how all that works!
On a side note, my breadboard version seems to have been reliably locked on for the last 8 days, so things are looking good for the migration to the PCB! I am going to include test-points pins on the PCB to make scope captures easier too. More of a development PCB for learning the ins-and-outs of this beauty.
-
...
Your last scope capture summarizes in a single image exactly how Lars' GPSDO works. It's just amazingly good. Thank you. :-+
Thank you! All I did was follow your setup advice!
Sorry for the radio silence here, I had to go back to working in the office so I have not had much fun time at home on the GPSDO.
I should have a little more time to play with it over the next month now. I am starting by making a little home-made PCB to get it off the breadboard and to refresh my PCB etching skills (or lack thereof). After that I will dive into TimeLab and start learning how all that works!
On a side note, my breadboard version seems to have been reliably locked on for the last 8 days, so things are looking good for the migration to the PCB! I am going to include test-points pins on the PCB to make scope captures easier too. More of a development PCB for learning the ins-and-outs of this beauty.
The test points on the PCB are a really good idea. :-+
-
I have tried three different Nano's, similar problems with all.
Are all of my Nano's and the Uno I tried bad?
Actually all three Nano's are bad! They probably have fake atmega328P chips as discussed in this thread:
"https://www.eevblog.com/forum/manufacture/atmega328p-woes-from-jlcpcb-smt-order/"
and elsewhere.
I replaced the Nano with another (removed from a different working project) and my GPSDO now seems
to work as it should. Has run for about 40 hours without losing lock. Thank you Lars.
The same chip is used on the pro mini and there are reports of similar problems with some of them as well.
Ding, KA8BRK
-
Actually all three Nano's are bad!
Oh dang, that sucks! Sorry to hear you got some duds. Where did you order them from?
If it helps, here is the link to where I got my Pro Mini's and my FTDI as well:
https://smile.amazon.com/gp/product/B004G53J5I/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
https://smile.amazon.com/gp/product/B00IJXZQ7C/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
I got two of those Pro Mini's and they work great. They seem to be authentic as far as I can tell. I didn't investigate them TOO much though because they looked legit and worked fine so I didn't dig deep. I think they are authentic though. They came with SparkFun's little warranty card too and their "thank you" note which I know comes in their authentic products. If you (or anyone else) is wanted to order from that link and you know of a more in-depth authenticity check for the Pro Mini with 328P, let me know, I would be happy to run the test on mine and make sure they are authentic before you buy some.
-
Oh dang, that sucks! Sorry to hear you got some duds. Where did you order them from?
Really, really sucks. This has cost me countless hours of hair pulling over about five or six weeks of calendar time.
These were purchased on Ebay from seller 'allamandi'. Purchased in early January, so beyond warranty time.
I suspect the seller got scammed by his vendor. Perhaps same vendor referenced in the link about the problems.
I see that other sellers on Ebay are also selling similar looking units. Buyer beware.
I should have remembered, "If the price seems to good to be true, it probably is."
Did order two more Nano's that appear to be genuine and in sealed, real Arduino boxes. Bet they will work.
Would be very suspicious of anything using the atmega328 that was manufactured since at least the start of 2022.
Neither Mouser or Digikey have them in stock, and they have many on order.
Ding, KA8BRK
-
Yeah eBay is always quite a hit or miss. I think I lucked out on my last coupled purchases there but I have been bit before. My 10Mhz oscillator I got on there works pretty good! And I got my HC390 and HC4046 chips on there too just for this project. One was a 3-pack and had a single chip with badly bent pins, so I messaged them and they sent me a whole new 3-pack! And the chip was still useable, I was just messaging them to tell them they should put more foam on the pins, but they sent them anyways, so I guess not all are bad sellers.
Did order two more Nano's
May I ask, is there a reason why you are using the Nano's for this project instead of the Pro Mini?
-
May I ask, is there a reason why you are using the Nano's for this project instead of the Pro Mini?
I just like having the USB / serial connection on the board. Easier to use to me, especially when testing.
I have had pretty good experiences on Ebay. Have only had a few bad experiences and the sellers
or Ebay made things right. Can't really fault the seller of the flaky Nano's too much except he does not
seem to want to admit that the chips are probably fake and that he got scammed. Plausible deniability??
Ding, KA8BRK
-
Has anyone else looked at the code behind the status words that are serial printed after the three hour averages?
I am using the 'lars_gpsdo_30_170801.ino' sketch.
The serial print code is located at lines 1017-1037. The status word for the first (0th) three hour average is based
on the values in EEPROM locations 576 and 720 (see line 1006) and on the value of variable
'temperature_Sensor_Type' (see line 1009). The values stored in EEPROM locations 576 and 720 is based on the
variable 'sumTemp2' (see lines 398 and 399).
I do not understand what temperature has to do with the 'locked', 'restarted', etc. status.
I think this is a mistake. I have not seen this discussed elsewhere.
Am I missing something?
Are there other versions of Lars' code out there that may have revisions?
Ding, KA8BRK
-
...
I do not understand what temperature has to do with the 'locked', 'restarted', etc. status.
I think this is a mistake. I have not seen this discussed elsewhere.
Am I missing something?
I'll take a look at that when I have some spare time... but that could take a while. :(
But in principle, the temperature readings from one of the thermistors are only used to adjust very slightly the DAC values, they should not have any further use than that (to the best of my knowledge).
This is the line of code that applies this adjustment:
dacValueWithTempComp = dacValue2 + ((tempRef * 100 - tempADC2_Filtered) * tempCoeff / 10000 * timeConst);
Note that you can build a Lars' DIY GPSDO without thermistors and it will still work fine.
Are there other versions of Lars' code out there that may have revisions?
...
No, Lars has only ever published a single revision of his code (as far as I know) and there have been no significant changes to his code base (again, as far as I know). From Lars before he unfortunately passed away:
...
One question is if I have an updated software and the answer is no. Actually I have not found or heard of any bug so severe that I have had a reason to do any changes. I have a long list of improvements but as testing is so important I would like to have a very good reason to do changes.
...
Lars
-
Hello,
I finally finished wiring my build of Lars' DIY GPSDO on a breadboard using an Arduino Uno clone. I turned it on a couple of hours ago, set the gain to 100 and am waiting now for the "Lock" status LED to come on. The TIC has not yet stabilized at 550mV or so.
Attached is a picture of the breadboard + Uno setup, and my humble 2ch DSO showing the 1PPS rising edge in yellow and the TIC capacitor (goes to ADC0 on the AVR MCU) charging.
(https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/?action=dlattach;attach=1448497;image)
There are two obvious problems with my build that are immediately visible on the DSO screenshot:
- Noise and ringing, which is more or less expected on this kind of circuit on a breadboard.
- The TIC is offset by approximately 200mV and there is a ton of noise at the AVR ADC input, meaning the input sometimes exceeds the 1.1V range of the ADC; Lars' software interprets this as a "missing 10MHz", but the 10MHz is very much there.
(https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/?action=dlattach;attach=1448503;image)
-
Well, since I wasn't getting a lock after more than 6 hours, I decided to try two things:
- I doubled the ground connection between the Uno and the breadboard.
- I replaced the 1N5711 Schottky diode in the TIC with a 1N4148 small signal fast switching diode. The assumption here is that this would prevent the voltage to the AVR ADC from exceeding 1.1V, since the 1N4148 has a larger forward voltage drop (around 0.7V) compared to the Schottky diode (around 0.25V). In his PDF Lars explained that he tried a 1N4148.
(https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/?action=dlattach;attach=1448890;image)
I powered Lars' DIY GPSDO back on and got a "lock" within 10 minutes! And the DSO shows the TIC voltage rather stable at ~550mV (meaning the PLL is working fine). I am very impressed!
(https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/?action=dlattach;attach=1448896;image)
-
A better ground connection certainly helps, but instead of the 1N4148, you could try choosing a larger resistor. Ideally, you want a low voltage drop and a small leakage current.
-
A better ground connection certainly helps, but instead of the 1N4148, you could try choosing a larger resistor. Ideally, you want a low voltage drop and a small leakage current.
Thank for the tip! :-+
I thought about replacing the 39k resistor with a 47k resistor and I think that would work too (to prevent the voltage across the capacitor from exceeding 1.1V), but I noticed that Lars has experimented with the 1N4148, so I decided to try replacing the diode first, and it worked.
But I might try the 47k resistor + 1N5711 Schottky diode combination. Actually I have a list of things I want to try:
1. Set my DSO probes to 1x (they are set to 10x right now) and see if this cleans up some of the noise.
2. Replace the 74HC4046 with a 74HC74 following the brilliant idea by Erik Kaashoek (erika in this forum).
3. Configure the thermistor and check if that makes any difference at all.
4. Adding a few extra status diodes and even perhaps a display of some kind. That would of course mean I would have to work on Lars' code, something I have avoided until now.
-
I finally finished wiring my build of Lars' DIY GPSDO on a breadboard using an Arduino Uno clone.
I would be first suspicious of the Uno clone. I have tested multiple different Nano's and one of my Uno clones.
Two of my Nano's are 'genuine", four others are clones.
They have different levels of DC offset at A0 varying from near zero to about 250 millivolts according to my old scope.
The two 'genuine' ones show 150 and 200+ millivolts offset. Two of the clones show near zero, the other two over 150.
So much for 'genuine'. I wonder if there is really a spec for this??
The Nano clone that seems to work best has almost 200 millivolts offset. Maybe the offset is not causing the no lock..
Suggest you try checking the offset with PPS disconnected. Perhaps with just a large resistor to ground and 'Blink'.
Probably should look at my earlier post about fake chips, as it looks like your Uno could be using the same style 328P
as my clone Nano's. I read somewhere that one of biggest problems with the bootleg chips has to so with the analog inputs.
All of this makes me wonder if there is not at least a little bit of luck involved in getting a Lars GPSDO to work.
Ding, KA8BRK
-
[I would be first suspicious of the Uno clone. I have tested multiple different Nano's and one of my Uno clones.
Two of my Nano's are 'genuine", four others are clones.
They have different levels of DC offset at A0 varying from near zero to about 250 millivolts according to my old scope.
The two 'genuine' ones show 150 and 200+ millivolts offset. Two of the clones show near zero, the other two over 150.
So much for 'genuine'. I wonder if there is really a spec for this??
The Nano clone that seems to work best has almost 200 millivolts offset. Maybe the offset is not causing the no lock..
Suggest you try checking the offset with PPS disconnected. Perhaps with just a large resistor to ground and 'Blink'.
Probably should look at my earlier post about fake chips, as it looks like your Uno could be using the same style 328P
as my clone Nano's. I read somewhere that one of biggest problems with the bootleg chips has to so with the analog inputs.
Thank you KA8BRK, for the information about the possibly fake or reject AVR chips in these clones. Definitely the approx. 250mV DC offset at the ADC input looks suspicious, and it does cause problems, as my personal experience shows. Perhaps that was the source of your problems too?
If you check Lars' code, you'll notice that he inserts a "dummy read" in between ADC readings:
// read ADC1 and 2 - temperature
int dummyreadADC = analogRead(A1); //without this ADC1 is influenced by ADC0
tempADC1 = analogRead(A1);
dummyreadADC = analogRead(A2); //without this ADC2 is influenced by ADC1
tempADC2 = analogRead(A2);
dummyreadADC = analogRead(A0); //without this TIC_Value (ADC0) is influenced by ADC2
which is really a waste of CPU cycles. What is this "influence" ? Unfortunately Lars is not among us anymore to answer this kind of questions.
EDIT: I found a thread on the Arduino forum that deals with this issue: https://forum.arduino.cc/t/is-reading-and-discarding-first-read-value-still-required-for-analogread/548741/2
It seems this is a problem inherent to the AVR chip ADC. :(
All of this makes me wonder if there is not at least a little bit of luck involved in getting a Lars GPSDO to work.
Indeed there is certainly some degree of tinkering required in some cases, and also possibly some room for improvements to the code and documentation. That is one of the reasons I created a repository for Lars' DIY GPSDO on GitHub, here: https://github.com/AndrewBCN/Lars-DIY-GPSDO
-
I have replaced the 74HC4046 part of the TIC with a 74HC74 configuration designed by Erik Kaashoek (see: https://github.com/erikkaashoek/Arduino_SI5351_GPSDO (https://github.com/erikkaashoek/Arduino_SI5351_GPSDO) ) and Lars' DIY GPSDO is still working fine. So the BOM for my build of Lars's DIY GPSDO is slightly simplified from the original:
- 1N5711 replaced with 1N4148.
- 74HC4046 replaced with 74HC74.
I have also set my DSO probes from 10x to 1x and that changes everything in terms of noise. Also the DC offset of the ADC input is now around 180mV, down from 250mV previously.
(https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/?action=dlattach;attach=1449811;image)
-
I do not understand what temperature has to do with the 'locked', 'restarted', etc. status.
I think this is a mistake. I have not seen this discussed elsewhere.
Am I missing something?
Yes, I was missing something. Lars used a subtle method of reusing a variable that was
not obvious to me when I first started looking at his program. I get it now.
Ding, KA8BRK
-
Hello,
Some time ago I built my own copy of Lars' GPSDO. It was operating just fine, but I decided to add an ability to read the qErr parameter out of UBLOX receivers. As a result, the phase jitter from the GPS module was attenuated about 10 times. In my version, this was done via I2C. Tested with NEO 6N, 8N, 8T modules.
I am attaching a modified source code to this message, for those who are interested (please rename .TXT to .INO). Changes are marked with "// DN" comment lines.
-
[attachimg=1]
[attachimg=2]
-
[attach=1]
[attach=2]
[attach=3]
-
That looks really very nice. Note also - this effectively eliminates the need for the TIC pre-filter in Lars' software. It was needed for anti-aliasing the time pulse, but the quantization correction achieves the same much better and without slowing down the regulation.
-
Yes, sure! But also the qErr is not a random value. It may show wierd patterns depending on GPS module type (8N or 8T), and also on the exact frequency of the module's oscillator. When I head the module, the pattern changes.
Unfortunately, there may be DC jumps, and I am afraid they may only be filtered by using a very long time constant. The blue track is an output of the TIC. Horizontal: seconds, vertical: nanoseconds.
[attach=1]
-
Yes, sure! But also the qErr is not a random value. It may show wierd patterns depending on GPS module type (8N or 8T), and also on the exact frequency of the module's oscillator. When I head the module, the pattern changes.
Unfortunately, there may be DC jumps, and I am afraid they may only be filtered by using a very long time constant. The blue track is an output of the TIC. Horizontal: seconds, vertical: nanoseconds.
(Attachment Link)
Very interesting and an outstanding addition to Lars' original firmware. With essentially zero cost in hardware or complexity, you have improved the performance of Lars' TIC by approximately an order of magnitude for tau < 1000s. :-+
I think finding the optimal time constant is more of a function of matching the intersection of the OCXO and PPS ADEV curves rather than trying to find ways to deal with the jitter in the TIC readings.
For the cheap OCXOs we use in DIY GPSDOs, this intersection is usually around tau=500s to 1000s so we would gain very little or nothing by using a shorter time constant.
-
"Andersrum wird ein Schuh draus".
The reason for the preferrably long time constant is the uncertainty (noise) of the timing reference signal. If you can remove uncertainty from the measurement you can use a shorter time constant. That's a big advantage especially with OCXOs with unknown history. You can also design a control loop that is more responsive to external influence like temperature, air pressure, OCXO misbehavior etc, without actually modeling these external sources (which can be tricky).
Using a PI regulator like in Lars software, think of Kp as its ability to respond to transients and Ki as the maximum aging speed of the OCXO it can follow. A small Ki means you need an OCXO that ages slowly. A noisy phase measurement requires a small Kp, a looser coupling to the reference.
A zero-cost addition that improves the input uncertainty by a magnitude is nothing I'd just write off as irrelevant.
-
Thank you, guys.
I believe, both of two points of view make sense. I should only notice that the qErr is not a white noise (but sometimes is having both periodic and DC components), and also the PI-filter does not eliminate the noise generated by DAC and power supply.
At least, I have not found any significant difference in the output signal of the GPSDO, with and without the qErr correction (ADEV from the GPSDO itself was showing the difference, of course). I made a lot of experiments, receiving QO-100 and telemetry beacons from Es'hail-1 and -2 sats, using my GPSDO for clocking the receiver. I had to pause two months ago, but I hope to continue soon.
As for the built-in TIC, I think we are missing the ability to measure ADEV at 0.01, - or - at least, at 0.1 seconds, since we can only get 1pps as a reliable, lowest-noise output of a GPS receiver. In addition, it is obvious that ADEV plotted from the built-in TIC, does not fully characterize the output signal of the GPSDO.
For the experiments, I built a stand-alone TIC, based on TDC7200 and Arduino M0. This is a home-brew analog of famous PIC TIC and TAPR TICC devices. I will publish all the details in the next message of this topic.
Of course, noise from ADC and power supply should also be studied. It is a good idea to use QO-100 or other sat's beacons to see the quality of the GPSDO's signal just on your screen, simply because thing invisible at 10 MHz become visible at 10 GHz. :-) It looks like the sats are ideal low-cost sources of high-quality 10 GHz signal. As many people successfully use RTL-SDRs and $3-$5 LNBs to receive signals from QO-100, the only task was to synchronize _all_ PLLs to the same 10 MHz output of the GPSDO. I experimented with several types of RTL-SDRs, Pluto and Lime SDR, and also with LNBs taking 24 or 25 MHz as an external clock (it looked like RTL-SDR is sufficient for many experiments).
To convert 10 MHz to a number of other frequencies, such as 28.8, 40, 31.25, 24 and 25 MHz, I developed a simple SI5338-based, Arduino-controlled device with 4 independent outputs. This setup (frequency converter + LNB + RTL-SDR) was very sensitive and was very good to compare several different GPSDOs. Also, it is much more pleasant to look at a live trace on the waterfall of the SDR, than to stare to the still ADEV graph. :-) I will also describe the details in next messages here.
-
Here is my version of the stand-alone, TDC7200 and Arduino M0 based TIC. This devices compares two inputs of 10 MHz, sending data to TimeLab.
TDC Click comes from mikroe.com , and the Arduino M0 comes from AliExpress.
PIC12F629 is carrying a PICDIV PD16 firmware, to generate 1 or 10 or 100 Hz our of 10 MHz. The output of the PICDIV is connected to the START input of the TDC Click.
74HC390 divides 10 MHz by 10 and again by 10 to get 1 MHz and 100 kHz, one of these signals is fed into the STOP input of the TDC click.
I am attaching a ZIP file with source code and other useful info. We will need the more powerful SAMD21 MCU instead of the ATMEGA328 just for the larger data throughput to be able to produce 10 or 100 outputs per second (ADEV at 0.1 or 0.01 sec).
8 MHz (own TCXO), connected to both inputs, was used to test the resolution. Unfortunately, I could only get about 125 ps instead of 50-55 ps (as they promise in the datasheet) - most likely, because of a poor PCB construction. Or, is it some dumb error in the software?
Interesting: thanks to Mode 2 and Multi-stops feature of the TDC7200, we do not need extra hardware to deal with a case when the phase difference of the two input signals is zero.
-
The images for the above message:
[attach=1]
[attach=2]
The input frequency for testing was 8 MHz, in fact.
Is 1.25E-10 (125 picoseconds) is a correct result, or did I forget to divide it by 2?
Some more tests are needed.
Correction: it looks like I need to count 55 picoseconds (resolution of the TDC7200) twice, since the ring oscillator is used twice in Measurement Mode 2.
-
...
Is 1.25E-10 (125 picoseconds) is a correct result, or did I forget to divide it by 2?
These are extremely interesting experiments you are performing.
My understanding is that 125ps is the theoretical resolution of your TIC device, but as in any time measuring experiment, theoretical does not mean real, you have to take into account various sources of uncertainty.
For example, the 74HC390 has a typical propagation delay of around 15ns per decade counter at 5V at 25C, but this varies with temperature and supply voltage. If you are using the two decade counters in series you effectively have a typical propagation delay of 30ns and even a 1% change in this means 300ps which is more than double your theoretical 125ps resolution.
...
At least, I have not found any significant difference in the output signal of the GPSDO, with and without the qErr correction (ADEV from the GPSDO itself was showing the difference, of course). I made a lot of experiments, receiving QO-100 and telemetry beacons from Es'hail-1 and -2 sats, using my GPSDO for clocking the receiver. I had to pause two months ago, but I hope to continue soon.
...
(my emphasis)
That is because your improvements to Lars' TIC only have an effect at tau<1000s, where the ADEV of Lars' DIY GPSDO is essentially determined by the inherent stability of the OCXO.
...
The reason for the preferrably long time constant is the uncertainty (noise) of the timing reference signal. If you can remove uncertainty from the measurement you can use a shorter time constant.
...
I have a different opinion about this. Clearly to me the reason why the time constant in Lars' DIY GPSDO is set in the range 100~1000s is because as in any GPSDO we are trying to combine the stability of the inexpensive OCXO with the stability of the PPS from the inexpensive GPS receiver, and we only want to start "disciplining" the OCXO at around the point where the two ADEV curves from the OCXO and PPS intersect.
In other words, in an inexpensive DIY GPSDO (using inexpensive OCXOs and inexpensive GPS receivers with inexpensive antennas), there is nothing to be gained by using a shorter time constant, on the contrary: if we "discipline" the OCXO at shorter intervals we are essentially introducing instability in the system and worsening the ADEV of the GPSDO in the region tau < 1000s.
A zero-cost improvement to the TIC with an order of magnitude better resolution is indeed a significant achievement but it won't change the ADEV curve for a typical Lars' DIY GPSDO build using an inexpensive OCXO and an inexpensive u-blox GPS receiver.
-
Here is a description of my 4-output, SI5338-based frequency synthesizer, which converts 10 MHz to different frequencies, such as 28.8 MHz (for RTL-SDR), 24 and 25 MHz for satellite LNB, and so on.
Silabs (SKYWORKS) ClockBuilder PRO sofrware is used to calculate registers for the SI5338. Out task is to upload the register map into the chip by using Arduino Nano. Four frequency profiles are now supported, and may be switched from a front panel. The OLED shows output frequencies at each output.
The synthesizer has its own 10 MHz OCXO, but, of course, may be switched to external 10 MHz source, such as GPSDO (by using a simple jumper). I had a spare small PC board with an SI5338 chip already installed, so I just connected four cables with SMA connectors to it. The whole device is assembled in a 100x100mm breadboard and installed into a suitable enclosure.
What about the quality of the output signal? Well, I do not see any spurs by using an old HP spectrum analyzer (dynamic rage is limited to 80-90 dB). But I _do_ see the spurs on the waterfall of the SDR sofware, using Es'hail satellites as signal sources, and using a cheap LNB with 25 MHz injected, as well as a RTL-SDR (one of XTAL contacts is desoldered and 28.8 MHz is injected via this XTAL). The level of such spurs is better than -40 dBc at 10 GHz, so I believe this means that at 10 MHz the spurs should be -90 dBc or better.
The cheap LNBs and RTL-SDRs are junk; in spite of this I could clearly see the difference between Lars' GPSDO and Leo Bodnar's one. Practically, we will need a signal which is 1) low-noise at 1..10 Hz from the carrier (at 10 GHz!!!) , and 2) low-drift, so to be able to receive FT8 at 10 GHz, the frequency drift should be less than 5 Hz in 15 seconds (0.33 Hz/sec at 10 GHz - which means 0.33 milliHz/sec at 10 MHz!).
The firmware is attached.
P.S. Bugfix: replace 14 with 22 here:
case 58:
case 69:
case 80:
case 91:
-
The photos to the previous post.
P.S. The white stuff is a polyethylene covering TCXO. I later replaced it with OCXO.
-
I found better photos.
-
Amazing work! Thank you for sharing!
-
To compare OCXO-based (Lars' with M6N GPS, IMG_5455) and TCXO-based (Leo Bodnar's with M8T, IMG_5454) GPSDOs, a beacon from one of Es'hail sats was received. (The mirror image is from the SDR software, please ignore). In both cases, an SI5338 converter was uses to get clocks for the LNB and for the SDR. Same GPS antenna. Same scale on the SDR software!
In both cases, the frequency drift was of the same order (theoretically acceptable to receive FT8). However, there is a noticeable difference in the noise (almost nil - or - 100% copy of any FT8 signal).
This is why I highly recommend taking a look at QO-100 and other sats, which in our case are inexpensive "magnifying glasses" for exploring GPSDOs. Important: you even do not need a dish to be able to receive beacons; just point your LNB in the sky.
-
To compare OCXO-based (Lars' with M6N GPS, IMG_5455) and TCXO-based (Leo Bodnar's with M8T, IMG_5454) GPSDOs, a beacon from one of Es'hail sats was received. (The mirror image is from the SDR software, please ignore). In both cases, an SI5338 converter was uses to get clocks for the LNB and for the SDR. Same GPS antenna. Same scale on the SDR software!
In both cases, the frequency drift was of the same order (theoretically acceptable to receive FT8). However, there is a noticeable difference in the noise (almost nil - or - 100% copy of any FT8 signal).
This is why I highly recommend taking a look at QO-100 and other sats, which in our case are inexpensive "magnifying glasses" for exploring GPSDOs. Important: you even do not need a dish to be able to receive beacons; just point your LNB in the sky.
These are very impressive results, and very interesting experiments. Do you have any recommendation for an inexpensive LNB ?
-
Hi Andrew!
I used to experiment with different types of LNBs, but later I bought a dozen of Eurosky UTP-5 Twin, and tried different methods to inject 25 MHz into the LNB, comparing the results.
Please do not inject 25 MHz into the same wire which is used for RF, as many people recommend. Instead, use one of the LNB's sockets for RF and power, and the other to injecting 25 MHz.
First, disassemble the LNB and power it up from 12V. By using an oscilloscope with 1:1 input (more capacitance than 1:10), find a pin of the XTAL, which has higher amplitude of 25 MHz signal. This is the output of the generator. Cut the trace, and then feed 25 MHz from external source through the XTAL. A 75 Ohm resistor to ground is recommended. Of course, the second socket should be disconnected from the existing circuit in the LNB.
Now you will need two cables to connect your LNB, but this will pay back. If you wish to be able inject 24 MHz, as well, just add another 24 MHz XTAL in parallel to 25 MHz.
-
Hi Andrew!
I used to experiment with different types of LNBs, but later I bought a dozen of Eurosky UTP-5 Twin, and tried different methods to inject 25 MHz into the LNB, comparing the results.
Please do not inject 25 MHz into the same wire which is used for RF, as many people recommend. Instead, use one of the LNB's sockets for RF and power, and the other to injecting 25 MHz.
First, disassemble the LNB and power it up from 12V. By using an oscilloscope with 1:1 input (more capacitance than 1:10), find a pin of the XTAL, which has higher amplitude of 25 MHz signal. This is the output of the generator. Cut the trace, and then feed 25 MHz from external source through the XTAL. A 75 Ohm resistor to ground is recommended. Of course, the second socket should be disconnected from the existing circuit in the LNB.
Now you will need two cables to connect your LNB, but this will pay back. If you wish to be able inject 24 MHz, as well, just add another 24 MHz XTAL in parallel to 25 MHz.
Thank you UR8US! :-+ This will certainly keep me busy experimenting this summer. :-/O
-
...
The reason for the preferrably long time constant is the uncertainty (noise) of the timing reference signal. If you can remove uncertainty from the measurement you can use a shorter time constant.
...
I have a different opinion about this. Clearly to me the reason why the time constant in Lars' DIY GPSDO is set in the range 100~1000s is because as in any GPSDO we are trying to combine the stability of the inexpensive OCXO with the stability of the PPS from the inexpensive GPS receiver, and we only want to start "disciplining" the OCXO at around the point where the two ADEV curves from the OCXO and PPS intersect.
In other words, in an inexpensive DIY GPSDO (using inexpensive OCXOs and inexpensive GPS receivers with inexpensive antennas), there is nothing to be gained by using a shorter time constant, on the contrary: if we "discipline" the OCXO at shorter intervals we are essentially introducing instability in the system and worsening the ADEV of the GPSDO in the region tau < 1000s.
A zero-cost improvement to the TIC with an order of magnitude better resolution is indeed a significant achievement but it won't change the ADEV curve for a typical Lars' DIY GPSDO build using an inexpensive OCXO and an inexpensive u-blox GPS receiver.
Let's have a look at this claim. I've made some simulations in octave using GPS 1PPS data from Leapsecond.com. Find attached three ADEV plots.
One uses an uncorrected 1PPS as input, the second one uses a 1PPS that is "sawtooth"-corrected. Those plots use a time constant of 800 seconds.
The third plot uses the uncorrected 1PPS but with a timeconstant of 2000 seconds.
The simulated GPSDO is spec'd similar to Lars design, 1ns TIC resolution, 16 bit DAC, PI regulator.
The oscillator is synthetic. It's made to be reasonable in performance but not stellar. Only white noise, no temperature dependence.
Legend:
cyan: oscillator phase
red: gpsdo output
magenta: GPS 1PPS
black: DAC values
-
...
Let's have a look at this claim. I've made some simulations in octave using GPS 1PPS data from Leapsecond.com. Find attached three ADEV plots.
...
The simulated GPSDO is spec'd similar to Lars design, 1ns TIC resolution, 16 bit DAC, PI regulator.
...
Very interesting but two points:
1. Does your simulation apply any filter to the PPS readings ?
2. As one can see from the simulation, the sawtooth correction essentially shifts down the PPS ADEV curve. However, a similar "correction" effect is achieved by Lars' TIC "pre-filter" (and in the STM32 GPSDO FLL, by the gate time averaged frequency readings). The sawtooth error is deterministic in nature so it is quite simple to deal with in practice. That explains why UR8US did not notice any real improvement in the overall Lars DIY GPSDO operation with the quantization error correction patch when tau > around 1000s.
Quoting Lars:
At short time constants (10-100secs) sawtooth correction probably is very useful for a GPSDO. At long time constants (1000-10000secs) a pre-filter probably is nearly as efficient I think.
...
My own rule of thumb is also that AT cut OCXO´s (and good VCTCXO as DOT050V) need time constants in the GPSDO of about 10-100secs, SC cut OCXO 100-1000secs and Rubidium 5000-20000secs to match good GPS receivers.
(my emphasis)
from this thread: https://www.eevblog.com/forum/projects/ocxo-stable-reference-and-control-voltages/50/ (https://www.eevblog.com/forum/projects/ocxo-stable-reference-and-control-voltages/50/)
Lars' rules of thumb are probably based on his years of perfecting his GPSDO design with various oscillators but they make perfect sense when one looks at the ADEV curves of the various oscillators he mentions and where they would intersect the ADEV straight line of the PPS from modern GPS receiver modules. As usual there is no "secret magic" that can improve the ADEV curve of a well-designed GPSDO.
-
Alright, some more simulation results, then.
I made a completely new set with a slightly enhanced oscillator model that now also incorporates flicker noise, which I think is more prominent in crystal oscillators than pure white noise. The effect of it is visible in the cyan curve, it is less steep because flicker noise doesn't average out like white noise.
Looking back at the my previous results, I'm pretty sure I made a mistake with the tc=2000 plot, it is considerably worse than you'd expect.
The colors are the same as before, I just added the ADEV of the TIC measurements in "green", it shows the effect of filtering most prominently.
First graph is without qerr correction, no filtering and tc=1000, which should be fairly optimal for this oscillator.
Second graph is identical but includes a 60 second EMA filter on the TIC measurements. See how the green curve gets flatter. Also notice that the effect for tau < 100s is almost negligible, there's a slight improvement between 100s and 1000s but the stability around 1000s is slightly worse.
Third graph is with qerr correction, no filter, tc=1000. There's a visible advantage for tau > 100s, but one can also see that the performance for tau > 1000 is worse than it could be. The time constant is too long already for this combination of GPS and oscillator.
Fourth graph is again no qerr correction, no filter but tc=2000, which gives a better result which almost matches the result from the sawtooth corrected GPS, but not quite. Of course such long time constants comes at a cost: you better have a really well controlled environment because the control loop will basically do nothing to counter any such effects.
I think this shows that there is definitely an advantage in using quantization correction, not particularly for short tau but for medium to long term stability starting with tau = 100s. Why UR8US didn't see any advantage, well, his requirements were for very short tau, well below 100s. This area is completely dominated by the oscillator.
-
Hi!
To study the qErr, I plotted it (in picoseconds) in TimeLab, and the ADEV looks quite smooth.
Idea: what if I feed qErr (instead of the TIC output) to the prefilter and so on, and then look at the DAC values in TimeLab? Will I see the difference with different time constants? I will do this experiment soon.
-
Hi!
To study the qErr, I plotted it (in picoseconds) in TimeLab, and the ADEV looks quite smooth.
Idea: what if I feed qErr (instead of the TIC output) to the prefilter and so on, and then look at the DAC values in TimeLab? Will I see the difference with different time constants? I will do this experiment soon.
I'm not sure what you're getting at with this. The "qErr" is the difference between the "true" GNSS top-of-second time signal in relation to the externally visible 1PPS pulse. It doesn't contain time information, as it is not referenced to absolute time. It is referenced to the 1PPS pulse. It is just the quantization noise. By itself it is useless.
-
I think of the qErr (in fact, "the absence of qErr correction") as a phase noise added to the noise of GPS itself (caused by atmospheric effects, etc), as well to the noise of the circuit of the GPSDO (temperature drifts, etc.).
If I see frequency drift of +=10Hz (+-1ppb) on the screen of the SDR software, receiving Es'hail beacons (the trace is almost identical to what I see at DAC), I am just curious: how much of this drift is caused by qErr? Can I efficiently reduce the drift by changing the time constant of the PI filter?
P.S: More phase noise is added when there is no qErr correction. With qErr correction, the quantization error is only ~10% compared to no correction.
-
Hi!
Here is the result of experimenting with turning qErr on or off. I used time constant of 64 seconds for the graphs not to be too smooth.
The blue line is qErr-corrected output of the GPSDO. I do not have an SDR right now to check the trace, but I believe the DAC values reflect the output frequency nicely. Similarly to previous experiments, there was a frequency swing of about +-3e-10 (+- 3 Hz at 10 GHz). However, A completely different hardware is used now; geographical position and height are also different.
The purple line is plotted with qErr correction turned off. There is no noticeable difference in the amplitude of the swing, although the line is not as smooth as the blue one.
Now, how much of the uncorrected qErr gets through the digital filters of the GPSDO? I simply fed the qErr read from the GPS module (instead of the TIC output) to the input of the pre-filter.
The qErr signal is periodical with period changing from 2 to 60 seconds. It looks like the more the period is, the more of the qErr leaks through the digital filters. However, the leakage is quite small even for a 64-second filter (green line).
Unfortunately, all three graphs were made at different time, so I can not add or subtract them.
-
Two remarks:
1- ADEV for all data sets would be nice
2- 600 seconds is not really a lot to make a meaningful statement.
-
Two remarks:
1- ADEV for all data sets would be nice
2- 600 seconds is not really a lot to make a meaningful statement.
Sure! More data is always better, but, I am too impatient. :-)
-
I definitely need to run the plots for 24 hours or so to get smooth graphs at t~1000sec.
-
Hi everyone, it's been 2 years since I built my Lars GPSDO and I haven't been here for quite a while.
Recently my Bliley OCXO starting drifting badly so I replaced it with a Vectron I found on eBay for just £9. I established the gain and linearization then set it running with no temperature compensation. This resulted in the attached graphs and I have a couple of questions about diff_ns.
What causes the periodic sudden swings?
You can see that diff_ns tracks the change in temperature. I know how to calculate tempRef but am not having much luck understanding how to get tempCoeff from the constantly changing DAC values. Can anyone help please?
Mike
-
What causes the periodic sudden swings?
How long have you run it? OCXOs that haven't been run for a while, and bounced around in transit, need time to settle. A week maybe?
-
3 or 4 hours should be enough, otherwise the OCXO is not good.
-
3 or 4 hours should be enough, otherwise the OCXO is not good.
Or 3 to 4 weeks. I'm sure it's been a while since it was powered on and it has been banged around quite a bit.
-
It's been running for about a week. I wasn't expecting much for such a cheap device that's 15 years old, but I thought the MDEV looked OK?
I just want to understand what causes those jumps in diff_ns.
Mike
-
It's been running for about a week. I wasn't expecting much for such a cheap device that's 15 years old, but I thought the MDEV looked OK?
I just want to understand what causes those jumps in diff_ns.
Mike
Looking at the MDEV and the raw data graphs I'd say, it's working fine. I believe the diff_ns jumps are just quantization artifacts. The raw phase error data does not suggest any particular problem like phase jumps. Also, no excessive drift or similar.
-
Looking at the MDEV and the raw data graphs I'd say, it's working fine. I believe the diff_ns jumps are just quantization artifacts. The raw phase error data does not suggest any particular problem like phase jumps. Also, no excessive drift or similar.
Thank you, that's good to hear. I think the Vectron OCXO was a bargain (I bought two at that price and they arrived from China in a week).
I will persevere with temperature compensation but it may not be worth the effort!
Mike
-
Q1 :
post 1 is always updated with the last goodies ?
so anyone who like to try make one, only need to look at post 1 ?
Q2 :
5V for arduino is normally not that clean, and this voltage is used to drive the VCO voltage via pwm,
is that a good idea ?
or are we missing a note about how to make a super clean and stable 5V for the arduino
PS: THANKS LARS.. for sharing, i am so much ready to make this project
-
Q1 :
post 1 is always updated with the last goodies ?
so anyone who like to try make one, only need to look at post 1 ?
Q2 :
5V for arduino is normally not that clean, and this voltage is used to drive the VCO voltage via pwm,
is that a good idea ?
or are we missing a note about how to make a super clean and stable 5V for the arduino
PS: THANKS LARS.. for sharing, i am so much ready to make this project
As Lars sadly is no longer with us, I'm afraid nobody is updating the 1st post. You'll have to dig.
-
OMG.. i am sad to hear about that.. ok i do the digging, could have been nice to know where to dig.. 45 pages :-) to search.
-
I did some experiments with a U-blox NEO-6 GPS with active antenna, moving the antenna to different places. My GPSDO design is nothing like Lars, but this may be of interest since Lars' design is also for low cost components. I guess a point of comparison is I use averages up to 768 seconds (3 *2^8 if you want to know why) which is like a loop time constant. The results show there isn't much reason to improve the GPSDO without improving the GPS signal reception.
I was wondering if it was worth $20 to hold the control voltage within 4µV. Answer, not really. It may be with the best of the positions with the antenna on the roof and no obstructing buildings. Like most things, upgrade one part, then have to upgrade another. Get a higher antenna, use a timing GPS module (maybe the dual band costing three figures) then play with power supply stabilisation for a DOCXO (another three figures) etc. etc.
I am currently selling kits for my GPSDO for $55AU (only in AU, includes postage) which includes antenna, GPS module, USB/serial adapter, PCB, OSC5A2B02, support components, 10MHz BNC output into 50Ω - well, basically everything except the 12V power supply and an enclosure. Achieves 1ppb stability (0.2 ppb with the best GPS signals) and is locked long term so has that descending Adev that everybody likes. Any upgrade to one part, match it with other upgrades, cost goes up very quickly. The moral is, as always, you get what you pay for.
-
MIS42N can you please share a working schematic, and a working arduino file ??
spend all night making one, after warm up, all i see is nolock,
when i scope all things, it apear to be correct
I am also using U-blox NEO-6 , and get super clean 1pps from my gps
I am using a 1ppm 10MHz TCXO
datasheet here
webx.dk/osc.pdf
-
MIS42N can you please share a working schematic, and a working arduino file ??
I think you skipped the bit where I said "My GPSDO design is nothing like Lars". If you are interested, the writeup is here https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/ (https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/)
You will find a schematic of the current design near the end of all the posts.
-
thanks a lot mate, that looks a bit better all over..
but right now all i like to see, is my Lars thingy go into lock
i saw it takes 10 hrs for the VCO voltage to drop 500mV
that is a long time to wait..
-
FINALLY MADE IT !!
it was not that easy to figure this out :-)
but now it is in lock and i am happy
-
if you dont own a 74HC390
a good old 7490 can also be used, here is how you do that
See also the note in my schematic, you can ofcourse also use 4046
then it is pin 1 that is the 0-1uS output
-
I have been playing a lot more with this circuit
added a driver buffer for the 1pps, so it can drive my cable correctly,
now i got fast and tight risetime,
this helped a lot on the nS error signal, see the attached picture
-
this is not a thing ??
https://www.beis.de/Elektronik/4046vs9046/74HCT4046vs74HCT9046-en.html (https://www.beis.de/Elektronik/4046vs9046/74HCT4046vs74HCT9046-en.html)
-
It seems to be for PC2 output but Lars was using PC3 (pin 15) which, afaiaa, does not have such a dead zone.
BTW, when you mentioned that ten hours wait for the ocxo's EFC pin to rise a mere 500mV, my first thought had been, "Jeez! I thought hanging in for the two and a half hours it took for my own version of the G3RUH gpsdo to finally establish lock with a 5000s TC was bad enough!!
I'd only stuck it out because unlike an earlier version with a 1000s TC PLL filter that had refused to get past a sticking point, this looked like it just might eventually reach its goal and I was curious enough to let it continue unmolested. I'd aborted the earlier run and added a 20M ohm 'helper resistor' between the output of the PLL filter and Vcc to brute force its way past its sticking point. This had done the trick, albeit at a slight reduction of the filter's time constant, and was retained as a permanent fix.
I'm pretty sure I'd used the same 470uF cap, tested for sub nA leakage at 5 volts, so the puzzle of the stickiness of the earlier test build remains an unsolved puzzle - possibly a leakage issue in the cheap paxolin stripboard I'd built it on.
Since I didn't want to be left hanging in the breeze for two and a half hours waiting for it to resume GPS lock every time I had to power it up (I was still tinkering with it), I came up with a two diode plus trimpot helper circuit to do the initial 'heavy lifting' of the EFC voltage to just shy of the 2.3570 on tune volts by about 150mV, relying on the forward bias current at sub 100mV dropping to less than a nA (12 and 15 volt zenners proving to the best choice over standard silicon diodes like the 1N4000 series for this job). This measure reduced the time to lock from a cold start to only half an hour. :)
The 5000s TC proved a bit too long for the oxco's short term stability so I reverted to a 1200s TC, keeping my speed up circuit in place where it now reduces the time to lock from cold to a mere 10 to 12 minutes, matching the time it takes for the ocxo's oven temperature to stabilise enough for the PLL to finally catch up with the resulting wild frequency swings (tens of mHz).
Looking at the circuit diagram of the Lars gpsdo you posted, I noticed the use of two pwm pins to create a 16 bit DAC. Presumably the 10 bit ADC is being oversampled to gain an extra 5 to 6 bits to match the effective PWM resolution? I haven't examined the code in detail (or at all, tbh).
==============================================================================================
[EDIT] Whilst scanning Lars's code to get a clue on whether he'd used oversampling, I realised why he'd ganged two pwm pins to create a 16 bit pwm - to make full use of the ADC's 10 bit resolution of course! Mind you, I'm surprised he didn't oversample by 16 and decimate by two to add a couple of extra bits resolution. Perhaps a lack of code space? :-\
==============================================================================================
At the time when I first download Lars' documentation, I'd not had any experience in using the Arduino IDE with any of these AVR based SoC boards. However, since spending the past 50 weeks (and counting), programming a Nano to control the base plate temperature of an LPRO-101 in my ongoing RFS project of the last two years, I now have a renewed interest in making a micro controller based alternative to my current gpsdo work horse lab reference and this looks a better bet than Andrew's pet project (for starters, at least).
I've attached a couple of screen shots of the ruby versus the gpsdo covering a 25 hour and a half interval. The infinite persistence includes the 5 or 6 ns gpsdo disciplining wobble (mostly ionospheric effect) and the leisurely 33ns phase wander of the ruby which appears to be in part, a diurnal artifact.
-
looks nice, we been performing quite a bit the last few days,
first using the same hardware,
but added a routine to count the 5Mhz, at 1Hz resolution, the AVR can do that just fine
then raw adjusting the DAC in a halve step methode, example :
from 32768 as the first try, then : if too high, then 16384, if still too high, then 8192
if too low now, then 12288 and so forth,
each measurement takes a 3 sec pause, just to be sure the dac filter is stable, after each dac change,
when error is under 1Hz, then call the normal software.
you be amazed how fast the system boots up and lock after this type of start up :-)
-
I should think using a 'binary chop search' would make quite a difference to the lock up time. With a cold start, you still have to wait on the ocxo's oven temperature to stabilise for the frequency to fully settle down though - perhaps another ten to twenty minutes?
That's the situation I'd had to face even with a hot start when the ocxo has only had a fraction of a second to cool down by a few mK after the briefest of power glitches. The oven temperature controller is obviously driven by a PID algorithm running on some sort of MCU which uses a "Shoot first, ask questions later" startup algorithm that doesn't check whether it actually needs to turn the heater on full blast to reach operating temperature in the shortest possible time.
For a genuine stone cold start, that's an excellent strategy but the worst possible if it's the result of a few ms dropout of power that's caused the restart. >:( :( This behaviour becomes very annoying when all you want to do is swap power sources or reroute the dc power feed - the gps module only takes 3 or 4 seconds to recover and start disciplining the ocxo back on frequency, assuming the ocxo didn't misbehave in such a fashion. Unfortunately, the resulting up and down temperature swings keep the PLL futilely trying to keep pace with the resulting frequency swings for the next 10 minutes or so before it can finally settle back down.
In the end, I'd suffered enough of this ocxo's behaviour that I designed and built a backup power reserve into the gpsdo using a protected LiPo pouch cell. I'd had to add yet a second buck converter into the mix and switch the original buck and boost converter arrangement so I could float charge the LiPo to 65% SOC at 3.85v to power the 12v output boost converter used to power the ocxo and now also the 5v buck powering the logic circuitry (the 5v buck had originally powered the 12v boost).
This added another 100mW onto the original 1500mW power budget but it was well worth the effort since not only did it remove the annoyance of having to suffer so much disruption for the briefest of interruptions during a power feed change over, it also extended the voltage range from a 6.5v minimum to 24v maximum by another two volts at the low end. In essence I can now use anything from a power bank or 2.1A rated usb wallwart right up to a 22v laptop charging brick and anything in between with a 5W or higher rating (hot swap case). I need a 10W minimum rated psu to handle the demand of a "Black Start" (stone cold ocxo with a discharged LiPo).
Anyway, the upshot of this final modification being that the startup time is no longer an issue. ;D
-
YES 'binary chop search' is the word i was looking for
that is exactly what we are doing, and it works amazingly
true the warm up drift is a thing,
but that should be handeled fine by the normal lock and filter software,
the way that it is today is it monitors the TIC variations over time, and when small enough
it changes the filter parameters, and then turn on the lock led
I suggest two lock leds, one for pre locked frequency mode, and the one we have today,
this means are the error far below 1Hz (1 mins after pow on)
or is it under 10e-10 or even smaller (5-10 mins after power on)
-
What you're achieving with that start up strategy is making use of the GPS's short term stability which compared to a fully stabilised ocxo is poor but still much better than that of an ocxo which is in the process of getting up to temperature.
Regarding a separate indicator lamp, there are ways to avoid adding another lamp but if you're already relying on only a single indicator lamp for power/gps lock/ocxo lock/or whatever else, a second one wouldn't come amiss since this provides a level of redundancy as to whether a lone completely extinguished lamp indicates power loss, an MCU lockup or simply a faulty LED or the circuitry that drives it. IOW, it helps reduce the guesswork when something goes wrong. :)
Of course, if the front panel includes an oled or lcd display, the need for redundant indicator lamps reduces somewhat. I rely on only two indicator lamps (LEDs but let's stick with "lamps") to display the operating state of my gpsdo. The traditional red to show that it's powered up and a green one to show whether the gps receiver is locked/unlocked (steady half brightness or blinking at 4Hz respectively) or whether the user settings have reverted to their defaults (flashing at 1 Hz or extinguished) for any reason.
This last set of signals are an inheritance from the days when I was using fake M8N modules with no functioning flash limiting the storage of user settings to the BBRAM alone with an 80mF supercap providing a mere 45 minutes of backup time if you don't add the usual fix of a CR2032 coin cell to extend the BBRAM endurance out to some 280 days in the absence of external power.
Now that I'm using genuine M8T modules with functioning flash storage, I don't really need this status information but since there's still a remote chance of losing the user settings, I retained this functionality anyway. Initially, the red lamp only indicated its powered up status but now that I have a built in backup power source, it blinks at 2Hz to indicate the loss of external power and the switch to backup battery power.
A reassuringly steady red glow is an unambiguous indication that all is well, whereas a blinking red lamp is an obvious warning that "There's trouble in Paradise" so it's worth dedicating a lamp to this one task alone - the power status. I was quite pleased with myself in reducing the indicator lamp count to just two but in a discussion regarding the minimum number of indicator lamps to indicate the various operational states of something like a basic gpsdo, I was chided for not being minimalist enough :o
When it came to building my RFS, I did elect to go "minimalist" on the indicator lamp count, However there really was no justification to have more than a single bi-colour 2 wire LED for power status. If it was glowing at all, regardless of colour, it was receiving power. Red indicating it was waiting for atomic lock or else green to show it had achieved atomic lock (typically some 3 minutes and ten seconds after being powered up from cold). Also, of course, I had a little SSD1306 oled display to provide a secondary indication that it was indeed in a powered up state.
Some might argue that I'd not been minimalistic enough and question the use of a LED whilst there was (just enough) room in the display for an "Atomic Lock" symbol forgetting that most failures with these oled panels result in a totally unlit display (either a fault in the module itself or a problem with the wiring or the software running on the attached micro controller).
I'm rather old skool in my attitude to the more extreme forms of minimalism in regard of front panel displays, meaning I'm all too mindful of the truth expounded by "Murphy's Law". There's no way I can guard against component failure other than to provide some sort of redundancy so I can at least minimise the chance of a single point of failure leaving me totally in the dark as to its most likely cause.
In the end, the number of front panel indicators I choose to inflict on any of my project enclosures tends to the less extreme minimalist approach, largely on the basis of "The fewer holes I have to drill in this damned panel, the better it is for me!" :-DD
-
Some might argue that I'd not been minimalistic enough and question the use of a LED whilst there was (just enough) room in the display for an "Atomic Lock" symbol forgetting that most failures with these oled panels result in a totally unlit display (either a fault in the module itself or a problem with the wiring or the software running on the attached micro controller).
My GPSDO is about as minimalist as it gets with a microprocessor. There are only two ICs, PIC16F1455 to do the work, 74HC04 to buffer the HCMOS OCXO 10MHz output to provide the 50Ω output. The processor had only one spare pin to drive a LED.
So I implemented a 24 bit shift register that is shifted every 50ms, a 1 bit in the register lights the LED. That encourages some inventive LED use.
At power up, 250ms on, 250ms off means there is no 10MHz from the OCXO (processor runs on its internal clock)
No NMEA data (faulty GPS module?) is 800ms on, 200ms off.
Satellites in view (waiting for GPS to indicate a fix) is indicated in binary over 4 seconds - 50ms on, 50ms off, 50ms on, 350ms off is a zero; 50ms off 50ms on 400ms off is a one. pad with off
NMEA data indicates a fix but no 1pps received - no LED data (another fault condition)
Adjusting control voltage - 400ms on 600 ms off
Locked but not stable - 50ms on, 50ms off, 50ms on, 850ms off
'all is well' - 50ms on 950ms off
The idea is the LED must be doing something if the circuitry is OK. Permanent on is a fault, permanent off is a fault (if it occurs at power up, different fault). It does go against your 'blinking red lamp is an obvious warning that "There's trouble in Paradise" ' (I use a white LED salvaged from Christmas Lights - good visual output with less than 50µA drive). But a one second blink is quite reassuring if it means normality, and it stands out against any background of other power on lights.
Regarding OCXO power on. The OSC5A2B02 I use takes about 3 minutes to be locked and 15 minutes before a guaranteed 10E-9 stability.
-
Some might argue that I'd not been minimalistic enough and question the use of a LED whilst there was (just enough) room in the display for an "Atomic Lock" symbol forgetting that most failures with these oled panels result in a totally unlit display (either a fault in the module itself or a problem with the wiring or the software running on the attached micro controller).
My GPSDO is about as minimalist as it gets with a microprocessor. There are only two ICs, PIC16F1455 to do the work, 74HC04 to buffer the HCMOS OCXO 10MHz output to provide the 50Ω output. The processor had only one spare pin to drive a LED.
So I implemented a 24 bit shift register that is shifted every 50ms, a 1 bit in the register lights the LED. That encourages some inventive LED use.
At power up, 250ms on, 250ms off means there is no 10MHz from the OCXO (processor runs on its internal clock)
No NMEA data (faulty GPS module?) is 800ms on, 200ms off.
Satellites in view (waiting for GPS to indicate a fix) is indicated in binary over 4 seconds - 50ms on, 50ms off, 50ms on, 350ms off is a zero; 50ms off 50ms on 400ms off is a one. pad with off
NMEA data indicates a fix but no 1pps received - no LED data (another fault condition)
Adjusting control voltage - 400ms on 600 ms off
Locked but not stable - 50ms on, 50ms off, 50ms on, 850ms off
'all is well' - 50ms on 950ms off
The idea is the LED must be doing something if the circuitry is OK. Permanent on is a fault, permanent off is a fault (if it occurs at power up, different fault). It does go against your 'blinking red lamp is an obvious warning that "There's trouble in Paradise" ' (I use a white LED salvaged from Christmas Lights - good visual output with less than 50µA drive). But a one second blink is quite reassuring if it means normality, and it stands out against any background of other power on lights.
Regarding OCXO power on. The OSC5A2B02 I use takes about 3 minutes to be locked and 15 minutes before a guaranteed 10E-9 stability.
The nice thing about these DIY projects is the freedom to be as minimalist as you like. Presumably you made up a "Cheat sheet list" of the blink codes as an aide-mémoire for the more obscure ones. ;)
As I mentioned, I'm a little "Old School" in my thinking in regard of the indicator lamp count, preferring to give the power status indicator a whole lamp of its own with one (or more) indicator lamps to indicate other vital information. I realise that modern LED lamps are just as, if not more reliable than, the rest of the component parts soldered onto the PCB(s) inside the box making the need for such redundancy a moot point.
Even so, having a second indicator lamp provides a sanity check as to why an indicator unexpectedly remains unlit when it should be doing something. In the case of my G3RUH inspired GPSDO, the only microcontroller in the box was the one inside the Ublox M8N and M8T modules I was using which allowed me push out additional status information via the green LED.
The use of a separate red LED to show power status had been a 'no brainer' choice as far as I was concerned, after all it was just a simple dropper resistor connection to the Vcc line, about as simple as it gets with no complications over interpreting its meaning (at least not until I'd added the battery back up feature :)). Even I wasn't so lazy as to avoid having to drill a second hole in "That damned front panel". :)
I appreciate the minimalist aesthetic but prefer to have some modicum of redundancy in the status indicator array, even if the "array" is just two lamps or one plus an oled or lcd panel. If you're using an oled display, you definitely need a separate power on indicator lamp. A backlit LCD panel, not so much, since the backlight makes for an effective power on indicator lamp in its own right.
I could so easily go on about the subject but I think I've said more than enough and in danger of committing the cardinal sin of "Trying to teach granny how to suck eggs." :palm: I've probably already committed this 'cardinal sin' but, what the Hey! The deed is done. ::)
-
..That encourages some inventive LED use.
..At power up, 250ms on, 250ms off means there is no 10MHz from the OCXO (processor runs on its internal clock)..
Would not be better to learn Morse code? There are tons of source code for generating morse..
:-DD
73
-
BTW, when you mentioned that ten hours wait for the ocxo's EFC pin to rise a mere 500mV, my first thought had been, "Jeez! I thought hanging in for the two and a half hours it took for my own version of the G3RUH gpsdo to finally establish lock with a 5000s TC was bad enough!!
..
To design the filter for Miller's design is not easy, indeed. I made a tool some time back to help with the design of the filter, and in my case the waiting time was not longer than 30 minutes.
Btw, it has been my understanding the Lars' design starts fine almost immediately as the mcu remembers the last EFC voltage (that is a great advantage over the Miller, sure).
https://www.eevblog.com/forum/projects/gpsdo-with-xor-phase-comparator-control-loop-filter-design/msg3458070/#msg3458070 (https://www.eevblog.com/forum/projects/gpsdo-with-xor-phase-comparator-control-loop-filter-design/msg3458070/#msg3458070)
-
..That encourages some inventive LED use.
..At power up, 250ms on, 250ms off means there is no 10MHz from the OCXO (processor runs on its internal clock)..
Would not be better to learn Morse code? There are tons of source code for generating morse..
:-DD
73
With messages in Estonian.
In practice, only one indication is useful. Single flash once a second? Yes - all good. No - there's a problem. The rest are window dressing.
-
So I'm fighting some GPS issues and I'm curious to hear the group's thoughts.
I've got a marine GPS antenna up on the eaves with a pretty good look to the sky. I'm running it down into a 4-way splitter (1 DC pass + 3 DC block) to have multiple GPS drops for different GPSDO designs I'm testing.
I'm trying to survey-in a few M8Ts, and I can't seem to get the position StDev below about 3, whereas below 1 is desired for accurate timing. I've noticed my ADEV for the "baseline" GPSDO I've built is also rather bad with this new setup. I know I take a 6 dB hit with the splitter, but there seem to still be plenty of birds in-view and in-use so I'm curious if it's just a signal level issue, and if adding an LNA inline would help things at all.
(https://i.imgur.com/usfuWGi.png)(https://i.imgur.com/zAOjjNr.png)
-
So I'm fighting some GPS issues and I'm curious to hear the group's thoughts.
I've got a marine GPS antenna up on the eaves with a pretty good look to the sky. I'm running it down into a 4-way splitter (1 DC pass + 3 DC block) to have multiple GPS drops for different GPSDO designs I'm testing.
I'm trying to survey-in a few M8Ts, and I can't seem to get the position StDev below about 3, whereas below 1 is desired for accurate timing. I've noticed my ADEV for the "baseline" GPSDO I've built is also rather bad with this new setup. I know I take a 6 dB hit with the splitter, but there seem to still be plenty of birds in-view and in-use so I'm curious if it's just a signal level issue, and if adding an LNA inline would help things at all.
My opinion. If you have enough satellites (I think 6 is enough) 40dB and over you don't need an LNA. Others have said there are benefits to programming the GPS to limit the sky view and/or not use all the available constellations. I use crap GPS modules so I don't have experience there. Monitor the DOP (dilution of precision), it may indicate some sort of problem - reflection off nearby structures etc. One place I tried my antenna it showed a full sky view when mapped despite being squeezed between two buildings. That makes me think some signals were reflections; the GPSDO performed poorly. The DOP was over 2 for around 20% of the time, whereas with a good sky view it doesn't ever go over 2.
I use GPSview to monitor, with my good antenna place and an Neo-7 it shows a std deviation of around 1 meter. So 3 seems a bit high, worthy of investigation. If you think signal strength is an issue, why not run monitoring for a day without the splitter, then another day with it in. That should show if there's a difference.
-
The signal strength looks sufficient, doesn't look like you need to worry about that.
Limiting the elevation doesn't help during survey-in, on the contrary. For accurate positioning you need low'ish elevation SVs, the more the better. What you can also do is enable SBAS (WAAS/EGNOS), but only during the survey-in. That will help getting a better positioning accuracy.
Final hint: Switch off all constellations but GPS and Galileo.
-
The signal strength looks sufficient, doesn't look like you need to worry about that.
Limiting the elevation doesn't help during survey-in, on the contrary. For accurate positioning you need low'ish elevation SVs, the more the better. What you can also do is enable SBAS (WAAS/EGNOS), but only during the survey-in. That will help getting a better positioning accuracy.
Final hint: Switch off all constellations but GPS and Galileo.
You win a cookie! Disabling all the constellations except GPS/Galileo resulting in an immediate order of magnitude improvement. I'm currently looking at a StdDev of 0.4 after only 8 hours.
Interesting that GLONASS was causing that much of an issue.
-
The signal strength looks sufficient, doesn't look like you need to worry about that.
Limiting the elevation doesn't help during survey-in, on the contrary. For accurate positioning you need low'ish elevation SVs, the more the better. What you can also do is enable SBAS (WAAS/EGNOS), but only during the survey-in. That will help getting a better positioning accuracy.
Final hint: Switch off all constellations but GPS and Galileo.
You win a cookie! Disabling all the constellations except GPS/Galileo resulting in an immediate order of magnitude improvement. I'm currently looking at a StdDev of 0.4 after only 8 hours.
Interesting that GLONASS was causing that much of an issue.
I generally keep GLONASS disabled. It also messes up timing. No idea if it's a firmware or a GNSS issue, though.
Another thing you can do to speed up position convergence: higher measurement frequency. I do 4 measurements per second during survey-in.
-
I haven't been on this topic in a while, and was wondering if sawtooth correction was added to this GPSDO?
I built one from a friend that was based on Lars', had dual EFC DACs, sawtooth etc. and it did a good job with HP 10811s, symmetricom sprinter series, and an X72 Rb I have. I brought it out the other day and promptly blew up the arduino by attaching the received signal from the GPS directly to it without using a voltage divider. Now I can't recognize the arduino or reprogram it, and Amazon let me down on overnight shipping. But then I started wondering if this DO had ever been updated with sawtooth and maybe start here if there was more support.
Using the other GPSDO, I had planned to take the DACs out and send the tuning word to the X72 over serial, but I ran out of serial ports so I would have to rewrite some of it and setup another software serial port. I planned also to convert it to an STM32 board so I didn't need a PC to monitor it. I want to shut down my two lucent GPSDOs and just run the X72 until I repair my Cesium (I have another tube to put in it). The two lucent boxes take over 100w of power to run and at .40 per KW hour, that's not cheap.
Thanks
Jerry
-
Anyone have any suggestions for improvement? This is my GPSDO, with a Bliley OCXO and an M8T surveyed-in to 0.1m stdev. For some reason, even with a TC of 96, the DAC value never totally settles.
(https://i.imgur.com/y2chDFM.png)
Any time constant higher than 96 and the loop doesn't seem to lock.
-
Anyone have any suggestions for improvement? This is my GPSDO, with a Bliley OCXO and an M8T surveyed-in to 0.1m stdev. For some reason, even with a TC of 96, the DAC value never totally settles.
How long have you run it? Some OCXO need a few days to settle down. Is the DAC just jittering around a value, or going in a particular direction (up or down). If it is going up or down it is worth waiting. If it is jittering, then it may be other causes - power supply maybe?
-
Anyone have any suggestions for improvement? This is my GPSDO, with a Bliley OCXO and an M8T surveyed-in to 0.1m stdev. For some reason, even with a TC of 96, the DAC value never totally settles.
How long have you run it? Some OCXO need a few days to settle down. Is the DAC just jittering around a value, or going in a particular direction (up or down). If it is going up or down it is worth waiting. If it is jittering, then it may be other causes - power supply maybe?
That was a 14-day run. Before I took that data it had also been running for about three months continuously. With G=27 and TC=96 it never unlocked, but I suspect my actual performance was rather poor as demonstrated by the plot I posted above.
-
Anyone have any suggestions for improvement? This is my GPSDO, with a Bliley OCXO and an M8T surveyed-in to 0.1m stdev. For some reason, even with a TC of 96, the DAC value never totally settles.
How long have you run it? Some OCXO need a few days to settle down. Is the DAC just jittering around a value, or going in a particular direction (up or down). If it is going up or down it is worth waiting. If it is jittering, then it may be other causes - power supply maybe?
That was a 14-day run. Before I took that data it had also been running for about three months continuously. With G=27 and TC=96 it never unlocked, but I suspect my actual performance was rather poor as demonstrated by the plot I posted above.
Yes sorry, I didn't look closely at the graph, just the question. You didn't say if the DAC was jittering or going in a direction. A 16-bit DAC will always be moving by 1 because it can rarely generate the exact EFC needed, it will be alternating between two adjacent values. But you imply it is doing more than that?
-
Anyone have any suggestions for improvement? This is my GPSDO, with a Bliley OCXO and an M8T surveyed-in to 0.1m stdev. For some reason, even with a TC of 96, the DAC value never totally settles.
How long have you run it? Some OCXO need a few days to settle down. Is the DAC just jittering around a value, or going in a particular direction (up or down). If it is going up or down it is worth waiting. If it is jittering, then it may be other causes - power supply maybe?
That was a 14-day run. Before I took that data it had also been running for about three months continuously. With G=27 and TC=96 it never unlocked, but I suspect my actual performance was rather poor as demonstrated by the plot I posted above.
Yes sorry, I didn't look closely at the graph, just the question. You didn't say if the DAC was jittering or going in a direction. A 16-bit DAC will always be moving by 1 because it can rarely generate the exact EFC needed, it will be alternating between two adjacent values. But you imply it is doing more than that?
Yeah, it seems to be alternating quite a bit more. Here's a log excerpt from the last of the 14 days (I have some extra columns in my FW). You can see the DAC value moves from 42013 all the way down to 42009.
1050906 -2 42013 31.3 Locked -1 5058 96 48 25092 629 11 0.764 4994 42018 30.1
1050907 -4 42013 31.3 Locked -2 5056 96 48 25092 625 11 0.765 4995 42018 30.1
1050908 -6 42013 31.3 Locked -2 5054 96 48 25092 622 11 0.766 5015 42019 30.1
1050909 -7 42013 31.3 Locked -1 5052 96 48 25092 622 11 0.767 5009 42019 30.1
1050910 -9 42013 31.3 Locked -2 5049 96 48 25092 621 10 0.768 4989 42019 30.1
1050911 -12 42013 31.3 Locked -3 5046 96 48 25092 620 10 0.769 4990 42019 30.1
1050912 -14 42012 31.3 Locked -2 5042 96 48 25092 618 10 0.7610 4995 42019 30.1
1050913 0 42012 31.3 Locked 14 5041 96 48 25092 631 10 0.7611 4983 42019 30.2
1050914 -1 42012 31.3 Locked -1 5041 96 48 25092 625 10 0.7612 4967 42017 30.2
1050915 -3 42012 31.3 Locked -2 5039 96 48 25092 624 11 0.7613 4971 42017 30.2
1050916 -5 42012 31.3 Locked -2 5038 96 48 25092 622 11 0.7614 4940 42015 30.4
1050917 -8 42012 31.3 Locked -3 5035 96 48 25092 621 11 0.7615 5021 42016 30.4
1050918 -11 42012 31.3 Locked -3 5032 96 48 25092 619 11 0.7616 5024 42018 30.5
1050919 -14 42012 31.3 Locked -3 5029 96 48 25092 618 11 0.7617 4970 42017 30.5
1050920 -16 42012 31.3 Locked -2 5025 96 48 25092 617 11 0.7618 4989 42016 30.5
1050921 -2 42012 31.3 Locked 14 5025 96 48 25092 625 11 0.7619 4976 42015 30.5
1050922 -4 42012 31.3 Locked -2 5023 96 48 25092 624 11 0.7620 4995 42016 30.7
1050923 -4 42012 31.3 Locked 0 5022 96 48 25092 622 11 0.7621 4971 42015 30.7
1050924 -5 42012 31.3 Locked -1 5021 96 48 25092 623 11 0.7622 5014 42016 30.7
1050925 -7 42012 31.3 Locked -2 5019 96 48 25092 627 11 0.7623 4990 42016 30.7
1050926 -9 42012 31.3 Locked -2 5017 96 48 25092 621 11 0.7624 4949 42014 30.7
1050927 -11 42012 31.3 Locked -2 5015 96 48 25092 619 11 0.7625 5020 42015 30.8
1050928 -13 42012 31.3 Locked -2 5012 96 48 25092 619 11 0.7626 4995 42015 30.8
1050929 -14 42012 31.2 Locked -1 5009 96 48 25092 617 11 0.7627 4948 42013 30.8
1050930 -15 42011 31.3 Locked -1 5006 96 48 25092 616 11 0.7628 5020 42014 30.8
1050931 -16 42011 31.3 Locked -1 5002 96 48 25092 615 11 0.7629 4968 42014 30.9
1050932 -18 42011 31.3 Locked -2 4999 96 48 25092 619 11 0.7630 5035 42015 30.9
1050933 -4 42011 31.3 Locked 14 4998 96 48 25092 624 11 0.7631 4910 42011 30.9
1050934 -7 42011 31.3 Locked -3 4997 96 48 25092 622 11 0.7632 5037 42012 30.9
1050935 -9 42011 31.3 Locked -2 4995 96 48 25092 622 11 0.7633 5013 42014 30.9
1050936 -11 42011 31.2 Locked -2 4993 96 48 25092 620 11 0.7634 4981 42014 30.9
1050937 -12 42011 31.2 Locked -1 4991 96 48 25092 618 11 0.7635 4981 42013 31.1
1050938 -15 42011 31.2 Locked -3 4988 96 48 25092 618 11 0.7636 4979 42012 31.1
1050939 -14 42011 31.3 Locked 1 4986 96 48 25092 622 11 0.7637 4976 42012 31.1
1050940 -3 42011 31.3 Locked 11 4986 96 48 25092 626 11 0.7638 4972 42011 31.1
1050941 -5 42011 31.3 Locked -2 4985 96 48 25092 625 11 0.7639 5003 42011 31.1
1050942 -6 42011 31.3 Locked -1 4984 96 48 25092 623 11 0.7640 4987 42012 31.1
1050943 -9 42011 31.3 Locked -3 4983 96 48 25092 621 11 0.7641 4989 42012 31.2
1050944 -11 42011 31.3 Locked -2 4981 96 48 25092 623 11 0.7642 4905 42009 31.2
1050945 -12 42011 31.3 Locked -1 4980 96 48 25092 618 10 0.8143 5091 42012 31.2
1050946 -14 42011 31.3 Locked -2 4977 96 48 25092 617 10 0.8144 4967 42010 31.2
1050947 -16 42011 31.3 Locked -2 4975 96 48 25092 615 11 0.8145 5019 42011 31.2
1050948 -4 42011 31.3 Locked 12 4974 96 48 25092 624 11 0.8146 4979 42010 31.2
1050949 -6 42011 31.3 Locked -2 4974 96 48 25092 623 11 0.8147 5065 42019 30.5
1050950 -9 42011 31.3 Locked -3 4973 96 48 25092 621 11 0.8148 4987 42016 30.4
1050951 -12 42010 31.3 Locked -3 4971 96 48 25092 623 12 0.8149 4988 42017 30.4
1050952 -13 42010 31.3 Locked -1 4969 96 48 25092 618 12 0.8150 4995 42017 30.4
1050953 -14 42010 31.3 Locked -1 4967 96 48 25092 616 12 0.8151 4976 42016 30.4
1050954 -14 42010 31.3 Locked 0 4965 96 48 25092 617 12 0.8152 5036 42018 30.4
1050955 -17 42010 31.3 Locked -3 4962 96 48 25092 616 12 0.8153 4964 42016 30.4
1050956 -3 42010 31.3 Locked 14 4963 96 48 25092 624 11 0.8354 5017 42017 30.2
1050957 -5 42010 31.3 Locked -2 4963 96 48 25092 624 11 0.8355 4991 42017 30.2
1050958 -6 42010 31.3 Locked -1 4962 96 48 25092 627 11 0.8356 4995 42018 30.2
1050959 -9 42010 31.3 Locked -3 4962 96 48 25092 620 11 0.8357 5010 42018 30.2
1050960 -11 42010 31.3 Locked -2 4960 96 48 25092 619 11 0.8358 5006 42018 30.2
1050961 -12 42010 31.3 Locked -1 4959 96 48 25092 619 11 1.0759 4984 42018 30.2
1050962 -14 42010 31.3 Locked -2 4957 96 48 25092 617 11 1.0760 5010 42019 30.2
1050963 -15 42010 31.3 Locked -1 4955 96 48 25092 617 12 1.0561 4992 42018 30.2
1050964 -17 42010 31.3 Locked -2 4952 96 48 25092 614 12 1.0562 4949 42017 30.4
1050965 -4 42010 31.3 Locked 13 4953 96 48 25092 625 12 1.0563 5033 42017 30.4
1050966 -7 42010 31.3 Locked -3 4952 96 48 25092 623 12 1.0564 4945 42016 30.4
1050967 -9 42010 31.3 Locked -2 4952 96 48 25092 622 11 1.0765 5001 42017 30.4
1050968 -10 42010 31.2 Locked -1 4951 96 48 25092 620 11 1.0766 4992 42017 30.4
1050969 -12 42010 31.3 Locked -2 4950 96 48 25092 619 10 1.0767 5025 42018 30.2
1050970 -13 42010 31.3 Locked -1 4948 96 48 25092 620 10 0.8368 5010 42018 30.2
1050971 -15 42010 31.3 Locked -2 4946 96 48 25092 616 10 0.8369 4978 42018 30.2
1050972 -17 42010 31.3 Locked -2 4944 96 48 25092 616 11 0.8370 4984 42017 30.2
1050973 -5 42010 31.3 Locked 12 4944 96 48 25092 624 10 0.8371 5034 42018 30.2
1050974 -7 42010 31.3 Locked -2 4944 96 48 25092 623 10 0.8372 4990 42018 30.2
1050975 -9 42010 31.3 Locked -2 4944 96 48 25092 620 10 0.8373 5003 42019 30.2
1050976 -11 42010 31.3 Locked -2 4943 96 48 25092 619 10 0.8374 5012 42019 30.2
1050977 -14 42010 31.3 Locked -3 4942 96 48 25092 623 10 0.8375 4960 42018 30.1
1050978 -2 42010 31.3 Locked 12 4942 96 48 25092 626 10 0.8376 5023 42018 30.1
1050979 -4 42010 31.5 Locked -2 4943 96 48 25092 625 10 0.8377 4993 42019 30.1
1050980 -6 42010 31.3 Locked -2 4943 96 48 25092 623 10 0.8378 4980 42019 30.1
1050981 -8 42010 31.3 Locked -2 4943 96 48 25092 622 10 0.8379 5012 42019 30.2
1050982 -10 42010 31.3 Locked -2 4942 96 48 25092 620 10 0.8380 4975 42018 30.2
1050983 -11 42009 31.3 Locked -1 4941 96 48 25092 620 11 0.8381 4969 42017 30.2
1050984 -12 42009 31.3 Locked -1 4940 96 48 25092 619 10 1.0782 4983 42018 30.2
1050985 -13 42009 31.3 Locked -1 4939 96 48 25092 617 10 1.0783 5034 42018 30.2
1050986 -15 42009 31.3 Locked -2 4937 96 48 25092 616 10 1.0784 4992 42018 30.2
1050987 0 42009 31.3 Locked 15 4938 96 48 25092 628 10 1.0785 5004 42019 30.1
1050988 -3 42009 31.3 Locked -3 4939 96 48 25092 626 10 1.0786 5003 42019 30.1
1050989 -4 42009 31.3 Locked -1 4940 96 48 25092 629 10 1.0787 4971 42018 30.1
1050990 -6 42009 31.3 Locked -2 4940 96 48 25092 622 11 1.0688 5039 42018 30.1
1050991 -7 42009 31.3 Locked -1 4940 96 48 25092 621 10 1.0789 5010 42021 30.1
1050992 -8 42009 31.2 Locked -1 4939 96 48 25092 621 10 1.0790 5002 42019 30.1
1050993 -10 42009 31.3 Locked -2 4939 96 48 25092 621 10 1.0791 4976 42020 30.1
1050994 -12 42009 31.3 Locked -2 4938 96 48 25092 619 10 0.8392 5017 42020 30.1
1050995 -14 42009 31.3 Locked -2 4936 96 48 25092 618 12 1.0593 4981 42020 30.0
1050996 -1 42009 31.3 Locked 13 4937 96 48 25092 631 12 1.0694 5002 42020 30.1
1050997 -3 42009 31.3 Locked -2 4938 96 48 25092 626 12 1.0695 4953 42019 30.1
1050998 -4 42009 31.3 Locked -1 4938 96 48 25092 626 12 1.0696 4975 42018 30.2
1050999 -6 42009 31.3 Locked -2 4938 96 48 25092 622 12 1.0697 4985 42018 30.2
Looking at that log, I also noticed my LM35 temp (last column) spikes when this happens. Which is strange considering the GPSDO is inside of an enclosure and insulated. Wonder if maybe the OXCO temperature regulation circuitry is going out?
-
At T=96 you have not yet eliminated GPS uncertainty. You need a longer time constant for that, especially when you're not using sawtooth correction.
Also, make sure you have calibrated the gain correctly. This is pretty important to obtain good stability of the regulation.
-
At T=96 you have not yet eliminated GPS uncertainty. You need a longer time constant for that, especially when you're not using sawtooth correction.
Also, make sure you have calibrated the gain correctly. This is pretty important to obtain good stability of the regulation.
Yep, I have calibrated my gain and it's 27, which seems high for an OCXO. Unfortunately, I can't go past T=100 with this revision for whatever reason. It just never locks. I'm guessing the tuning resolution probably just isn't fine enough.
I do have a newer revision PCB that I've built and am testing for my friend, and that one is miles better. Gain of 16 and actually has a good MDEV plot. I guess if nothing else I can just build another one of those...
-
Locking is not a question of tuning resolution. If the GPSDO doesn't lock at higher T, the OCXO is drifting too fast for the regulation to keep up. Try setting a smaller "damping" parameter. I think the default is "2", but you can easily set it to 1 without risking instability.
-
Well initially I thought setting damping to 1.0 had fixed things, but this morning the GPSDO is unlocked again. I guess my OXCO must be going out. Not sure what else it could be.
-
Well initially I thought setting damping to 1.0 had fixed things, but this morning the GPSDO is unlocked again. I guess my OXCO must be going out. Not sure what else it could be.
I've had only one OCXO fail, the input impedance of the control pin went from a couple of hundred kΩ to about 5kΩ - no idea why. One thing to look at.
I had trouble figuring your log with no heading, two columns with figures in the 420xx range - which one is the control voltage? One is going down slowly which was the initial symptom of my OCXO, then it just dropped away and failed. I looked at everything except the OCXO as I've used quite a few and none failed before (whereas with experimentation lots of other things went wrong).
-
Well initially I thought setting damping to 1.0 had fixed things, but this morning the GPSDO is unlocked again. I guess my OXCO must be going out. Not sure what else it could be.
I've had only one OCXO fail, the input impedance of the control pin went from a couple of hundred kΩ to about 5kΩ - no idea why. One thing to look at.
I had trouble figuring your log with no heading, two columns with figures in the 420xx range - which one is the control voltage? One is going down slowly which was the initial symptom of my OCXO, then it just dropped away and failed. I looked at everything except the OCXO as I've used quite a few and none failed before (whereas with experimentation lots of other things went wrong).
The first 42xxx column is the one you're looking for. I've added in some extra NMEA columns for # of sats and HDOP, but I'm not sure what the last few columns in my log are.
It does appear to be decreasing, but extremely slowly. A few days and restarts later and it's now around 419xx. I've got my rev E PCB running alongside the rev D model now, we're doing a direct head-to-head run. I'll let these cook for a few days to see just how much better my later revision design is. Appreciate the help everyone.
As a sidenote, I'm using my rev E PCB as the reference for the ARRL Frequency Measurement Test (https://fmt.arrl.org/) this evening. Wish me luck!
-
Hi,
for all of you wanting to find out the actual performance of your GPSDOs: Forum user @erikka has made a pretty ingenious firmware implementation for the nanoVNA-H4. It turns the device into a very precise phase-frequency analyzer that is ideal to measure the stability of the 10MHz output of your GPSDO.
Website here: https://www.tinydevices.org/wiki/pmwiki.php?n=TinyPFA.Homepage (https://www.tinydevices.org/wiki/pmwiki.php?n=TinyPFA.Homepage)
BR,
Matthias
-
I think this box is more convenient. But the solution with the NanoVNA is interesting.
https://www.youtube.com/watch?v=k76_IXb_FRc (https://www.youtube.com/watch?v=k76_IXb_FRc)
-
Curious what you guys think could be the issue here.
I built up another one of my GPSDO boards, and after calibrating the gain and linearizing the TIC it's having all kinds of problems keeping lock. It's running an M8T module surveyed in to around 0.6m STDEV and has a consistent 8-10 satellites and a good skyview.
Here's a plot from my plotting tool showing a couple things. Top graph is the TIC value and diff_ns value. Middle is the DAC output value, and bottom is # of satellites in view. I normally also plot HDOP but since it's a surveyed-in module that always stays at 99.
(https://wiki.w3axl.com/images/4/41/GPSDO_rev_E_loop_issues.png)
OCXO is a Bliley NV47x, which I've had good luck with. Gain is 25 which isn't unreasonable for an oven as far as I can tell. I've been running it at a TC anywhere from 96 to 128 with the same results. Thinking this one might have a drift issue of some kind. Notice as soon as the loop closes and the DAC value is held constant, the OCXO quickly drifts low.
I'm going to scrounge up another OCXO to test with, but I'd love to hear the thoughts of the group.
-
Yes, the OCXO drifts faster than the regulation can cope with once it's switching into "locked" mode. If you're sure about the gain, check the filter coefficient for the TIC input prefilter. It might be too slow. Also, check the "damping" parameter. It might be too high. Try setting it to 1.
All in all one can see that the GPSDO is in principle working because it gets the phase locked, but then the bandwidth is too narrow to follow the OCXO.
-
Curious what you guys think could be the issue here.
Is it possible a bad earth and hum is getting in causing a beat with the mains.
-
Curious what you guys think could be the issue here.
Is it possible a bad earth and hum is getting in causing a beat with the mains.
:-) Look at his graph. It is a cycle with an approx ~10 minute period. That can't be 50 or 60 Hz mains, can it?
(It is possible I missed something)
Cheers,
Neal
-
Well, I swapped with another Bliley OCXO and it seems to be behaving better so far. I made sure to re-run the linearization and gain calibration as well.
I guess you can't expect too much with these secondhand salvaged ovens. They aren't exactly gentle when they remove them from the looks of it. At least they're cheap!
-
Curious what you guys think could be the issue here.
Is it possible a bad earth and hum is getting in causing a beat with the mains.
:-) Look at his graph. It is a cycle with an approx ~10 minute period. That can't be 50 or 60 Hz mains, can it?
(It is possible I missed something)
Cheers,
Neal
The power company try to keep the mains frequency exact at 50 or 60 Hz so that clocks that use the mains as a reference are accurate. However there are deviations due to load changes. If hum gets into the detector, it will bias the result. If the mains were exactly right that bias would be the same point in the cycle when the 1pps arrives, would not affect the timing. But if the phase changes slightly each second you get something like what OP saw. It was a long shot, but the regularity of the error makes me think of external influences rather than internally generated. Probably wrong, but I would check it out to make sure.
-
Things are looking much better now, except there seems to be a very slow downward drift in my DAC values. Wondering if this oven is also having issues, or if it's still not totally stabilized. This is after about 5 hours of runtime.
(https://wiki.w3axl.com/images/e/ec/GPSDO_rev_E_new_OCXO.png)
-
Things are looking much better now, except there seems to be a very slow downward drift in my DAC values. Wondering if this oven is also having issues, or if it's still not totally stabilized. This is after about 5 hours of runtime.
I have powered up quite a few second hand OCXO. Many take a day to settle in, and may show an improvement for a few days after that.
I had a further thought about the previous OCXO - was its thermostat working properly? If it was cycling every 10 minutes that could produce the problem you saw. Could confirm it with an infrared thermometer if you have one.
-
Just graph the DAC curve over a few days. You'll see it flattening out as time goes on. OCXO "retrace" is a thing. When you power up an OCXO that has been off for a longer time period, it goes through a cycle of accelerated aging that can last days or even weeks. At least it behaves much better than the one you've tried before.
-
With aging the required OCXO's control voltage may drift off the limits (thus the control voltage level is a good indicator of the OCXO's state).. For example with 7V ref voltage the voltage for 10MHz with new OCXO could be somewhere around 3.5V, after years of aging it drops to, for example, 1.2V - that could be too low for the internal circuits to regulate properly.
Also some OCXOs need weeks to settle after long power off, afaik.
-
Also some OCXOs need weeks to settle after long power off, afaik.
Seems you were spot on with this point. Here's 6 days of running. It's super satisfying to see a real-world asymptotic curve.
(https://wiki.w3axl.com/images/8/88/RevE_6days.png)
-
Do you have no thermal influences at all? You only need to open the window for a moment, then the curve drifts away. Sure, over a long period of time, almost every series of measurements tends towards zero.
-
I built this project this week, only to discover that I don't have a 4046 with the right phase detector. I ordered some from Mouser, but North Texas is frozen over, so I found some old chips in a drawer, and they work alright in place of the 4046. They even leave a JK flip flop and a couple of gates left over:
-
chatgpt:
A replacement for the 4046 PLL would depend on the specific requirements of the application. Some newer PLL integrated circuits that are compatible with the 4046 PLL and can be used as replacements include:
74HC4046: This is a modern CMOS version of the 4046 PLL that offers improved performance and lower power consumption.
LMX2594: This is a high-performance, wideband PLL with integrated VCO that offers improved phase noise and frequency stability.
ADF4351: This is a wideband PLL and frequency synthesizer that can generate output frequencies from 35 MHz to 4400 MHz.
It's important to note that these are just a few examples and that the best replacement for the 4046 PLL will depend on the specific requirements of the application. It's always a good idea to carefully review the datasheets for the PLLs being considered to ensure that they meet the requirements of the application.
-
The ones I used work well enough, given the "Locked" indication, at least until my Mouser order with the 74HC4046's gets here.
-
Thanks for posting the alternative chips and circuits.
Here is another replacement circuit that I'm going to try myself.
It's using a 74HC74 FF.
https://github.com/erikkaashoek/Arduino_SI5351_GPSDO (https://github.com/erikkaashoek/Arduino_SI5351_GPSDO)
-
I tried the 7474 replacement today, and it works great. I tried all the variations I had in stock, the 7474, the 74F74, the 74LS74, the 74AHC74 and the 74HC74.
-
Here's another variant of the Lars GPSDO. I ported it to PIC (PIC18F27Q84). My approach has one main difference: instead of using external ICs (4046 and HC390) to divide the 10 MHz to 1MHz and measure the phase difference, I implemented those functions using PIC Configurable Logic Cells (CLC). The divide by 10 is made up with 4 CLC flip-flops, and the phase detector using 2 CLC flip flops. This seems to work really well.
https://github.com/n4ogw/n4ogw-gpsdo
BTW thanks for all the information posted in this thread, it helped me a lot!
-
Here's another variant of the Lars GPSDO. I ported it to PIC (PIC18F27Q84). My approach has one main difference: instead of using external ICs (4046 and HC390) to divide the 10 MHz to 1MHz and measure the phase difference, I implemented those functions using PIC Configurable Logic Cells (CLC). The divide by 10 is made up with 4 CLC flip-flops, and the phase detector using 2 CLC flip flops. This seems to work really well.
Nice. Could you add a picture of the KiCad schematic, saves unpacking etc. I did it for my GPSDO (also PIC based) https://github.com/ajcashin/budget-gpsdo (https://github.com/ajcashin/budget-gpsdo)
-
Sure- I put a copy of the schematic in the kicad directory.
-
Unfortunately, I must come back on my earlier report that all versions of the 7474 replacement circuit for the 4046 works well.
The SN74AHC74 doesn't.
While researching other phase detection measurements, I noticed a strange behavior with the 7474. To investigate it further, I breadboarded the 74AHC74 circuit next to a 74HC4046 and fed them both with my GPSDO 10Mhz and 1PPS signals, and observed both outputs on my DSO.
The pictures show the problem. Normally, both circuits are in agreement and follow each other through the NEO sawtooth cycle.
Several times per minute though, the SN74AHC74 circuit produces a glitch. Some times just one, sometimes several in succesion during the sawtooth cycle, and then reverts back to following the 4046.
Also the SN74HC74 has the same problem and also a "normal and old" SN7474NV.
I also tried a much slower 74LS74 or even a 74F74, same problem.
I reported it to the inventor, Erik Kaashoek on his Github, but is there anybody else here that can shed some light on this behavior?
-
If you are feeding 10 MHz directly into the circuit, then the first image might actually be ok. At 10 MHz the maximum phase difference is 100 ns. If the actual phase difference is very close to 100 ns, one circuit might show a pulse of ~100 ns, and the other a very short pulse. The actual phase error between the two would be very small even though they look very different on the scope.
I'm using the same flip-flop circuit in my PIC version, except the flip-flops are implemented in PIC CLC logic. Although I never compared to a 4046, as far as I can tell it works well. I did the test described by Lars of feeding the pps using a picdiv which can phase shift by 400 ns- I get that shift within a few ns.
-
Good hunch.
When I was testing older 7474 technologies (7474, LS and even F), they could not handle the "glitch", it is too low in amplitude.
Not surprizingly, this means that only the fasttest and newer technologies can be used with a 10MHz signal.
In most applications I've seen, including Lars' design of course, the 10Mhz is divided down to get a 1MHz input frequency, so that may not show the problem.
-
Here's another variant of the Lars GPSDO. I ported it to PIC (PIC18F27Q84). My approach has one main difference: instead of using external ICs (4046 and HC390) to divide the 10 MHz to 1MHz and measure the phase difference, I implemented those functions using PIC Configurable Logic Cells (CLC). The divide by 10 is made up with 4 CLC flip-flops, and the phase detector using 2 CLC flip flops. This seems to work really well.
https://github.com/n4ogw/n4ogw-gpsdo
BTW thanks for all the information posted in this thread, it helped me a lot!
Thank you for sharing this design with us!
Would it be possible for you to put a copy of the hex file for the PIC in your Github? I am getting odd results from the circuit that I think may be down to the hex file I am producing from MPLAB.
The first version of the MPLAB project I compiled in February '23 resulted in a load of odd characters on the LCD and serial output that the terminal program could make no sense of. I then compiled the Apr '23 update and that doesn't seem to do anything at all - no activity on the LCD data lines or serial output.
Thanks,
Anthony
-
Hi everyone,
I know it's been a long time since this post was made, but after reading some pages, I still have a question about the timer_us variable calculation on the SW.
There is an explanation about it:
timer_us = timer_us + 50000 -
(((timer1CounterValue - timer1CounterValueOld) * 200 + TIC_Value - TIC_ValueOld) >>> those are in 200ns timer1C_ increments (OCXO/2) and you add TIC_V diff value (TIC is the voltage measured by the ADC from 4046+diode+3.9k+1nF) in nanoseconds to it thus everything is in nanoseconds now
+50000500)/1000; >> you add 50000500 because you do modulo 50000 and you want to round properly (xxx.500) and finally you divide all by thousands to get microseconds
You do modulo 50000 therefore (an example)
timer_us = timer_us + 50000 - (((1)*200 + 530 - 490) + 50000500)/1000 = timer_us + 50000 - ((200+40) + 50000500)/1000 = timer_us + 50000 - (50000740)/1000 = timer_us + 50000 - 50000 = timer_us + 0 >>> no change as the 1PPS came within 1usec.. (or better to say: the OCXO's freq at this moment is such thus it fits into 1PSS +/-0.5us).
But what does "modulo 50000" means? Sorry if it is a stupid question, I'm a HW guy with limited SW knowledge.
Thank you very much in advance!
-
OMG, it is 5 years old explanation, but I'll try - I think iMo wanted to say the values used in that math were always max 50000, even though a value off the timer registers is 16bit or max 65535, therefore the term "modulo 50000".
PS: for example a counter in "modulo 5" means it counts 0,1,2,3,4,0,1,2,3,4,0,1,2.. - the counter wraps around when it reaches the "modulus" 5.
-
But what does "modulo 50000" means? Sorry if it is a stupid question, I'm a HW guy with limited SW knowledge.
Thank you very much in advance!
modulo 50000 means the remainder when the number is divided by 50000.
e.g. 98765 divided by 50000 is 1 remainder 48765. So 98765 modulo 50000 is 48765
modulo is shorthand for 'remainder when divided by'. There's probably some much more esoteric meaning in mathematics, but this explanation works for me.
-
OMG, it is 5 years old explanation, but I'll try - I think iMo wanted to say the values used in that math were always max 50000, even though a value off the timer registers is 16bit or max 65535, therefore the term "modulo 50000".
PS: for example a counter in "modulo 5" means it counts 0,1,2,3,4,0,1,2,3,4,0,1,2.. - the counter wraps around when it reaches the "modulus" 5.
Thank you very Much iMo, and you're right talking to you in third person as a 5-year-old answer is like another person's answer ;D
So, please correct me if I'm wrong, as I'm trying to understand Lars code, and it seems this line is one of the most important:
Timer_us = timer_us + 50000 - (((timer1CounterValue - timer1CounterValueOld) * 200 + TIC_Value - TIC_ValueOld)+50000500)/1000;
- The TIC_Value, if I understand correctly, measures time difference (in nanoseconds) between PPS rising edge and 1MHz rising edge. This is done by knowing the RC ramp behavior, measuring the voltage and hence estimating the time (time_diff_ns = ADC_read * 1ns/bit). So, if the ADC reads 500 and the old read was 450, that means 50ns off time difference
- The timer1CounterValue is what I do not understand. If timer1CounterValue - timer1CounterValueOld = 5, it means that there has been 100 overflows of 10ms and 5 additional counts? (which means the 5MHz signal counted 5million pulses 1us before the PPS).
With that said. Let's put an example:
Timer1CounterValueOld = 5
Timer1CounterValue=49995 (because the 5MHz signal goes slower than PPS). Without going to the formula, this means a difference of 10 pulses (10*200ns = 2us difference).
Supposing that TIC_Value-TIC_ValueOld = 0 (to simplify the example), let's go to the formula:
Timer_us = 50000 - (((49995 - 5) * 200) + 50000500)/1000;
Timer_us = 50000 - ((49990 * 200) + 50000500)/1000;
Timer_us = 50000 - ((49990 * 200) + 50000500)/1000;
Timer_us = 50000 - (9998000 + 50000500)/1000
Timer_us = 50000 - 59998500/1000
Timer_us = 50000 - 59998
Timer_us = -9998
Maybe I have done something wrong on this example, because I do not understand the actual/physical meaning of this timer_us variable.
Thank you again, I know this topic is very old :P
-
As I can remember the key message here is the control loop works such it tries to keep the edges phase difference such it always points to the 500ns at the "RC ramp". The RC ramp starts at 0ns and ends at 1000ns (0V..5V aprox), the mid of the RC slope is at 500ns (or 2.5V aprox).
That is the ADC's input voltage, measured by the 10bit ADC, that is 1024 values from 0-1000ns (from 0 to 5V), that means 1ns TIC resolution aprox.
So when there is stable phase difference (I am not sure whether 0deg or not) between the edges the RC ramp voltage should point at 500ns or "into the middle of the ramp" and the ADC reads 511 (ideally). System loop adjusts the DAC voltage (the tuning voltage of the OCXO) such you are always close to the mid of the RC slope (around those 500ns).
When there are frequency fluctuations the phase shift between the edges jitters and that jitter means the voltage at the RC slope jitters around its middle - around the 500ns or 2.5V.
The result of all that math has to consider that principle - the max deviation from the middle (the middle being at those "500ns" at the RC slope) has to be less than +/-500ns - only then it fits into the regulation loop as the phase diff stays on the RC slope (the slope is from 0-1000ns aprox). When it is larger, it "jumps" into the adjacent usecond.
Mind you are always within the RC slope, even you are XXXusecs off, therefore the timer_us value must be 0 when all works as intended (the OCXO freqs is locked). Simply the total phase diff is "timer_us+/-(0..500ns from ADC)".
Otherwise it perhaps adjusts the DAC tuning slope such you get the phase diff much faster towards the 0 usecs. You have to doublecheck how it is used in the source..
Disclaimer: no warranties of any kind provided :)
-
Old topic indeed, but it shows that we may not yet fully understand what Lars did with the code in his sketch.
BTW, Lars uses the 1.1V reference for the ADC so the mid-point of the ramp at 512 bits is at about 550mV, as the DSO screenshots in one of the above posts shows. (I can't verify that at the moment, but that's what I remember)
I don't mind instrumenting the sketch so we can better track what is going on, but that will have to wait until the second half of the month because I'm currently on vacation.
8)
-
Agree, specially for those who are not very skilled on SW (me), there are a lot of tricky parts on the code.
Thank you for the explanation iMo.
Yes, as Lars documented, he used 1.1V maximum voltage input to obtain a more linear response (the RC circuit values are calculated to charge until that voltage).
Dbldutch that would be an priceless effort if you finally decide do it. Keep us updated :)
I'm also considering an alternative design using a Time-to-Digital Converter (TDC7200) as I have seen many people here that have implemented it successfully.
Thank you both for the answers.
-
TDC7200 is quite viable (I've done it myself), but not sensible if you don't implement "sawtooth correction".
-
Is there anybody willing to share their implementation for 'sawtooth' correction? This has come up several times in this Blog, but never with an example.
-
Regarding a sawtooth example, no volunteers as yet so I started a little research project myself.
Here's an explanation I found while researching this topic. source:https://www.efos3.com/GPSDO/GPSDO.html (https://www.efos3.com/GPSDO/GPSDO.html)
Sawtooth error.
The GPS receiver contains a CPU that is clocked from a crystal somewhere[1]. When time comes to output a pulse, the CPU must chose a clock edge of the incoming clock signal on which to go from low to high on the output pin — theres no [sic] magic gates that can toggle up and down independently of the clock signal, that is just a fact of digital processors.
More often than not, the PPS out will not occur precisely at the time the CPU thinks the second starts, it will start on the closest clock edge, which can be off by up to half the period of the clock frequency of the receiver, ballpark 20-50 nanoseconds. However, the CPU will know "how wrong it is", and many modules will output a message with that information. This is what's known as "sawtooth correction". So if the PPS out from the GPS differs in time from the PPS from the OCXO by 623 picoseconds, and the GPS reports an error of 211 picoseconds, we can correct the reading and use the resulting 412 ps in our disciplining loop. Another option is to simply ignore the error — we want the time constant of the disciplining loop to be as long as possible, and over time the sawtooth error will simply average out. This is a short term error that is relatively easy to deal with.
The correction -might- be "relatively easy", but there are caveats as shown here: http://www.leapsecond.com/pages/m12/sawtooth.htm (http://www.leapsecond.com/pages/m12/sawtooth.htm)
Some more information using a hardware solution is here, read pages 23-28 : https://ivscc.gsfc.nasa.gov/meetings/tow2013/Clark.Sem.pdf (https://ivscc.gsfc.nasa.gov/meetings/tow2013/Clark.Sem.pdf)
Here is a link to an article that shows a solution from a scientific view: https://www.researchgate.net/publication/3262481_An_unbiased_FIR_filter_for_TIE_model_of_a_local_clock_in_applications_to_GPS-based_timekeeping/download (https://www.researchgate.net/publication/3262481_An_unbiased_FIR_filter_for_TIE_model_of_a_local_clock_in_applications_to_GPS-based_timekeeping/download)
The following quote is from Nick Sayer, who implemented a look-alike Lars GPSDO and sells it commercially, at least he did a number of years ago.
My code sets the averaging window for the phase to the PI time constant divided by 4. This averages out the PPS jitter, but some GPS modules have a phenomenon called a "hanging bridge." See http://www.leapsecond.com/pages/m12/sawtooth.htm (http://www.leapsecond.com/pages/m12/sawtooth.htm) for an example. A hanging bridge can cause the averaging to be incorrect. Virtually all modules have PPS jitter because the microcontroller clock doesn't stay in phase with UTC, but it's only when the phase rate-of-change changes sign and the phase angle remains constant second-to-second for some period of time that there's trouble. Some GPS module select fractional controller clock frequencies to make *sure* that the phase rate of change never approaches zero for this reason. They don't have a problem because if you average the phase errors, they'll center around the actual value.
Timing modules will often provide you with a quantization error correction message. You take the observed PPS phase error and adjust it by the value of the quantization error. That gives you the actual phase error to the true UTC second. Hanging bridges and averaging are completely mooted by that.
Italics are mine.
The quantization error solution was already described a few pages up (#43) by UR8US. I'm going to try that myself soon.
It seems that with that qErr inclusion, there is no need for an additional sawtooth correction, or is there?
-
Is there anybody willing to share their implementation for 'sawtooth' correction? This has come up several times in this Blog, but never with an example.
I have an implementation but don't use the Lars system. So just passing it on in case it helps someone.
The 1PPS is timed to the nearest 25ns. The arrival times are attributed an odd number: -75ns to -50ns is -5, -50 to -25ns is -3, -25ns to 0 is -1, 0 to 25ns is +1, 25ns to 50ns is +3 etc.
Arrival times are accumulated over a period of 2n seconds (without altering the control voltage). The best results seem to come from 256 or 512 seconds. Calculations are done after 2 successive periods and a control voltage adjustment is calculated and applied. The aim is to reduce the averages to zero.
The jitter becomes a necessary part of the equation, as it randomises the arrivals so ideally half arrive in the -25ns to 0 period and half arrive in the 0 to 25ns period. The technique wouldn't work if there isn't jitter. And because the control voltage is altered infrequently, it is relatively insensitive to 'suspension bridge' and other shorter term artifacts caused by the jitter.
If the accumulations for successive periods are values A and B, then a frequency error is proportional to A - B, and a phase error at the end of the second period is proportional to A-3B. If the exact pulling Hz per V slope is known (it is determined for the OCXO in a calibration process) then it is simple to compute a change of control voltage that corrects the frequency, and a voltage offset to null out the phase error over a chosen period.
Someone mathematically inclined can work out the statistics. I think most errors created by using this method is 25ns / sqrt(measurement period) so in the region of 1 or 2ns. Which when applied to a oscillator period of 100ns (10MHz) is not much.
-
The "sawtooth" is an aliasing effect. GNSS receivers will inevitably output their timing pulse relative to an edge of their own, fixed, internal clock. This clock will not have any defined relation to the time signal received. Therefore, the time pulse is always slightly "wrong", because it is quantized through the internal clock. This "wrongness" is an error introduced by the quantization of "time" inside the GNSS receiver.
Fortunately, the GNSS receiver knows quite precisely how much error this quantization introduces, and can publish that information before outputting the time pulse, making it possible for e.g. a GNSSDO program to correct for it. It is a simple matter of subtracting (or adding) the published quantization error to the TIC measurement.
-
@thinkfat:
The way I understand it from the ublox documentation, the qErr information is available for the next 1PPS pulse.
This is the little bit of information in this document: u-blox-M8_ReceiverDescrProtSPec_UBX-13003221.pdf
On page 71:
19.1 Introduction
u-blox receivers include a time pulse function providing clock pulses with configurable duration
and frequency. The time pulse function can be configured using the UBX-CFG-TP5 message. The
UBX-TIM-TP message provides time information for the next pulse, time source and the
quantization error of the output pin.
On page 432: Time Pulse time data:
This message contains information on the timing of the next pulse at the
TIMEPULSE0 output.
-
@thinkfat:
The way I understand it from the ublox documentation, the qErr information is available for the next 1PPS pulse.
That's correct.
-
TDC7200 is quite viable (I've done it myself), but not sensible if you don't implement "sawtooth correction".
Hi Thinkfat, I didn't know the phenomena you have described (and I appreciate it so much).
But why the TDC7200 needs the sawtooth correction and not the Lars solution? I mean, the problem you described seems inherent to any GPSDO, doesn't it?
I have a question about the TDC7200 approach: this device only measures time difference between START events and STOP events, right? Let's suppose that the phase difference has been reduced progressively until 1ns, but at certain time, the second signal comes first (for example the STOP triggers 1ns before), how is this managed? because the TDC72000 does not measure negative phase difference, right?
If we are using a 500kHz as the STOP signal, that would mean the time difference would jump to 1.999us aprox. (1ns-2us). How does the algorithm should manage this?
Thank you again for yor help
-
TDC7200 is quite viable (I've done it myself), but not sensible if you don't implement "sawtooth correction".
Hi Thinkfat, I didn't know the phenomena you have described (and I appreciate it so much).
But why the TDC7200 needs the sawtooth correction and not the Lars solution? I mean, the problem you described seems inherent to any GPSDO, doesn't it?
I have a question about the TDC7200 approach: this device only measures time difference between START events and STOP events, right? Let's suppose that the phase difference has been reduced progressively until 1ns, but at certain time, the second signal comes first (for example the STOP triggers 1ns before), how is this managed? because the TDC72000 does not measure negative phase difference, right?
If we are using a 500kHz as the STOP signal, that would mean the time difference would jump to 1.999us aprox. (1ns-2us). How does the algorithm should manage this?
Thank you again for yor help
The TDC7200 can measure down to a 56ps single-shot resolution. But without correcting for quantization error, this makes no sense at all. 56ps will be completely drowning in the quantization noise.
Correcting qErr will make sense with Lars' design, too. The best case resolution of 1ns of Lars TIC can benefit from it. But the original design has no way to connect to a GNSS receiver. Instead, it is all down to the filtering and time constant choices.
For your other questions, I think I'd like point you to my own GPSDO design, which uses the TDC7200. If you read through this thread, I started the project sometime late in 2019, I think.
Direct link to first post:
https://www.eevblog.com/forum/projects/diy-gpsdo-project-w-stm32-tdc7200/ (https://www.eevblog.com/forum/projects/diy-gpsdo-project-w-stm32-tdc7200/)
Best regards
-
Thank you, I will take into account the qErr (I have to check if my receiver gives me that information, which I guess it does).
I have already read all the post (there is a lot of information and I will need days to process everything, as I am new in the timekeeping world :))
I have just two questions about your design:
Did you need to invert the 500kHz signal before inputting it to the TDC STOP pin?
It seems you implemented also a local PPS output. Did you generate it from the OCXO or did you generate it directly from the microcontroller (from a digital pin)? In the second case, did you need to compare the PPS phase difference with another TIC?
In my case I'm planning to use the 10MHz OCXO as the microcontroller main clock, and then generate the local PPS and output it to a digital pin once I know the 10MHz are locked to the GPS PPS.
Regards!
-
Both ;) If you read the end of the thread, I explain how to get a zero-drift GNSS synchronized NTP and PTP time service. Stratum 1.
-
But why the TDC7200 needs the sawtooth correction and not the Lars solution?
I mean, the problem you described seems inherent to any GPSDO, doesn't it?
See also https://www.eevblog.com/forum/projects/gpsdo-question-378182/ (https://www.eevblog.com/forum/projects/gpsdo-question-378182/)
where a 1us Analog TIC is used, without any MCU step at all.
The way I look at it is, if the GPS unit has a 20.833ns granularity, per second, it can resolve/average to 2ns in 10s and 1ns in 20s.
ie a time constant of 20s can make use of a ~1ns TIC.
You rely on the OCXO taking care of stability inside that 20 second average window.
A digital TIC is not mandatory, but if you plan to use a MCU anyway, it does give you extreme number of digits, you can decide how many matter :)
If you want to work in absolute time (not just GPSDO ), a digital TIC and qErr makes more sense.
Meanwhile, I'm pondering small MCUs with faster timer/capture, as a mid-ground.
Generic MCUs with sysclk timers, are a bit coarse, being the same ballpark (or worse) as the GPS.
Full precision TIC of sub 1ns, are easily able to see a single GPS granularity step, but are probably excessive.
MCUs with Config Logic cells can be used to swallow the XOR Time -> Ramp -> ADC, someone posted a PIC design using Config Logic.
Newer MCUs (STC, Megawin etc) have 150~250MHz capture PLLs, which is quite a bit finer than the GPS, and likely now enough to sense every GPS correction if you want to do that.
The parts are relatively new, which is a minus, but they can offer an entirely digital capture side.
-
Before you dive in with the TDC7200, there is an even better alternative, the AS6501.
The reason I bring this up is because I started a project last year to see if I could build a counter that could measure my main GPSDO, that is based on small improvements on the Lars design.
I found a few very promising reciprocal counter designs from a developer (Michael Nowak) that is also published on this Forum, and started to experiment with them. Michael build counters based on the TDC7200, but his latest and currently best performing counter uses the AS6501.
Any (reciprocal) counter needs a very good reference frequency, so I also experimented with variations of the Lars design and also an analog (no cpu) alternative.
Needless to say, my conclusion was (duh) that I needed an external reference clock for the counter that was al least as good as (or ideally 10x better) than the GPSDO it is measuring.
This lead me to further improvements on the Lars design that I'm actually still working on. (BTW, I will add the qErr feature to it)
I choose to continue to use the Lars design for my improvements and not deviate too much from it, just to see how far I could get with that design. That's why I did not yet swap to a completely different GPSDO architecture, but who knows...
Describing my design process is difficult to do on this Forum, so if you're interested, here are links to my Blog where I describe my attempts.
https://www.paulvdiyblogs.net/2023/01/a-high-resolution-reciprocal-counter.html (https://www.paulvdiyblogs.net/2023/01/a-high-resolution-reciprocal-counter.html)
https://www.paulvdiyblogs.net/2023/05/a-new-gpsdo-design-v3.html (https://www.paulvdiyblogs.net/2023/05/a-new-gpsdo-design-v3.html)
https://www.paulvdiyblogs.net/2023/06/gpsdo-version-4.html (https://www.paulvdiyblogs.net/2023/06/gpsdo-version-4.html)
Have fun...
-
Before you dive in with the TDC7200, there is an even better alternative, the AS6501.
Thank you, I will check that component, I have heard that Part Number before at this forum.
Any (reciprocal) counter needs a very good reference frequency, so I also experimented with variations of the Lars design and also an analog (no cpu) alternative.
Did you implement an analog GPSDO? My first approach was to build basically a PLL with 7 decade counters connected in order to compare two 1PPS signals. Th problem of this approach was that the signal error outputed by the 4046 JK comparator had a very small Duty Cycle (compared to the 1s cycle) and its mean value (introduced into the OCXO) is basically 2,5V (the error signal is uncapable to "move" that value when phase difference is small.
See also https://www.eevblog.com/forum/projects/gpsdo-question-378182/ (https://www.eevblog.com/forum/projects/gpsdo-question-378182/)
where a 1us Analog TIC is used, without any MCU step at all.
The way I look at it is, if the GPS unit has a 20.833ns granularity, per second, it can resolve/average to 2ns in 10s and 1ns in 20s.
ie a time constant of 20s can make use of a ~1ns TIC.
You rely on the OCXO taking care of stability inside that 20 second average window.
A digital TIC is not mandatory, but if you plan to use a MCU anyway, it does give you extreme number of digits, you can decide how many matter :)
If you want to work in absolute time (not just GPSDO ), a digital TIC and qErr makes more sense.
Meanwhile, I'm pondering small MCUs with faster timer/capture, as a mid-ground.
Generic MCUs with sysclk timers, are a bit coarse, being the same ballpark (or worse) as the GPS.
Full precision TIC of sub 1ns, are easily able to see a single GPS granularity step, but are probably excessive.
MCUs with Config Logic cells can be used to swallow the XOR Time -> Ramp -> ADC, someone posted a PIC design using Config Logic.
Newer MCUs (STC, Megawin etc) have 150~250MHz capture PLLs, which is quite a bit finer than the GPS, and likely now enough to sense every GPS correction if you want to do that.
The parts are relatively new, which is a minus, but they can offer an entirely digital capture side.
Thank you very much for the ideas :)
I am not especially interested in using a microcontroller, it's just that the solutions I see over here lead me down that road. I'm trying to implement a GPSDO that is capable to output a disciplined PPS signal, and that has a maximum drift of 1ms over a day or less in holdover mode. So I do not really need a phase difference of picoseconds, but to have a controlled and stable phase difference and, in case the GPS switches off or does not has PVT, the GPSDO can give me a reliable PPS signal to bring to the NTP server (making some temperature compensations if needed).
Thank you again for all the information youre bringing, it is really useful for me :)
-
I am not especially interested in using a microcontroller, it's just that the solutions I see over here lead me down that road. I'm trying to implement a GPSDO that is capable to output a disciplined PPS signal, and that has a maximum drift of 1ms over a day or less in holdover mode. So I do not really need a phase difference of picoseconds, but to have a controlled and stable phase difference and, in case the GPS switches off or does not has PVT, the GPSDO can give me a reliable PPS signal to bring to the NTP server (making some temperature compensations if needed).
1ms a day is a little more than 0.1Hz error with a 10MHz signal. That should not be a problem. Most GPSDO will hold the OCXO better than 0.01Hz. It is a matter of choosing a good OCXO and a bit of care with the control voltage, and has very little to do with the quality of the GPS side. My experience is the OCXO is not affected much by temperature, but the control voltage can be (depending on where it comes from). A variation of my design buffers the control voltage in such a way it is derived from a MAX6350 precision 5V source, very little temperature effect.
But why a day of holdover? I have recorded GPSDO output for weeks and not seen any significant outage of the GPS signal. It triggers a reboot if there is a long GPS outage (I think 60 seconds, I'd have to look at the code), and it has never happened. And that is with an antenna in a place with poor reception. The current test has been running 5 days with no signal loss. There are counters in the program to keep stats, up 445492 sec 0 loss.
-
My first approach was to build basically a PLL with 7 decade counters connected in order to compare two 1PPS signals. Th problem of this approach was that the signal error outputed by the 4046 JK comparator had a very small Duty Cycle (compared to the 1s cycle) and its mean value (introduced into the OCXO) is basically 2,5V (the error signal is uncapable to "move" that value when phase difference is small.
The link I gave above uses a sample and hold phase detector, that can work with 1pps update rates, and paulv has an example in those links above of a Micro-GPSDO, that uses analog-loop (no MCU), but does boost the 1pps to 100kHz first.
A 1pps update is slow, and relies on long hold times for short update impulses.
You do need some divider, from 10MHz, in that link the poster has issues with the divider just too small for the wide control range of the OCXO, so more than one edge is in range.
ie your OCXO control range should help decide the 10Mhz divider /10/20/50/100... you do not need 7 decade ctr, that just buys trouble as you have to walk one pps to match the other !
Pick a minimal divider to avoid errant locks, and that means much less phase walk is needed to lock.
I am not especially interested in using a microcontroller, it's just that the solutions I see over here lead me down that road. I'm trying to implement a GPSDO that is capable to output a disciplined PPS signal, and that has a maximum drift of 1ms over a day or less in holdover mode. So I do not really need a phase difference of picoseconds, but to have a controlled and stable phase difference and, in case the GPS switches off or does not has PVT, the GPSDO can give me a reliable PPS signal to bring to the NTP server (making some temperature compensations if needed).
If you add in a requirement for a day hold-over, that's getting beyond a MCU-less solution, as you need to hold the OCXO control voltage at last-voltage for a very long time, when a break is sensed.
A lot of logic is needed there, so simplest to use a MCU to manage the DAC.
-
1ms a day is a little more than 0.1Hz error with a 10MHz signal. That should not be a problem. Most GPSDO will hold the OCXO better than 0.01Hz. It is a matter of choosing a good OCXO and a bit of care with the control voltage, and has very little to do with the quality of the GPS side. My experience is the OCXO is not affected much by temperature, but the control voltage can be (depending on where it comes from). A variation of my design buffers the control voltage in such a way it is derived from a MAX6350 precision 5V source, very little temperature effect.
But why a day of holdover? I have recorded GPSDO output for weeks and not seen any significant outage of the GPS signal. It triggers a reboot if there is a long GPS outage (I think 60 seconds, I'd have to look at the code), and it has never happened. And that is with an antenna in a place with poor reception. The current test has been running 5 days with no signal loss. There are counters in the program to keep stats, up 445492 sec 0 loss.
Very interesting, of course if I can get more than 1 day of holdover I will go for it!! :)
Did you generated the disciplined PPS from dividing down the 10MHz OCXO freq or did you generated it directly from the controller?
Thank you for the info
-
Very interesting, of course if I can get more than 1 day of holdover I will go for it!! :)
Did you generated the disciplined PPS from dividing down the 10MHz OCXO freq or did you generated it directly from the controller?
Thank you for the info
The GPSDO does not generate a 1PPS, output is a disciplined 10MHz. However, the design is minimal (the original aim was lowest cost GPSDO with a guaranteed accuracy of ±0.01Hz). There were not enough pins on the CPU to have another output. I have been thinking of using a more recent CPU (one with more pins), to drive a small OLED screen in addition to what it does now (OLED screen currently in the mail).
It would be simple to add a 1PPS output. The CPU is clocked by the 10MHz OCXO, and the arrival time of 1PPS from the GPS is captured by gating a 16-bit timer clocked at 40MHz. Which is why the design is nothing like Lars, it is a 25ns TIC and uses no extra components. At the moment the actual gated time is not important, as long as it is the same every pulse (within a couple of counts). The counter and gate operation are independent of the CPU, so it would be possible to arrange a pulse be generated at a particular time, and adjust that time by requiring that the 1PPS from the GPS be gated at a particular count thereby aligning the output 1PPS to the average of the input 1PPS (within 25ns). The interrupt from the gate would be delayed by the interrupt to produce the 1PPS, but that wouldn't be an issue because the timer has stopped and can be read any time later.
-
Going back to the qErr topic that UR8US provided.
I managed to make that work in my setup.
Afterall, the hardware changes turned out to be really easy to do.
I did found that I had to fix an error in his provided sketch but that was quite simple as well.
The results are such that in my setup, up to +/-10nS of qErr data is now added/subtracted from the NS result and eliminates that particular source of "error".
More details can be found on my Blog, go towards the end for the description.
https://www.paulvdiyblogs.net/2023/06/gpsdo-version-4.html (https://www.paulvdiyblogs.net/2023/06/gpsdo-version-4.html)
Note that this is not a solution to the "sawtooth" issue. The NS values are now cleaner, because devoid of the NEO internal clock/1PPS timing errors, but that overall challenge remains.
My next step is to figure out a way to eliminate or reduce the remaining sawtooth effect without changing too much to Lars' code.
The trick is where and how to do that in his code so I don't mess with his intended and already provided functionality.
That may be a real challenge for me because his code is not so easy to understand. :-//
Any help to address this is welcome...
-
The "sawtooth" effect typically refers to the quantization error only. Whatever other effect you're seeing, it's not that ;)
However, it's known that the qErr doesn't perfectly compensate the quantization error. I remember reading somewhere, that at least with the LEA/NEO 6/7/8 receivers, the qErr is represented through too few bits to completely compensate the aliasing.
But other measures should be taken first, to improve the performance. For example, if you use a timing-type receiver (like, LEA/NEO M8T), make sure you have done a proper survey-in. This will allow the receiver to operate in "overdetermined clock" mode. It will greatly reduce the uncertainty on the timing signal.
BTW - the better your TIC data, the less sense it makes to go for super-long TC. Increasing the TC mainly does two things: The contribution of each measurement gets smaller, and the correction steps are becoming smaller and less frequent. The downside is that the control loop will be unable to compensate for environmental upsets. If you have a smaller measurement uncertainty, you can go for shorter TC without sacrificing performance.
In my own GPSDO, I typically run with a TC of 500 or so and my frequency offset over 500 seconds is in the tens of nano-Hz territory.
-
The following graph is also on my Blog.
Here is a small sample of the combination or raw_ns, qErr and the resulting (new) ns.
The qErr values are always in the +/- 10ns range, the raw_ns excursions are larger so there is not a complete correction.
I found that the raw_ns excursions are also a factor of the OCXO stability, they are not only GNSS related.
I just switched from a CTI OC5SC25 to an IsoTemp 143-141 OCXO to see what is different.
BTW, I'm also running with a TC of 500 and gain of at least that amount so that I have small PPM/changes per PWM bit.
-
A place to look for sawtooth type behaviour is the DAC. The sensitivity of an OSC5A2B02 is around 0.1V/Hz. A 16 bit 5V DAC delivers around 1300 steps for 0.1V. So the frequency is varied in steps of 0.8mHz. The system will flip between 2 DAC values to keep the average frequency accurate. The problem is less with better OCXO, they have a smaller pulling range.
-
The voltage output range of the DAC can be greatly reduced by using only three resistors.
Two to "clamp" the output to the sweet-spot of the OCXO and a third series resistor to reduce the DAC output voltage effect.
So instead of having a DAC where the output ranges from 0..5V, you can create an output that only moves say +/- 100 mV around the sweet-spot over the full 16-bit range.
Of course that's also how you can get to very high gains.
-
The voltage output range of the DAC can be greatly reduced by using only three resistors.
Two to "clamp" the output to the sweet-spot of the OCXO and a third series resistor to reduce the DAC output voltage effect.
So instead of having a DAC where the output ranges from 0..5V, you can create an output that only moves say +/- 100 mV around the sweet-spot over the full 16-bit range.
Of course that's also how you can get to very high gains.
True. There are a few designs I've seen with a coarse adjustment like that. Just means you have to manually adjust around the sweet spot. I was just offering another place to look for sawtooth behaviour.
I avoided the problem by synthesising the equivalent of a 24-bit DAC.
-
I am about to make a GPSDO based on the design by Lars. I have a query about the 4046 “Tic” circuit.
This version by Murray Greenman differs from the Lars one, plus it has a duplicate pin 10 and just looks wrong with additional grounding (grounding pin 10, an output).
https://www.qsl.net/zl1bpu/PROJ/NGPSDO/TIC.htm (https://www.qsl.net/zl1bpu/PROJ/NGPSDO/TIC.htm)
I guess there is nothing much wrong with the Lars version.
Your thoughts are appreciated.
SJ
-
I am about to make a GPSDO based on the design by Lars. I have a query about the 4046 “Tic” circuit.
This version by Murray Greenman differs from the Lars one, plus it has a duplicate pin 10 and just looks wrong with additional grounding (grounding pin 10, an output).
https://www.qsl.net/zl1bpu/PROJ/NGPSDO/TIC.htm (https://www.qsl.net/zl1bpu/PROJ/NGPSDO/TIC.htm)
I guess there is nothing much wrong with the Lars version.
Your thoughts are appreciated.
SJ
Hi, I can assure you the TIC 4046 circuit as originally designed by Lars works fine, so you can follow Lars´ schematic and you'll have zero problems. Another variant of the TIC circuit that uses a simple 74HC74 flip-flop (which is slightly easier to obtain, compared to the 74HC4046) was designed by Erik Kaashoek, also works fine. And you can also replace the Schottky diode with a 1N4148.
-
Thanks Andrew, there are a few changes to the circuit by Murray and anyone who uses his Arduino code (the display version) may also wonder why there is reference to an Si5351 synth in the code...
Sadly we can't ask Murray, as it appears he has also died, SK is amateur radio speak for "silent key" (Morse key). See:
https://www.nzart.org.nz/news/break-in/break-in-awards (https://www.nzart.org.nz/news/break-in/break-in-awards)
SJ
-
I am about to make a GPSDO based on the design by Lars. I have a query about the 4046 “Tic” circuit.
This version by Murray Greenman differs from the Lars one, plus it has a duplicate pin 10 and just looks wrong with additional grounding (grounding pin 10, an output).
https://www.qsl.net/zl1bpu/PROJ/NGPSDO/TIC.htm (https://www.qsl.net/zl1bpu/PROJ/NGPSDO/TIC.htm)
I guess there is nothing much wrong with the Lars version.
Your thoughts are appreciated.
SJ
Moreover, pin 10 is connected to both +5V and GND, which makes no sense at all. I guess pin 5 was meant to be connected to +5V to turn off the demodulator and vco and pin 10 was meant to be NC. The circuit is then pretty much identical to Lars'. However, pin 9 it not an output and therefore doesn't look right to me either. Obviously, one of the phase comparators was meant to be connected to the sample/hold circuit.
-
There is another issue with the circuit by Murray, the use of parallel connections to the outputs of the hex inverters is plain wrong, as is using a 100 Ohm series resistor on the output of two in parallel. If you take the scenario of a short on the output, the hex inverters will be trying to draw excessive current and may fail. The correct method of using inverters as buffer stages for a 50 Ohm output is to use four inverters with a 200 Ohm series resistor on each, this article shows the method:
http://www.jrmiller.online/projects/ministd/manual.pdf (http://www.jrmiller.online/projects/ministd/manual.pdf)
I will try to model the TIC circuit by Lars, but by all accounts it works fine.
SJ
-
using a 100 Ohm series resistor on the output of two in parallel.
If it was for adapting the impedance to 50ohm i agree.
However i also have seen 100ohm used in output chains, just to dampen ringing.
/Bingo
-
Mind a naked CMOS output has got some output impedance already.
Look at the output's voltage/current characteristic and you'll get it.
Thus adding 200ohm into each of 4 paralleled outputs (or 100ohm with 2) will not create 50ohm, imho..
-
In my design I used 5 parallel outputs with 270 ohm resistor in each. The 270 ohm is enough to limit current with a continuous short. And it provides a very nice square wave into a 50 ohm load.
That said, the unloaded output is near 5V P-P which can overload some devices. If I do a redesign, I was thinking two gates in parallel each with 330 ohm, in series with a 68 ohm across the output. A much smaller P-P unloaded and should suppress most ringing into 50 ohm. Also frees 3 gates for other uses - a generated 1PPS maybe.
All vaporware ATM.
-
There is another issue with the circuit by Murray, the use of parallel connections to the outputs of the hex inverters is plain wrong, as is using a 100 Ohm series resistor on the output of two in parallel. If you take the scenario of a short on the output, the hex inverters will be trying to draw excessive current and may fail. The correct method of using inverters as buffer stages for a 50 Ohm output is to use four inverters with a 200 Ohm series resistor on each, this article shows the method:
http://www.jrmiller.online/projects/ministd/manual.pdf (http://www.jrmiller.online/projects/ministd/manual.pdf)
I will try to model the TIC circuit by Lars, but by all accounts it works fine.
SJ
Hi SJ,
You may want to check a few pages back in this thread, where you'll find some fine DSO captures of the actual workings of Lars' TIC. It's certainly very interesting to model Lars' TIC, but I suggest you possibly may find it quite fun tp assemble Lars' DSO to examine its workings. Also a few pages back you'll find some pictures of Lars' GPSDO which I have assembled on a breadboard, it can in fact be put together in a couple of hours if you already have the parts. :-+
-
Seeing a strange issue with my current GPSDO, looking for some opinions
Last week I replaced the Bliley OCXO in my GPSDO with one of those smaller CTI 10MHz OCXOs since I got a big bunch of them for a good price. I was letting it retrace all week, watching the DAC value slowly go down, until today when I noticed I'd lost lock. Here's a nice plot of several log values over the last week:
[attach=1]
Everything seems like it was okay until about day 5, where the first big DAC spike occurs. The loop slowly brings things back down again, but the latest data shows the loop seems to be failing to keep the oscillator stable.
[attach=2]
The oscillator starts drifting like crazy, the loop brings it back in, and then the oscillator drifts again. It's happening on a period of approximately 12 minutes or so. GPS is fine, this is on a surveyed-in M8T, so the PPS shouldn't be going wacky. I'm guessing the CTI OCXO has just failed in some way?
-
Patrick, my guess is that it’s the oven. My Lars GPSDO has a high grade NEC oven and M8T, with a roof mounted “mushroom” antenna. During the past week it hasn’t missed a beat, although I don’t have it connected to USB, only monitoring via a ZL1BPU LCD display on the Arduino. My timing loop is set for 120 seconds, but that obviously depends on the stability of the oven.
Attached is a plot of my GPSDO with 30, 60 and 120 seconds loop time setting. Damping is 6. The reference is a rubidium and a TinyPFA (phase frequency analyser).
73 SJ
-
Seeing a strange issue with my current GPSDO, looking for some opinions
...
Everything seems like it was okay until about day 5, where the first big DAC spike occurs. The loop slowly brings things back down again, but the latest data shows the loop seems to be failing to keep the oscillator stable.
...
The oscillator starts drifting like crazy, the loop brings it back in, and then the oscillator drifts again. It's happening on a period of approximately 12 minutes or so. GPS is fine, this is on a surveyed-in M8T, so the PPS shouldn't be going wacky. I'm guessing the CTI OCXO has just failed in some way?
I've powered up quite a few of the OSC5A2B02. One was DOA, one went weird, the rest have been OK. The weird one control input resistance dropped and eventually was too low to maintain lock. I guess at the price you get what you pay for. I replaced it with another, was OK. I've had one powered now for months, its control volts was around 1.6V a week after I powered it up and it still is around 1.6V. Might last years.
I would be inclined to replace the OCXO first, start debugging if it doesn't fix the problem. If that's not your style, do you have a meter good enough to see the change of DAC voltage at the OCXO pin? Then you can see if the change is real, or something like a dry joint.
-
Thanks guys. Thankfully I've got 30 of the things so I just did a quick swap and it's running again now. We'll see if it works any better.
-
Welp, sadly the new oscillator has the same issue
[attach=1]
Obviously, that implies a hardware fault somewhere on the mainboard. But since everything else is working fine, it's got to be something directly related to the OCXO itself.
I wonder if maybe it's drawing too much current for the oven from the 5V rail through my ferrite bead - the voltage could be sagging just enough to cause the internal circuitry to freak out periodically like we see in the plot.
[attach=2]
-
Patrick, if you shorten the loop time, does it remain in lock, or is the problem still there?
SJ
-
that definitely seems to be part of the problem. I was originally running with a TC of 128. I halved it to 64 and it seems to be running fairly stable now.
[attach=1]
Are these CTI OCXOs just a little more drifty than, say, the Bliley OCXO I was using previously? I was able to stretch my TC up to 128 and above easily with that one.
-
Are these CTI OCXOs just a little more drifty than, say, the Bliley OCXO I was using previously? I was able to stretch my TC up to 128 and above easily with that one.
First time powered up they are very drifty for at least a day, and get much better over a week. They are fine if (1) you keep it powered (2) don't move it. I suggest just monitor daily, look for tiny improvements.
-
W3AXL,
OCXO's like the OSC5A2B02 you're using have a very flimsy package. They are therefore very sensitive to ambient temperature changes.
Compare that to a Bliley or an Oscilloquartz and the likes, which have a much more thick casing, and most likely, also a better oven regulation.
The other reason that you are seeing these fluctuations can be due to the instability/drift of the voltage at the adjustment pin (CV). I don't mean the DAC changes, but really the stability of the voltage that you can measure when the DAC output is fixed (like with h32767). Variations in micro Volts can already have an effect on the OCXO output frequency and will effect the controlling loop.
When you can keep these two factors under control, a TC of say 500 should pose no problem.
I went through a lot of work to reduce both effects in my GPSDO.
Have a look here for possible inspiration: https://www.paulvdiyblogs.net/2023/06/gpsdo-version-4.html (https://www.paulvdiyblogs.net/2023/06/gpsdo-version-4.html)
A little heads-up is probably in place. It's easy to get sucked in to the deep and dark rabbit hole of time-nutters.
Enjoy!
-
OCXO's like the OSC5A2B02 you're using have a very flimsy package. They are therefore very sensitive to ambient temperature changes.
<SNIP>
When you can keep these two factors under control, a TC of say 500 should pose no problem.
<SNIP>
A little heads-up is probably in place. It's easy to get sucked in to the deep and dark rabbit hole of time-nutters.
It is also easy to become fixated on running long time constants, unless you can reasonably accurately measure the stability I don't think there is any point in increasing the time constant beyond the point where the short term stability improves. With my NEC Toyocom oven, going from a TC of 60 seconds to 120 seconds only improves the short term wandering by 1E-11. From a warm or cold start, 120 seconds is about the longest TC that my unit will lock in a reasonable time, which takes around 20 to 30 minutes after the 7 mins oven warm up delay.
I have some foam insulation over the TIC parts, as suggested by Lars, but I have no temperature measurement, compensation or cabinet heater.
I have no experience with the CTI ovens, as I am fortunate in having a couple of NEC TCO-6703N ones that are probably an order of magnitude better... although the spec is a bit vague: Temperature Stability +/-2.5x10^-9, Ageing: +/-2x10^-10 (per day), +/-3x10^-8 (per year), Frequency trim: +/-0.3ppm (0-5V). They are larger than a CTI oven and draw 1A (cold) and 300mA (warm) from 12 Volts.
I am happy that my home made Lars/Muray Greenman GPSDO has around 10 times better short term stability/jitter than a Leo Bodnar GPSDO and 4 times better than a G3RUH Simple GPSDO, as measured using a TinyPFA (phase frequency analyser) and TimeLab. The limitation I have is that my reference is a rubidium with a spec of 1 second Allan Var 1E-10, 10 second Allan Var 3.16E-11 and 100 sec of 1E-11. I am really only interested in the short term stability for use with test equipment and to keep my ham radio gear on frequency.
SJ
-
OCXO's like the OSC5A2B02 you're using have a very flimsy package. They are therefore very sensitive to ambient temperature changes.
Compare that to a Bliley or an Oscilloquartz and the likes, which have a much more thick casing, and most likely, also a better oven regulation.
The other reason that you are seeing these fluctuations can be due to the instability/drift of the voltage at the adjustment pin (CV). I don't mean the DAC changes, but really the stability of the voltage that you can measure when the DAC output is fixed (like with h32767). Variations in micro Volts can already have an effect on the OCXO output frequency and will effect the controlling loop.
I agree with the second reason. The OSC5A2B02 is more sensitive to changes of control voltage than many other OCXO. Its sensitivity is about 1 part per million/V. i.e. a change of 1V changes the frequency by 10Hz. A Morion MV89 is 0.1 ppm/V - 10 times better. The MV89 also has an internal precision voltage source from which CV can be derived.
The quoted sensitivity to temperature change of the OSC5A2B02 is ±10ppb over its full operating temperature 0-75°C so less than 1ppb/°C. If the OCXO was in the weather this might have some effect, but in an indoor situation the temperature normally changes quite slowly, and most OCXOs would be in some sort of enclosure which gives even more isolation. So I don't think the OCXO is directly affected by temperature as much as indirectly by other components. A typical voltage regulator (7805) changes output measured in parts per million/°C. If the same regulator is supplying an IC that is the output, plugging a lead into the output can also cause a voltage change.
My design is different to Lars, the CV is not adjusted each second, but once every 1024 seconds. The largest adjustment in the last 5 hours (which is how much history is stored in the uP) was 4.2*10-11 Hz. These adjustments are mainly dictated by the crappy GPS signal from a NEO-7, not temperature. The OCXO runs off a different regulator to the rest of the circuit and the CV is derived through a precision regulator and is varied in steps of less than 1µV. A test a while back with an M8T reduced this to around 2*10-11 Hz with a crappy antenna. I have yet to put up a decent antenna, doing some renovations instead.
-
The better the stability of your timing reference signal, the shorter time constants you can afford without impacting the output stability.
However, the longer the time constant, the less the control loop will be able to compensate for other influence than OCXO aging, especially temperature, the more effort you need to spend on compensating or eliminating those external factors.
-
Is there -on GitHub or elsewhere- a complete project available for DIY of this GPSDO project? I've read most of this thread but I got lost in the woods...
-
Not unless somebody else has put it up. Lars sadly died a few years ago.
-
Is there -on GitHub or elsewhere- a complete project available for DIY of this GPSDO project? I've read most of this thread but I got lost in the woods...
@RikV, have you looked at the Budget GPSDO project by @MIS42N. There is a partial kit for the hard-to-get parts available for this project at Silicon Chip (Australia). I built one and it works well.
https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/ (https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/)
-
Is there -on GitHub or elsewhere- a complete project available for DIY of this GPSDO project? I've read most of this thread but I got lost in the woods...
See : https://www.qsl.net/g4aon/gpsdo/ (https://www.qsl.net/g4aon/gpsdo/)
There is a complete circuit diagram and a link to the Murray Greenman LCD display version of the Lars GPSDO. Sadly Murray has also died, but his web page is still available inc the Arduino code
SJ
-
@RikV,
There is a lot of information available for a DIY build on my Blog. Somewhere earlier on this forum there are references to my Blog.
A first version, and later a version 3 and a "final" version 4 is described in a lot of detail. Everything (Schematics, Gerbers, details, script etc.) is available for a DIY build.
Several people have already successfully build these versions.
https://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html (https://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html)
https://www.paulvdiyblogs.net/2023/05/a-new-gpsdo-design-v3.html (https://www.paulvdiyblogs.net/2023/05/a-new-gpsdo-design-v3.html)
https://www.paulvdiyblogs.net/2023/06/gpsdo-version-4.html (https://www.paulvdiyblogs.net/2023/06/gpsdo-version-4.html)
Have fun!
Paul
-
@RikV,
There is a lot of information available for a DIY build on my Blog. Somewhere earlier on this forum there are references to my Blog.
A first version, and later a version 3 and a "final" version 4 is described in a lot of detail. Everything (Schematics, Gerbers, details, script etc.) is available for a DIY build.
Several people have already successfully build these versions.
https://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html (https://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html)
https://www.paulvdiyblogs.net/2023/05/a-new-gpsdo-design-v3.html (https://www.paulvdiyblogs.net/2023/05/a-new-gpsdo-design-v3.html)
https://www.paulvdiyblogs.net/2023/06/gpsdo-version-4.html (https://www.paulvdiyblogs.net/2023/06/gpsdo-version-4.html)
Have fun!
Paul
First off, I have to take my hat off at your tenacity in overcoming the effect of temperature on a micro-controller based gpsdo design. :)
I read through all those blogs, aghast at all the extra complication being introduced to match the stability of a G3RUH design where this issue of temperature effect is effectively subsumed into the PLL feedback correction. By the time I got to looking at the latest blog, I have to admit my eyes were starting to glaze over. ::)
I've been tempted to trial a micro-controller based gpsdo design over the past three years but this issue of temperature stability has been the main reason why I've been sticking with the modern day variation of the James Miller design as offered by Gyro's post which had inspired my very first attempt at lashing together the most basic of gpsdo circuits onto a solderless breadboard.
https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg1493431/#msg1493431 (https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg1493431/#msg1493431)
Rather pragmatically, I'd omitted the cmos rro opamp (I didn't have one to hand at the time) and fed the filtered output from the pll directly to the efc pin on my 13MHz ocxo (divided down to 10MHz with a rather cunning but noisy ttl circuit). It worked surprisingly well and I only recently discovered the reason why I'd been able to get away with is additional 'simplification' being the G ohm input impedance of the ocxo I'd been using. ::)
Like you, I'd been motivated by the 'infamous' FY6600-60M arbitrary wave generator which amongst several other improvements, now sports a 10MHz ocxo which can be frequency injection locked to an external reference I can plug in or out without the need to power cycle it each time as Tony Albus has to do with his FY6600. The ocxo has its own independent 12v 6W smpsu to keep it powered all the time it is plugged into a mains outlet (a 1.3W vampire load) to eliminate the warm up time whenever I wish to use the generator and, more importantly, eliminate the issue of 'retrace'.
The first boxed up gpsdo (the MK I) had been based upon that breadboard lashup (with an RRO opamp included) built onto stripboard (not a quiet combination with all the extra ttl circuitry to generate 10MHz from a 13MHz ocxo - I could barely pick out the 1.2MHz switching frequency of the tiny Mini 360 24v to 5v buck converter from all the ttl noise on the Vcc rail when looking at the noise spectrum. I had to add a 10MHz xtal in series with the LPF output filter to filter out the close in frequency harmonics generated by the ttl circuitry but, apart from that, it was otherwise operating perfectly fine.
The MK II version didn't require the extra xtal since I'd acquired a bunch of 10MHz ocxos by then, allowing me to ditch all that ttl circuitry (reducing the power demand from 1.8W to a mere 1.4W and eliminate all those troublesome current ripple noise components in the Vcc rail with the change from stripboard to a copper clad groundplane construction further reducing this issue of noise on the Vcc rail to a vanishingly small level no doubt helping somewhat.
This MK II gpsdo has been (and still is) my only gpsdo frequency reference over the past three years or so. Initially, I'd used (fake) M8N receiver modules until I chanced upon a seller on Amazon selling genuine M8T modules for a mere 42 quid. Since the description quite clearly described the timing feature, I took a chance and bought one.
This proved to be the genuine article so, when i spotted a few weeks later that the seller had dropped his price to just 24 quid each, I snapped up another two despite a slight misgiving on account of not being able to reprogram the minimum elevation angle without locking the module and having to reset to defaults and do the settings all over again (that turned out to be the effect of a faulty FTDI 232 usb to serial converter so am rather glad I took the chance to purchase the additional 'spares' when I did - he'd raised the price just a week or two later to 61 quid each. :o
At the moment, I'm in the middle of constructing a MK III based on the same design but using a Sparkfun ZED9T gps receiver module to reduce the effect of 'space weather' on the phase stability (slow +/- 5ns movements against my temperature stabilised rubidium reference). I say 'in the middle of constructing' but the reality is that it has been set aside over the past 4 or 5 months whilst I continue to wrestle with refining the baseplate temperature control algorithm of my rubidium reference, a project not unlike yours since I've spent the past three and a half years on this particular project. ::)
The motivation for building a ZED9T based gpsdo being the need to reduce this phase wander to allow me to more accurately syntonise the ruby to a more stable reference and eliminate mood swings which range between elation and that of despair as I seemingly achieve rock solid stability followed by a 'sudden' phase drift of 'failure' due to a combination of just by chance adjusting it just as the gps drift cancels the daily 2 or 3 mico Hertz ageing drift and thus seeing less than 20 ns in 24 hours phase drift, followed by a seemingly rapid increased phase drift rate (the ZED9T should reduce this effect by an order of magnitude).
I really should stop trying to 'tweak' the temperature control algorithms and switch my attention back to completing the MK III project but it's hard to leave it alone. However, since I do need a much more stable gpsdo reference in order to more accurately assess the frequency stability of my rubidium reference, I've very little excuse for putting it off any longer. :palm:
One thing I did finally come up with to extend the lower ambient temperature limit to below the 16 degree point at which the fan had to be brought to a standstill to limit undershoot and the addition of a special 'kickstart' pulse to bring it back up to speed to reduce the ensuing overshoot, was to add a couple of return galleries (40mm plastic waste pipes to return the exhaust air back to the intake plenum) and add a couple of servo controlled flap diverter valves between the angled ends of these tubes and the exhaust ports along with an intake damper flap (all linked to the same servo) controlled by the temperature reported by a BMP280 formerly used to sense the ambient temperature but now relocated by the fan intake inside the plenum chamber to control the fan intake air temperature.
I tried various temperature settings and rates of control, landing up with a plenum midpoint setting of 31.0 deg C with a +/- 0.5 degree control range over which it would gradually transition between full flow exhaust and total internal recirculation. This plenum temperature range corresponds to an ambient temperature ranging from a low of around 19 to a high of 30 degrees. Below 19 degrees, the hatches were battened down and the plenum temperature would continue falling at a tenth of the rate of the drop in ambient temperature.
This measure saved the fan control algorithm from having to get anywhere close to the cut off point, allowing for a more responsive control at very low ambient temperatures even down to a very chilly 4 deg during an overnight test run in my garage/workshop a few weeks back.
You might well find this technique of (effectively) enclosing your gpsdo inside a larger "air conditioned box' an effective way to stabilise the temperature of the whole gpsdo enclosure's contents.
For a bit of added interest, I've attached a 26 hour sequence of screenshots showing the drift between the gpsdo (yellow trace) and the rubidium starting just before 8pm last night (image 17 is where I cleared the infinite persistence), along with a screenshot of the arduino plot of base plate temperature (498 points at an 80Hz control cycle rate plus an adjacent pair of rescale defeating spikes (0 and 120). The vertical scale is milli-Kelvins above the 36.00 degree base line.
-
I have generally avoided saying much about my own project since this thread is about Lars project. However, lately there is a bit of commentary about temperature stability, a problem addressed by my design. So I commend my design to you: https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/ (https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/)
Unfortunately, the link still says 'work in progress' despite changing the title to 'complete'. Although are these projects ever complete?
In the design, control voltage is generated by dithering a 10-bit PWM to synthesize a 24-bit DAC. That output can be used directly as the control voltage, and was in the first PCB design. It was done that way to avoid the complication of using multiple fixed PWM to come up with a pseudo 16-bit DAC, or using a proper DAC. The control voltage is varied in increments less than 1uV, which is as good or better than any other uP based design. But does suffer the problem that the generated voltage is dependent on the supply voltage of the processor.
The second PCB design overcame that by buffering the PWM in the digital domain, using a pair of small signal FETs. Now the control voltage is dependent on the supply to the FETs. And since the current is negligible, this can be from a precision voltage source such as a MAX6350, or in a high end OCXO the regulated voltage supplied by the OCXO. In the simplest implementation where a 5V OCXO is used, the OCXO supply can also be used as supply to the FETs. The supply to the OCXO is separate to the supply to the rest of the circuitry so provides a fairly constant load. Which the uP and 10MHz buffer doesn't.
Maybe the design doesn't get traction because it looks too simple. But I have not had any negative feedback from the few who have built it. Even though @enut11 built a cut down version using a different OCXO than the design, he says "it just works".
So what am I missing? I am not a marketing person, no idea how to promote my design and I don't have any investment in having it used. However, I see people struggle with other designs and think "I addressed that". More documentation? Another new blog with a better title? {end of self promotion}
-
Johnny, I will be interested in hearing how much improvement a Sparkfun ZED9T makes over an M8T. My own Lars build (Murray Greenman, ZL1BPU, display variant), is at the limits of what I can measure in terms of short term stability.
I haven't experimented with increasing the smoothing caps on the oscillator Voltage control line, I note that Murray used 22uF caps against Lars using 4.7uF. I use 10uF. If you refer back to the James Miller "Simple" GPSDO, James uses a 160K resistor and 100uF cap to smooth the control Voltage line and achieves around +/-5 parts in 10^11 over a 10 second period. Maybe a larger capacitor would work just as well as going to a more expensive GPS module?
http://www.jrmiller.online/projects/ministd/manual.pdf (http://www.jrmiller.online/projects/ministd/manual.pdf)
My reference oscillator is a surplus Efratom FRS-C, which has a specification of 3.16 parts in 10^11 over 10 seconds, and 1 part in 10^10 over 1 second, which puts my short term comparisons at the limit of that rubidium. I use a TinyPFA (phase frequency analyser) with TimeLab softwre. Details of the rubidium at:
https://bama.edebris.com/manuals/efratom/rfs (https://bama.edebris.com/manuals/efratom/rfs)
Back to GPS modules, my measurements using a Lars/Murray GPSDO give an reduction in short term jitter by about half, when using a genuine UBlox Neo-M8T compared to a doubtful origin Neo-6M (I have boards with both types and can swap over in a few minutes). The differences are pretty small and may be more related to using a timing vs navigation module, as opposed to genuine vs fake.
My thoughts are that the stability of the OCXO has more effect on the overall short term stability than the GPS module, although using high grade versions of both is the ideal solution... it can come at significant cost.
In addition to a Lars/Murray GPSDO, I also have a James Miller Simple GPSDO, in both these I use NEC ovens and M8T modules. I also have a Leo Bodnar GPSDO that uses a TCXO and (I guess) a navigation grade GPS module. In terms of short term stability, the Lars unit is around 2 to 4 times better than the James Miller and 10 times better than the Leo Bodnar. The latter is realistically good enough for all I need and has the advantage of being ready to use within a minute or two of being switched on, and can output any frequency from 400 Hz to 810 MHz.
SJ
-
Johnny, I will be interested in hearing how much improvement a Sparkfun ZED9T makes over an M8T. My own Lars build (Murray Greenman, ZL1BPU, display variant), is at the limits of what I can measure in terms of short term stability.
If you're interested in short-term stability of oscillators, you can do a lot with the "tinypfa". For cheap.
https://www.tinydevices.org/wiki/pmwiki.php?n=TinyPFA.Homepage (https://www.tinydevices.org/wiki/pmwiki.php?n=TinyPFA.Homepage)
-
@Solder_Junkie
Whilst I'd love to answer your questions in detail and the information is relevant to any design of DIY gpsdo project, I think it would be better to start a separate topic thread rather than completely hijack this one (I can post a link here for anyone interested), However, as a 'teaser', assuming you haven't already seen this YouTube video, have a look here https://www.youtube.com/watch?v=3tQjIHFcJVg (https://www.youtube.com/watch?v=3tQjIHFcJVg)
@thinkfat
Thanks for the links to the TinyPFA. ISTR Solder_Junkie mentioning this gadget a month or two back. I checked it out but being the cheapskate that I am (says he who blew 250 smackers on that Sparkfun module some 14 months ago :o) I was looking for the cheapest option and gave up on making sure of getting the exact right version to convert. However, money isn't everything so, for the sake of my much put upon SDS1202X-E, I'll pick one of those sources in the list whether pre-loaded or not with the SW. I've been hankering after a means to record the data for a while now anyway (you know how it is - not enough round tuits).
-
..
I haven't experimented with increasing the smoothing caps on the oscillator Voltage control line, I note that Murray used 22uF caps against Lars using 4.7uF. I use 10uF. If you refer back to the James Miller "Simple" GPSDO, James uses a 160K resistor and 100uF cap to smooth the control Voltage line and achieves around +/-5 parts in 10^11 over a 10 second period. Maybe a larger capacitor would work just as well as going to a more expensive GPS module?..
The precise finetuning of the filter is not an easy task, imho. I made an excel tool, trying to ease the filter design for Miller's XOR based GPSDO in past, posted here.
https://www.eevblog.com/forum/projects/gpsdo-with-xor-phase-comparator-control-loop-filter-design/msg3458070/#msg3458070 (https://www.eevblog.com/forum/projects/gpsdo-with-xor-phase-comparator-control-loop-filter-design/msg3458070/#msg3458070)
-
Johnny, I will be interested in hearing how much improvement a Sparkfun ZED9T makes over an M8T. My own Lars build (Murray Greenman, ZL1BPU, display variant), is at the limits of what I can measure in terms of short term stability.
If you're interested in short-term stability of oscillators, you can do a lot with the "tinypfa". For cheap.
https://www.tinydevices.org/wiki/pmwiki.php?n=TinyPFA.Homepage (https://www.tinydevices.org/wiki/pmwiki.php?n=TinyPFA.Homepage)
I've just ordered one from Mirfield Electronics in the UK. :)
-
Martin (G3ZXZ) of Mirfield is really good to deal with.