GNSS RB (chinese) - Page 1
Forum section: electronics / general

author: kpjamro
author_rank: Contributor
timestamp: January 20, 2022, 02:57:05 am
content: Has anyone tested one of these GPS-disciplined rubidium frequency standards?The spec says: "Final accuracy will reach 2E-11 (0.0002Hz at 10MHz), within 24 hours"I have one and, when compared with my Z3801A, it measures ~3.8E-11 low in frequency. It is very stable, just off frequency.This frequency offset never changes. It is always low by about that amount, as best I can measure.As a test, I disconnected the GPS antenna and measured the frequency after an hour, or so, and found it had dropped to 5 or 6 E-11 low, so I guess the GPS adjustment of the rubidium is working. But it is not adjusting it to the right frequency, or not able to pull it as far as it needs to go (?)The issue I have now is that this does not meet its own spec by a factor of about 2. On the other hand, its notthatbad. Do I want to send it back to China and if they send me another one, will it be exactly the same?Ken

author: SilverSolder
author_rank: Super Contributor
timestamp: January 20, 2022, 03:17:21 am
content: How do you know which one of the two is actually right?

author: kpjamro
author_rank: Contributor
timestamp: January 20, 2022, 03:56:36 am
content: Good question. I have reasonable confidence that the Z3801A keeps its frequency within a 1E-12 range over the time periods involved.But you are right - how do I know the center frequency of the Z3801 is exactly what it says it is? The Z3801 is not supposed to gain or lose more than 1 microsecond per day while locked. That means its average frequency must be within +/- 1.157E-11 of the correct value. That is worst case and better than the 3.8E-11 difference I am seeing.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.Ken

author: edpalmer42
author_rank: Super Contributor
timestamp: January 20, 2022, 08:32:24 am
content: FYI, the graph you posted shows the stability, not accuracy, of 13 quartz oscillators that are in Z3801A GPSDOs that are*NOT*locked to GPS.  So that graph tells you nothing about the frequency error of the GPSDOs themselves.The frequency error of the Z3801A is spec'ed at only 1e-9 on the 10 MHz output averaged over one day. Like you, I suspect that it performs much better than that. But to actually test it you have to compare it to something of known accuracy. In this case, you'd have to use a Cesium or Hydrogen Maser or a calibrated Rb standard as a reference.I've attached a couple of graphs showing measurements I made comparing an FTS-4065A Cesium to my Z3801A. The measurements start at 10 sec. because below that, you're seeing the limitations of my measuring equipment.So, averaged over 100 sec., there were frequency variations in the range of +-1e-11 between my Z3801A and FTS-4065A. These variations could have been due to either device. More measurements with different devices would be required to narrow it down, but I suspect that both units are contributing noise to the result. Cesium is not known for being an extremely low noise technology and any GPSDO will show noise due to the random noise inherent in any system that uses radio waves that interact with the ionosphere.So if your Z3801A is showing good status information, i.e. low HUP, good signal strength, etc. then the frequency error you're seeing could be in the GPS-disciplined Rb unit. But it would require more equipment and more measurements to be certain.It's also possible that there is a frequency adjustment built-in to your unit. Does the manual discuss that?http://www.leapsecond.com/pages/z3801a-osc/

author: kpjamro
author_rank: Contributor
timestamp: January 20, 2022, 09:11:13 pm
content: EdThanks for the graph.Strangely enoughthe number you came up with is the same as my guess for the absolute accuracy of the 3801 (around 1E-11).My rational was that the 3801 will have some worst case difference in absolute time and then you add to that +/- the Allan deviation, which will be a function of observation time.If the Allan deviation is in the E-12 range (I think it is) and the absolute time difference is 1E-11, then the short term performance of the OCXO it could be ignored.My 3801 is presently showing an average TI error of +/- 500ps/24 hours, day after day. That tells me the average frequency and absolute time must be pretty good. I mean the average amount of correction applied during the course of a day (86,400 seconds) is 0.5 ns. That works out to a frequency fraction of 5.8e-15.So probably the Allan deviation *cannot* be ignored.Edit - I realize now that the lower numbers I was seeing were because the phase had actually slipped an extra full cycle so, for example, the slip was not 48 ns but 148 ns.Some folks on another reflector have suggested this may be a repeat of a bug in BG7TBL equipment ca 2015-2016. That bug was fixed with a firmware update.Ken

author: edpalmer42
author_rank: Super Contributor
timestamp: January 21, 2022, 05:33:52 am
content: Ken,I don't know your background so apologies if this is trivial for you. I'm playing to the audience. That's my story and I'm sticking to it!An ADev graph is a combination of the effects from the measurement system, DUT (Device under test) and the reference. In my graph, I removed the measurement system by starting at 10 sec. The time period from 10 sec. to 100 sec. is dominated by the FTS-4065A Cesium. After 1000 sec., the graph turns downward due to the effects of GPS. This will continue until you hit the noise floor of the system.If your reference was a nice stable, quiet OCXO or Rb, you'd see the effect of the OCXO in the Z3801A. Basically, the OCXO comes in from the left and then turns downward as it merges with the effect of GPS. As it is, the OCXO is almost totally hidden by the FTS-4065A.Oddly enough, when you're dealing with this kind of time-nuttery, the actual frequency error isn't high on the list of priorities because it's considered to be a trivial item that can be calibrated out. The stability, i.e. Allan Deviation is most important because it's a fundamental characteristic that can't be altered. But of course, it's much easier to wrap your head around the idea of a frequency error than the Allan Deviation.Regarding the BG7TBL issue, you didn't specify that this was the unit you had so I wasn't about to make assumptions. I know nothing about that unit other than the ebay ads state that it uses an X72 Rb standard. The X72 was available with a disciplining option so the unit could be using the X72 option or a system he created himself. AFAIK he's never publicly commented on any of his devices.Ed

author: kpjamro
author_rank: Contributor
timestamp: January 21, 2022, 03:00:37 pm
content: Again - thanks for comments. I understand that being off frequency does not impact on Allen Variance. But I would expect that GPS clocks should agree very closely when averaged over time. That means that any comparison may show + and - over some random period, but the swings should average out to zero. This one is just always slow. As a clock it would lose 1 second every 8 years. It appears that the GPS disciplining function is working - it is just disciplining it to the wrong frequency.I will eventually try doing an ADEV run on this once I find my little FA-2 frequency counter. If it were an HP boat anchor it would not get lostKen

author: edpalmer42
author_rank: Super Contributor
timestamp: January 21, 2022, 06:40:59 pm
content: Be careful with your terminology. In the early days of ADev people used variance, but that faded away. Today, nobody talks about variance. Everyone uses deviation.Variance = SQRT (Deviation)You might find that using a frequency counter to measure ADev is frustrating. Something in the math causes time interval-based measurements to drop twice as fast as frequency-based measurements. If you were measuring a non-disciplined quartz oscillator you could find that frequency-based measurements take so long to average-down that the oscillator's aging kicks in and your results look worse than they should. That shouldn't be a problem for a Rb measurement but it will take longer to reach time-nutty measurement levels. There have been a few discussions about this in other threads.Ed

author: SilverSolder
author_rank: Super Contributor
timestamp: January 21, 2022, 06:48:13 pm
content: Quote from: kpjamro on January 21, 2022, 03:00:37 pmIs that even theoretically possible? Seems to me that either it is disciplined, or undisciplined?

author: edpalmer42
author_rank: Super Contributor
timestamp: January 21, 2022, 07:37:28 pm
content: Quote from: SilverSolder on January 21, 2022, 06:48:13 pmWhether the disciplining function is analog or digital, it's possible to have an error creep into the system. For an analog system, you could have an offset voltage that you didn't compensate for. For a digital system, you could have an unexpected high or low propagation delay through a gate or a software instruction that takes more or less time than the book says it should. These could result in everything still being disciplined, but with a frequency or time offset.When you're working at the PPT (Parts per Trillion) level, weird stuff becomes normal.Ed

author: kpjamro
author_rank: Contributor
timestamp: January 22, 2022, 01:58:11 am
content: what I did was remove the GPS antenna. After an hour I checked and the frequency had drifted down a bit. After I reconnected the antenna, the frequency came back to where it has been all week. That tells me that the GPS-disciplining function is working.Ken

author: SilverSolder
author_rank: Super Contributor
timestamp: January 22, 2022, 02:25:09 am
content: It seems very weird indeed... you count the frequency of the local oscillator between each 1 second pulse, and somehow end up with a number that is, on average, too low.Wonder how you'd go about designing a circuit that was immune to that kind of thing. Maybe count the time between all edges of the 1s signal (both rising and falling) so the error averages out in the long run?

author: kpjamro
author_rank: Contributor
timestamp: January 22, 2022, 02:41:57 am
content: 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 ....KenKen

author: kpjamro
author_rank: Contributor
timestamp: January 22, 2022, 02:55:47 am
content: Not using 1 second pulses. What I am doing is displaying the 10 MHz sine wave on a scope. I sync the scope to my reference source. Then I watch the other trace drift (always to the right because it is slower). Using the calibrated cursor(s) on the scope, I can read out the accumulated phase difference (in ns) over some period of time.For example - 68.4 ns drift in 30 minutes = -3.8E-11 which is the average frequency difference as a fraction (seconds/second)If it drifted both faster and slower than the reference, then this test would only give you the net difference and not tell about the rate of deviation. But in this case the DUT is very stable and moves at a seemingly constant rate in one direction (as determined by eyeball).Ken

author: edpalmer42
author_rank: Super Contributor
timestamp: January 22, 2022, 02:56:42 am
content: QuoteYes, the disciplining function is working. That was never in question. SilverSolder was just asking if such a problem was possible and the answer is yes.It still isn't clear to me that there's even a problem. More measurements with more equipment would be necessary. You also haven't mentioned whether there's any fine tuning adjustments on your unit. It might just need a small tweak to set the frequency.AFAIK, the first version(s) of BG7TBL's GPSDO had a small frequency error. This was well documented. I later heard that the error had been fixed via an update to the software. The magnitude of the error was similar to the error you're seeing with the disciplined Rb. The software worked and disciplined the oscillator, but it was just a bit off frequency.I had an experience with a commercial GPS receiver board that had a similar frequency error. It turned out that the unit I purchased had a software version that used a frequency-locked loop instead of the more common phase-locked loop. A phase-locked loop requires a phase difference to generate an error signal that is used to lock the oscillator to the reference. A frequency-locked loop requires a frequency error for the same purpose. In my case, the vendor provided a different software load that used a phase-locked loop. This removed the frequency error.As I said, at the PPT level, weird stuff happens.Ed

author: edpalmer42
author_rank: Super Contributor
timestamp: January 22, 2022, 03:12:28 am
content: Quote from: kpjamro on January 22, 2022, 02:55:47 amWhile this works for 'normal' measurements I wouldn't trust it for 'time-nut' level measurements. What type of scope do you have? Typical hobbyist-level scopes can't be synced to an external standard and it may not even be possible to adjust the internal clock to improve the timing accuracy.The typical go-to equipment for time-nuts measurements is some flavor of time interval counter. As you go further down the rabbit hole, you outgrow that and either need to dig really deep into your wallet for some commercial equipment or construct some DIY equipment to allow you to make better measurements.Ed

author: kpjamro
author_rank: Contributor
timestamp: January 22, 2022, 01:57:34 pm
content: Thanks for all.I will pursue a double mixer / interval timer as a long-term project.just a reply to your questionThis is a 1 GS/s two channel digital scope. It cost all of $200 new.the scope is sync'd to channel 1 which is the 10 MHz sinewave of the Z3801A. It puts the zero crossing of that waveform dead-still in the center of the screen at 0.00 ns.then I watch the channel 2 trace (which is the DUT) and manually move an on-screen cursor to the zero crossing point. I start my stopwatch and record the zero crossing point some minutes later. The scope reads out the time in nanoseconds and it has two cursors. It is quite easy to measure the phase difference to within 0.1 ns. with this method. I just have to watch it so that it does not go beyond 100 ns (slipping a full cycle) because then the results are ambiguous - did it slip one cycle, two?. The unit I am testing takes about 43 minutes to slip a cycle. Like I said - this only works if the DUT is drifting in one direction steadily. And that is the situation I have.I can potentially resolve 0.1 ns in 2400 seconds: that is 4E-14. Almost a nutty-level.I asked the seller if there is anything I can adjust on the GNSS RB but he has no clue - If it is phase-locked to the GPS signal, in principle there should be nothing to do. Frequency-locked might be another story I suppose.Ken

author: edpalmer42
author_rank: Super Contributor
timestamp: January 22, 2022, 10:29:20 pm
content: Quote from: kpjamro on January 22, 2022, 01:57:34 pmAlthough a DMTD is the gold standard for a time-nut measurement system, you should consider an interim solution. A TAPR-TICC (https://tapr.org/product/tapr-ticc/) is a manageable cost device that will give you an ADev noise floor of 6e-11 @ 1 sec. You can make a lot of good measurements at that level. The graph I posted earlier was made with a Fluke PM-6681 which has a noise floor of about 5e-11 @ 1 sec. The TAPR-TICC can be used later with a DMTD front-end to get to crazy low numbers.There are also counters like the SR-620, HP 5370A, or perhaps the Wavecrest DTS-20xx that can get to levels of 2e-11 or 3e-11. They can be pricey and all the typical caveats apply when buying used boat anchors.Just to be clear, I'm not suggesting you buy the TAPR-TICC and later get one of the counters. Choose one or the other as a stepping stone to a DMTD system.QuoteWhy are you being so shy? You're claiming that your Rb-disciplined standard is off-frequency. You've discussed your procedure - which is non-standard. After being asked twice, I still don't know what scope you're using. That's not the way it's done Ken. Particularly when you're making a claim this serious, you should provide as much info as possible regarding the equipment you're measuring, the equipment you're using to make the measurements, and the methodology you're using. Then others can look at your info and see if they can find any problems with your work. You've done some of this, but not all.QuoteAnything in the e-14 range is most definitely a nutty-level. However, considering what you're measuring and how you're measuring it, it's likely at the too-good-to-be-true level.I also have a cheap 1 GSPS digital scope - a Hantek DSO5202B. It specs the delta time measurement error as: "1 sample interval + 100 ppm x reading +0.6 ns". TBH, I don't know how to translate that spec into an error value for your measurement. In any case, we should be using the spec for your scope. But running the measurement for 43 minutes makes me think the error is going to build to something horrible.My scope also specs frequency measurement as 6 digits of resolution and a *typical*, not worst case, error of 30 ppm. As you can see, it can't be considered to be a precision measurment device. Low end scopes never are.QuoteIf it's not in the manual, there's not much you can do. The X72 is a smart box with both hardware and software frequency adjustments, but I don't know if your unit has a way to access either of them.Ed

author: SilverSolder
author_rank: Super Contributor
timestamp: January 22, 2022, 11:21:44 pm
content: Using your scope, if you put a signal on channel A and another on Channel B, isn't it reasonable to expect the two channels are sampled at the same speed, so a comparison of frequency between the two is valid? I.e. does it really matter what sample frequency the scope has? You could even use an analog scope, and that kind of differential frequency estimate should work?I'm probably overlooking something obvious...

author: edpalmer42
author_rank: Super Contributor
timestamp: January 22, 2022, 11:54:40 pm
content: Quote from: SilverSolder on January 22, 2022, 11:21:44 pmI'm not worried about the sample frequency. Ken is talking about using cursors to read phase difference in nanoseconds between the channels. That measurement will be affected by the scope's accuracy. But he also mentioned the time to slip one cycle. That would be almost precisely 100 ns regardless of any error in the scope. Hmmmm. That sounds interesting.Of course, the fact that there *is* a cycle slip means that there is a frequency difference which is bad.Ken, earlier you talked about being deep in the weeds. Get used to it. We spend a lot of time there!Ed

author: SilverSolder
author_rank: Super Contributor
timestamp: January 23, 2022, 01:34:48 am
content: The weeds is where we are happiest, lol!

author: kpjamro
author_rank: Contributor
timestamp: January 23, 2022, 02:50:27 am
content: Yes - the only thing the scope is measuring is the slip (not the phase angle, but thechangein phase expressed in nanoseconds) between the two displayed sine waves.As long as the sample start time between channel 1 and channel 2 does not *vary* during the measurement period, then the measurement is good. They don't even have to start sampling at the same time, just not a *variable* times. Just now I tried applying the same signal to both channels and the ch1/ch2 waves stand perfectly still relative to each other. So no variation in sample start.Remember this is a digital scope driven by its own clock crystal. There is no calibration to be done or that *can* be done. Sampling accuracy is given in the product spec as 100PPM. In this exercise I am reading out values of 0.1 ns over a displayed field of 100 or 200 ns. That is only 1 part per 1000. So the scope has ~10x the accuracy that I need. Setting the cursors on two upslope zero crossings on the display shows exactly 100.00 ns difference. So the time measurement seems quite correct.It's nothing special, but if you want to see one, here it is:https://www.ebay.com/itm/324478069595I should mention that this is the digital equivalent of watching a Lissajous pattern on an XY scope. No one worries about the specs of the scope when doing that.Ken

author: edpalmer42
author_rank: Super Contributor
timestamp: January 23, 2022, 05:31:15 am
content: Quote from: kpjamro on January 23, 2022, 02:50:27 amWhen it counts nanoseconds, what is it using as its reference? Its internal clock - which is likely a simple oscillator, maybe a TCXO. If the clock is off frequency, the counted nanoseconds will be off too.QuoteA 100 PPM error over 100 ns. is 1e-11. That's about a quarter of your measured frequency error of 3.8e-11. Yes, I know I'm flipping between time and frequency, but you see my point. However, your idea to use the scope cursors to measure the period was excellent and shows that your scope is reasonably well-calibrated.I'm not trying to be a PITA here. There have been research papers written discussing how the internal architecture of actual high-end time interval counters affects the measurements! Switching from one model to another can give different results. Which one is right? Welcome to the wonderful world of PPT where you have to question everything! I've seen a new measurement technique that crashed and burned because, even though the results looked good and aligned with results from more standard methods, the originator couldn't provide a full-blown mathematical analysis to explain and justify his methodology.It's easy and correct to state that there's a frequency difference because the traces are drifting. The challenge is coming up with a number and being able to explain and defend that number.QuoteOkay. The thing is, no one has ever heard of that brand. No one knows if it's good or bad. No one will trust measurements made with that scope.QuoteNo one tries to make measurements at the PPT level with Lissajous patterns. They're adjusted for an approximately stationary pattern and that's good enough.I wondered if you could make your measurements by measuring the time for a cycle slip. This would completely remove the scope accuracy from the equation. You stated that it took about 43 minutes. To measure 43 minutes to an accuracy of 1e-11, you're looking at an accuracy of about 26 ns. So that's not going to work either.The bottom line here is that you've made some interesting measurements. You've learned some things about how fussy the measurements can be at the PPT level and the limitations of your measurement equipment. You've shown that there is a measurable frequency error between the disciplined Rb GPSDO and your Z3801A and that the error is likely in the Rb unit.So what will you do next? Improve your measurement capability? Buy a stand-alone Rb unit and compare it to the Z3801A and the Disciplined Rb? Buy one or more (always more!) OCXOs to see how they compare? All of the above? Throw all this crap out the window and move on??The Rabbit Hole awaits .........Ed

author: Leo Bodnar
author_rank: Frequent Contributor
timestamp: January 23, 2022, 10:21:23 am
content: Ed,Long time (about 15 years) ago I have used similar setup with multichannel scope configured to trigger on one source's leading edge and measuring delay from that edge to the second's source leading edge. It does work. Moreover, if you set it up TimeLab correctly (i.e. give it the signal frequency) it will magically deal with phase rollovers for you.I have used SCPI to automatically sample the results every 100ms or so (they were two 10MHz signals.)One issue I have encountered was when the delay between two edges was less than +-0.5ns (from my memory) it would be reported as 0ns by the scope. I am not sure (or care) about the reasons - I have just automatically scaled up the timebase via SCPI to increase the resolution (and scale down this problem.)Similar result can be achieved by setting the scope to multiple event captures and logging the delays to a USB stick - if the scope allows that.It did work but it's clunky and inelegant. But gets you what looks like ADEV chart in TimeLab.I think this might be the cheapest way to get ADEV chart in a lab that already has a scope and SCPI/GPIB automation in the absence of any other timing tools.Of course you would not use it in place of proper testing which is reasonably affordable today.By triggering on one signal and observing the other, Ken, basically, asserts that if he sees two signals on the scope drift apart by 100ns in an hour he is reasonably confident that they did in reality. Of course, the accuracy of the scope is not perfect, but I would tend to agree that in that case you can reasonably trust the scope. Otherwise, it is not a scope, right?If your scope timebase accuracy is 100ppm and you have detected 100ns drift over 1 hour then, assuming one of the signals is your absolute time reference, the error of absolute time measurement is below 1E-14, right?CheersLeoQuote from: edpalmer42 on January 22, 2022, 11:54:40 pm

author: edpalmer42
author_rank: Super Contributor
timestamp: January 24, 2022, 07:43:41 am
content: Quote from: Leo Bodnar on January 23, 2022, 10:21:23 amWould you publish that data?QuoteEven some high-end counters suffer from that problem. One of many potholes we have to navigate.QuoteThere's no question that Ken's methodology is sound. I've already stated that. But the equipment he's using is seriously holding him back. It's easy to say he's found a frequency error, the problem comes when he tries to hang a number on that error that will be accepted as credible.Back in the day, a scope was a general-purpose piece of equipment that was *never* considered to be a precision device. As technology improved, it became possible to build more precision into the box. Today's high end scopes can hold their own against all but the most specialized and expensive devices. The situation with hobbyist scopes isn't nearly as clearcut.QuoteOn paper, yes. As I've said, for lower precision measurements it's fine. But for time-nuts measurements, as you said above, "you would not use it in place of proper testing which is reasonably affordable today." I've been trying to figure out a way that Ken could modify his methodology to improve the credibility of his results with the equipment he's got, but I'm coming up empty.Ed

author: Leo Bodnar
author_rank: Frequent Contributor
timestamp: January 24, 2022, 09:37:48 am
content: Quote from: edpalmer42 on January 24, 2022, 07:43:41 amI 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

author: edpalmer42
author_rank: Super Contributor
timestamp: January 24, 2022, 07:28:40 pm
content: Quote from: kpjamro on January 22, 2022, 02:41:57 amKen,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 counterwith 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

author: SilverSolder
author_rank: Super Contributor
timestamp: January 24, 2022, 09:35:49 pm
content: Quote from: edpalmer42 on January 24, 2022, 07:28:40 pmIf 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...

author: edpalmer42
author_rank: Super Contributor
timestamp: January 24, 2022, 11:02:22 pm
content: Quote from: SilverSolder on January 24, 2022, 09:35:49 pmYes, 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

author: SilverSolder
author_rank: Super Contributor
timestamp: January 24, 2022, 11:36:54 pm
content: Quote from: edpalmer42 on January 24, 2022, 11:02:22 pmI 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

author: edpalmer42
author_rank: Super Contributor
timestamp: January 25, 2022, 02:50:18 am
content: Quote from: SilverSolder on January 24, 2022, 11:36:54 pmAh. 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 ustime-idiotstime-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

author: edpalmer42
author_rank: Super Contributor
timestamp: January 27, 2022, 09:27:40 pm
content: 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

author: FriedLogic
author_rank: Regular Contributor
timestamp: January 29, 2022, 11:42:29 pm
content: Quote from: kpjamro on January 20, 2022, 03:56:36 amThat'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.

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: February 08, 2022, 04:28:52 am
content: Quote from: FriedLogic on January 29, 2022, 11:42:29 pmI'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.

author: testpoint1
author_rank: Frequent Contributor
timestamp: February 10, 2022, 10:01:58 pm
content: 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

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: February 10, 2022, 11:23:04 pm
content: Quote from: testpoint1 on February 10, 2022, 10:01:58 pmYes, 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".

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: May 14, 2022, 03:22:38 am
content: 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.

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: May 14, 2022, 08:09:37 pm
content: 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 AWGThe 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.

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: May 14, 2022, 08:12:51 pm
content: 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).

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: September 01, 2024, 05:03:53 pm
content: 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 +/- 5mKdue to the physics package ovens' control activityfrom 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.

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: November 26, 2024, 07:14:25 pm
content: 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.

author: Solder_Junkie
author_rank: Frequent Contributor
timestamp: November 26, 2024, 09:08:39 pm
content: 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

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: November 27, 2024, 01:30:59 am
content: Quote from: Solder_Junkie on November 26, 2024, 09:08:39 pmYes, 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/#msg3714325Hopefully, 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 crossedOnly 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.

author: Solder_Junkie
author_rank: Frequent Contributor
timestamp: November 27, 2024, 09:45:39 am
content: 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 enoughSJ

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: November 28, 2024, 03:24:32 am
content: Quote from: Solder_Junkie on November 27, 2024, 09:45:39 amActually, 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).Quote from: Solder_Junkie on November 27, 2024, 09:45:39 amJust 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/#msg1493431That 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.Quote from: Solder_Junkie on November 27, 2024, 09:45:39 amIt 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"Quote from: Solder_Junkie on November 27, 2024, 09:45:39 amWell, 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.

author: bingo600
author_rank: Super Contributor
timestamp: November 28, 2024, 04:54:58 am
content: Quote from: Johnny B Good on November 27, 2024, 01:30:59 amJohn will you "snap a few pics" of exchanging the Tant's ?And maybe make a short comp replacement guide/Bingo

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: November 28, 2024, 10:49:50 pm
content: Quote from: bingo600 on November 28, 2024, 04:54:58 amHi 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.

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: December 11, 2024, 11:26:47 pm
content: 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).

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: December 12, 2024, 12:10:50 am
content: 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....

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: December 12, 2024, 12:58:30 am
content: 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 alignmentafterrefitting 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:5203:4913:1912:00A 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.

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: December 12, 2024, 07:28:16 pm
content: I see there is still some interest in the use of rubidium frequency standards from the number of views all those images I'd attached to each post had gotten.I have a few points to make, the first being that, in view of the exquisite sensitivity of the crystal oscillator to mechanical excitation demonstrated by all of these LPROs (and even the SA22.C according to another poster - I've yet to test this on my own unit), it's not a good idea to rigidly attach a cooling fan to a heatsink that's also firmly mounted onto a heatspreader to which the rubidium oscillator is in firm contact with.The effect of random vibrations from the cooling fan may not be obvious in a scope trace (although likely to raise close in sideband noise that can be observed with a spectrum analyser) until you improve the cooling algorithm used to adjust the fan speed with so much precision and stability as to achieve base plate temperature regulation to within +/- 1mK of the set temperature.In this case, it then becomes entirely possible to phase modulate the crystal oscillator at precisely the wrong frequency for seconds long periods where it can then destabilise the corrective action by the physics package (153Hz adjustment rate AFAICR) leading to the crazy wobble of instability I'd observed.In hindsight, I'd been catching glimpses of this effect during the progression of my project all along. It was just that initially they had been so brief it had been a case of rubbing my eyes to check that it wasn't an optical illusion of some sort that I'd seen. Of course, over the now four year long project's development, this effect became ever more obvious to the point about a year back, I could no longer pass it off as an 'optical illusion'.In perfecting my temperature control algorithm to the point where it could maintain the temperature of the base plate to within less than a milli-Kelvin from the set point, I had become "Hoist by my own petard".All it took to point me to the fan as the culprit was the use of those replacement LPRO 101s I'd acquired. They'd shown no sign of this issue when parked on top of my rubidium frequency standard as a convenient temporary heatsink for their initial testing so it was a bit of a shock to see them behaving exactly the same as my original LPRO once mounted into my rubidium reference to allow me to check their lamp voltage.This left me with only one conclusion, namely that the fan cooling was the source of my mystery wobble in some way, leaving me to ponder just exactly what that mechanism might be.The most bleedin' obvious in hindsight cause being the last possibility I'd considered after disproving electrical noise imposed on the supply by the fan's commutation pulses by fitting a 16v 10mF capacitor across the fan connection to the driver board and magnetic interference from the unshielded 5.6mH filter choke or leakage from the fan's rotor by using a powerful HDD voice coil actuator magnet with a 2mm thick perspex shim to avoid the risk of saturating the mu-metal shield and magging it up, where only by careful placement, could I detect any effect on the ruby's output frequency (and that, despite the perspex shim where the magnet was still quite strongly attracted to the mu-metal cover.Only after discounting those two possibilities did I finally (like Sherlock Holmes) accept the one and only remaining possibility and removed the fan retaining screws for a final test did I finally solved the mystery. The aperture in the polystyrene foam plenum divider through which the fan poked, supported the fan in place to allow such a quick temporary test.The fan was a snug enough fit to hold it in place but I wrapped a couple of turns of electrical insulating tape around it afterwards to ensure a tighter friction fit to make it a more permanent fix.The second point being in regard of those A23A3 adapted LPRO-101 versions, namely which market segment they're targeting. It can't be the telecoms market since there's no means of disciplining it from a gpsdo via the external C field pin nor any means to monitor its health status via the lamp and crystal voltage monitoring pins, just an indication of atomic lock (BITE) which begs the question as to who would be satisfied with such a frequency reference oscillator?Oh hang about!I'd completely forgotten about the Audiophool market! Couldthatbe the target market demographic do you think? Now that I've remembered the phrase, "An audiophool and his money are soon parted" the whole over-hyped description and premium pricing certainly fit the bill (although in this case, the pricing probably undercuts the more regular purveyors of such audio snake oil).Whilst writing this post, I noticed an upturn in the drift rate between the rubidium and the gpsdo so decided to wait for the full 24 hour run to complete before posting the final two screenshots. This seems to mimic previous behavior which I now rather think is due to an ageing rate of circa -2μHz per day calculated from the 10 year ageing data in the Datum spec sheet for the LPRO.I'd suspected as much with the MK II gpsdo results but that 33ns diurnal phase wobble had made it rather difficult to pick up on. The upgraded MK III with its ZED9-FT gps module (also a G3RUH type) has made this effect rather more obvious. I guess it won't be too long before I add the RTC module to the electronic baggage and rustle up another bunch of code to mitigate this ageing issue.Anyway, here's the last two screenshots, timed at 18:20 and 19:00 this evening.

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: December 15, 2024, 09:20:41 pm
content: Here's another six screenshots, taken over the past four hours from 12:12 this afternoon. The first one shows the accumulated phase drift over the previous 24 hours. The second one was recorded within half a minute after clearing the persistence to start yet another 24 hour run.I'd adjusted the LPRO's frequency by +3μHz at the start of the previous run and by +2μHz at the start of today's run which was under heavy overcast conditions which had cleared up by the time of the fourth screenshot. It was the first time in over a week that I was able to see a clear blue sky and contrails of passing jet liners. Indeed, also my first view of a glorious red sunset in over a week!The screenshots seem to reflect that change in cloud cover. The extra propagation delay on the gps signals due to the earlier cloud cover had been reduced by some 2 or 3 ns, hence the apparent 2 ns 'backward' step on the rubidium trace.PS All images had been taken at hourly intervals (12 minutes past the hour) except for the fourth image which had been taken between those hourly images at 14:36 when I'd noticed the disappearance of the cloud cover.

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: January 02, 2025, 08:43:28 pm
content: For anyone interested, I've just posted an update on my RFS project here:https://www.eevblog.com/forum/rf-microwave/gpsdo-phase-between-pps-and-clock/msg5768749/#msg5768749Included in the attachments is a 12 hour movie condensed into a 2 minute timelapse showing ZED9FT and M8T based G3RUH type gpsdos along with the RFS and a spare LPRO mounted onto a passive heatsink with, naturally, the ZED9FT triggering the display as described.

author: bingo600
author_rank: Super Contributor
timestamp: January 02, 2025, 09:02:47 pm
content: Hi JohnThanx for the "Tant pics"And nice trackdown of the "Fan vibrarion" issue

author: Johnny B Good
author_rank: Frequent Contributor
timestamp: January 02, 2025, 10:21:55 pm
content: Quote from: bingo600 on January 02, 2025, 09:02:47 pmYou're welcome.That repair turned into a bit of an epic adventure and in the end, resulted in no discernible improvement, just a bit of grief in almost totally destroying the replacement trimpot I'd fitted less than 12 months ago.The only interesting finding being that the original tantalum caps had remained in a remarkably good state of health despite the generally accepted 'wisdumb' that they'd be totally shagged after a decade's worth of service life.I've put that original unit to one side until I can remedy my previous (in hindsight) ill advised adjustments to the lamp exciter oscillator tuning to increase the lamp voltage from its original 4.9ish volts to a more reasonable 5.3ish volts.It does seem to be less stable than the replacements when it comes to percussive testing. Without the fan induced vibrations, I'd expect it to recover from a percussively induced loss of atomic lock without any need to power cycle it. I can't recall whether or not I'd tested this, so that remains something for me to explicitly test for when I do finally get around to it.