Pocket-Sized 6 GHz 1 TS/s ET Scope

[joeqsmith]

Looking at my crappy PAM8, note the gaps in the 2nd and 3rd levels, even at the highest brightness and max resolution.  Again, min 10k triggers.   It's interesting there would be dead spots like this.   

[SJL-Instruments]

Auto.  So, I'm not sure.  Assuming the the grayed out values are what it is using, then 329.   If I manually bump it to 10,000 it does clean things up but of course, takes much longer to sweep.   

Based on your screenshot, the acquisition rate is limited by the trigger holdoff. Setting the holdoff to 80 ns will speed up the sweep by 6x.

[joeqsmith]

Set to 80ns, it requires 95 seconds to sweep. 

[SJL-Instruments]

Looking at my crappy PAM8, note the gaps in the 2nd and 3rd levels, even at the highest brightness and max resolution.  Again, min 10k triggers.   It's interesting there would be dead spots like this.   

Thanks, this is interesting. Based on the histogram on the right, the signal spends most of its time at the lowest and highest PAM8 levels. The fidelity of the rarer features might be limited by the 256-level quantization of the returned CDF values, since the R command encodes the CDF in 1 byte.

We'll add an option for higher CDF resolution to the R command in the next firmware update.
With the current firmware version, you can get much better resolution by using the direct CDF read (@) command, although this will require custom software.

Perhaps we could add a mode to the software that uses the @ command. This is useful in cases where you want the maximum quality, and don't care so much about speed. It would essentially do a 2D sweep.

Set to 80ns, it requires 95 seconds to sweep. 

Given that your clock rate is 50 MHz, at 80 ns holdoff the scope will trigger every 80 or 100 ns. At 10k triggers/sample and 30 samples/CDF, you need 461 million triggers @ 128 pts/div (12 divisions). This is ~46 seconds. Odd that you measured a factor of 2 higher, but the order of magnitude is correct.

The factor of 2 discrepancy is likely due to the Nmax setting. Lowering this to match Nmin should give a 46 second sweep.

[joeqsmith]

I can certainly change from a single XNOR to a Fibonacci LFSR to do a better job of evening out the distribution which does not show the gaps I mention.

Measured again at 101 seconds for a single sweep.   Yes samples per CDF is 30, Min triggers is 10k,  50MHz clock and 128pts per division. 

[SJL-Instruments]

I can certainly change from a single XNOR to a Fibonacci LFSR to do a better job of evening out the distribution which does not show the gaps I mention.

Measured again at 101 seconds for a single sweep.   Yes samples per CDF is 30, Min triggers is 10k,  50MHz clock and 128pts per division. 

Thanks for confirming the settings. The remaining noise spikes you're seeing are likely the CDF quantization noise getting amplified by the max brightness setting. The upper end of the slider range is very strong, and tends to saturate every detail.

The speed-quality tradeoff is inherent to the CDF sampling approach. This might require playing around with parameters.

[joeqsmith]

The factor of 2 discrepancy is likely due to the Nmax setting. Lowering this to match Nmin should give a 46 second sweep.

Changing Max from infinite to 10k required  the same sweep time.    Shown with color and min brightness.  Increased to 100MHz signal but scope set the same.   

[SJL-Instruments]

The factor of 2 discrepancy is likely due to the Nmax setting. Lowering this to match Nmin should give a 46 second sweep.

Changing Max from infinite to 10k required  the same sweep time.    Shown with color and min brightness.  Increased to 100MHz signal but scope set the same.   

We just reproduced your settings with a 100 MHz signal and measured 84 s. Of this, 47 s is spent collecting data, and 37 s is communication overhead (likely computer-dependent).
Thanks for catching this. This will be fixed in the v14 firmware revision.

The vertical resolution in your last screenshot is limited by the 30 samples/CDF setting - each PAM8 level gets ~4 voltage samples, and this becomes worse during the transitions. The limit of 30 is due to our OpenGL rendering pipeline and will be increased in the next software update. The v13 firmware can go up to 100 (and the v14 we are working on can go up to 1000).

This can again be worked around using the direct CDF sample command (@) if you need it.

[joeqsmith]

I'm more just trying to get a feel for the limitations of the scope.  There is a lot of ground that could have been covered in the review but at an hour and a half,  I figure 90% of the people would be asleep by the end!        

I don't normally look at YT metrics as I just don't care.   But just for you, showing the view duration compared with my typical numbers.   So yes, sleeping or bored stiff.    

[joeqsmith]

The fidelity of the rarer features might be limited by the 256-level quantization of the returned CDF values, since the R command encodes the CDF in 1 byte.

We'll add an option for higher CDF resolution to the R command in the next firmware update.
With the current firmware version, you can get much better resolution by using the direct CDF read (@) command, although this will require custom software.

The vertical resolution in your last screenshot is limited by the 30 samples/CDF setting - each PAM8 level gets ~4 voltage samples, and this becomes worse during the transitions. The limit of 30 is due to our OpenGL rendering pipeline and will be increased in the next software update. The v13 firmware can go up to 100 (and the v14 we are working on can go up to 1000).

This can again be worked around using the direct CDF sample command (@) if you need it.

Shown is my crappy Fibonacci PAM8 50MHz test signal, scaled to 950mV.  20,000 triggers for min/max, centered around the switch point.  I wanted to increase the spread between levels without overloading the front end.   

When using an oscilloscope, I am expecting what is being displayed represents the actual signal.   With your scope, talking about 12bits TSPS equivalent, I am expecting some decent fidelity.  Especially when the claim is the primary use is for high speed signal integrity.   

Not being a math guru,  the last thing I want to think about when trying to evaluate some high speed signals is how the scope is statistically dealing with the data.    If I saw a waveform like the one shown, I would assume the signal was bad.  I may spend time trying to determine the cause of the noise.  Eventually, I would try another scope.  (For a comparison, shown attached to my vintage LeCroy 64xi).   

I am sure some of the shortcomings could be addressed with custom software.  I wouldn't expect many of your customer's to be software developers.  If this was a direction you wanted to take, you may want to consider open sourcing the main application to allow people to build off it rather than starting from scratch.  It may actually help with sales.

Sure we can talk about the low cost compared with other scopes but IMO, if the tool can't do the basic job it was designed for, or causes the user to spend time trying to track down nonexistent hardware problems, that lower cost is a bit of a false selling point. 

Again, others may have a different view. 

[SJL-Instruments]

Shown is my crappy Fibonacci PAM8 50MHz test signal, scaled to 950mV.  20,000 triggers for min/max, centered around the switch point.  I wanted to increase the spread between levels without overloading the front end.   

When using an oscilloscope, I am expecting what is being displayed represents the actual signal.   With your scope, talking about 12bits TSPS equivalent, I am expecting some decent fidelity.  Especially when the claim is the primary use is for high speed signal integrity.   

Not being a math guru,  the last thing I want to think about when trying to evaluate some high speed signals is how the scope is statistically dealing with the data.    If I saw a waveform like the one shown, I would assume the signal was bad.  I may spend time trying to determine the cause of the noise.  Eventually, I would try another scope.  (For a comparison, shown attached to my vintage LeCroy 64xi).   

I am sure some of the shortcomings could be addressed with custom software.  I wouldn't expect many of your customer's to be software developers.  If this was a direction you wanted to take, you may want to consider open sourcing the main application to allow people to build off it rather than starting from scratch.  It may actually help with sales.

Sure we can talk about the low cost compared with other scopes but IMO, if the tool can't do the basic job it was designed for, or causes the user to spend time trying to track down nonexistent hardware problems, that lower cost is a bit of a false selling point. 

Again, others may have a different view. 

These are good points. We do want to emphasize that the vertical fidelity you're seeing is entirely a software limitation.
The default settings are chosen for a good tradeoff between speed and fidelity for an eye diagram of a two-level signal. In particular, for a PAM8 signal, K needs to be set to ~100 for good resolution. The software limit is currently 30 due to OpenGL implementation.

As the number of levels increase, the required Nmin and K values increase. We think it is possible to detect these automatically and set them appropriately. As you mentioned, this is likely necessary to give a good user experience.

Later today we can send you a prerelease that increases the maximum K. This will give better vertical fidelity on your PAM8 eye.
For the next update, we will put UI features on hold, and focus on automatically determining the CDF settings. This way, the user does not need to understand the theory of operation to take more complex eye diagrams.

[joeqsmith]

These are good points. We do want to emphasize that the vertical fidelity you're seeing is entirely a software limitation.
The default settings are chosen for a good tradeoff between speed and fidelity for an eye diagram of a two-level signal. In particular, for a PAM8 signal, K needs to be set to ~100 for good resolution. The software limit is currently 30 due to OpenGL implementation.

As the number of levels increase, the required Nmin and K values increase. We think it is possible to detect these automatically and set them appropriately. As you mentioned, this is likely necessary to give a good user experience.

Later today we can send you a prerelease that increases the maximum K. This will give better vertical fidelity on your PAM8 eye.
For the next update, we will put UI features on hold, and focus on automatically determining the CDF settings. This way, the user does not need to understand the theory of operation to take more complex eye diagrams.

When I hear about 12-bit converters I  am thinking 4096 discrete levels, not 30.   I understand those 30 points are distributed around the input signal.  Its fine if we are looking at simple single level waveforms.  But the manual opens the gates when it talks about eye diagrams.   When we start looking at different modulation schemes things break down fast.   It makes sense that the vintage LeCroy with 8-bits is able to resolve the PAM8 test case with much higher fidelity.  It just may not be apparent to the casual follower.   It will be interesting to see what SignalPath has en-store for us. 

Guessing your proposal would support PAM16,  so it may cover the majority of cases.   I am guessing there is going to be a pretty big hit in the sweep times.    I'll post some data once I have your new software.  I'll see about changing my hardware to support another data bit.   

[SJL-Instruments]

When I hear about 12-bit converters I  am thinking 4096 discrete levels, not 30.   I understand those 30 points are distributed around the input signal.  Its fine if we are looking at simple single level waveforms.  But the manual opens the gates when it talks about eye diagrams.   When we start looking at different modulation schemes things break down fast.   It makes sense that the vintage LeCroy with 8-bits is able to resolve the PAM8 test case with much higher fidelity.  It just may not be apparent to the casual follower.   It will be interesting to see what SignalPath has en-store for us. 

Guessing your proposal would support PAM16,  so it may cover the majority of cases.   I am guessing there is going to be a pretty big hit in the sweep times.    I'll post some data once I have your new software.  I'll see about changing my hardware to support another data bit.   

For single-level waveforms and two-level eye diagrams, the scope works well. PAM4 is usable but slow. To be honest, if we got an inquiry about PAM8 or PAM16 eye diagrams, we would recommend against buying the product. The hardware is certainly capable of it, but at some point the time taken does not make commercial sense.

The time required for a good acquisition scales roughly as the square of the number of levels in the eye. A PAM-16 eye would take 64x longer than a two-level eye. We will significantly expand Section 2.4 to clarify this in the next revision, and add more information in general about the limitations of CDF sampling. This might be a good topic to put in a video on our homepage.

We are still working on the software changes and will provide a prerelease shortly. (A surprisingly large fraction of the graphics pipeline needs to be rewritten.)

Sure we can talk about the low cost compared with other scopes but IMO, if the tool can't do the basic job it was designed for, or causes the user to spend time trying to track down nonexistent hardware problems, that lower cost is a bit of a false selling point. 

Just to hear your honest opinion: having worked with the scope for a month, do you think the price we have set is fair? Suppose we restrict the recommended use cases to single-level signals and eye diagrams for two-level protocols, and state this clearly.

Internally, one of our goals was to bring the cost of a 5+ GHz scope down far enough for hobbyist use. Bandwidth and timing precision are the two things you can't fix by averaging down - our architecture trades these for acquisition speed. But perhaps the price is still too high for this goal.

[joeqsmith]

Just to hear your honest opinion: having worked with the scope for a month ...

I think your comment about making the limitations clear in the manual are very important, especially when you start marketing it as 12-bits 1TSPS.  IMO that  raises expectations.  Someone may read that 30 samples per CDF and think nothing of it.  Even if they take the time to read the manual, they may not understand how it relates to a multi-level signal.  Providing examples in the manual that describe the expected sweep times,  tradeoffs of performance versus various settings, why/when to change settings from the defaults, all good things to include.   As I wrote before, I think that the software is what is going to sell it. 

I appreciate trying to sell it into the hobbyist market.  It would be interesting to know why that early kickstart failed.  Or why the sampling scopes mentioned earlier failed.   That was a much lower cost unit and they still couldn't make a go of it.  Maybe they underestimated the cost of software development and support.  It could also be that there are not many hobbyist that have a use for a scope this fast.  Or, if they are, they may need features that they can't get with a sampling scope.   I fall into that category.  I can't afford new prices and my only choice is used. 

Cost wise, for me it's more a question on if the product fits a particular need I have.   This product isn't something that you would ever consider for general purpose use.  Adding ability to measure distances for fault finding and other features that expand its use may help sell it. 

****
The CDF sampling options are not saved in the setup.   It always defaults to auto. 

[SJL-Instruments]

I think your comment about making the limitations very clear in the manual are very important.   Especially when you start marketing it as 12-bits 1TSPS.  IMO that  raises expectations.  Someone may read that 30 samples per CDF and think nothing of it, even if they take the time to read the manual they may not understand how it relates to a multi-level signal.  Providing examples in the manual that describe the expected sweep times,  tradeoffs of performance versus various settings, why/when to change settings from the defaults, all good things to include.   As I wrote before, I think that the software is what is going to sell it.

Thanks for the feedback. We will add at least a few pages about this in the next revision. In addition to explaining these tradeoffs in detail, we will make it clear that we only recommend the scope for eye diagrams of two-level protocols.

I appreciate trying to sell it into the hobbyist market. It would be interesting to know why that early kickstart failed.  Or why the sampling scopes mentioned earlier failed.   That was a much lower cost unit and they still couldn't make a go of it.  Maybe they underestimated the cost of software development and support.

Our guess is the lack of software support. Early on, someone mentioned:

FWIW, I have the 11 GHz scope from fastsampling.com (2 actually, but one has an problem). I find it difficult to use, mainly because of the software. I am not sure if they are still in business, as the last time I tried to contact them, I got no reply. The two channel limitation and the cumbersome software has made it difficult to use for my needs.

This is part of why we are focusing so much on the software. It should never "get in the way" of making measurements. Developing without user feedback is a good way to make the UI impossible to use.
It's important for customers to feel confident that support will continue. We have baked the software development cost into the price of the product, and suspect that the earlier attempts did not.


As promised, here is a v2.5.12 pre-release that increases the max K to 200 and the max Nmin to 500k:
https://gigawave-releases.s3.us-east-2.amazonaws.com/GigaWave_v2.5.12_PREVIEW_2024-02-27_Windows.zip
Note that setting K above 100, or Nmin above 30k, will fallback to using the direct CDF read (@) command due to v13 firmware limitations. This mode incurs a lot of overhead (80% of the time is spent on communications...), and will be resolved in v14 firmware.
We've attached an example of a PAM4 signal @ Nmin = 60k, K = 200. This is of course impractically slow. But it illustrates the ultimate limits of the hardware when catching rare transitions.

***

The CDF sampling options are not saved in the setup.   It always defaults to auto. 

Thanks for catching this - will be fixed in v2.5.12.

[SJL-Instruments]

I appreciate trying to sell it into the hobbyist market... I can't afford new prices and my only choice is used. 

We've decided to offer a 35% hobbyist discount. That puts the 6200 model at under $1500. One of our hopes when launching the product was to give students/hobbyists access to 6+ GHz bandwidth who otherwise can't afford it. Sacrificing some margin to better achieve this goal is worth it to us.

If you're a hobbyist designing your own PCBs, it might not be as big of an issue to include SMA breakouts and/or a pretrigger. This compensates for the lack of probes (for now) and sequential sampling. This of course depends on the application. But being able to see things on the timescale of picoseconds is a qualitatively new capability.

[joeqsmith]

It's important for customers to feel confident that support will continue. We have baked the software development cost into the price of the product, and suspect that the earlier attempts did not.

I would hope anyone who has followed along would come to this conclusion. 

Trying out the new software now.   Shown with PAM16 30SPCDF and 10k min/max, followed by PAM16 with 100SPCDF.   Most of the error is my home made really poor setup I built for this test.  Too embarrassing to show that level of craftsmanship.       No doubt a real RF generator would do a much better job.   Next I changed to PAM8 with 100SPCDF, much better.  Then finally set the min/max to 20k.  Wow!  Sure it's slow, but still, very impressive.   

 

[joeqsmith]

That's one nice price break! 

If you're a hobbyist designing your own PCBs, it might not be as big of an issue to include SMA breakouts and/or a pretrigger. This compensates for the lack of probes (for now) and sequential sampling. This of course depends on the application. But being able to see things on the timescale of picoseconds is a qualitatively new capability.

For anything digital this may very well be the case. 

Shown with 20k min/max, 100SPCDF.  What is interesting about this plot is the areas where we see the speckles.  Of course, turn up the brightness, it is loaded with them.  Even with the min/max set to 30k.   PAM4 is certainly doable.   It will be interesting to see how the new firmware compares, but this is a huge step in the right direction!  Thanks.

[joeqsmith]

Going back to PAM4, single gate test (uneven distribution).  Note that the gaps are no longer present.   Any idea what causes there to be a harsh lines when looking at the speckles?  Note at the start of the first transition, they  are fairly sparse.  Then as we work our way to the next transition, they don't has the same density.   As the scope continues to sweep this pattern repeats. 

[SJL-Instruments]

Going back to PAM4, single gate test (uneven distribution).  Note that the gaps are no longer present.   Any idea what causes there to be a harsh lines when looking at the speckles?  Note at the start of the first transition, they  are fairly sparse.  Then as we work our way to the next transition, they don't has the same density.   As the scope continues to sweep this pattern repeats. 

This is a subtle point.

The root cause is the fact that we change the query voltage for all channels in parallel when acquiring CDF data. If the query voltage for Channels 1, 3, 4 (hidden) were fixed during CH2 acquisition, the speckles would not appear. A hacky way to do this is to set CH1,3,4 to 5 mV/div and CH3,4 offset to -10V to force the comparator outputs to a constant at each post-trigger delay, by always clipping the waveform.

There's a small (~100 uV) digital-to-analog crosstalk from the comparator output of CH1,3,4 to the analog input of CH2. Since the PDF is computed using CDF differences, this doesn't matter if the comparator outputs of CH1,3,4 are constant. But if they're not, then the input of CH2 is bumped up or down by ~100 uV depending on what the other channels are doing. This is enough to perturb the CDF up or down by a fraction of a percent, in a way that does not cancel upon subtraction.

Of course, when multiple channels are visible, the only way to avoid this is to issue one R command per visible channel, each keeping all but one query voltage constant.  This would slow down acquisition if multiple channels are visible. We could add this mode in software, and it would allow acquisition of very clean eye diagrams. But you're now probing the limits of the hardware.

To be clear, if you change the CH1 clock duty cycle, the speckled regions will change accordingly. If CH1,3,4, are always clipped (either high or low), the speckles should largely go away.

[joeqsmith]

Using above method with previous setup does indeed even out the speckles.   Interesting the speckles are constrained within the signals max/min voltage levels.   

I like these little insider snippets of what is going on.  When using a scope, no one is going to expect to see the spotted plague.  IMO, because it is such a deviation from the norm,  I would dedicate a section of the manual to explain why they are present, proper brightness adjustment, maybe include your previous post....

I assume the original work around was limiting the brightness, which created the other problems we have gone over.  While I can trim the brightness to remove all the speckles, I loose information at the switch points.   It's a tradeoff that I don't like.   Could some of that fancy dancy math of yours resolve the speckles at any brightness level? 

[SJL-Instruments]

I like these little insider snippets of what is going on.  When using a scope, no one is going to expect to see the spotted plague.  IMO, because it is such a deviation from the norm,  I would dedicate a section of the manual to explain why they are present, proper brightness adjustment, maybe include your previous post....

We will include all this information in the next manual revision. Eventually we'd like to turn this into a video with clear visuals.

I assume the original work around was limiting the brightness, which created the other problems we have gone over.  While I can trim the brightness to remove all the speckles, I loose information at the switch points.   It's a tradeoff that I don't like.   Could some of that fancy dancy math of yours resolve the speckles at any brightness level? 

The residual noise after clipping the hidden channels is largely due to the 256-level quantization of the CDF levels. This will be resolved by v14 firmware which will allow a 16-bit CDF return format.
If you bump the Nmin above 30k, the fallback to the direct CDF read mode will allow for higher CDF resolution (but will be horribly slow due to communication overhead). But this will give you a sense of what will be possible with v14.

There are fancier ways to reduce the speckles. Assuming temporal coherence, you can apply a Bayesian filter to improve the prior distribution for each subsequent acquisition. In plain terms, you can compare neighboring times with the assumption that the data should be similar to remove outliers. This should improve the situation significantly, but only works at high timebase resolutions. We'll see how well this works.

[SJL-Instruments]

Shahriar has just posted his review of the scope - linked below.
We left a comment with some responses, but it seems to have been blocked for now - hopefully it will get through soon.
Now posted.

[hpw]

Looking at 15:50 as Jitter-1.png and I would say this a must have for any OXCO clock or clock distribution to test as on AUDIO gear.

While most relay on PN given figures, as those used PN measurement gear measured simple the filtered sine signal of the square wave.

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

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.

Just my 2 cents

Hp

[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) ?