little math thing...

[server]

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.

 

[Jan Panteltje]

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

 

[server]

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.

 

[Phil Hobbs]

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

 

[whit3rd]

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,

 

[Martin Brown]

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

 

[server]

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