Pocket-Sized 6 GHz 1 TS/s ET Scope

[joeqsmith]

We found a simple, bias-free way to remove 90% of the speckle. Essentially, we just enforce monotonicity on each CDF. In detail, any neighboring pair of points that are in the wrong order are set to their average. This might need to be repeated a few times until the entire CDF is monotonic.

From what I can tell, the latest manual makes no mention of this.   

So, if CDF(0) > CDF(1), both CDF(0 &1) are set to the average of CDF (0&1).   We then check the new value of CDF(1) with CDF(2).  Once all are checked, we repeat this entire process until they are in order.   Then we calculate the new PDF.

For example, CDF  0, 0.1, 0.05, 0.2    Final CDF is 0, 0.075, 0.075, 0.2,     PDF is then calculated from final CDF. 

[SJL-Instruments]

From what I can tell, the latest manual makes no mention of this.   

So, if CDF(0) > CDF(1), both CDF(0 &1) are set to the average of CDF (0&1).   We then check the new value of CDF(1) with CDF(2).  Once all are checked, we repeat this entire process until they are in order.   Then we calculate the new PDF.

Yes, that's correct. We'll document this in the next manual revision. If you want it to converge faster, you can overcompensate slightly: set CDF(0) to (average - delta) and CDF(1) to (average + delta) where delta is some fraction of CDF(0) - CDF(1).
Essentially you're just removing all of the negative probability densities in the PDF in the minimally invasive way.

[joeqsmith]

Shown using the same setup as previous plot with your software.   For those wanting to try their own thing,  attached Zip contains CSV file for the voltage and CDF pairs.   

...where delta is some fraction of CDF(0) - CDF(1).

Interesting is how much of a difference using 50% vs 40% vs 30% makes in how well it de-speckles.

[PHOStronics]

Is the reason the monotonicity constraint is not directly part of the gausian process regression just implementation complexity, or is there a reason not to do it?
You mentioned you enforce it only in post processing but that seems like something that would aid in reducing the space of possible functions, and thereby alter the actual amount of information potentially gained from a trial voltage chosen

[SJL-Instruments]

Is the reason the monotonicity constraint is not directly part of the gausian process regression just implementation complexity, or is there a reason not to do it?
You mentioned you enforce it only in post processing but that seems like something that would aid in reducing the space of possible functions, and thereby alter the actual amount of information potentially gained from a trial voltage chosen

The monotonicity violations are just a result of the inherent statistical noise during sampling and are unrelated to the choice of query voltages. The monotonicity condition applies only to the "true" CDF values and not to the sampled CDF values, so you cannot assume this during acquisition.

[joeqsmith]

Sorry about the long delay but finally rebuilt the FPGA to further even out the distribution so we can see all of the level state changes.  Showing with 40k trigger min/max PAM4 with brightness set to max and something reasonable.   Zoomed into the transition area.  This was after a few hours of warmup.  At 128 pts/div, it took several minutes to collect this data  and initially the drift was really messing with the measurements.  Big improvement in the noise but is it ever slow.   

I tried several approaches to further reduce the speckles.  I mentioned looking at the histograms and doing a window.  One used a weighted filter.  Then there was a modified conways life sort of technique.  They all of course strip out good data.   Looking forward to the new firmware.   

[joeqsmith]

With the brightness set to the min, all of the transitions are still buried in the noise.  Guessing that the increase in samples per CDF will greatly improve this. 

[SJL-Instruments]

Sorry about the long delay but finally rebuilt the FPGA to further even out the distribution so we can see all of the level state changes.  Showing with 40k trigger min/max PAM4 with brightness set to max and something reasonable.   Zoomed into the transition area.  This was after a few hours of warmup.  At 128 pts/div, it took several minutes to collect this data  and initially the drift was really messing with the measurements.  Big improvement in the noise but is it ever slow.   

To clarify, is this with 40k Triggers/Sample min/max with 100 samples/CDF?

With the brightness set to the min, all of the transitions are still buried in the noise.  Guessing that the increase in samples per CDF will greatly improve this. 

With 40k triggers/sample, the speckles are likely dominated by CDF quantization noise (will be fixed in v14). Increasing samples per CDF (if below 100) will also help, but 100 should be sufficient for PAM4.

Some updates on v14 firmware: USB DFU is working. We are in the process of offloading more work onto the FPGA for faster acquisition. This is quite a large rewrite, so we will likely spend 2 or more weeks performing stability and regression tests. If all goes well, it should still be on schedule for end of month.

[joeqsmith]

To clarify, is this with 40k Triggers/Sample min/max with 100 samples/CDF?

That is correct. 

Some updates on v14 firmware: USB DFU is working. We are in the process of offloading more work onto the FPGA for faster acquisition. This is quite a large rewrite, so we will likely spend 2 or more weeks performing stability and regression tests. If all goes well, it should still be on schedule for end of month.

I am not sure how you define firmware.   Can you program both the microcontroller as well as the FPGA over USB with this new version? 

I'm up for fastest acquisition.   I wouldn't be surprised if those previous plots didn't require an hour  to collect one sweep.   I suspect some of the smearing (4 men enter, five exit) isn't from the scopes trigger drifting with temperature, shifting time.     

[SJL-Instruments]

I am not sure how you define firmware.   Can you program both the microcontroller as well as the FPGA over USB with this new version? 

Yes, both the FPGA and MCU can be reprogrammed via USB. We will add an "Update Firmware" menu option to the software that will just require selecting a single .bin file. Ideally, should never need to open the case after v14.

I'm up for fastest acquisition.   I wouldn't be surprised if those previous plots didn't require an hour  to collect one sweep.   I suspect some of the smearing (4 men enter, five exit) isn't from the scopes trigger drifting with temperature, shifting time.     

The ideal sweep time can be calculated from Section 2.2.2. Our goal is for v14 firmware to be within 20% of the theoretical minimum across all parameter ranges.

[joeqsmith]

Same signals applied to my 20 year old LeCroy waveblunder 64Xi.   Gigawave 6GHz, 1TS,12-bit vs the LeCroy's  600MHz, 5GS, 8-bit.  Of course, the LeCroy has a faster sweep rate (<sec vs several minutes), but the transitions are also much more discernible.  Of course, the 64xi can't show 35ps transitions like the 6400 can.   

***
Right tool for the job.  If you need to measure fast edge, 2-state signals,  6400 really shines. 

***
Qualify that with MHz trigger rates....

[SJL-Instruments]

As promised, we have released v2.6.0 of the software which adds jitter analysis. Measurement markers have been added, and more measurements are now available in point mode. The manual has been updated to revision H13. Image attached.

If we introduce a dual-comparator version of the GigaWave, it would be similar enough to integrate into the existing software. The sweep speed would be the same (or faster).

We've recently come up with a better algorithm for the dual-comparator version that offers a quadratic speedup. In theory this should reduce the Nmin requirement for eye diagrams by a factor of 300. This would allow capturing a PAM4 eye in 10 seconds, and a two-level eye in <1 second, without any increase in trigger rate. This also lets us avoid the pretrigger requirement. Now to put this into practice...

[joeqsmith]

Tried out the latest software and the first thing I noticed was when I change to color grading, the plots background now turns solid white.   Turning off the readouts, changing the scaling and CDF options has no effect.   With vectors enabled, it appears normal.

[SJL-Instruments]

This is due to graphics-card-specific OpenGL implementation details. This prerelease should fix the problem:
https://gigawave-releases.s3.us-east-2.amazonaws.com/GigaWave_v2.6.1_PREVIEW-2024-03-10_Windows.zip

NVIDIA Quadro M4000,  Xeon E5-1650 v4,  32G RAM, Win 10 Pro 1903.

Is this the machine you're testing on? We'll build one with the same specs for future QA checks.

[joeqsmith]

NVIDIA Quadro M4000,  Xeon E5-1650 v4,  32G RAM, Win 10 Pro 1903.

Is this the machine you're testing on? We'll build one with the same specs for future QA checks.

Yes.  I suspect the other machine I listed would have the same problem if you would like me to try it.   Updated software does solve it. 

Looking at task manager, does seem to require a bit of processing on this old PC.   

[SJL-Instruments]

Yes.  I suspect the other machine I listed would have the same problem if you would like me to try it.   Updated software does solve it. 

If you have the time, this would be helpful information to know. Good that the fix addresses the problem.

Looking at task manager, does seem to require a bit of processing on this old PC.

We'll improve the caching structure and CPU usage in the next update. We've put just enough time into optimizing the software for it to run smoothly on Windows tablets - but there's always more that can be done.

[joeqsmith]

1GHz oscillator attached to the 6400 using a 6dB attenuator:

https://www.minicircuits.com/WebStore/dashboard.html?model=BW-S6-2W263A%2B

Both systems are using 80/20.   6400 was allowed to warmup about an hour.   Rj is more than triple with the 6400. 

[joeqsmith]

Zooming in and increasing the resolution and samples per CDF has no effect (resetting cursors after adjustments). 

***
Updated plot to include P-P@ 1e-3&1e-2 BER.   

[SJL-Instruments]

The 6400 reports total RMS jitter, and cannot automatically currently isolate the Rj contribution.

The histogram at the bottom looks double-peaked (before the image was updated). The 1 sigma deviation for one of the features looks like ~6 ps RMS. This should be closer to Rj.

At 13 ns, your specific unit has ~4.7 ps RMS intrinsic trigger jitter that adds in quadrature (calculated from Section 2.3 and the calibration sheet). Subtracting this contribution gives 3-4 ps RMS as an estimate for Rj.

***

We can extract the Rj(δδ) and Dj(δδ) contributions assuming the dual-Dirac model. This will be implemented in the next update. There is no way to further decompose Dj(δδ) with this architecture.

[joeqsmith]

Using your 85ps @ BER 1e-3,  @ BER 1e-12  is about 185 ps p-p vs 48ps measured.   

https://www.analog.com/media/en/technical-documentation/app-notes/hfan0402-converting-between-rms-and-peaktopeak-jitter-at-a-specified-ber.pdf   

[SJL-Instruments]

Using your 85ps @ BER 1e-3,  @ BER 1e-12  is about 185 ps p-p vs 48ps measured.   

https://www.analog.com/media/en/technical-documentation/app-notes/hfan0402-converting-between-rms-and-peaktopeak-jitter-at-a-specified-ber.pdf   

Both the 85 ps and 48 ps measurements are correct - they're just measuring different things.

The conversion you quoted is valid only in the absence of Dj(δδ). It assumes a Gaussian jitter distribution. Since in your case there is visible double-edging, the Dj(δδ) contribution is a significant factor.

Since you're looking at the 12th transition after the trigger, likely the Dj(δδ) of the transition you're looking at is roughly 12x larger than the Dj(δδ) inherent to the clock (which is what was reported by your clock analyzer). (This assumes the Dj correlation timescale is ~10 ns or longer - in general the true Dj spectrum can be complicated.)

The appropriate alpha (equal to 2*Q_BER in below reference) for 1e-2 BER is 4.652.
https://people.engr.tamu.edu/spalermo/ecen689/jitter_dual_dirac_agilent.pdf
Eyeballing your plot, it looks like Dj(δδ) ~ 20 ps. Taking Rj(δδ) ~ 6 ps (effective, due to trigger jitter), this gives ballpark estimates:
TJ(BER = 1e-2) = 20 + 4.652*6 = 48 ps
TJ(BER = 1e-3) = 20 + 6.180*6 = 57 ps.
The reported measurements are larger than this since the selected analysis window has a significant vertical extent compared to the slope of the signal.

The PP jitter measurements reported in our software are the "true" PP jitter and do not assume the dual-Dirac model. When we implement Rj(δδ) and Dj(δδ) decomposition, we will also add TJ(δδ) measurements at BER down to 1e-12.

[joeqsmith]

Moving the start to 7.7ns does significantly lower the p-p values.

[joeqsmith]

When importing, is there a reason that the software will no allow disabling vectors?   

[SJL-Instruments]

When importing, is there a reason that the software will no allow disabling vectors?   

Imported traces (.CSV) only contain voltage as a function of time. There is no information about the distribution of the noise, so disabling vector mode would show no extra information.

[joeqsmith]

Why not store the raw CDF, voltage and settings?   This would have allowed me to upload the files directly from your software for those wanting to post process it and in this case, you could display the data any way you like. 

Shown using the delayline.   I wouldn't have expected a such a reduction as the sample delay is still the same but it is channel 2 rather than 1 and we have added a lot of coax plus all the other errors that go along with it.