Pocket-Sized 6 GHz 1 TS/s ET Scope

[SJL-Instruments]

It seems that it limits the maximum data points to 3072.   It's a PC with basically unlimited resources.   Why is there such a limit?

Currently this is due to the way some algorithms (e.g. histograms) and display (e.g. OpenGL buffer size) are implemented. This limit can be drastically improved (to the ~million scale); it's just a matter of priority, and putting the work in. We can have it in by next update if you find it important.

Color grading would be much better. The worse thing about intensity grading is that you are typically interested in the parts of the signal which occur the least. At low (or near zero) intensity, that information is not visible. Some oscilloscopes (like the ones from R&S) even have reverse intensity grading which highlights the rarely occuring waveforms.

Color grading would be nice.  Of course, a lot of features, like changing the horizontal axis from time to distance would also be nice to have.  The attached screen shot was taken from the following PicoTech 9400 sampling scope training class:

https://eltesta.com/wp-content/uploads/2010/05/2010.07.01-Sampling-Oscilloscope-Training.-Munchen-Olympic-Tower.pdf

Note the several display styles they offer, Dots, Vectors, Variable Persistence.....   I don't think anyone would suggest the software is polished.  However,  I thought based on the following that they felt it was good enough and to drive the stake into the ground and move ahead.  Which is what I did.   

Using the power user mode to zoom in as much as possible and using the Light Mode and disabling vector trace mode for all channels.  This is about the best contrast I can get.   

Here is a prerelease version that significantly increases the range of the brightness slider, and adds color-grading:
https://gigawave-releases.s3.us-east-2.amazonaws.com/GigaWave_v2.5.10_PREVIEW_2022-02-17_Windows.zip
The scale of the color-grading (if enabled) can be controlled by the brightness slider.

When using very high intensity settings, there may be speckles within the open eye due to statistical noise in the CDF samples. These will reduce as the minimum number of triggers per CDF sample (Section 3.7.1) is increased.

Note that we are nominally out of office this weekend. But this was a small enough change, and is holding up the review.

You should review the product as it exists now.

For now, I will hold off with the review until they decide what they want to do.

We stand by this statement for 99% of the review - the product will continue to improve for the foreseeable future, and so any review must necessarily be a snapshot.
We singled out the eye diagram issue since it's one of the main target applications (signal integrity), and is being held up by a UI limitation. The cost-benefit tradeoff makes this point a bit silly not to address.
Overall, we found the review fair and very thorough. If the UI patch resolves the issue, we're happy for it to be published.

[joeqsmith]

Note that we are nominally out of office this weekend. But this was a small enough change, and is holding up the review.

I work full time, plus double downing on your product.   That's my level of commitment!     Sleep, what's that! 

Using the demo mode and comparing the previous version,  there is a slight improvement in the contrast.  It seems you feel this is one of the main selling points.  Before I spend time changing my review,  I want to make sure that you are satisfied with your software.  I can certainly postpone the review if you feel you can improve it.   

A bit of advice, because I assume you actually want to leverage these reviews for sales, in my experience, if I make a multi-part series,  the first and last videos will see the highest view counts.  If we make a follow up video showing software improvements, I doubt it will have half the views.  IMO, you really only get one chance at it.   For me, this isn't really a problem.  It's a small channel and isn't there to make money.  IMO, it is something you should consider.   Give it some thought and let me know.   

[joeqsmith]

Enable color grading, then disable the channel, waveform is still displayed.   Disable still works when color grading is turned off.   

Saving the defaults does not store the state of the color grading when it is selected.   

It seems that it limits the maximum data points to 3072.   It's a PC with basically unlimited resources.   Why is there such a limit?

Currently this is due to the way some algorithms (e.g. histograms) and display (e.g. OpenGL buffer size) are implemented. This limit can be drastically improved (to the ~million scale); it's just a matter of priority, and putting the work in. We can have it in by next update if you find it important.

My only goal was to improve the contrast of the eye by adding more data (further slowing down the collection).  It is more if you find it important.  It may not help.   

[SJL-Instruments]

Using the demo mode and comparing the previous version,  there is a slight improvement in the contrast.  It seems you feel this is one of the main selling points.  Before I spend time changing my review,  I want to make sure that you are satisfied with your software.  I can certainly postpone the review if you feel you can improve it.

The demo mode uses a simulated (idealized) eye diagram, and the contrast is already good with default settings. You will likely see a larger contrast improvement when using the actual hardware.

A bit of advice, because I assume you actually want to leverage these reviews for sales, in my experience, if I make a multi-part series,  the first and last videos will see the highest view counts.  If we make a follow up video showing software improvements, I doubt it will have half the views.  IMO, you really only get one chance at it.   For me, this isn't really a problem.  It's a small channel and isn't there to make money.  IMO, it is something you should consider.   Give it some thought and let me know.   

Fair points. Perhaps the single largest area of improvement is the sweep speed (as you mentioned in the review). As we estimated in our reply #282, it is theoretically possible to make the sweep 10-100x faster with careful firmware optimization.

We suspect this will take 2-4 weeks to get right and thoroughly test, but it will make a qualitative change in the viewer's first impression. It may be worth waiting until this improvement to post the review.

As a middle ground, perhaps you could link the (unlisted) current version of the review here. This will let the community members here voice their thoughts, and suggest anything they'd like to add. We also suspect that those who are following the thread closely enough to see the link will also watch an updated version when it becomes public.

[SJL-Instruments]

Enable color grading, then disable the channel, waveform is still displayed.   Disable still works when color grading is turned off.   

Saving the defaults does not store the state of the color grading when it is selected.   

Both fixed in below prerelease:
https://gigawave-releases.s3.us-east-2.amazonaws.com/GigaWave_v2.5.10_PREVIEW_2022-02-18_Windows.zip
Note that this feature will go through our normal QA process later this week, before the public v2.5.10 release.

It seems that it limits the maximum data points to 3072.   It's a PC with basically unlimited resources.   Why is there such a limit?

Currently this is due to the way some algorithms (e.g. histograms) and display (e.g. OpenGL buffer size) are implemented. This limit can be drastically improved (to the ~million scale); it's just a matter of priority, and putting the work in. We can have it in by next update if you find it important.

My only goal was to improve the contrast of the eye by adding more data (further slowing down the collection).  It is more if you find it important.  It may not help.   

For this purpose, increasing this limit will likely not help. 3072 points is already finer than the pixel resolution of the display.

[joeqsmith]

I have updated the review to include the new software with the color grading feature.   

[SJL-Instruments]

I have updated the review to include the new software with the color grading feature.   

Just saw you posted the review - thanks for the last-minute change. We're quite happy with how it turned out, and grateful for your patience and constructive suggestions over the past month.   

Do you mind if we link to/embed your video on our website?

Going forward, feel free to continue posting any suggestions or feedback here. (This of course includes any new viewers coming from the video.) Next software update is scheduled for this coming weekend.

[joeqsmith]

We're quite happy with how it turned out, and grateful for your patience and constructive suggestions over the past month.   

It was my pleasure.  Its always such a treat to work with people like yourself who are interested in improving their products. 
 

Do you mind if we link to/embed your video on our website?

Not at all.  I also suggest you link it to your very first post in this thread to make is easier to find as the thread grows.

[joeqsmith]

They have released new software which includes an auto setup.   It's a big improvement over what I showed during my review of the 6400.   Some of it is still a bit crude.  For example, they allow you yo change the color for the min/max but entering in (guessing a 32-bit) hex number.  By a show of hands, how many of you have that memorized?   Most software is going to present the user with a color wheel, with a simple point click. 

I would like to see a single button select for basic horizontal or vertical measurements with trending.   Maybe more useful than a way to sweep faster.   

When vectors are disabled, what prevents you from calculating Tr?  Don't you have all the data needed for this measurement?   

Version 2.5.10 (2024-02-23):
- Automatic setup for vertical offset/scale and trigger level.
- Color-grading for multivalued signals
- Allow double-click when selecting device on startup
- Always show reset button when vertical scale is "Custom"
- Allow smaller vertical scales (1 mV/div)
- Keep settings from last closed FFT window when opening new one
- Include FFT configuration when saving settings
- Bugfix: Dialog boxes briefly flash on startup

[SJL-Instruments]

Some of it is still a bit crude.  For example, they allow you yo change the color for the min/max but entering in (guessing a 32-bit) hex number.  By a show of hands, how many of you have that memorized?   Most software is going to present the user with a color wheel, with a simple point click. 

Our plan was to release v2.5.11 tomorrow (Sunday) and post a notification here. This version includes a GUI color picker (among other features). Other features are currently going through QA.
The v2.5.10 minor update was needed for another reviewer this weekend (in particular the color-grading feature).
 

I would like to see a single button select for basic horizontal or vertical measurements with trending.   Maybe more useful than a way to sweep faster.

To clarify, do you mean a button which adds several basic measurements at once for a specified channel?
By trending, do you mean min/max/avg measurements?

When vectors are disabled, what prevents you from calculating Tr?  Don't you have all the data needed for this measurement?

Yes, but only if the signal is single-valued at each point in time. In an eye diagram with double-edging, for example, it's ambiguous which feature Tr should be calculated for.
In the case where the signal is single-valued, the software would extract the average and then calculate Tr. This is equivalent to having vector trace mode on. For clarity, we chose to require vector mode to be enabled (as to not produce garbage with multivalued signals).

***
For next update (~March 9), we'll see if it's possible to reliably detect when the signal is single-valued. Then all measurements would be available with vector mode disabled, but would give an error if they cannot be accurately calculated.

[joeqsmith]

I would like to see a single button select for basic horizontal or vertical measurements with trending.   Maybe more useful than a way to sweep faster.

To clarify, do you mean a button which adds several basic measurements at once for a specified channel?
By trending, do you mean min/max/avg measurements?

For example basic horizontal would be frequency, period, rise/fall, width, duty cycle ...  Trends would be min,max, p-p, avg, std-dev...   (histograms would also be nice) See attached for example.   Adding basic measurements is a pain.  Having the ability to save the settings has been very useful but not a work around.     

When vectors are disabled, what prevents you from calculating Tr?  Don't you have all the data needed for this measurement?

Yes, but only if the signal is single-valued at each point in time. In an eye diagram with double-edging, for example, it's ambiguous which feature Tr should be calculated for.
In the case where the signal is single-valued, the software would extract the average and then calculate Tr. This is equivalent to having vector trace mode on. For clarity, we chose to require vector mode to be enabled (as to not produce garbage with multivalued signals).

I'm surprised the software can't back it out or just have two processing paths.  I get what you are saying about avoid showing garbage but it seems odd that it can't make basic measurements in all modes. 

For next update (~March 9), we'll see if it's possible to reliably detect when the signal is single-valued. Then all measurements would be available with vector mode disabled, but would give an error if they cannot be accurately calculated.

It may be a good tradeoff. 

[joeqsmith]

From the manual:

When vector trace mode is disabled, the full distribution of the measured signal is displayed with
intensity grading.

While you have described how to calculate the voltage for a given time, you do not explain how this full distribution is derived.   Can you provide more details?  Are you still working with the same set of data from the R command?  If so, do you still toss out the same outliers? 

... if the signal is single-valued at each point in time.

   
I assume that this full distribution is needed to see the multiple points in time. 

When vector trace mode is enabled, the channel is drawn with one continuous line that follows
the average of the measured sample distribution. The standard deviation will be shown as a band
around the trace, indicating of the noise level.

I assume this standard deviation is also looking at the same full distribution.   

[SJL-Instruments]

From the manual:

When vector trace mode is disabled, the full distribution of the measured signal is displayed with
intensity grading.

While you have described how to calculate the voltage for a given time, you do not explain how this full distribution is derived.   Can you provide more details?  Are you still working with the same set of data from the R command?  If so, do you still toss out the same outliers? 

The full probability density function (PDF) is obtained by numerically differentiating the CDF data from the R command. You can implement this with a finite difference. Nothing is tossed out.

... if the signal is single-valued at each point in time.

   
I assume that this full distribution is needed to see the multiple points in time. 

When vector trace mode is enabled, the channel is drawn with one continuous line that follows
the average of the measured sample distribution. The standard deviation will be shown as a band
around the trace, indicating of the noise level.

I assume this standard deviation is also looking at the same full distribution.   

Yes, the full distribution is required for multivalued signals such as eye diagrams.
The standard deviation can be calculated from the PDF. The software calculates it directly from the CDF for numerical efficiency (integration by parts), but it gives equivalent results.

[joeqsmith]

... we'll see if it's possible to reliably detect when the signal is single-valued.

Based on your last response, your previous post makes more sense.  So, you assume if the vectors are turned off that the user is looking at multi-value points and hence, turn off the math calculations.  It's not that you can't calculate them assuming it is single value points, you just don't, at least for now.   

Much more clear to me now.  Thanks.

[SJL-Instruments]

For example basic horizontal would be frequency, period, rise/fall, width, duty cycle ...  Trends would be min,max, p-p, avg, std-dev...   (histograms would also be nice) See attached for example.   Adding basic measurements is a pain.  Having the ability to save the settings has been very useful but not a work around.     

We have just released v2.5.11 of the software which contains these features. Histograms are scheduled for next update, but for now the measurement history can be exported as a CSV.

Changelog (https://www.sjl-instruments.com/software/):
- Allow measurements to be edited
- Track measurement statistics (min/max/avg/pp/stdev/etc.)
- Export measurement data
- Add pulse width measurements
- Quick add all standard horizontal/vertical measurements for a channel
- Quick remove all measurements for a channel
- Automatic reconnect if scope is unplugged
- Color picker for min/max
- Bugfix: Brightness slider does not respond smoothly at low update rate
- Bugfix: Attenuation does not update when acquisition stopped
- Bugfix: Measurements loaded improperly from settings file when measurements exist

[joeqsmith]

Looks like the actual changelog was not updated.   

Nice job with the new release. 

[SJL-Instruments]

Looks like the actual changelog was not updated.   

Nice job with the new release. 

It may be cached by your browser. Try a refresh - this goes for the manual as well.

[joeqsmith]

Ran the new software a fair amount and did not find any problems.   Looks like you fixed some of the minor problems I saw with the previous versions.   I like you are taking the time to clean it up as well as adding features.   I like the new dialog readout.   The auto setup has been working well for me.  A time saver.  I like that I can tune the time base to get it close and have it auto adjust from there.  It was a good idea.

IMO, the two big ticket items now are programming the FPGA and microcontroller over the USB, if it is even possible.  The other is or course, can it be sped up with a loss of performance.   I make use of the manual resolution settings to hunt down the timing but that only helps so much.  Having a way to sweep faster would be very helpful even suing the setup phase.

While making the review, I though about comparing it with my old LeCroy 7200 while looking at an ignition signal.  The problem is that I am working with trigger rates <500Hz.  The scope is currently just too slow for this application.   It may be a case where it just isn't going to be a good fit for this application.   

[SJL-Instruments]

Ran the new software a fair amount and did not find any problems.   Looks like you fixed some of the minor problems I saw with the previous versions.   I like you are taking the time to clean it up as well as adding features.   I like the new dialog readout.   The auto setup has been working well for me.  A time saver.  I like that I can tune the time base to get it close and have it auto adjust from there.  It was a good idea.

Thanks for the feedback. Glad to hear that the recent features have been helpful, and that no new bugs have cropped up.

IMO, the two big ticket items now are programming the FPGA and microcontroller over the USB, if it is even possible.  The other is or course, can it be sped up with a loss of performance.   I make use of the manual resolution settings to hunt down the timing but that only helps so much.  Having a way to sweep faster would be very helpful even suing the setup phase.

USB-based DFU for the FPGA and microcontroller is possible with the current hardware. It just takes time to implement. Our plan is for the next firmware revision (v14) to be the last one requiring external flashing hardware.

So far we have sped up the firmware by a factor of ~3 compared to v13. Above 500 ktrig/s, we can achieve at least 30x practical speedup based on our accounting of timings. This also just takes time.

Before release, will also need to rerun our glitch/performance/temperature tests for at least a week, as these are substantial firmware changes. It's a bit early to give an ETA, but we're aiming for end of March.

While making the review, I though about comparing it with my old LeCroy 7200 while looking at an ignition signal.  The problem is that I am working with trigger rates <500Hz.  The scope is currently just too slow for this application.   It may be a case where it just isn't going to be a good fit for this application.   

The theoretical minimum acquisition time for one point @ 500 Hz trigger rate is 12*2 ms = 24 ms for 12-bit resolution, with 1 trigger per CDF sample. At 4 pts/div, this is ~1 second per sweep. Slow, but usable.

For comparison, we measure ~250 ms required with firmware v13 @ Nmin=5, Nmax=5, K=12 with 500 Hz trigger. We measure ~15 seconds/sweep with these settings @ 500 Hz.
So practically, there's a factor of 10 to be gained at low trigger rates.

Asymptotically, CDF sampling requires about the same number of triggers as an ADC sampler, when the full distribution (noise, eye diagram) is required. (Section 2.1.2, point 3.) This holds in the limit of many points acquired. But for single-valued signals where only 1 sample is needed, CDF sampling requires 12x more triggers for a 12-bit resolution.

[joeqsmith]

From the manual:

When vector trace mode is disabled, the full distribution of the measured signal is displayed with
intensity grading.

While you have described how to calculate the voltage for a given time, you do not explain how this full distribution is derived.   Can you provide more details?  Are you still working with the same set of data from the R command?  If so, do you still toss out the same outliers? 

The full probability density function (PDF) is obtained by numerically differentiating the CDF data from the R command. You can implement this with a finite difference. Nothing is tossed out.

... if the signal is single-valued at each point in time.

   
I assume that this full distribution is needed to see the multiple points in time. 

When vector trace mode is enabled, the channel is drawn with one continuous line that follows
the average of the measured sample distribution. The standard deviation will be shown as a band
around the trace, indicating of the noise level.

I assume this standard deviation is also looking at the same full distribution.   

Yes, the full distribution is required for multivalued signals such as eye diagrams.
The standard deviation can be calculated from the PDF. The software calculates it directly from the CDF for numerical efficiency (integration by parts), but it gives equivalent results.

While it seems simple enough, based on my past history, let's start out making sure I am interpreting your comments correctly.  Shown is the PDF for your example data from 4.3.3.   Assuming this is correct, you just directly plot this data when the vector is disabled?

[SJL-Instruments]

You should also take the differences of the voltage array, and perform a division. The PDF is given by dF/dV.

[joeqsmith]

You should also take the differences of the voltage array, and perform a division. The PDF is given by dF/dV.

Shown with diff and division for example.  Numbers seem very high.  When you plot this, do these values go through another conversion?

[SJL-Instruments]

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.

[joeqsmith]

Thanks for double checking my work.    It's interesting how this thing works.   I will need to think about how best to plot it.   

Poor mans PAM4 simulation gets a bit messy.   You can turn down the brightness to remove some of the dots, but the switch points will wash out.   Of course the question is if my test signal actually has this much noise.   

[SJL-Instruments]

Thanks for double checking my work.    It's interesting how this thing works.   I will need to think about how best to plot it.   

Poor mans PAM4 simulation gets a bit messy.   You can turn down the brightness to remove some of the dots, but the switch points will wash out.   Of course the question is if my test signal actually has this much noise.   

This results from statistical noise in the CDF samples. What value for Nmin (minimum triggers per CDF sample) are you using? The noise will reduce as you increase this value.