GNSS RB (chinese)

[kpjamro]

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 not that bad. Do I want to send it back to China and if they send me another one, will it be exactly the same?


Ken
 

 

[SilverSolder]

How do you know which one of the two is actually right?

[kpjamro]

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

[edpalmer42]

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. [1]  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?

[1] http://www.leapsecond.com/pages/z3801a-osc/

[kpjamro]

Ed
Thanks for the graph.
Strangely enough  the 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

[edpalmer42]

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

[kpjamro]

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 lost 



Ken

[edpalmer42]

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

[SilverSolder]

[...] It appears that the GPS disciplining function is working - it is just disciplining it to the wrong frequency. [...]

Is that even theoretically possible?  Seems to me that either it is disciplined, or undisciplined?

[edpalmer42]

[...] It appears that the GPS disciplining function is working - it is just disciplining it to the wrong frequency. [...]

Is that even theoretically possible?  Seems to me that either it is disciplined, or undisciplined?

Whether 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

[kpjamro]

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

[SilverSolder]

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?

[kpjamro]

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


Ken

[kpjamro]

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

[edpalmer42]

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.

Yes, 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

[edpalmer42]

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

While 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

[kpjamro]

Thanks for all.
I will pursue a double mixer / interval timer as a long-term project.

just a reply to your question

This 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

[edpalmer42]

Thanks for all.
I will pursue a double mixer / interval timer as a long-term project.

Although 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.

just a reply to your question

This is a 1 GS/s two channel digital scope. It cost all of $200 new.

Why 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.

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.

Anything 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.

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.

If 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

[SilverSolder]

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...

[edpalmer42]

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...

I'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

[SilverSolder]

The weeds is where we are happiest, lol! 

[kpjamro]

Yes - the only thing the scope is measuring is the slip (not the phase angle, but the change in 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/324478069595

I 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

[edpalmer42]

Yes - the only thing the scope is measuring is the slip (not the phase angle, but the change in phase expressed in nanoseconds) between the two displayed sine waves.

When 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.

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.

A 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.

It's nothing special, but if you want to see one, here it is:     https://www.ebay.com/itm/324478069595

Okay.  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.

I 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.

No 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

[Leo Bodnar]

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?

Cheers
Leo

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.

[edpalmer42]

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

Would you publish that data?

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

Even some high-end counters suffer from that problem.  One of many potholes we have to navigate.

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?

There'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.

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?

On 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