@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/ 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
). 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)