Pocket-Sized 6 GHz 1 TS/s ET Scope

[ddavidebor]

Hi SJL-Instruments !

My name is David and I'm responsible for all of the electronics engineering at https://thinksmartbox.com/
We design custom tablet computers for people with disabilities.

I would like some help to understand if your device can be used for USB SI testing up to USB 3 Gen 2 (10gbit). I admit I'm not that familiar to problems in the GHz range.

Here's a quick summary of the test specs, compiled by R&S https://www.rohde-schwarz.taipei/data/activity/file/1644474550064631375.pdf

My questions are:

- Are you familiar with the standard? have you ever tried anything like this, or do you have customers that have done it?
- Can your device meet the requirements for USB 3 Gen 1 (5gbit) ?
- Can your device meet the requirements for USB 3 Gen 2 (10gbit) ?

[SJL-Instruments]

In the digital world, any 10..90 or 20..80% rise/fall variations are of any interests.

This is an ideal application for the GigaWave. With the recent improvements to the measurement UI in v2.5.11, you can track the variation of rise/fall times over thousands of sweeps, view all the standard statistics, and export the data for analysis.

So I would like:
- to measure digital 3.3..5V references signals given form OXCO or clock distributions as in the range of 5...100MHz
- this means, an internal or external accurate reference is needed. while the DUT PN OXCO is about -120 rtHz @ 1Hz or even lower
- this requires a high impedance differential connection/probe to the DUT
- also to measure any ripple of the analog/digital power on ADC/DAC as on VRef
- a Histogram would tell, all or use any pricey LeCroy gear with Jitter SW

IMHO the picture tells all but do not convince me, whether we measure the DUT jitter or internal used TXCO reference jitter.

We would not recommend the GigaWave for measurement of very low phase-noise clock sources, for the reasons you mentioned. The TXCO phase noise above ~1 kHz does not matter, as it's used only to calibrate the delay generator. The jitter of the delay generator is what determines the jitter floor of the scope. This is 4 ps RMS at the trigger and increases with the timebase position. At 100 ns, this is 8 ps RMS.
Shahriar was actually quite generous with the jitter comparison, as the shaded region in vector mode plots the RMS, not the peak-to-peak jitter, as digitized by the scope. His 10 ps measurement corresponds to 5 ps RMS (slightly better than spec).

[SJL-Instruments]

Hi SJL-Instruments !

My name is David and I'm responsible for all of the electronics engineering at https://thinksmartbox.com/
We design custom tablet computers for people with disabilities.

I would like some help to understand if your device can be used for USB SI testing up to USB 3 Gen 2 (10gbit). I admit I'm not that familiar to problems in the GHz range.

Here's a quick summary of the test specs, compiled by R&S https://www.rohde-schwarz.taipei/data/activity/file/1644474550064631375.pdf

My questions are:

- Are you familiar with the standard? have you ever tried anything like this, or do you have customers that have done it?
- Can your device meet the requirements for USB 3 Gen 1 (5gbit) ?
- Can your device meet the requirements for USB 3 Gen 2 (10gbit) ?

Thanks for your interest! And quite a noble cause. 

For quantitative characterization of an eye diagram, the scope should have a bandwidth several times the baud rate of the signal. For 5 Gbit/s USB 3, we would recommend a bare minimum of 10 GHz bandwidth.

While the GigaWave can show a USB 3 Gen 1 eye diagram, it will not be quantitatively accurate due to its 6 GHz bandwidth. For this reason, we only target up to USB 2.0 High Speed (480 Mbaud).

[joeqsmith]

I enjoyed watching their review.  I almost wish they had given you another week to work on it.  Even from the time of the video's release you have made several improvements.   It's too bad that the speckles are a focal point.   I was talking out loud as he started trying different settings to improve it,  crank up the triggers!!    

I was going to play with the speckles but my brain hasn't evolved to get past even the basics...

Yep, these numbers look correct. Units are in probability density per volt. For intensity-grading, the overall scaling is arbitrary and is controlled by the brightness slider. The official software has some auto-ranging for convenience, but it’s not necessary.
...
The first point in your result (with a negative dV) should be thrown out. Each final PDF value corresponds to the interval between two neighbouring CDF points.

Thanks for double checking my work.    ... I will need to think about how best to plot it.   ..

For starts I need to sort out how to plot the PDF.  I collected raw PAM4 data and attempted to post process it. Any tips on how you converted the PDF back into the voltages you plot? 

***
Shown is looking at the raw PDF data for the PAM8 signal.  While I can see the 8 distinct levels, obviously this is not correct.   
***
Looking at the PAM4 data (20k triggers, 100  CDF samples, basically the same settings that with your software will produce a decent looking eye.   I was surprised how much the PDF varies.  On the right side, you can see the sorted PDF values (48,000 total), represented by 366 unique levels ranging from 1264 to 0.   Negative PDFs were set to 0. 

[joeqsmith]

Sorting the highest PDF values and then indexing to their corresponding voltage, I get the display on the left (pure guess on my part that is what you are doing).   I then look at the PDF distribution (right histogram) and sort for the areas with the highest peaks.  I then search for only data that falls within a small percentage of these, which gives me the plot in the center.  Does a fair job de-speckling the data but we are also missing some of the good data....  So not a good solution.    I tried a few other simple corrections.  My take away, it's not a super simple problem.   

[Lukas]

I was building pretty much this about 12 years ago: https://www.eevblog.com/forum/projects/diy-ghz-sampling-head-for-lt100mhz-scopes/msg971961/#msg971961 but didn't really get around to finish it.  (that post is much newer than the project itself). I didn't know how to do FPGAs back then, so there's a bit more discrete ECL logic on my design. Really nice to see that someone took that concept and turned it into a well-polished modern product!

I built the ring oscillator out of a meandering trace rather than the adjustable delay line since I thought that it'd have lower jitter.

Since there was no FPGA in my design and everything was controlled by an MCU, the triggering rate was much slower. To somewhat compensate for that, I didn't sweep the comparator threshold to build the CDF. Instead I used the comparator to build a SAR ADC that does one bit per trigger event. This approach obviously falls apart when there's significant noise or jitter on the measured signal, but worked well enough for my purposes.

[SJL-Instruments]

I enjoyed watching their review.  I almost wish they had given you another week to work on it.  Even from the time of the video's release you have made several improvements.   It's too bad that the speckles are a focal point.   I was talking out loud as he started trying different settings to improve it,  crank up the triggers!!    

Yep, we're happy with how his review turned out. Of course, the performance has improved since the review - such is the nature of any actively developed product.

For starts I need to sort out how to plot the PDF.  I collected raw PAM4 data and attempted to post process it. Any tips on how you converted the PDF back into the voltages you plot? 

***
Shown is looking at the raw PDF data for the PAM8 signal.  While I can see the 8 distinct levels, obviously this is not correct.   
***
Looking at the PAM4 data (20k triggers, 100  CDF samples, basically the same settings that with your software will produce a decent looking eye.   I was surprised how much the PDF varies.  On the right side, you can see the sorted PDF values (48,000 total), represented by 366 unique levels ranging from 1264 to 0.   Negative PDFs were set to 0. 

The PDF values shouldn't be sorted. Each PDF value corresponds to the region between the two voltage values from which it was derived. The interval within this region should be shaded with intensity proportional to the PDF value.
This is why there is one less PDF value than the count of voltages you start with.

Sorting the highest PDF values and then indexing to their corresponding voltage, I get the display on the left (pure guess on my part that is what you are doing).   I then look at the PDF distribution (right histogram) and sort for the areas with the highest peaks.  I then search for only data that falls within a small percentage of these, which gives me the plot in the center.  Does a fair job de-speckling the data but we are also missing some of the good data....  So not a good solution.    I tried a few other simple corrections.  My take away, it's not a super simple problem.   

Filtering each individual PDF distribution is not a good approach, as you've found, since it biases the data downwards. This will remove rare features and lead to inaccurate visualization of the data.

The approach we mentioned before does not introduce any bias, and only improves convergence properties. In more precise terms, the expectation value is unaffected, and we're just changing the inference prior. This will remove any random/uncorrelated noise (speckles) while preserving the signal. We think this has a good chance of working well.

Of course, the firmware and software changes should largely fix the root issue, and the above technique will just deal with the residual statistical noise.

[SJL-Instruments]

I was building pretty much this about 12 years ago: https://www.eevblog.com/forum/projects/diy-ghz-sampling-head-for-lt100mhz-scopes/msg971961/#msg971961 but didn't really get around to finish it.  (that post is much newer than the project itself). I didn't know how to do FPGAs back then, so there's a bit more discrete ECL logic on my design. Really nice to see that someone took that concept and turned it into a well-polished modern product!

I built the ring oscillator out of a meandering trace rather than the adjustable delay line since I thought that it'd have lower jitter.

Since there was no FPGA in my design and everything was controlled by an MCU, the triggering rate was much slower. To somewhat compensate for that, I didn't sweep the comparator threshold to build the CDF. Instead I used the comparator to build a SAR ADC that does one bit per trigger event. This approach obviously falls apart when there's significant noise or jitter on the measured signal, but worked well enough for my purposes.

Interesting work! Yep, the basic concept is quite simple - just a precisely triggered comparator. The hard part is of course the precision, and achieving it fast.

The timing core represents about three years of work. Freshly calibrated, we can get precision down to 50 femtoseconds RMS. It's actually somewhat of a shame that the comparator supports an analog bandwidth of only ~6 GHz, since the timing accuracy would support a Nyquist bandwidth of ~500 GHz. Foreshadowing...   

[joeqsmith]

The PDF values shouldn't be sorted. Each PDF value corresponds to the region between the two voltage values from which it was derived. The interval within this region should be shaded with intensity proportional to the PDF value.
This is why there is one less PDF value than the count of voltages you start with.
...
Filtering each individual PDF distribution is not a good approach, as you've found, since it biases the data downwards. This will remove rare features and lead to inaccurate visualization of the data.
...
Of course, the firmware and software changes should largely fix the root issue, and the above technique will just deal with the residual statistical noise.

Top graph should be what you describe above complete with speckles which is not really what I am after.   Sorting for high PDFs was to removed points having less of an effect,  speckles.   

It reminds me of the game of life.  I had read about it in one of Steven Levy's books and coded it into an FPGA. 
https://youtu.be/5OUfx2F43ek?t=515

Wiki
https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life

I could treat these speckles similar to cells that live in secluded areas and die off.   

[joeqsmith]

Doing a vertical scan that requires cells above and below to be active, we are already loosing a fair amount of good data.  I would need to do a horizontal scan as well.  It could certainly be done but what a mess...   

[KE5FX]

Looks like a job for a median filter to me.  Or if you want to get a little fancier...

[SJL-Instruments]

Looks like a job for a median filter to me.  Or if you want to get a little fancier...

Doing a vertical scan that requires cells above and below to be active, we are already loosing a fair amount of good data.  I would need to do a horizontal scan as well.  It could certainly be done but what a mess...   

Yes, horizontal correlation is the way to go. There is no way to distinguish statistical noise from a rare event using only the information in one PDF. A horizontal median filter is a simple way to do this. The approach we mentioned before is theoretically better-conditioned than the median filter, but the gist is the same - temporal correlation.

A general-purpose image despeckle algorithm isn't really sufficient for this application, since we're dealing with quantitative data. The results should be accurate and unbiased, whereas an image despeckle just needs to visually resolve the problem.

[joeqsmith]

Attached is the PAM4 (CSV) data I used to create the above plots for those who want to try their hand at cleaning up the speckles.  Each line is CRLF terminated.  Header should explain the format.     

[SJL-Instruments]

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.

Attached are before/after images, plotted on the same color scale. This will be implemented in software v2.5.12, and long-term will be done in firmware v14.

Beyond this, we don't think it's a good idea to try filtering the data in any way. It's better to just increase the CDF settings and gather more statistics.
The monotonicity filtering is based on an inherent mathematical property, and will not alter any already-valid CDF data, so it's always OK.
But any other filtering method will introduce artifacts in some cases.

In the long-term, the speckle issue can be completely eliminated with a dual-comparator design. If/when we introduce a new model of the GigaWave (or a dedicated SI analyzer), we will implement this.

[SJL-Instruments]

We've just released minor software update v2.5.12 which significantly improves the speckle issue (and fixes several UI bugs).

The corresponding manual has been updated to revision H12. We have significantly expanded Section 2 to add detailed guidance on choosing appropriate CDF sampling settings.

As always, let us know if anything in the manual is unclear.

[joeqsmith]

Comparing the latest 2.5.12 with the earliest version I have, 2.5.3.  Both in demo mode.  Attempting to set intensity to give the same shading. 

IMO, these speckles are always going to raise questions for the user if they are dealing with a scope or a signal problem.  Looking forward to the updated firmware.  I have not tried to bump the triggers above 30k as suggested.   

In the long-term, the speckle issue can be completely eliminated with a dual-comparator design. If/when we introduce a new model of the GigaWave (or a dedicated SI analyzer), we will implement this.

I am sure you were aware of the speckles early on in the design phase.   Most likely before even starting on the hardware.  I envision the signal processing was simulated first, but maybe not.    I am curious if you knew changing the architecture would have solved it, why didn't you just change it.   Was the added cost really that big of a factor?   

Had the dual-comparator approach been used, how would it have effected the sweep speed compared to your future firmware approach? 

[SJL-Instruments]

Comparing the latest 2.5.12 with the earliest version I have, 2.5.3.  Both in demo mode.  Attempting to set intensity to give the same shading. 

IMO, these speckles are always going to raise questions for the user if they are dealing with a scope or a signal problem.  Looking forward to the updated firmware.  I have not tried to bump the triggers above 30k as suggested.

The range of the brightness slider is increased in 2.5.12 compared to 2.5.3. Attached is a screenshot with both at the same internal setting.

The speckles are inherent to any single-comparator CDF sampler, and will tend asymptotically to zero as Nmin is increased. The math is in Section 2.2.5 of the new manual revision. The new firmware revision will remove the CDF quantization noise (which contributes about half the statistical noise at Nmin = 10k), which will improve but not eliminate the speckles.

Our hope is the expanded manual section is clear enough for the user to understand why they occur, and what factors control their intensity. Practically, this limits the BER fidelity to 10^-5 for a reasonable acquisition time with a single comparator.

I am sure you were aware of the speckles early on in the design phase.   Most likely before even starting on the hardware.  I envision the signal processing was simulated first, but maybe not.    I am curious if you knew changing the architecture would have solved it, why didn't you just change it.   Was the added cost really that big of a factor?   

Had the dual-comparator approach been used, how would it have effected the sweep speed compared to your future firmware approach? 

There's a mix of reasons. Adding another comparator is not trivial - it opens up part matching issues, and the math + feedback algorithms get substantially more complex. It would likely have added another 6 months of development time.
When the GigaWave was launched, we had no idea how customers would react to a CDF sampling scope. There wasn't any existing product to directly compare to. It was also our first product, so we wanted to minimize the hardware complexity to reduce the chance of things going wrong. (And as you know, things still managed to go wrong with the initial firmware revision.)
The original target application was in photonics and ultrafast laser research, where they mainly want to measure pulse widths and risetimes (with very high repetition rates), with less emphasis on eye diagrams and BER. We realized only after launch that the latter market might be much larger.
We have been turning away customers who ask about BER applications, due to the single-comparator design. Had we known what we know now, we would have gone with the dual comparator design. Of course, all the problems are obvious in hindsight.

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

For a dedicated SI analyzer, we can substantially simplify the trigger, and run the comparator clock at GHz speeds. This would allow for an eye diagram that updates in real-time, as well as BER testing to 10^-12.

Hope this cleared things up. May not be what you were looking for - but it's the honest story, and the best answer we can give.

[KE5FX]

It's the old dilemma -- if you wait to ship until your product is perfect, you will never ship anything.  Either that, or the competition will beat you by shipping something even worse.

You're doing it right.  Ship something imperfect and support it fanatically.  The best product isn't one that's perfect right out of the gate, it's one that keeps getting better even after the customer takes delivery.  That's the lesson I took away from the original iPhone -- it sucked in various ways, but it sucked a little less every time an update came out, and that experience was nothing short of magical. 

Of course, now, almost 20 years later, the idea that something actually gets better after an update is nothing short of laughable.  But it doesn't have to be that way.  Keep doing what you're doing!

[joeqsmith]

12 (top) vs 12 preview (bottom), both set to max brightness. 

Some of the features are lost when turning down the brightness to reduce the speckles.

So yes, better. 

[joeqsmith]

Does the new filtering only effect how the data is displayed?   If a user saves the data to a file, is this post filtering? 

[SJL-Instruments]

The filtering is done in the backend after the serial query, prior to insertion into data storage. All subsequent operations (including saving) therefore act on the filtered data.

The long-term plan is to move the filtering into firmware. Since the filtering is just enforcing an inherent mathematical property of the CDF, it does not introduce additional artifacts, and there's no reason not to do it.

We expect that the 16-bit CDF return format in v14 will improve the speckles by a further ~50-80% relative to your screenshots above (depending on the settings you used). Beyond that, they are limited by statistical noise (number of triggers acquired).

[PHOStronics]

We are a student interested in learning how the sequence of query voltages is chosen to optimally extract information, especially in the case of a non single-valued signal.

Can you explain a bit more on how these sequences are determined?

[SJL-Instruments]

This requires some understanding of statistics. Essentially, given all the samples collected so far, you can compute the differential entropy reduction given one additional sample collected as a function of the next query voltage. This is the Fisher information. Maximizing this quantity gives the optimal choice of query voltage.

This is a greedy algorithm and only locally maximizes the information gained per trigger. It generally does not give the globally optimal voltage sequence, but the FPGA/MCU does not have enough processing power to perform a global optimization in real-time.

[PHOStronics]

Do you have books/resources you can recommend on the topic, or does the algorithm you are using have a name?

We do not yet understand enough about statistics to understand how you can determine which sample locations may be optimal in reducing the error, and it seems like a very fascinating problem.
I guess we would start by reading up on Fisher information, and see if we can find some relevant information there

[SJL-Instruments]

Usually we try to give the simplest explanation possible, but in this case there isn't really one. You do need to get an intuitive understanding of Gaussian process regression and maximum-likelihood estimation.

We tried many simpler algorithms as well, but all of them perform poorly on at least some subset of possible signals. The fancy stats is actually necessary in general. There isn't a name for this algorithm - we derived it specifically for this application.