We have some wonderful old Tek 11801 scopes. The later versions will measure rising-edge RMS jitter of a vertical input step relative to the external trigger. But maybe that trigger has jitter. I'd rather scope two vertical inputs and compute the jitter between them. The two signals would be sampled exactly simultaneously and would be expected to have low vertical noise. We can RS232 interface to the scope and extract a list like time vert1 vert2 ... which delivers data from the screen display buffer; both edges have to be on the screen. Maybe 1000 points. So, what's the math? One can measure the two jitters separately, each relative to trigger, and do the sqrt-of-diff-of-squares calc, but that gets nasty fast. I'd rather use the two channel samples. Modern digital scopes can internal trigger on one channel, which I assume is actually computed from the acquired vertical samples. That typically has far less jitter than using external trigger which typically rounds to one sample clock period. Cheapskates rarely interpolate the trigger time. -- Father Brown's figure remained quite dark and still; but in that instant he had lost his head. His head was always most valuable when he had lost it.
little math thing
Started by ●December 1, 2021
Reply by ●December 1, 20212021-12-01
On a sunny day (Wed, 01 Dec 2021 08:55:43 -0800) it happened jlarkin@highlandsniptechnology.com wrote in <q79fqg55ua4i29o6r3kqs6lk0r1n27q2uq@4ax.com>:>We have some wonderful old Tek 11801 scopes. The later versions will >measure rising-edge RMS jitter of a vertical input step relative to >the external trigger. But maybe that trigger has jitter. > >I'd rather scope two vertical inputs and compute the jitter between >them. The two signals would be sampled exactly simultaneously and >would be expected to have low vertical noise. > >We can RS232 interface to the scope and extract a list like > >time vert1 vert2 >... > >which delivers data from the screen display buffer; both edges have to >be on the screen. Maybe 1000 points. > >So, what's the math? > >One can measure the two jitters separately, each relative to trigger, >and do the sqrt-of-diff-of-squares calc, but that gets nasty fast. I'd >rather use the two channel samples. > >Modern digital scopes can internal trigger on one channel, which I >assume is actually computed from the acquired vertical samples. That >typically has far less jitter than using external trigger which >typically rounds to one sample clock period. Cheapskates rarely >interpolate the trigger time.Not sure what you want, but if I wanted to know jitter between 2 signals I would put both into an XOR gate or 'phase compararor' if you want, Changes in the XOR output can then be low passed and the changes in amplitude are then a measure for the jitter. That is as old as the world? I do not trust digital scopes not even for the simplest things. ??
Reply by ●December 1, 20212021-12-01
On Wed, 01 Dec 2021 17:15:16 GMT, Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> wrote:>On a sunny day (Wed, 01 Dec 2021 08:55:43 -0800) it happened >jlarkin@highlandsniptechnology.com wrote in ><q79fqg55ua4i29o6r3kqs6lk0r1n27q2uq@4ax.com>: > >>We have some wonderful old Tek 11801 scopes. The later versions will >>measure rising-edge RMS jitter of a vertical input step relative to >>the external trigger. But maybe that trigger has jitter. >> >>I'd rather scope two vertical inputs and compute the jitter between >>them. The two signals would be sampled exactly simultaneously and >>would be expected to have low vertical noise. >> >>We can RS232 interface to the scope and extract a list like >> >>time vert1 vert2 >>... >> >>which delivers data from the screen display buffer; both edges have to >>be on the screen. Maybe 1000 points. >> >>So, what's the math? >> >>One can measure the two jitters separately, each relative to trigger, >>and do the sqrt-of-diff-of-squares calc, but that gets nasty fast. I'd >>rather use the two channel samples. >> >>Modern digital scopes can internal trigger on one channel, which I >>assume is actually computed from the acquired vertical samples. That >>typically has far less jitter than using external trigger which >>typically rounds to one sample clock period. Cheapskates rarely >>interpolate the trigger time. > >Not sure what you want, >but if I wanted to know jitter between 2 signals I would put both into an XOR gate or 'phase compararor' if you want, >Changes in the XOR output can then be low passed and the changes in amplitude are then a measure for the jitter. >That is as old as the world? >I do not trust digital scopes not even for the simplest things. >??I want to do this in a 10 GHz bandwidth, and that scope will be part of our test system anyhow. We automate testing and archive test reports. I haven't used an analog scope in a decade or two. The 11801s are hybrids, digital scopes with (vertical raster scan) CRTs. One of my guys has a 7104 in his office, the 1 GHz microchannel-plate analog scope. He still likes it. That's the last analog scope anybody uses. -- Father Brown's figure remained quite dark and still; but in that instant he had lost his head. His head was always most valuable when he had lost it.
Reply by ●December 1, 20212021-12-01
jlarkin@highlandsniptechnology.com wrote:> We have some wonderful old Tek 11801 scopes. The later versions will > measure rising-edge RMS jitter of a vertical input step relative to > the external trigger. But maybe that trigger has jitter. > > I'd rather scope two vertical inputs and compute the jitter between > them. The two signals would be sampled exactly simultaneously and > would be expected to have low vertical noise. > > We can RS232 interface to the scope and extract a list like > > time vert1 vert2 > ... > > which delivers data from the screen display buffer; both edges have to > be on the screen. Maybe 1000 points. > > So, what's the math? > > One can measure the two jitters separately, each relative to trigger, > and do the sqrt-of-diff-of-squares calc, but that gets nasty fast. I'd > rather use the two channel samples. > > Modern digital scopes can internal trigger on one channel, which I > assume is actually computed from the acquired vertical samples. That > typically has far less jitter than using external trigger which > typically rounds to one sample clock period. Cheapskates rarely > interpolate the trigger time.In a sampling scope, you get only one point per trigger, so each point on the screen has its own independent instance of the jitter. If the amplitudes are stable, just threshold both and look at the jitter in the difference of the threshold-crossing times. If the jitter is much less than the rise time, you can adjust the crossing times by taking the nearest point and computing delta_t = (V(n)-Vth)/(dV/dt). That's probably what I'd do to start with. You can refine the threshold crossing times by fitting a line to the nearest 10 samples (say), computing where that line crosses the threshold, and doing as above for several data points per trace. The jitter is the spread of the samples vs. the best fit line near the threshold. Using samples to compute the line will cause the jitter to be underestimated by a little bit. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●December 2, 20212021-12-02
On Wednesday, December 1, 2021 at 8:55:52 AM UTC-8, jla...@highlandsniptechnology.com wrote:> We have some wonderful old Tek 11801 scopes. The later versions will > measure rising-edge RMS jitter of a vertical input step relative to > the external trigger. But maybe that trigger has jitter. > > I'd rather scope two vertical inputs and compute the jitter between > them. The two signals would be sampled exactly simultaneously and > would be expected to have low vertical noise. > > We can RS232 interface to the scope and extract a list like > > time vert1 vert2 > ... > > which delivers data from the screen display buffer; both edges have to > be on the screen. Maybe 1000 points. > > So, what's the math?You want a polygon area calculation. Assuming both signals start at zero, and rise to 3.3V, the time between them is the area (in volt-seconds) bounded by the two traces divided by the (3.3V - 0) range. To compute the area of a polygon, you just list the points in clockwise-around-the-edge order, and take the first three points, calculate that triangle area. If the triangle sweeps clockwise from point two to point three, it's positive area, otherwise negative. Then calculate triangle area for points one, three, four... then one, four, five... and when you get back to the origin, you're done. The 'clockwise-around-the-edge assumes that some zero-size triangles occur when both signals are pre-edge at 0V, and when both signals are post-edge at 3.3V,
Reply by ●December 2, 20212021-12-02
On 01/12/2021 18:32, Phil Hobbs wrote:> jlarkin@highlandsniptechnology.com wrote: >> We have some wonderful old Tek 11801 scopes. The later versions will >> measure rising-edge RMS jitter of a vertical input step relative to >> the external trigger. But maybe that trigger has jitter. >> >> I'd rather scope two vertical inputs and compute the jitter between >> them. The two signals would be sampled exactly simultaneously and >> would be expected to have low vertical noise. >> >> We can RS232 interface to the scope and extract a list like >> >> time vert1 vert2 >> ... >> >> which delivers data from the screen display buffer; both edges have to >> be on the screen. Maybe 1000 points. >> >> So, what's the math? >> >> One can measure the two jitters separately, each relative to trigger, >> and do the sqrt-of-diff-of-squares calc, but that gets nasty fast. I'd >> rather use the two channel samples. >> >> Modern digital scopes can internal trigger on one channel, which I >> assume is actually computed from the acquired vertical samples. That >> typically has far less jitter than using external trigger which >> typically rounds to one sample clock period. Cheapskates rarely >> interpolate the trigger time. > In a sampling scope, you get only one point per trigger, so each point > on the screen has its own independent instance of the jitter. > > If the amplitudes are stable, just threshold both and look at the jitter > in the difference of the threshold-crossing times. If the jitter is > much less than the rise time, you can adjust the crossing times by > taking the nearest point and computing > > delta_t = (V(n)-Vth)/(dV/dt). > > That's probably what I'd do to start with. > > You can refine the threshold crossing times by fitting a line to the > nearest 10 samples (say), computing where that line crosses the > threshold, and doing as above for several data points per trace. The > jitter is the spread of the samples vs. the best fit line near the > threshold. Using samples to compute the line will cause the jitter to > be underestimated by a little bit.I think I'd be inclined to go for pairs of points either side of the steepest point on the curve working outward to make a few independent estimates of the crossing point. That should give you a feel for how much jitter is in the sampling arm as well as in the signal source. Hopefully one of them will dominate but if not at least you know. Calibrating it by deliberately slugging the rise time with a small load and seeing if you can recover the right answer would be a good test. -- Regards, Martin Brown
Reply by ●December 2, 20212021-12-02
On Thu, 2 Dec 2021 11:40:14 +0000, Martin Brown <'''newspam'''@nonad.co.uk> wrote:>On 01/12/2021 18:32, Phil Hobbs wrote: >> jlarkin@highlandsniptechnology.com wrote: >>> We have some wonderful old Tek 11801 scopes. The later versions will >>> measure rising-edge RMS jitter of a vertical input step relative to >>> the external trigger. But maybe that trigger has jitter. >>> >>> I'd rather scope two vertical inputs and compute the jitter between >>> them. The two signals would be sampled exactly simultaneously and >>> would be expected to have low vertical noise. >>> >>> We can RS232 interface to the scope and extract a list like >>> >>> time� vert1� vert2 >>> ... >>> >>> which delivers data from the screen display buffer; both edges have to >>> be on the screen. Maybe 1000 points. >>> >>> So, what's the math? >>> >>> One can measure the two jitters separately, each relative to trigger, >>> and do the sqrt-of-diff-of-squares calc, but that gets nasty fast. I'd >>> rather use the two channel samples. >>> >>> Modern digital scopes can internal trigger on one channel, which I >>> assume is actually computed from the acquired vertical samples. That >>> typically has far less jitter than using external trigger which >>> typically rounds to one sample clock period. Cheapskates rarely >>> interpolate the trigger time. >> In a sampling scope, you get only one point per trigger, so each point >> on the screen has its own independent instance of the jitter. >> >> If the amplitudes are stable, just threshold both and look at the jitter >> in the difference of the threshold-crossing times.� If the jitter is >> much less than the rise time, you can adjust the crossing times by >> taking the nearest point and computing >> >> delta_t = (V(n)-Vth)/(dV/dt). >> >> That's probably what I'd do to start with. >> >> You can refine the threshold crossing times by fitting a line to the >> nearest 10 samples (say), computing where that line crosses the >> threshold, and doing as above for several data points per trace.� The >> jitter is the spread of the samples vs. the best fit line near the >> threshold.� Using samples to compute the line will cause the jitter to >> be underestimated by a little bit. > >I think I'd be inclined to go for pairs of points either side of the >steepest point on the curve working outward to make a few independent >estimates of the crossing point. That should give you a feel for how >much jitter is in the sampling arm as well as in the signal source. > >Hopefully one of them will dominate but if not at least you know. > >Calibrating it by deliberately slugging the rise time with a small load >and seeing if you can recover the right answer would be a good test.The problem is that a dual-channel sampling scope takes one pair of points per trigger. A matched pair has the same time from trigger but different amplitudes. If you work from pairs, the only information is the voltages. I guess one could compute the local, average slopes and translate the voltage difference into a time difference, and work with those numbers. Sort of what Phil suggested. It's easy to compute the RMS jitter of each signal relative to the external trigger - the later rev 11801's did that - and compute channel-to-channel jitter from those measurements. In moderation, like down to maybe half the scope's native jitter. This is from a little Basic program that slurped a waveform from an 11801 and computed jitter from trigger. https://www.dropbox.com/s/jf224rd7uyxs1t8/Jitter2.gif?raw=1 Estimated scope jitter was entered manually, and it mathed that out. -- Father Brown's figure remained quite dark and still; but in that instant he had lost his head. His head was always most valuable when he had lost it.
