What's interesting is that multiple tests throughout the day always show the same offset.... it seems both devices are quite stable. Just that one of them is slower than the other.
That's pretty much how I would do it with that setup. The complication with GPSDOs - and particularly with rubidium ones - is that the filter time constants can be quite long. Taking measurements spread well out over a couple of days helps to get representative measurements.
The scope should add relatively little uncertainty (maybe in the region of 1E-12 in this case) so if you are getting stable measurements close to 3.8E-11, that is likely correct.
If you find the FA-2 counter, a log from it would show any fluctuations as well as the longer term average. They usually have small offsets that need to be taken into account.
There are various other things that can be done, such as dividing the frequency down to increase the time range that it scope covers without slipping cycles, but if you already have a lot of similar measurements, spread over days, they're probably not really necessary.
I've been working on a rubidium oscillator reference project ever since I purchased an LPRO-101 way back in August 2020. I've been looking out for Rubidium based topic threads every so often ever since. This evening, I decided to see if there were any more recent threads on the topic and this appears to be the most 'current' discussion on the subject.
Anyway, I was a little bemused by edpalmer's needless concern over the quality of the DSO being used to compare oscillators. He seems to have jumped down the wrong rabbit hole.
Anyway, I thought I'd add a few comments of my own whilst I pluck up the courage to actually start cutting out 40mm diameter ventilation holes and thus commit to the final enclosure build phase for housing my extremely well insulated LPRO with its fan cooled base plate heatsink attachment.
Regarding the quality of the DSO, unless it is seriously out of whack, it will have zero effect on the results when comparing one oscillator against whatever is being used as a reference from which the scope timebase is being triggered. There was absolutely nothing wrong about the way kpjamro was using his DSO to compare the two reference oscillators against each other.
When it comes to detecting whether the DUT has drifted by more than one cycle during protracted test runs, the infinite persist option is your best friend here.
This was what I used when syntonising my newly acquired LPRO to my diy gpsdo's 10MHz output, initially discovering that simply using a passive heatsink wasn't good enough to hold the LPRO sufficiently stable against modest diurnal shifts in ambient temperature in my "lab", hence the thermally regulated fan cooler attachment and an initially inadequate 3mm thick layer of thermal insulation to allow the fan maximum control of the whole LPRO's temperature.
This initial attempt to stabilise the frequency against changes in room temperature did show some improvement but it was obvious that I needed much more insulation and a much larger enclosure than the one I'd initially chosen. I spent a few fruitless weeks searching for a suitable enclosure before giving the project a rest.
A few months later, I decided to make use of an old polystyrene frozen foods container from which to cut out 20mm thick panels to wrap around the LPRO and do some more testing. I'd decided that with that much insulation, the lack of an enclosure would make little difference as indeed proved to be the case.
Apart from changes to the temperature controller, that's pretty well where the project stands to date. I was now able at long last to syntonise the LPRO to my gpsdo reference sufficiently to see less than half a cycle drift in 24 hour long test runs using a solderless breadboard lashup that was prone to upsetting the temperature control if you so much as gave it a funny look.
This was when I finally came to fully appreciate the persistence feature of my SDS1202X-E (in particular, the infinite persistence option
). Prior to that, I hadn't been able to see the worth of such a feature.
As well as providing a check against cycle slip overruns, the persistence feature had also confirmed my previously estimated 6 to 7 ns pk-pk milliHertz phase modulation due to ionospheric disturbance and other lesser GPS system errors (the initial impetus for investing some 200 quid in that LPRO-101 in the first place!
).
As for the consistent frequency offset of kpjamro's Chinese GPSDRO, that surely can only be down to the use of a FLL algorithm, with a small rounding error (a 15mHz offset afaicr with the earlier GPSDOs), rather than the PLL algorithm called for in this usage case. Opening up the GPSDRO is unlikely to reveal whether it's using a FLL or a PLL algorithm (but it might reveal a JTAG by which to load a firmware update to correct this deficiency
).
The use of a FLL instead of the more appropriate PLL algorithm seems a little odd until you remember that this guy is a radioham where such a slight frequency offset in the 10GHz band and beyond might be considered a lesser evil compared to the issue of phase noise being magnified by a PLL algorithm. I may be wrong but that's my best guess for what most of us here might think of as an oddball way to synchronise a Rubidium oscillator to a GNSS time/frequency reference source.
Home
Help
Search
Login
Register
