Building one's own GPS-disciplined oscillator to generate 10 MHz cheaply? - Page 1
Forum section: electronics / projects

author: cdev
author_rank: Super Contributor
timestamp: July 13, 2017, 02:31:57 pm
content: I'd really like to have a precise source of 10 MHz precision goodness, but the substantial cost of commercial offerings makes it less attractive than a DIY project.Recently there was a discussion about a PLL cleaning up device for cheap GPSs that output a relatively jitter prone square wave.. This may take a while but my usual way of getting to some capability is to ask a lot of questions and read and build up a picture of what I need to do bit by bit.Recently there was a discussion of cheap GPSs and cleaning up their output to make a lab quality precision 10 MHz frequency standard..I have those references. Basically I just want to ask if there is any standout way to go from a GPS 1PPS with the typical issues to a low jitter 10 MHz signal in people's opinion.The commercial offerings start at around $150.I was thinking that my old Cobalt Qube 2 would make a good platform for a GPSDO because its a very solid mini server, way out of date, but built like a tank, (and also the cosmetic aspect, its pretty) it also (like RPI) has several GPIOs unlike most newer PC hardware. (It also seems that some recent ports to it arent getting the network performance they should, don't know why, it may be fixable)The top is gently rounded, its not perfectly cubical..A ceramic passive GPS antenna fits perfectly under the center of the plastic shell thats on its top - it has a solid metal internal case and a very pretty blue plastic outer shell, so the metal makes a good groundplane for my Taoglas passive GPS antenna and the plastic will prevent the frying of the little GPS's RF input from ESD which is a danger if you use a passive antenna, the antenna input needs to be protected from static.. (according to Skytraq implementation notes)There is more than enough room inside the Cobalt for an oscillator and oven.The GPS that I want to use is a Navspark Mini, which is a unique little GPS (around the size of a nickel or dime) that only costs $7. Its very sensitive and it uses a Leon 3 CPU. It has a bunch of GPIOs plus the standard UART connections plus it may be able to be configured to have an additional Tx data UART. Also the Leon 3 CPU I think has an analog input pin which is unsupported but there.One of the GPIOs is 1PPS by default, but I think it may be possible to configure it to provide other frequencies.All in all the Skytraq Navspark Mini and other Navspark hardware are clearly outliers in the GPS field in that they have a higher level of programmability. What that programmability allows - I am still trying to get a feel for what may be possible. (If its not with this GPS I may switch to another one for this project, important to also state here that I'm not a programmer, but have managed several times to get tasks Ive needed to done, through reading a lot, then if I dont use it I forget it.I think that so far the number of interesting things that people have done with them may not be so large because the field of cool new boards is very large and people only have so much time, but its possible that some neat things could come out of programmable GPS hardware especially if the data could be used to cotrol external factors to improve accuracy, and also to deliver different frequencies so that a frequency standard's cost could be lowered.See:https://www.febo.com/pipermail/time-nuts/2016-August/099953.htmlThis is a thread on the timing on the much much more expensive Venus (not Navspark) timing-module hardware..https://www.febo.com/pipermail/time-nuts/2016-August/099713.htmlThis is interesting.. although sort of off topic its about means of doing division of squarewave signals from GPS hardware with cheap add ons.https://www.febo.com/pipermail/time-nuts/2016-October/101087.htmlThese also look interesting:http://www.gaisler.com/index.php/products/processors/leon3?task=view&id=13http://www.skytraq.com.tw/A001.pdfhttp://t.cn/8FbovJT(GRIP/Leon 3)http://t.cn/8Fboh6t

author: edpalmer42
author_rank: Super Contributor
timestamp: July 13, 2017, 03:03:50 pm
content: if your GPS receiver can output a 10 KHz signal that's locked to GPS, you could use the James Miller circuit.http://www.jrmiller.demon.co.uk/projects/ministd/frqstd0.htmIt's performance is comparable to commercial GPSDOs.http://www.leapsecond.com/pages/gpsdo/Ed

author: NivagSwerdna
author_rank: Super Contributor
timestamp: July 13, 2017, 03:06:04 pm
content: Have you seen...eBay auction: #252610556561?If you want to DIY then go for it... but depending on how you value your time it might be $100 well spent. These GPSDO modules are very discounted due to being surplus now... you get a lot of engineering per $.

author: wkb
author_rank: Super Contributor
timestamp: July 13, 2017, 03:41:29 pm
content: This might be of interest:http://qrp-labs.com/progrock.htmlcheers, Wilko

author: MosherIV
author_rank: Super Contributor
timestamp: July 13, 2017, 04:41:48 pm
content: HiI was thinking of doing something similar. You have not said what you are using for the base oscillator. Most people would use a OCXO off ebay, make sure it has voltage controlled adjustment.The quoted spec for 1pps jitter of the Skytraq Navspark Mini look impressive (10ns) but wait till you try it out.I like the look of the Adafruit GPS (based on Global Top GPS module) or UBlox 6/7/8MThe performance of any of these is governed by the temperature behaviour of the crystal that drives the GPS, I looked at the UBlox devices, the T is the best but expensive and not available cheaply or easily.There are a number of articales around now about doing digital PLL in software, that is basically what you will be tring to do phase lock 10MHz to 1PPS.A simpler way round is to just average over a very lone time, look at this :http://www.instructables.com/id/GPSDO-YT-Disciplined-Oscillator-10Mhz-Reference-Fr/

author: FlyingHacker
author_rank: Frequent Contributor
timestamp: July 13, 2017, 06:06:46 pm
content: Pretty good video here:

author: CJay
author_rank: Super Contributor
timestamp: July 13, 2017, 06:42:04 pm
content: Quote from: FlyingHacker on July 13, 2017, 06:06:46 pmNot really, that GPS ha sa ton of jitter because of the way it generates frequencies.The second user GPSDOQuote from: NivagSwerdna on July 13, 2017, 03:06:04 pmThose ex telecom GPSDO modules are a damn good buy. That type in particular appeared and started out selling at around $38 a few weeks ago.There will be more, different models etc. so it's worth setting up a search that alerts you.What they'll sell for is anyone's guess though.

author: voltsandjolts
author_rank: Unknown
timestamp: July 13, 2017, 06:43:49 pm
content: What do you actually want to do with it?For calibrating a frequency counter, this does the job just fine:https://www.eevblog.com/forum/testgear/economical-option-for-precision-frequency-reference/msg754025/#msg754025https://www.eevblog.com/forum/projects/ebay-u-blox-lea-6t-gps-module-teardown-and-initial-test/

author: metrologist
author_rank: Super Contributor
timestamp: July 13, 2017, 07:07:29 pm
content: Quote from: edpalmer42 on July 13, 2017, 03:03:50 pmThanks for the links. I have one of the Jupiter modules and have been wanting to build this for years.

author: mycroft
author_rank: Regular Contributor
timestamp: July 13, 2017, 08:24:31 pm
content: Take a look atttp://navsparkcommunity.ning.com/blog/more-ns-t-programmable-frequency-testing. It uses a PLL to clean the jitter but in doing so double the frequency, just add a divide by two flip-flop and you have a nice, clean and symmetric 10 MHz square wave.

author: tautech
author_rank: Super Contributor
timestamp: July 13, 2017, 08:40:43 pm
content: Ha, I was looking into exactly this last night.A couple of links found that might be handy for someone:https://hackaday.io/project/11263-gps-locked-10mhz-lab-frequency-referencehttp://www.hanssummers.com/gpsref.htmlI was looking to cannibalize an old car GPS............Following along with interest.

author: FlyingHacker
author_rank: Frequent Contributor
timestamp: July 13, 2017, 09:41:16 pm
content: Quote from: CJay on July 13, 2017, 06:42:04 pmI was under the impression that the modern versions of that unit were fine. Perhaps not the version he is using, though.

author: cdev
author_rank: Super Contributor
timestamp: July 13, 2017, 09:47:43 pm
content: I would like to have a precise 10 MHz source for synchronizing test instruments and also for use as a means of tuning radios precisely. The higher you go in frequency the more off frequency you can potentially get unless you do something like that.Most of my current devices are accurate to 1 ppm but that is not accurate enough, and my radios also drift with temperature and the crystals also age. I don't want to worry about crystals aging just because I'm leaving my receiver on much of the time.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: July 13, 2017, 10:07:27 pm
content: Quote from: CJay on July 13, 2017, 06:42:04 pm$38.... I don't believe it. These NEC ones have always been around $100 for the last year or so. There did seem to be a golden age in early 2015 when these things were super-cheap but they have climbed in price due presumeably to not turning up in mobile scrap anymore.@cdev BTW.... avoid seller flyxy2015...and read some of the other threads if you decide on a Symetricom or Trimble; I really like the look of the NEC... it is most modern GPSDO doing the rounds on ebayFYIhttps://www.eevblog.com/forum/beginners/does-anyone-recognize-this-board-is-it-a-gpsdo/

author: cdev
author_rank: Super Contributor
timestamp: July 13, 2017, 10:12:51 pm
content: That price sounds more like what Ive seen for the OCXO alone, not the GPSDO w/OCXO?

author: CJay
author_rank: Super Contributor
timestamp: July 14, 2017, 06:40:50 am
content: Quote from: NivagSwerdna on July 13, 2017, 10:07:27 pmMea culpa, not that specific one but there was a Furuno based board with OCXO for sale around May this year for $49.99 (not the $38 I remembered so, again, mea culpa)http://www.ebay.com/itm/GPS-Receiver-board-from-TruePosition-GPS-locator-/152340314423?_trksid=p2047675.l2557&ssPageName=STRK%3AMEBIDX%3AIT&nma=true&si=059%252BT0IcF5f8%252BFx%252Fzruz8c%252BWN00%253D&orig_cvip=true&rt=ncThere are a few available from China still:http://www.ebay.com/itm/TruePosition-10mhz-GPS-DISCiPLINED-CLOCK-GPSDO-AS-IS-untested-/302233354233?hash=item465e82fff9:g:0IAAAOSw4CFYrxG7

author: NivagSwerdna
author_rank: Super Contributor
timestamp: July 14, 2017, 09:15:54 am
content: Quote from: CJay on July 14, 2017, 06:40:50 amThat might work but is a bit crusty looking and is sold as not working.The NEC comes with in-built LVDS goodness amongst other things.(I have a Symetricom (which has Furuno GPS) but am still considering buying an NEC before they go un-obtainium).

author: CJay
author_rank: Super Contributor
timestamp: July 14, 2017, 09:52:14 am
content: Yeah, it's not the best example in the picture but for that money it's worth a punt if the Bliley OCXO is in working order.The Furuno GPS has a decent reputation as a timing receiver so even just for parts it's not too bad a price if they can be persuaded to work.I've broken with tradition (of being skint) and spent some money on one so I'm really hoping I'll be lucky and I'll report back when it arrives*edit* Ah, my memory isn't that bad after all, these units were where the modules came from (ISTR they had bare boards too):http://www.ebay.com/itm/TruePosition-LMU300-GPS-Navigation-model-101333-/162267042516?hash=item25c7de92d4:g:wEgAAOSwAvJW~UIiDirt cheap and there's information out there about them on a few websites, including a project to use one with an Arduino as controller:http://www.packratvhf.com/GPS%20Project/A%20Packrat%20GPS%20Receiver%20Project-Web-upload-06-17-1.pdf

author: cdev
author_rank: Super Contributor
timestamp: July 14, 2017, 03:02:03 pm
content: Hmm.. looks like Skytraq makes the s2525 "VCTCXO" - this may be affordable and more modern (better satellite acquisition performance)Had not seen this version of the S2525 before. I wonder how much this particular version costs. This could be a useful project for hobbyists if it could be used to make a stable, low jitter frequency standard in a small package.http://www.skytraq.com.tw/datasheet/S2525DC8_v0.2.pdfThis is a TCXO and GPSDO with the associated jitter reduction circuitry, in module form format and likely also with low cost, not just another GPS.So this might be comparable in cost to old telco equipment but higher quality output, and better satellite aquisition.Thats the area where the skytraq GPSs stand out compared to my other GPSs. (Garmin and SIRFstar). They even work well with a passive antenna, indoors. (No LNA) They will work with a (right handed) coiled piece of wire as the antenna.Still dont own any ublox devices so I have not compared them to ublox.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: July 14, 2017, 03:19:53 pm
content: To throw a spanner in the works....The GPSDOs need to be on continuously to meet their performance specifications, this can be a bit of a pain (especially since the OCXOs run hot and act a room heater!)... if you need a reliable standard but not continously then there are other options... e.g. Rb Standard

author: metrologist
author_rank: Super Contributor
timestamp: July 14, 2017, 03:44:03 pm
content: I bought one of those Rockwell Jupiter modules many years ago with the intent to build a GPSDO lab reference. The OCXO I got was spec'd to < 2E-10/day. I'd have to build the circuit and all, but now I see these completed modules seem so reasonably priced, I feel it would be a waste of time.This module would be so much more versatile than what I had in mind:http://www.sdr-kits.net/Webshop/products.php?106&cPath=5"Short term signal quality is defined by internal TCXO clock source providing high-quality, low phase noise clock signal with sub-picosecond RMS jitter."Maybe I should sell of that Jupiter module and OCXO and put it towards an out of box solution?

author: DaJMasta
author_rank: Super Contributor
timestamp: July 14, 2017, 07:52:55 pm
content: Quote from: NivagSwerdna on July 14, 2017, 03:19:53 pmEh, a decent GPSDO with an OCXO will run maybe 10-15W tops (and less after it's warmed up), while a Rubidium standard doesn't have to be always-on to be super stable, it does if it's going to be GPS disciplined (if absolute frequency is important, rather than just high stability), and it still will take half an hour or more to warm up. Plus, the rubidium will be consuming 10-20W after being warmed up and sometimes 50W+ while heating. Sure, it's still a savings, but it's not going to be an instant-on reference, and you can get to a pretty stable point with a GPSDO in just a couple hours, even if it's highest performance is usually after a week or so.I agree that the DIY route, while interesting, is not all that cheap compared to what's available. It's also really nice to have stats specified when you're using it as a reference for your equipment. While the basic PLL isn't so complicated, there's a huge variation in the performance of the loop given component choice and additional smoothing algorithms. GPS receivers can vary greatly in their ability to generate a clean, stable reference frequency, and if you're not using a slow-reacting highly averaged smoothing algorithm for your PLL, those small changes in its stability will throw off the stability of your OCXO. To get a really stable, disciplined output, you need to be averaging that output pulse for a long time to get rid of the jitter from the GPS frequency. Even the very best GPS timing units will have 15ns RMS or so in their PPS output timing when fully locked and stabilized, so if you only use the output of the module to discipline your loop without any additional smoothing, the variance will likely be visible using a good OCXO.My advice would be either get a surplus GPSDO module from a telecom or similar application or just pick up a GPS receiver that can make a 10MHz reference. A lot of them with the higher frequency output options actually have a TCXO that's being disciplined by the GPS PPS signal, so while it's not quite as stable as a really nice OCXO, it's a good source in its own right in a very small and power efficient package.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: July 15, 2017, 12:03:01 am
content: Quote from: DaJMasta on July 14, 2017, 07:52:55 pmYou are, of course, correct. It really depends on what you are trying to achieve. For my purposes as a hobby electronics person I don't tend to run a frequency standard on a regular basis, it is more a couple of times a year calibration exercise (or just a timenut indulgence). The advantage of something that converges to a properly defined standard (e.g. the atomic clocks in the GPS constellation) is hard to argue against if you have the time and the electricity bill.

author: David Hess
author_rank: Super Contributor
timestamp: July 16, 2017, 03:07:57 pm
content: More complex designs rely on jitter correction from the GPS so if we ignore those, then we have typically 10s of nanoseconds of jitter in the pulse from the GPS because the clock generating the output pulse is asynchronous to GPS time in addition to the timing error from the GPS solution. That leads to the simplest GPSDO solution being to divide down the output from the disciplined oscillator so that the maximum jitter from the GPS pulse does not allow cycle slipping when a phase locked loop is used to compare them. At that point, performance depends on the time constant of the phase locked loop filter and even an analog filter can achieve 10s to 100s of seconds.The Jupiter-T solution relies on a 1kHz reference and the James Miller circuit relies on a 10kHz reference from the GPS but there is no reason this cannot be done with the more common 1PPS reference. Note that many or even most GPSes which provide a high frequency output are just phase locking it to the 1PPS solution so the higher reference frequency provides no advantage.

author: tggzzz
author_rank: Super Contributor
timestamp: July 16, 2017, 04:00:50 pm
content: Quote from: cdev on July 14, 2017, 03:02:03 pmEven the cheap (£10) ublox neo6m modules can have their "1pps" output changed to a maximum of 500kHz. You do need a reasonable view of the sky with the supplied 4cm*4cm active antennas.They have a 48MHz clock, so a 10MHz output would fall across clock boundaries (would need a neo6t).A ublox app note implies 8kHz is a good frequency because it is an integer fraction of 48MHz, but doesn't say why 10kHz isn't just as good.

author: Gyro
author_rank: Super Contributor
timestamp: July 16, 2017, 04:47:37 pm
content: Damn, you've reminded me of yet another project that I still need to progress - I't ground to a halt once it had become accurate enough to verify my frequency counter.It's about time I checked it again.https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/

author: edpalmer42
author_rank: Super Contributor
timestamp: July 16, 2017, 05:26:11 pm
content: Quote from: David Hess on July 16, 2017, 03:07:57 pmJames Miller's circuit uses the 10 KHz output of the Jupiter board because at that frequency it's easy to use hardware PLL circuits. In general, to phase lock to a 1 PPS signal, you have to use a software PLL. It might be technically possible to use a hardware circuit, analog and/or digital, but it's really difficult.FYI, here are measurements that I've made of the period of the 1 PPS output of some GPS receivers and GPSDOs.Code:GPS Devices -- Measure & analyze the period of the 1 PPS OutputDevice ............... Std Dev (ns).... Range (max-min)(ns) ... Device ...... NotesNavsync CW12 ......... 4 - 5 .......... 20 - 25 ............... GPS Rcvr .... 1,7Motorola UT+ ......... 40 - 55 ........ 95 - 110 .............. GPS Rcvr .... 2,7Rockwell Jupiter ..... 10 ............ 50 ................... GPS Rcvr .... 3,7Motorola M12M ........ 10 - 15 ........ 40 - 60 ............... GPS Rcvr .... 7Trimble Thunderbolt .. 0.4 - 0.5 ...... 2 - 4 ................. GPSDO ....... 6,8HP Z3801A ............ 0.1 - 0.2 ...... < 1 ................... GPSDO ....... 6HP Z3817A / CW12 ..... < 0.1 .......... < 1 ................... GPSDO ....... 4,6Jackson Labs GPSTCXO . 0.3 - 0.4 ...... 2 - 3 ................. GPSDO ....... 6NEC NWM-034241-201 ... 0.1 - 0.2 ...... < 2 ................... GPSDO ....... 5Trimble UCCM ......... 0.09 - 0.11 .... < 1 ................... GPSDO ....... 5Results are based on multiple runs of ~ 1000 measurements each.Sawtooth correction has not been used for any of the GPS receivers. Where supported, it would reduce the numbers substantially.All units were connected to the same antenna system.Notes1. Sawtooth correction not supported.2. Most 'range' results were in this group, but there were a few at 20 - 30.3. Only one test.4. Requires external 1 PPS input. Equipped with E1938 oscillator.5. Measurement made with Fluke PM6681.6. Measurement made with HP 5370B.7. Measurement made with HP 5372A.8. Standard parameters.9. Optimized parameters. (Not yet used in any tests)Ed

author: David Hess
author_rank: Super Contributor
timestamp: July 16, 2017, 07:52:55 pm
content: Quote from: edpalmer42 on July 16, 2017, 05:26:11 pmThe problem as I see it is that the GPS timing error over short timescales is much greater than the disciplined oscillator error and a PLL with a long time constant to overcome this does not need the higher frequency reference and ignores the jitter in the 1 Hz output anyway. 1000 or 10,000 pulses showing the same phase error between the GPS solution and the oscillator is not any better than 1 pulse. So the high frequency output makes the PLL easier because a faster time constant can be used but the faster time constant defeats the purpose of making a GPSDO; instead you could manually adjust your frequency counter based on the GPS pulse output and get better results using the frequency counter's reference output.I agree the analog implementation is a technical challenge; common phase detectors are not designed with the low output leakage needed to support such long time constants. That means using a discrete implementation with low leakage analog switches or maybe low leakage diodes. I was working on a design when squirrels chewed through the cable on my GPS18x and ran off with it; after that I lost interest. I was more worried about adding lock detection and fast settling from startup than achieving a long time constant.QuoteThose are consistent with my own measurements of a Garmin GPS18x which can operate at 5PPS. It was easy enough to see that the output pulse was aligned with the roughly 32 MHz clock inside the receiver so under ideal conditions, the pulse was jumping around by 33 nanoseconds. The GPS mounted outside made a pretty good outdoor temperature sensor by monitoring the difference between the GPS receiver clock and GPS pulse.

author: edpalmer42
author_rank: Super Contributor
timestamp: July 16, 2017, 08:38:06 pm
content: Quote from: David Hess on July 16, 2017, 07:52:55 pmI think that the higher frequency just makes it technically easier to use hardware PLL circuits. After that, it's up to the designer to make sure that the oscillator's performance isn't degraded by the short-term GPS noise. If you look at this page:http://www.leapsecond.com/pages/gpsdo/, you'll see James Miller's hardware PLL compared to three commercial, presumably software, circuits. Note that at low values of Tau, the free and locked performance is the same for all units. That means that those designers did their job properly, regardless of whether they were working in the hardware or software realms.Notice also that Miller's circuit was able to realize similar results to the other units at higher values of Tau. That's not to say that hardware is superior to software. Software can do tricks that hardware can only dream of. eg. Dual time constants for acquiring vs. tracking or aging compensation during holdover.Ed

author: metrologist
author_rank: Super Contributor
timestamp: July 16, 2017, 09:08:08 pm
content: Wow, you guys are way over my head in this. I was looking at my Jupiter module and tried to trigger that against my OCXO. Not sure what this is telling me...top is 10kHz and I tuned my ocxo to sync with it.

author: Gyro
author_rank: Super Contributor
timestamp: July 16, 2017, 09:14:48 pm
content: It's telling you that there's jitter on the 10kHz output of the Jupiter (as you would expect from the raw output of a GPS).Edit: The equivalent display with the LEA-6T against OCXO, both signals at 1MHz, showing the same thing...

author: cdev
author_rank: Super Contributor
timestamp: July 16, 2017, 09:22:17 pm
content: I don't have any fancy equipment but I do now have a bunch of identical tiny GPSs so to see if their timing pulses align perfectly I connected two (I currently only have two antenna adapters that fit the ultra-tiny UFL socket on the GPSs)There are visible differences in the PPS pulse's leading edge's timing between two units, even when they are receiving the same signal (split using a signal splitter)Like Ublox, Skytraq makes a slightly more expensive timing-specific GPS that also embeds a changeable frequency source. But they state that its got significant amounts of jitter, as all such devices do. However its good enough for some uses as it is.I'm still working on my NTP setup. It would be interesting to sample the signals emanating from consumer GPS equipment with an eye to seeing if any of the available signals could be leveraged to make a stable frequency source very cheaply, with components that were not one of a kind finds.(Taking the approach that was done here, perhaps..https://www.eevblog.com/forum/projects/3-dollar-precision-frequency-standard/)The Skytraq "Navspark" maker-friendly GPSs actually run on a CPU, a Leon 3 processor, which also offers a substantial amount of processing power compared to an Arduino - but the Arduino code should work unmodified on it, with a simple recompile..So, it might even be possible to build the associated processing capability needed to turn the available signals into a 10 MHz (or other frequency) standard by using self-written software running on the Leon 3. It also has an ADC which might be useful also (although on the Mini it may not be brought out to a pin because its on the bottom of the chip)I am just ruminating here, I have nowhere near the skill I would need to do this. I'm just speculating.Cheap science is important to me because I see the doors to taught science closing for a good percentage of the planet.Quote from: David Hess on July 16, 2017, 07:52:55 pmSquirrels.. now it all starts falling into place... *wink*

author: edpalmer42
author_rank: Super Contributor
timestamp: July 16, 2017, 09:35:08 pm
content: Quote from: metrologist on July 16, 2017, 09:08:08 pmYou're seeing a combination of jitter and drift. You can't tell what's coming from the Jupiter, the OCXO, or both. Over time, the OCXO trace will just continue to wander across the screen. If your scope has infinite persistance, you'll just see a continuous smear instead of a trace.I've never found it very useful to look at these signals with a scope. Once I've confirmed that the waveform is more or less as expected, I switch to a time interval counter so I can measure speed, drift, jitter, etc. Basically, measure from the rising edge of the 1 PPS to the next rising edge of the OCXO. This gives a much more precise view than the scope or even a frequency counter.By the way, which OCXO are you using?Ed

author: David Hess
author_rank: Super Contributor
timestamp: July 16, 2017, 09:38:38 pm
content: Quote from: edpalmer42 on July 16, 2017, 08:38:06 pmDual time constants are common in long time constant analog designs to improve lock time. In PLL designs where the reference is variable frequency, there are some clever analog tricks which can be used to vary the loop gain with frequency (1) so the time constant (and settling time) follows the reference frequency. I was considering something similar where the correction was the square or non-linear function of the error and this would also have allowed analog lock detection. Of course this makes the analog design more complex and a partial or all digital design relatively less costly.Here is a summary of my "simple" idea. On the leading edge of the reference pulse, use the phase detector to produce a voltage proportional to the phase error. A window comparator can use this to provide a lock signal. Then use a timed second stage to transfer charge proportional to that voltage to the integrator which is driving the voltage controlled oscillator. Since the integrator is not connected to anything except when charge is transferred, offset, drift, and noise are more easily controlled. Breaking the phase detection and integrator stages up allows lots of possibilities for non-linear control. I know from experience that integrators in circuits like this can achieve better than 1uV/second drift.(1) This is surprisingly easy to do. National Semiconductor included it in one of their PLL application notes although I have never seen it used in real life.

author: metrologist
author_rank: Super Contributor
timestamp: July 16, 2017, 09:57:51 pm
content: Quote from: edpalmer42 on July 16, 2017, 09:35:08 pmMTI 220 series, are these of any value anymore?http://www.mti-milliren.com/hirel_220.htmlIt took some time to get these signals synchronized. My counter can only measure 0.1Hz resolution at 10 MHz with a buffer.I am tending more to scrapping this and buying an off the shelf solution, but something without questions.

author: edpalmer42
author_rank: Super Contributor
timestamp: July 16, 2017, 10:19:53 pm
content: Quote from: metrologist on July 16, 2017, 09:57:51 pmThat looks like a nice OCXO. 1 PPB per day and 5e-12@ 1 sec. Aging isn't really relevant when it's locked, but that short-term stability would give good performance in a GPSDO.You're seeing the classic problem of trying to measure and compare frequencies of these signals. To get better resolution, you have to use long gate times, but that blinds you to things going on at intervals shorter than your gate time. The solution is simple - buy better test equipment!Ed

author: DaJMasta
author_rank: Super Contributor
timestamp: July 16, 2017, 10:54:41 pm
content: If you want a simple digital way to do your disciplining to a PPS signal, it doesn't take much to make a counter that will operate at 10MHz, and then you just read out the value every PPS signal and use that as the basis for your phase adjustment. It's once again going to be prone to jitter and such from the disciplining system, but you can build into your system the slow reaction time to GPS adjustments to decrease the impact of the jitter. The difficulty here is that things need to be synchronous and you need a high resolution DAC to drive the VCO. You could do a decent job with TTL to divide down the oscillator and a regular micro, or a fast enough micro (you MUST be able to detect every pulse, so several times the nyquist of the oscillator clock is needed, at minimum), but you'll run into problems from interrupts and such - you really want the counting and comparison to the PPS to be totally synchronous, and it seems like the common tactic is to use CPLD where you can divide the clock domains.The higher frequency clocks are more useful for traditional PLL designs, but you've basically got the same thing described above happening in the GPS module generating that clock. The received GPS signal gives you seconds, though they are accurate to many zeroes, so PPS is the simplest output for the GPS module, even if they can be tough to deal with in some designs.

author: MosherIV
author_rank: Super Contributor
timestamp: July 16, 2017, 11:09:21 pm
content: So I was thinking of using something like STM32F4 micro to do the freq count using the PPS as the gate source. The clever part is that I was planning on clocking the STM32F4 directly from the 10MHz oscillator. I think this means that the STM32F4 counter will always be in synch with the oscillator (am I wrong??)As I said before, I found there are some articales on the WEB on doing digital PLL in software, to adjust the oscillator freq.Not sure about locking the 10MHz to the PPS if there is jitter on the PPS. Surely you are better off with the short term stability of the OCXO and using PPS long term to check and correct for freq drift of xtal

author: DaJMasta
author_rank: Super Contributor
timestamp: July 17, 2017, 12:16:08 am
content: Clocking it from the reference will probably do the trick, I think an F4 series is probably way overkill for it, though - unless you're actually trying to timestamp the changes.After posting that I realized there was an easy way to get the jitter-resistance built into just a ttl circuit - just make the counter count over several PPS before evaluating the difference from the target.You could also read the counter output directly into a micro, do all your software averaging algorithms, and then drive a DAC with I2C or something, which if you're going to be waiting for a full second worth of counting, makes the speed and stability requirements of the micro near nothing.So something like:10MHz VCO into two daisy chained 12 bit counters. Outputs of the counters into 3 8 bit storage latches. PPS input triggers the latches to store their input, next 10MHz cycle stops the reading, next 10MHz cycle resets the counters.Micro reads the latched outputs, adds 2 to the cycle count, does whatever averaging you want to reduce the impact of jitter, then I2C or I2S to the DAC (I2S is probably simplest because audio DACs are cheap and high resolution). Then that feeds into a buffer amp which feeds back into the VCO.Maybe $10-15 in ttl, a cheap micro, a cheap dac, an opamp, your VCOCXO of choice, a PPS signal from a GPS, and a bit of programming. Could be a pretty capable little device and is probably less fiddly than trying to breadboard up a good quality analog PLL (especially when you can do so much for adjustments in the micro).

author: David Hess
author_rank: Super Contributor
timestamp: July 17, 2017, 12:34:03 am
content: Quote from: DaJMasta on July 16, 2017, 10:54:41 pmThe high precision DAC in a digital design is what prompted me to look for alternatives leading to a charged pumped analog design which originally was a digital design with the charge pump replacing the precision DAC.

author: cdev
author_rank: Super Contributor
timestamp: July 19, 2017, 11:42:35 pm
content: These could be used with an additional microprocessor to control it.http://www.analog.com/en/products/rf-microwave/pll-synth.html

author: SKHILLBILLYSlures
author_rank: Regular Contributor
timestamp: July 20, 2017, 01:17:37 am
content: I was probing the depths of the internet and whilst search for a viable wifi jammer circuit strictly for home use. I found the wonders of the Motorola mc145151 in the schematic I veiwed it was being used as a GPS signal jammer. The ic however appears to perfectly capable of being configured to operate a smooth 10MHz and the ic structure also utulized a VCO

author: mark03
author_rank: Frequent Contributor
timestamp: July 26, 2017, 04:43:10 pm
content: This discussion brings up a question that's been nagging me for a while. Keep in mind I am not a time nut nor a GPS expert.As I understand it, the typical homemade GPSDO design uses an OCXO and a GPS module with the 1 PPS output averaged over very long intervals. The long time constant is necessary to average out the jitter in the PPS signal, which is due to the PPS pulses happening only at transitions of the GPS module's free-running internal clock. Hence "hanging bridges" and "sawtooth correction" etc. You also have to pay extra $$ (usually a factor of two or more) for a GPS module with the correct firmware features for timing applications.So a fair bit of effort is being expended to reduce jitter which  should never have been introduced in the first place. I.e., if the GPS module itself were built around a stable oscillator, and that oscillator were disciplined in the course of its normal operation, presto, you'd have your GPSDO already. Reading through hamster_nz 's thread on building a GPS receiver around a Skyworks front-end chip, I was wondering what the minimal system implementation would look like, if all you want is a stable frequency reference, not position nor time? Are the GPS carrier frequencies locked to their atomic clocks, such that if you decode the PN sequence from one satellite, you could just do carrier tracking and have your accurate frequency reference right there? Or is there some reason a multi-satellite solution is required for accurate *frequency* that I don't understand?

author: MosherIV
author_rank: Super Contributor
timestamp: July 26, 2017, 05:02:04 pm
content: QuoteHi, I am not time nut either and my understanding is not perfect either but here is my answer to you:Only the simpler/cheaper gpsdo implementatiins user the 1pps, the better more advanced and stable ones use a better gps module the are able to derive a 10KHz clock from the agregation of the locked gps signals, not sure what they are agreagating, you might be right that they are based on the carrier waves byt I do not know.The hanging bridge or saw tooth effect on the 10MHz clock is due to poor implementation in adjusting the OCXO. The adjustment should be filtered, ir to put it in simplist terms the adjustment is done over a period of time so that it is 'blended in'. Instantly applying the correction will result in something looking like hanging bridge or saw tooth.The more advanced gosdo work by phase locking the 10MHz to the 10KHz, this allows for jitter free counting the error. Without PLL the 10MHz to the gps reference will result in a jitter in the error count BUT if you PLL to a jittery 1pps you will introduce the same jitter in the 10MHz, so in my oppinion it is better to live with the 1 count jitter when using 1pps.I do not know how the better gps modules lock the 10KHz signal to what from the gos satellite, you might be right it might be the carrier signal.

author: David Hess
author_rank: Super Contributor
timestamp: July 26, 2017, 05:25:40 pm
content: Quote from: mark03 on July 26, 2017, 04:43:10 pmThe jitter in the PPS signal is not the only error source. The GPS timing solution itself has considerable uncertainty and once the timing error from a good local oscillator overlaps with the error from the GPS, the jitter in the uncorrected PPS signal becomes less important.QuoteCorrecting for propagation errors and relativistic Doppler shift requires knowing the receiver's location with respect to the satellites. You could track the carrier and timing from one satellite but it would be much like monitoring the various NIST broadcast frequencies which also suffer from propagation errors and Doppler shift limiting their accuracy.

author: mark03
author_rank: Frequent Contributor
timestamp: July 26, 2017, 07:54:30 pm
content: Quote from: David Hess on July 26, 2017, 05:25:40 pmYeah, that makes sense. I suppose if you knew both your own location (based on an earlier survey) and the satellite positions (based on a reasonable ephemeris), you could correct the Doppler. But there would still be more residual error than if one performed the full solution using many satellites?It still seems like one could build a GPS receiver which disciplines its own LO (perhaps an OCXO), rather than the indirect approach of using 1PPS.

author: jpb
author_rank: Super Contributor
timestamp: July 26, 2017, 08:36:29 pm
content: Quote from: mark03 on July 26, 2017, 07:54:30 pmThe Ublox LEA-M8F does this (it is not an OCXO but it is an oscillator disciplined to GPS) but I think it would still be best to combine it with an external OCXO and pll anyway.https://www.u-blox.com/en/product/lea-m8f-moduleUblox's timing white paper is quite interesting as well:https://www.u-blox.com/sites/default/files/products/documents/Timing_AppNote_%28GPS.G6-X-11007%29.pdf

author: DaJMasta
author_rank: Super Contributor
timestamp: July 26, 2017, 09:04:40 pm
content: Quote from: mark03 on July 26, 2017, 07:54:30 pmThey make these, most GPS receivers designed for timing or with any sort of high frequency output will have a TCXO or better disciplined to the GPS source. I think PPS takes less hardware, since you can basically just interpolate in a micro when the second would tick over (GPS timestamps give you down to microseconds), so you're basically just using that stability of your micro's clock and software as the control loop. There are a number of modules that advertise that they include one sort of high stability oscillator or another, and you need at least a decent baseline just to get a good PPS signal, so it is very common for them to be integrated, even if it's less common for their output to be directly available.

author: Vgkid
author_rank: Super Contributor
timestamp: July 27, 2017, 01:11:42 am
content: I was thinking about this when at the gym. What if you do it this way. Power on?wait for gps lock? wait for ocxo heater to reach operating temp? use adc to fll ocxo efc pin to 1pps of gps unit ( slowly, just needs to be close. Might not take to ) after it locks ? switch system to pll(it can go a lot slower, I was thinking about a analog loop...). Just my thoughts.

author: 0xPIT
author_rank: Regular Contributor
timestamp: July 31, 2017, 06:55:12 pm
content: Hi,I'm not sure if I'm on topic: I also intend to build a cheap & low parts count GPSDO.Hardware I have at hand are a 10MHz OCXO and a NEO 7M, plus several micros. I really want to opt to use a ESP32 module, so it would be powerful (LCD, etc.) and cheap and I want to gain some experience with an actual project that can be released freely later.I was thinking to implement a DPLL, but I've read several times (can't remember where) that it's "problematic". I fail to see the problems, though – can anyone enlighten me?The ESP32 has hardware timers and even hardware pulse counters, I guess it should be possible to compensate jitter caused by code execution, as this is deterministic. It seems to be straight forward to feed a NEO Module's 48/n MHz, as well as the 10MHz of the OCXO to external counter inputs and measure lead/lag timing, and after some IIR low pass filter drive the VCO input of the OCXO – what do you think?So, what are arguments against a Software DPLL? Does anyone have a pointer to read?Cheers- pitPS: The ESP32's firmware only support 40 MHz crystal oscillator for now if you want to use Wifi and Bluetooth, but that would be ok without for this application, so the OCXO could serve as clock source for the ESP32, too.

author: MosherIV
author_rank: Super Contributor
timestamp: July 31, 2017, 07:38:06 pm
content: QuoteIf the pulse counter is truely a hardware counter, you do not need to comprnsate for code execution. The pulse counter works independantly of the processor.QuoteNothing from me, that was what I was proposing.You will have to average over thousands of seconds to overcome jitter in the 1PPS of the NEO7M.

author: metrologist
author_rank: Super Contributor
timestamp: July 31, 2017, 07:56:42 pm
content: Quote from: 0xPIT on July 31, 2017, 06:55:12 pmI hope to do something like what this fellow did, but maybe use his idea of clocking the micro with the 10MHz ref.http://k6jca.blogspot.com/2016/02/an-arduino-based-gps-disciplined.htmlI also started to collect parts to make a Brooks Shera design (maybe not low parts count).http://www.rt66.com/~shera/index_fs.htm

author: 0xPIT
author_rank: Regular Contributor
timestamp: July 31, 2017, 08:42:38 pm
content: Quote from: MosherIV on July 31, 2017, 07:38:06 pmYes, but the hw timer will not work alone, there will be code involved, so some compensation will be necessary.QuoteWith the Neo7 Series, you can set an arbitrary output frequency.

author: MosherIV
author_rank: Super Contributor
timestamp: August 01, 2017, 07:32:11 am
content: QuoteThen the hw timer implementation is not up to the job!HW timer counters should be able to latch the count without sw intervention. You should be able to just read out the count.They should also be able to start the next count without sw intervention.Do not rely on the ESP32 clock to be accurate enough to gate your counter, it is 10 times worse than the clock you are trying to verify.The 1pps should have something like 15ns jitter so is a better gate source for the timer.QuoteThe Neo7 48MHz clock cannot be divided down to 10MHz evenly, this will result in the 10MHz freq having significant jitter. Do a search, I saw some people already tried to use the freq out of a gps as a clock source, they found there was jitter due to the divided down ratio.In addition, the M series is the positioning model so the clock on it is not temperature compensated so any temperature variation will cause enough clock variation that it is not worth it.

author: tggzzz
author_rank: Super Contributor
timestamp: August 01, 2017, 07:52:54 am
content: Quote from: MosherIV on August 01, 2017, 07:32:11 amJust so.The XMOS xCORE processors recognise that common problem quite neatly. Each i/o port contains a counter that operates at up to 250MHz/4ns. You can setup the "FPGA-like" ports so thatan input is captured at a specific count, orwhen an input changes, or is equal or not equal to a specified value, the input is captured and the time is recorded, andthere are SERDES options, ands/input/output/Plus the timing of each core is deterministic, so that the IDE will tell you whether you meet timing constraintsbeforeyou execute the code.

author: tggzzz
author_rank: Super Contributor
timestamp: August 01, 2017, 07:57:10 am
content: Quote from: MosherIV on August 01, 2017, 07:32:11 amJust so. There are two techniques to reduce that jitter: only select frequencies that are sub-harmonics of the 48MHz clock, or use the output to drive a high-Q filter.If you do the latter and the filter has a time constant of ~1s, then the jitter ought to be the same as for a 1pps output

author: David Hess
author_rank: Super Contributor
timestamp: August 01, 2017, 09:35:04 am
content: Quote from: tggzzz on August 01, 2017, 07:57:10 amA high Q filter introduces its own problem in the form of variation of phase and group delay versus temperature.

author: CJay
author_rank: Super Contributor
timestamp: August 01, 2017, 11:02:18 am
content: Integer divisors of the 48MHz clock on the Neo GPS modules work fairly well, there is significant jitter if you don't use an integer, it's that bad you can see it on a 'scope even though a frequency counter will show a solid 10MHz for instance.Calling it a divisor is being generous as well, I believe it 'drops' clock cycles to get the correct number of pulse per second.A HW counter, as others have already said, should, once configured, work independently of software, PICDiv is a good example of this and it achieves ridiculously good performance from an extremely simple 12F series PIC

author: tggzzz
author_rank: Super Contributor
timestamp: August 01, 2017, 11:36:43 am
content: Quote from: David Hess on August 01, 2017, 09:35:04 amAw, you mean there isn't any such thing as a free lunch? ShameOr perhaps I was presuming perfect components and/or a perfect environment, just to hint at the issues involved.

author: Gyro
author_rank: Super Contributor
timestamp: August 01, 2017, 12:08:08 pm
content: Quote from: CJay on August 01, 2017, 11:02:18 amAs you say, there will be be severe jitter if you don't do an integer divide of the 48MHz clock. From my experiments inhttps://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg929133/#msg929133there is still some jitter for an integer divide (1MHz). This is very much lower but still sufficient to be visible on a scope, viewed against an OCXO (I measured it as about 25ns P-P).

author: CJay
author_rank: Super Contributor
timestamp: August 01, 2017, 12:32:45 pm
content: Quote from: Gyro on August 01, 2017, 12:08:08 pmYeah, sorry, I should have been a little more verbose and added that there is still jitter with an integer divisor but it's much reduced.Even with the jitter at 10MHz it still checks out to two decimal places on my counters but at 8MHz it's even better.

author: Gyro
author_rank: Super Contributor
timestamp: August 01, 2017, 12:57:59 pm
content: Yes, I also found the jittery 10MHz gave a very consistent reading with my counter on a 10s gate time. It was almost enough to put me off bothering with OCXO locking experiments.

author: cdev
author_rank: Super Contributor
timestamp: August 01, 2017, 02:15:17 pm
content: All GPS's need some form of fairly good temperature compensation or they will lose position lock when situated in an environment where the temperature changes quickly.

author: mark03
author_rank: Frequent Contributor
timestamp: August 02, 2017, 03:52:05 pm
content: Quote from: CJay on August 01, 2017, 11:02:18 amSomething else to keep in mind is that most MCU timer/counters run in the clock domain of the MCU; for this reason they put reclocking logic (a couple of D flip flops clocked by the MCU clock) on all I/O pins. This is easily recognized by comments in the reference manual to the effect of "the MCU clock must be greater than twice the frequency on this input pin". In a GPSDO, it seems to me that this will introduce some additional uncertainty in the count values. My understanding (correct me if I'm wrong) is that the PIC MCUs have timer/counters which can run in their own clock domain, i.e. if you set one up to count external pulses, it is really running in that external clock domain. The reclocking logic is then on the readout (register) side of the timer/counter. This always seemed to me like an obvious good idea, and I'm somewhat disappointed that none of the ARM Cortex-Ms I use feature this type of peripheral.Another way around this would be to clock the MCU from the disciplined oscillator.