GNSS RB (chinese)

[Leo Bodnar]

Would you publish that data?

I myself didn't trust it at the time.  It was just a ballpark qualitative measurement.
Scopes often have non-linear quirks around zero delay area between the channels.
Leo

[edpalmer42]

Now we are getting deep in the weeds. 
The frequency counter in question has a noise floor of around 1E-12 (found by using the same signal for clock and counter input) so I guess that's not a time-nutty level.
But it will reveal stuff about hobby-level equipment.
The frequency counter vendor spec says accuracy is 0.00001 Hz @ 10 MHz and that also sounds like 1E-12.

What I have been measuring is MDEV and doing runs of something like 8 hours or less (because you hit the noise floor by then).
In that time frame I don't expect aging to be a factor, in comparison with other things causing frequency perturbations.

But now you have me looking at msg 3396377  ....

Ken,

I was going over the message thread to see if there was anything I missed.  What frequency counter are you referring to?  It occurred to me that if you have access to a counter with a good reputation, you could use the Z3801A as the external reference and measure the frequency of the GPSDO-Rb.  This would give you a credible measurement.

Second, how do I find msg 3396377??  I've never seen anyone refer to message numbers on this board. 

Ed

[SilverSolder]

[...]
Second, how do I find msg 3396377??  I've never seen anyone refer to message numbers on this board. 

Ed

If you hover your mouse over the message title (or do a 'Copy Link Address' on it), you will see the URL contains the message number... 

[edpalmer42]

[...]
Second, how do I find msg 3396377??  I've never seen anyone refer to message numbers on this board. 

Ed

If you hover your mouse over the message title (or do a 'Copy Link Address' on it), you will see the URL contains the message number...

Yes, I saw that, but what do I do with that?  The URL also includes the name of the forum area, metrology in our case, and the subject of the thread, so I can't just paste 3396377 into the URL.  I tried searching for 3396377 but no luck.

Ed

[SilverSolder]

[...]
Second, how do I find msg 3396377??  I've never seen anyone refer to message numbers on this board. 

Ed

If you hover your mouse over the message title (or do a 'Copy Link Address' on it), you will see the URL contains the message number...

Yes, I saw that, but what do I do with that?  The URL also includes the name of the forum area, metrology in our case, and the subject of the thread, so I can't just paste 3396377 into the URL.  I tried searching for 3396377 but no luck.

Ed

I found a reference when using the "Google" search option in the dropdown.

For convenience, it is:

https://www.eevblog.com/forum/metrology/a-simple-time-interval-counter-for-dmtd-work/msg3396377/#msg3396377

[edpalmer42]

[...]
Second, how do I find msg 3396377??  I've never seen anyone refer to message numbers on this board. 

Ed

If you hover your mouse over the message title (or do a 'Copy Link Address' on it), you will see the URL contains the message number...

Yes, I saw that, but what do I do with that?  The URL also includes the name of the forum area, metrology in our case, and the subject of the thread, so I can't just paste 3396377 into the URL.  I tried searching for 3396377 but no luck.

Ed

I found a reference when using the "Google" search option in the dropdown.

For convenience, it is:

https://www.eevblog.com/forum/metrology/a-simple-time-interval-counter-for-dmtd-work/msg3396377/#msg3396377

Ah.  Google.  I think I've heard of it.     Thanks, Silver.

Back on topic.....  Yes, the Parallax Propeller.  Something else that's stuck on my list of things to do.  It has some *very* nice features for us time-idiots time-nuts.  The creator of the counter program has a list of even nicer future capabilities but we have no idea if or when he will get time to do them.  It looks like his last update was Dec. 2020.  And he hasn't released the source code.  And the Propeller itself is more or less a dead platform since Parallax has come out with the Propeller 2.  I actually ordered three Propellers, but the place I ordered from didn't have 3 and was discontinuing the product so I cancelled the order.  Yes, I know they're available from various sources.

Ken, notice that the Propeller only has a resolution of 12.5 ns. so, by itself, it isn't really useful for your measurements.  However, it's perfect as a counter for a DMTD system.

Ed

[edpalmer42]

I don't know if I have to mention this, but if anyone else has one of these Rb-GPSDOs and can make some good measurements, please post them here so that we can confirm Ken's findings.  It's possible that he just got a bad unit.

Ken, would you be willing to pop the top off your unit and take a few pictures?  Good resolution shots of both top and bottom would be great.  We might be able to infer something about the architecture of the unit.

Ed

[FriedLogic]

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.

[Johnny B Good]

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.

[testpoint1]

Hi, you need to know which Rubidium clock inside, and, my selling the Rubidium Clock that combined the GPS, I am in US:
https://www.ebay.com/itm/185256532144

[Johnny B Good]

Hi, you need to know which Rubidium clock inside, and, my selling the Rubidium Clock that combined the GPS, I am in US:
https://www.ebay.com/itm/185256532144

 Yes, I know where you're located. You sold me an Efratom LPRO-101 a year ago last August. 

EDIT: I've attached some photographs showing that LPRO I'd purchased from you.

 The first shows it perched on top of the 1/4 inch thick alloy heatsink plate resting on top of what I'd originally thought would be a most suitable enclosure.

 The second shows it resting on the heatsink plate, revealing my initial test measurements noted in black marker on the top cover.

 The third demonstrates how woefully inadequate my initial choice of enclosure had been - it's perched on top of the custom built case that it's now destined to be installed into.

 The fourth shows the LPRO wrapped in its initial 20mm thick polystyrene jacket still dwarfed by the more adequately sized enclosure - there'll be another 25mm thick wrapping of insulation plus 10mm polystyrene panels glued to the inner walls of the enclosure to prevent the warm/hot exhaust from heating up the enclosure itself.

 The enclosure is going to be used to couple changes of room temperature to a sensor, the output of which currently sets the fan speed to match cooling demand and minimise over/undershoot and eventually allow me to compensate for their biasing effect on the base plate heatsink's temperature control.

 Incidentally, the traces on the DSO are showing a 2MHz Sinc pulse from my modified FY6600 locked to the 10MHz GPSDO reference and the 10MHz output from the LPRO which is the trigger source. That had been my initial attempt to keep track of overnight phase drift due to leaving the LPRO "Hanging in the breeze".

[Johnny B Good]

Hello all!

 I've noticed that the attached images in my previous post did manage to attract some attention. The project is still a work in progress but in view of the interest shown, I thought I'd post a couple more images showing the more or less finalised assembly to satisfy curiosity as to its final incarnation.

 I've had it assembled and running for the past three weeks or so but I've been rather pre-occupied with refining the code that controls the temperature regulation and compensates for the effect of ambient temperature on cooling demand as well as the minuscule effect of barometric pressure variations (~ +8E-14/hPa) to even consider posting an update on my efforts so far.

 However, I've been itching to make some token effort at providing a brief update on my progress, hence the couple of attached images of the (almost) completed project.

 The project is "almost complete" since I'd like to wire the "Lamp voltage" and VCXO EFC monitor pins to a rear panel mounted 3.5mm stereo jack and possibly do the same for the calibration tuning voltage and the 5v regulator dedicated to supplying a thermally stabilised bias voltage for critically sensitive circuit elements such as the calibration pot and the ADC reference pin on the nano mcu and maybe even use it to power an add on buffer to prevent the current ripple noise on the mcu's 5v power rail from polluting the PWM outputs.

 However, this last item is going to require a mark II controller board since I've pretty well crammed as many components onto the current circuit board as I possibly can. 

 I've given the images descriptive names. The full view shows the 'scope traces of the GPSDO and RFS with infinite persistence (GPSDO is the trigger source) and the GPSDO's EFC voltage (SDM3065X) in the background.

 I do plan to post a full article on the project... eventually. I'm afraid you'll just have to make do with this mini-update and these attached photos for the time being.

[Johnny B Good]

I've picked out some more photographs (19 in all so another post to follow this one) to show the transition from bare box with a polystyrene foam insulated LPRO simply plonked inside to the (essentially) "finished project".

 I finally decided to rebuild a redesigned polystyrene 'overcoat' using 25mm thick foam (the original had been a bit of a bodge using 20mm thick foam and needed some improvement to better accommodate the nano mcu board I'd piggybacked onto the DC jack with SMA adaptor board that testpoint1 had added to the LPRO).

 The pictures should give you an idea of the ventilation pathways which were designed specifically to minimise passive convective cooling (the heatsink fins are orientated horizontally to help meet this goal). The inspiration for this being the almost non existent convective cooling of FeelTech's (in)famous FY6600 AWG 

 The final seven picture sequence shows the run up from initial power on  through to reaching the target base plate temperature state. The bi-colour status LED shows red until "atomic lock" has been achieved, at which point it changes to green. Reaching the target base plate temperature typically requires another 15 to 20 minutes. It then takes another 12 to 24 hours to reach ultimate stability somewhere in the region of 1E-12 to 3E-13 beyond which, a daily ageing rate in the region of 1E-13  begins to make its presence known.

[Johnny B Good]

Here are the remaining 9 photographs:-

[EDIT 2024-02-28] I've added a photo showing the latest version of the oled display as a 'teaser' of my progress so far. I believe I'm now (at last!) very close to the completion of this epic project (fingers crossed - I've been making similar announcements over the past two or three years now ).

[Johnny B Good]

 It's been just over 6 months since I last edited my previous post so I thought I'd post a 2 minute movie clip and a couple of temperature plots by way of a progress report on my rubidium reference project, the bulk of which has essentially been an exercise in establishing as fine a control of the LPRO's base plate temperature as possible using an Arduino Nano to control a cpu cooling fan to maintain it at 36.05 deg C.

 I finally reached a surprisingly high stability of 36.050 deg +/- 1mK (80 to 90 % of the time with random excursions up to +/- 5mK due to the physics package ovens' control activity from testing in the sub zero to 18 deg ambient range when the servo controlled flap diverter valves have totally sealed it off from random air drafts it never shows higher than 51 or lower than 49 mK above the 36 or 37 deg baseline).

 I still have to fine tune the barometric compensation and add thermal gradient (and possibly even ageing) compensation to take it to the ultimate frequency stability limit (10E-13 or better) but I need to upgrade my MK II GPSDO to a ZED-9T MK III version to stand any chance of gettng any further with this epic project (three years and counting ).

 The two minute movie clip shows the plenum and base plate temperature one second averages of 133 samples per second along with the barometric one second readings (not averaged - merely truncated to one decimal place to fit the "mBar" units label in place of the mildly irritating "hPa" unit label).

 The first plot shows 498 one second base plate temperature averages over an 8 minute and 18 second period some 2 or 3 minutes after it has recovered from the 35 second interruption of fan control due to uploading the modified sketch.

 The second plot shows the individual (7ms) 16 bit ADS1115 sample readings from the thermistor and its series resistor bridge embedded within the  quarter inch thick aluminium heat spreader attached to the base plate. This is a very noisy plot due to running the ADC at "maximum smoke" (256mV reference at 860 sps for maximum sensitivity and response speed).

 In this case, the noise is actually more friend than foe since it dithers the 10 bit PWM driving the fan to in between values, increasing the effective resolution by another 2 bit's worth (the inertia of the fan nicely integrates the 7ms worth of the 15.625KHz 10 bit PWM samples fed to the fan via a DRV8871 module, running in half bridge mode, to eliminate the voltage pumping effect of a simple low side switching FET trying to drive a capacitively decoupled BLDC fan driver board, typical of the classic brushless DC fan cooler commonly used in desktop PCs).

PS I've had to rename the movie file to .doc to get past eevblog's stupid file type restrictions - just delete the .doc bit after you've downloaded it if your media player can't figure it out.

 PPS The Y axis in the plots are in mK above the original 36.000 degree baseline reference (covering a 40mK range - 30 to 70 mK above 36.000 degree baseline).

 Also worth noting is the fact that the base plate temperature readout has been averaged to four (or more? I forget exactly how many) decimal places and is rounded to the nearest whole milli Kelvin (i.e. the readings are to within half a mK of the voltage to resistance and resistance to temperature calculations).

[EDIT 2024-11-26]

 I've just last night updated the temperature control algorithm to increase the base plate temperature by one degree to run at a 37.050 deg set point along with changes to the plenum chamber target temperature to set it 5.55 deg below the base plate to increase the delta amb by an extra degree to improve stability in the 31 to 33 deg maximum ambient region plus changes in the plotter code to accommodate these changes and increase the Y axis window from 40mK to 100mK centred on the 50mK above the new 37.050 deg baseline.

 I've always wanted to be able to post short movie clips of the plotter display but could't track down any screenshot to movie clip software until this afternoon when I installed one such utility called "Blue Recorder" and was able to finally create a 60 seconds movie clip of the temperature plot.

 I've attached the movie to this post. As with with the previous movie clip, I've renamed it to type doc.

 Please note the 'jump cuts' that occur every half second. this is due to the 70ms or so required to service the display update code (the in between plot points only burn 7ms of main loop cycle time). The 100 mK pk-pk spikes are a deliberately introduced artifact to defeat the arduino v1.8 plotter's insane auto zooming "To Infinity and Beyond!".

 It doesn't stop it zooming out, just limits it to that minimum. Without such a measure the auto zooming would totally defeat the purpose of such a graphical representation of the data. Also, the spikes (inserted every 498th plot point to ensure they remain present within the 500 points wide x axis window) facilitates checking the average loop cycling rate by the use of a stopwatch.

[Johnny B Good]

 A new post to trigger any notifications to alert anyone interested enough to have pressed the notify button to the latest edit to my previous post.

[Solder_Junkie]

John, was it yourself that bought a TinyPFA to measure phase/frequency differences? If so, how do you find it when measuring down in the weeds/mud?

I have a TinyPFA that I use with TimeLab software and find it gives repeatable results down into the 1 part in 10^11 region, at least for short term stability comparisons. My only reference is a basic rubidium (Efratom FRS-C,  short term stability is quoted as: 1 sec Allan Var of 1 part in 10^10, 10 seconds is 3.16 parts in 10^11 and 100 seconds is 1 part in 10^11). These rubidium units were used in cellular and telecommunications link equipment, they are not a lab instrument.

SJ

[Johnny B Good]

John, was it yourself that bought a TinyPFA to measure phase/frequency differences? If so, how do you find it when measuring down in the weeds/mud?

I have a TinyPFA that I use with TimeLab software and find it gives repeatable results down into the 1 part in 10^11 region, at least for short term stability comparisons. My only reference is a basic rubidium (Efratom FRS-C,  short term stability is quoted as: 1 sec Allan Var of 1 part in 10^10, 10 seconds is 3.16 parts in 10^11 and 100 seconds is 1 part in 10^11). These rubidium units were used in cellular and telecommunications link equipment, they are not a lab instrument.

SJ

 Yes, that was myself.

 I did use it to try and get some figures but got impatient over the time needed to try and get it to show anything better than 10 E -11 and when I tried another run, it was struggling to do any better than 10 E - 9. The MK II gpsdo wasn't doing any better either but I was aware of the ionosphere issue. I figured I just needed to fettle the rubidium a little more so packed the TinyPFA away until I had made further improvements to remedy the rather lackluster performance of the ruby which had previously been showing phase drifts of less than 50ns in 24 hour test runs against the MK II.

 I'd decided it would be best to wait until I finally completed the ZED9 FT based MK III gpsdo project before taking it back out of its box. I did finally complete enough of the build sufficient to get sensible test results out of the MK III a couple of weeks ago (well, enough to see the 33ns diurnal phase wander of the MK II  ).

 Unfortunately, I'm now waiting on replacement smd tantalum capacitors to repair the LPRO. That weird 3 to 4ns phase wobble that had appeared about six months or so back proved to the harbinger of doom.

 Now instead of the crystal oscillator responding to percussive testing with a short lived wobble without making it lose lock, I could now cause a temporary loss of lock, regaining lock a full sweep cycle later.

 The problem has now worsened to the point where I only have to wait a few hours for it to spontaneously lose lock and never regain lock until the power is briefly interrupted for a second or so whereupon it would regain lock in just a matter of seconds.

  If I get impatient waiting for it to lose lock over the next few hours, I merely have to thump the case at the right cadence in the right place to trigger another loss of lock with the only way to get it to lock again being to briefly interrupt power for a second or more.

 Indeed, I now only have to wait half an hour or less for it to lose lock. I've just deprived it of power for a couple minutes, observing the base plate rising by a couple of degrees due to the lack of cooling and the heat stored in the physics package leaking into base plate, courtesy of leaving the nano powered via the connection to the PC's usb port. It takes some 10 to 15 minutes for the temperature to top out about 3 deg above the set base plate temperature before it starts falling (very slowly).

 This deterioration was what I was hoping to see after raising the base plate set point by one degree to 37.050 deg. Failing tantalum caps are a pretty safe bet for the cause of this fault so the effect of replacing them should now give a clearer indication as to whether these are indeed the true cause.

 If replacing those caps doesn't fix the problem, I've already ordered another just like this one from an Israeli dealer:

https://www.eevblog.com/forum/blog/eevblog-235-rubidium-frequency-standard/msg3714325/#msg3714325

 Hopefully, I'll end up with three working rubidium oscillators (an SA22.C and two LPRO 101s)

 With a bit of luck, I should have my ailing LPRO 101 back to full health by the end of this week - fingers crossed

 Only after that happy event (or a swap out to the other LPRO), will I have good reason to unpack the TinyPFA and put it to work.

 I'll post my results here.

[Solder_Junkie]

Wow John, you are unlucky with the rubidiums. As I mentioned, I only have the one and it seems quite good within it's limitations/specification.

I have 4 GPSDOs... the best being a Lars Arduino controlled one with a high spec NEC OCXO, followed by a G3RUH "simple" one again with an NEC OCXO. I also have two Leo Bodnar GPSDOs, one is the older dual BNC socket type and the other the later LBE-1420. The LB units are much less stable and have noticeable jitter/short term wandering compared to my home made units, on the other hand the LB units can output any frequency up to around 1 GHz (LBE-1420) and settle in a minute or two of switching on. The LB units only use a TCXO and I believe a Ublox 6 navigation grade GPS module, and are USB powered.

I had considered buying a Sparkfun ZED-F9T and dual band antenna, but for my purposes my current Ublox NEO M8T and single band mushroom antenna are more than adequate, in fact my every day GPSDO is the LBE-1420. I guess it depends on whether you have a real use for a GPSDO, or are just using one for fun.

Back to the TinyPFA, I only use mine with TimeLab using the rubidium as the reference. The screen of the TinyPFA seems to be hard to use for measurements, but with TimeLab it "just works". I leave my TinyPFA to warm up for around 30 minutes before use.

I have seen others measure the Efratom FRS units around 5 parts in 10^12 over a time average between 10 and 100 seconds using a lab Cesium Beam as reference, although 3 parts in 10^11 in 10 second is the specification. The best I can measure between my FRS and my Lars GPSDO is 2 parts in 10^11, which is at the limit of my measurements. As the only realistic maximum accuracy I "need" is 1 part in 10^9, or in practice +/-10 Hz on the 1296 MHz amateur band, any of the frequency references I have is more than enough 

SJ

[Johnny B Good]

Wow John, you are unlucky with the rubidiums. As I mentioned, I only have the one and it seems quite good within it's limitations/specification.

 Actually, I don't see it that way. The more recent SA22.C purchase works perfectly and the PoH data shows a mere 2.7 years of run time. The LPRO was perfectly ok until some 6 to 12 months ago and considering its age (about 25 years) and the fact that I've had it powered up 24/7 these past three years, I'd be very surprised if those tantalum caps were still in a healthy condition. If I've guessed correctly, I should have it back up to specification by the end of this week.

 The other LPRO I'd ordered Saturday night/Sunday morning is expected to arrive this Friday which is a much quicker delivery than  the first one I'd bought from Testpoint1 in Massachusetts which took about three weeks afair, leaving me to pay import duty and VAT which I'll also most likely have to do when this one lands up in the clutches of UK Customs & Excises (likely to be north of the sixty quid mark).

I have 4 GPSDOs... the best being a Lars Arduino controlled one with a high spec NEC OCXO, followed by a G3RUH "simple" one again with an NEC OCXO. I also have two Leo Bodnar GPSDOs, one is the older dual BNC socket type and the other the later LBE-1420. The LB units are much less stable and have noticeable jitter/short term wandering compared to my home made units, on the other hand the LB units can output any frequency up to around 1 GHz (LBE-1420) and settle in a minute or two of switching on. The LB units only use a TCXO and I believe a Ublox 6 navigation grade GPS module, and are USB powered

I had considered buying a Sparkfun ZED-F9T and dual band antenna, but for my purposes my current Ublox NEO M8T and single band mushroom antenna are more than adequate, in fact my every day GPSDO is the LBE-1420. I guess it depends on whether you have a real use for a GPSDO, or are just using one for fun.

 Just before I started experimenting with a diy version of my own inspired by Gyro's post here:
https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg1493431/#msg1493431

That topic thread (only a single page long over a two year period of activity) is well worth a read.

 I did seriously considering buying one of Leo's gpsdo offerings but changed my mind and started building my own variation on that circuit. It didn't include an rro opamp because I didn't have one to hand so simply connected the PLL filter output directly to the 13MHz ocxo's efc pin instead.

 As I later discovered, I didn't actually need to buffer the filter output on account my ocxo's efc pin had an input impedance in excess of 10G ohms! The final build onto veroboard did include one to buffer the buffer amp that (needlessly) buffered the filter output in order to drive the efc voltage monitor socket meter connection.

 The MK II used the same buffering circuit but the current MK III drives the efc pin directly from the PLL lpf and the RRO opamp merely buffers this to drive an external 10Mohm voltmeter to avoid reliance on a bench meter that happens to have a 10Gohm input option.

 I've never purchased any ready made gpsdos, only a lot of fake M8Ns and a genuine M6N that proved totally unsuited to the RUH design. The MK II started out using M8N modules (both fake in varying degrees of badness) before I came across an Amazon seller offering genuine M8T based module boards for just 41 quid versus the hundred quid pricing for similarly blessed break out boards.

 I kept my eye on his his activities after making that purchase for a week or three and jumped at the chance to purchase another two for a mere 24 quid each, noting a week afterwards that he'd hiked the price to 60 quid or so each. Talk about being in the right place at the right time!

 At the time, I'd already upgraded the MK II but was having some slight doubts on account trying to change the elevation filter mask from its 5 deg default resulted in a lockup every time. All other commands worked without issue and I assumed that it was perhaps just a bug in its firmware that I could either live with or else fix with a uBlox firmware upgrade. However when I replaced it with one of the 24 quid examples, I saw exactly the same behavior. However it did occur to me to swap the FTDI232 for another one out of my dwindling brand new stock which fixed this weird issue which I then suspected had been present when I'd previously been using Lady Heather.

 The MK II had been cursed/blessed with a massive 1100s TC (I had tried an even more massive 5000s TC PLL filter before 'compromising' with the 1100s TC LPF) in a futile attempt to reduce the 2 to 3 ns phase shifts in as many minutes due to the rapid variations in the ionosphere's TEC. When I upgraded to the M8T and ran a self survey on the earlier mag mount active patch antenna located just above the ridge tiles to gain a full all round view down to the horizon, I saw a marked reduction of this effect and a further reduction when I upgraded the antenna to the multi-band band GNSS/RTK type. I guess such large TC filtering is wasted effort with a navigation class of gps receiver module.

 When it came to the MK III where the ZED9FT would neatly sidestep that issue, I chose a more reasonable lpf time constant of 50 seconds. Phase locking to 128th of the ocxo's frequency (versus the 100th of the ocxo's 10MHz used in the previous MKs I and II) is what does most of the heavy lifting with regard to the overall time constant anyway. Using a long time constant in this case would be like gilding an already well gilded Lilly, an unnecessary and counterproductive add on feature.

 As for my own need's it could be described as being for the fun of discovering just how much further I can take such precision to its maximum possible limits using mass produced telecom grade rubidium reference frequency oscillators. To me, it looks like I could gain as much as an extra two orders of magnitude improvement. I'm doing this because, rightly or wrongly, I think I can.

Back to the TinyPFA, I only use mine with TimeLab using the rubidium as the reference. The screen of the TinyPFA seems to be hard to use for measurements, but with TimeLab it "just works". I leave my TinyPFA to warm up for around 30 minutes before use.

 It didn't take long for me to search out a download of the free version of Timelab. It's just as well it includes a usb interface to talk to a PC app like Timelab otherwise I'd have returned it as "Not fit for purpose"

I have seen others measure the Efratom FRS units around 5 parts in 10^12 over a time average between 10 and 100 seconds using a lab Cesium Beam as reference, although 3 parts in 10^11 in 10 second is the specification. The best I can measure between my FRS and my Lars GPSDO is 2 parts in 10^11, which is at the limit of my measurements. As the only realistic maximum accuracy I "need" is 1 part in 10^9, or in practice +/-10 Hz on the 1296 MHz amateur band, any of the frequency references I have is more than enough 

SJ

 Well, in this regard, the MK III is just a tool to allow me to gain a more accurate assessment of my efforts to convert an ex cell tower rubidium frequency reference into a decent home lab reference standard. In the meantime I'll be discovering ever more knowledge about the subject and sweep away yet more of my earlier misconceptions about GPS based frequency and timing standards.

 Suffice it to say that apart from the need for ground control to instigate orbital correction maneuvers maybe once a year or so when the SV has to be marked as "out of service" for maybe a day or two, they'll take that opportunity to adjust any clock drift in the cesium and rubidium frequency references.

 In between such major maintenance, clock drift is continuously monitored and clock error data is included in the ephemera data packets to allow the gps receivers' navigation engines to correct these timing errors, which reduces the need to place an SV out of service to allow ground control the time needed to adjust the on board clocks.

 Ground control, as you might surmise from this is a hive of activity. There is a lot more to maintaining the integrity of a GNSS system than first meets the eye. Despite all this care and attention, there are still some five or six or sources of error within the gps system with the state of the troposphere thrown into the mix for good measure.

 The only benefit a dual frequency gps receiver like the ZED9FT brings to the party is the virtual elimination of the ionosphere's variable TEC which, for single frequency receivers is by far the major source of error of them all. When you look at the attached 15 hour sequence of screen shots starting from 2am Wednesday morning until quarter past 5pm that afternoon showing the drift of the M8T based MK II on ch2 against the MK III on ch1, you're only observing the diurnal ionospheric induced phase drift component since all the other error sources effect both types equally and cancel out.

 I suspect there'll still be some 2 or 3 ns of phase wander in the MK III's output due to rounding errors in its calculations (plus some random noise effects in capturing the time delay data) so not all of that apparent 39ns phase drift necessarily lies with the M8T alone.

[bingo600]

Unfortunately, I'm now waiting on replacement smd tantalum capacitors to repair the LPRO. That weird 3 to 4ns phase wobble that had appeared about six months or so back proved to the harbinger of doom.

John will you "snap a few pics" of exchanging the Tant's ?
And maybe make a short comp replacement guide

/Bingo

[Johnny B Good]

Unfortunately, I'm now waiting on replacement smd tantalum capacitors to repair the LPRO. That weird 3 to 4ns phase wobble that had appeared about six months or so back proved to the harbinger of doom.

John will you "snap a few pics" of exchanging the Tant's ?
And maybe make a short comp replacement guide

/Bingo

 Hi Bingo,

 It's been a while since we last communicated. I could oblige you but I rather think that you'd be better off using the DeVries repair guide. On the off chance that you don't already have a copy, you can download the latest version that I've attached.

 Althought the 10μF 25v caps turned up in today's post, I'm still waiting on the 100μF 20v caps that should have also arrived by today. Also, the latest UPS tracking on the rubidium oscillator shows it had arrived at their UPS Facility Stanford Le Hope, United Kingdom at 13:43 today with an estimated delivery of "Friday, November 29 by End of Day".

 I also got a payment request for government and brokerage charges of 73 quid when checking just now, which I've paid to avoid any delivery issues. The say the delivery driver can accept some forms of payment on delivery but don't list what my options are limited to, hence my settling the import charges which could be adjusted (presumably to account for any exchange rate fluctuations between now and the actual delivery).

 Ah well, I was already prepared to shell out Duty and VAT charges north of the sixty quid mark anyway - the 11 quid or so 'brokerage charges just happens to be "Icing on the cake" (for them, not me!).

 So it looks like I'll have a "New Toy" to play with before I'll be able to start repairing my first LPRO. Speaking of which, I powered it back up yesterday some time around 6pm after leaving it powered down overnight so I could check how it would react to a fully stone cold start.

 It fired up as usual, taking the anticipated 276 seconds (ambient was only 18.5 deg). It still showed the 2 or 3 ns of phase wobble. I was expecting it to lose lock in a matter of hours but it surprised me by not doing so until some time just after 4pm this afternoon. Resetting with a short (seconds long) power cycle works as before but it now loses lock within an hour or less like it had been doing before I shut it down for the night.

 Now that I have a proper LCR meter in the form of a Zoytec ZT-MD1, I'll be able to get a better in circuit measure of those caps than I was able to get with a MESTEK DM91A dmm (or any of the other cheap component testers) and I will be rechecking those two suspect 0603 100K resistors underneath the physics package region of the main board that DeVries had pointed out in his repair manual.

 I will of course, be extracting those caps anyway to test them without any questions about the effects of other circuit components.

 If you really need yet more photos than those kindly provided by DeVries, please let me know either way.

[Johnny B Good]

 Here's the latest update on my repair / replace saga.

 The A23A3 LPRO-101 unit I'd ordered from patentix_ltd arrived on Saturday afternoon (30 Nov) before the capacitors did (they didn't turn until the following Monday). So I unpacked it, parked it on top of my RFS, made up a DB9F connector to connect to the Wanptek (after raising its voltage from 5 to 15 volt - it was and still is powering the MK III gpsdo) and connected its output to the dso and plugged the red 4mm banana plug into the Wanptek to complete the circuit and observed its startup, stopwatch in hand with the bench meter monitoring the one and only signal being offered through the DB9M connector, namely the BITE (the other 6 pins were all marked NC as you will see in the attached photo).

 I left it running until the next day, after syntonising it as best as I could using its internal trimpot before considering breaking the warranty sticker in order to access the lamp voltage pin. Closer inspection revealed that the sticker had already been slit at the join between the adapter and the LPRO so I removed the cover hoping to gain access to the lamp pin without any further disassembly.

 Unfortunately, the only pin that had anything of use for me to test was the 23.88v power feed into the LPRO from the A23A3 boost module (remained pretty constant over an input voltage spanning 10 to 18v). All other useful connections being inaccessible without removing the power module from the base plate adapter which would best be modified to pass the missing connections through to the DB9M connector to avoid any risk of a catastrophic short circuit.

 Since this was more trouble than simply transplanting the LPRO itself onto my own customised fan cooled heat spreader plate and its associated electronic baggage (a problematic exercise at the best of times - the photo will reveal why). This is what I chose to do since it also provided temperature control and barometric compensation and much greater precision in syntonising it to my gpsdo.

 Only after all this faff and bother was I able to finally check the lamp voltage which proved to fall rather short of its described "LONG LIFE HIGH LAMP VOLTAGE OVER 9V”.

 I complained about this disparity between my measurement of lamp voltage and its description to the seller who replied within the hour with an apology and a promise (which he kept) to ship me a replacement straight away without any need to return the first one.

 This duly arrived 3 days later. Unlike the first one, the case was blemish free, however, the lamp voltage still fell short of the >9v but at least it was higher than the first one (just 5.838v versus the 6.3ish volts of this replacement).

 Pondering the mysterious absence of the vital health monitoring and external C field connections in the DB9M connector, I had a pretty good idea of his most likely response to a second complaint.

 Assuming he even had a test rig, be it just a modified A23A3 adapter to pass the lamp pin out to its DB9M connector for testing, it would take a fair bit of time just to undo the six screws (and 12 washers) to remove each one to temporarily attach to his test rig. Expecting him to process just half a dozen, let alone dozens, just to pick out a unit that even came close to the ">9v" just wasn't on.

 His response was that they only shipped one replacement in such circumstances, giving me the option to return the (presumably second unit) for a full refund or else keep it and receive a 50% refund. Since this second unit had a lamp voltage some 1.5v higher than the very first one I'd purchased just over four years ago from Testpoint1, I opted for the 50% refund option. At least that way, I had gotten hold of two working units for less than it had cost me for the very first one from Testpoint1.

 So, there you have... the "Saga". As for my repair attempt, that had not made any difference. However, that had not been without its own unexpected problems... I'll attach the evidence of this in my next post (too measly an allowance on file attachments per post).

[Johnny B Good]

 Here's the rest of the photos.

 What a palaver! EEVBLOG's attachment mechanism is very badly broken.  It took several attempts to get it to stop nagging about its pathetic 8000KB limit when I was posting just a mere 6.9MiB's worth in 5 images.

 Anyway, the last two images in the previous post along with the first three images in this post should give some idea as to how fiddly a process is involved just to transplant a replacement into my Rubidium Frequency Reference case.

 And there are a few more images demonstrating what can go wrong after reinstating the 5K trimpot that those paying attention to the first two images in the previous post may have noticed....

[Johnny B Good]

 And finally, the last six photos of what can go wrong if you don't wriggle the PCB into alignment with the trimpot adjustment access tube (after making sure this tube hasn't been dislodged out of true). For anyone concerned about checking the alignment after refitting the case cover, you can use a torch (aka "flashlight")  to shine enough light into its interior via a handy base plate threaded fixing hole to provide a clear view of the trimpot's adjustment screw to check whether you need to open it up and wriggle the board into alignment before securing the screws once more.

 I had replaced the original (presumed to be worn out) Bournes 5K trimpot with a Suntan equivalent a few months back before deciding to remove this and use an external 2.5K wirewound pot fed off the same "5v" reference that feeds the front panel Bourns hybriton 5K ten turn pot. Now, having realised that this had had nothing to do with the fault I was trying to fix, I decided to put the Suntan pot back onto the board.

 As you can see, I managed to almost completely destroy it in my misguided attempts to get the screwdriver tip to re-engage for another tweak. No matter how carefully I tried to get the screwdriver tip to re-engage, I eventually gave up, but only after I'd almost destroyed it, and pulled it all apart again to see what the bl**dy h*ll had gone so wrong.

 I'd had this apart several times before without hitting this issue and knew only too well of the need to finesse the screwdriver tip into engagement before giving it a serious twist of adjustment. I was somewhat taken aback by what I saw. It's just as well I'd hung onto that "worn out" Bournes trimpot as a spare (although I think I could have straightened out the lead wires on the Suntan if necessary - it's now my "spare" of last resort).

 Oddly enough, I had the same trimpot alignment issue with the replacement A23A3 LPRO-101 but by then, I knew better than to persevere with any further adjustment attempt without pulling it apart to correct the problem. In this case, it looked like the adjustment access tube had been pushed or pulled out of alignment. Either way, I got it back into alignment, verified with that flashlight technique I'd mentioned and all is working just fine as evidenced by the two 'scope screenshots with some 6 hours separation between them.

[EDIT this afternoon]

 Further to the above DSO screenshots, I was quite surprised to see the following screen captures taken some 3 and 8 hours later.

More precisely, the actual timings for these four screenshots are as follows:

18:59 (yesterday evening)
00:52
03:49
13:19
12:00

 A total time span just 1 minute shy of 17 hours with the trace still within the band of persistence an hour and a half later. This is with the second LPRO-101 fitted in place of the original ailing unit I had tried to repair.

 I've had this running 24/7 over the past 48 hours or so to allow the lamp voltage to stabilise (now showing a reading of 6.47520v versus the typical 1 volt overshoot after the first half hour followed by a slow decline down by just over a volt over the next hour or two, followed by a gradual rise over several days of run time before it reaches its ultimate peak from there on in, the expected 1mV per week decline starts to show itself.

 Quite frankly, I'm amazed at how quickly it seems to have settled down to better than I'd hoped to see (it hadn't looked particularly promising over the first 36 hours or so until quite suddenly at 7pm yesterday evening). Of course, I'm only too aware that this may be yet another case of serendipity as I'd experienced when using the M8T based MK II gpsdo which shows a 33ns ionospheric induced diurnal phase wander when compared against the ZED9-FT MK III I' now using as my reference.

 The one thing to keep in mind about this 33ns phase wander between the MKs II and III gpsdos is that it only shows the ionospheric induced diurnal phase wander. Both gpsdos still suffer the remaining gps errors and the variations induced by "Precipitable moisture content in the troposphere" as u-Blox put it to essentially describe the effect of cloud cover.

 Since these error sources effect both types equally, they cancel out in this comparison, leaving only the difference in how they deal with the variation of the TEC in the ionosphere. As tempting as it is, I'd be a fool to think that the small 10ns wander shown by the band of persistence could mostly be gps system errors. It's far too soon to be counting my chickens just yet.