Pocket-Sized 6 GHz 1 TS/s ET Scope

[joeqsmith]

Can you specify exactly which delays you are trying to take data at, and the delay/number of commands at which you start seeing an error (for e.g. a trigger holdoff of 50 ns and at 500 ns)? This will help us when trying to reproduce your error.

See attached image.  Post trigger delay set to 110000, trigger holdoff set to 50, stepping by 500ps for 1ns or 20 steps.  Third response was a timeout.  Increasing the trigger holdoff will allow it to run without the timeout.  The smaller I step the post trigger delay,  the more I must increase the trigger holdoff for it not to timeout.  Stepping by 5ps for example requires a trigger holdoff of around 2500.   I suspect there is more to the holdoff than the simple explanation in the manual. 

To clarify what you mean by "behaves the same:" are you referring to the need to start our software first, or that you are seeing errors past some number of samples? If the former, then the extra parameters to the R command should have resolved the issue. If the latter, then the level settings are likely not related to the root cause.

Behaves the same meaning it will send the NO TRIG ZERO SJLI or NO TRIG TIMEOUT nn SJLI in response to the R command.  Startup is now fine. 

[SJL-Instruments]

The screenshot shows a "current trigger delay" of 2210000. Does this mean you are sending the command D2210000? This corresponds to a delay of 221 nanoseconds and would explain the error message.

[joeqsmith]

     

Good catch!!  It is now working as expected.  2ns of recording a 2GHz signal with 10ps resolution.  Calibration is ran every half second with linear interpolation. 

I would like to know more about how you perform the fit. 

When you perform your Gaussian fit, you truncated the CDF within 10-90%) then  mirror the CDF, then fit to that shape?  I assume you are not fitting to the CDF's S shape directly.

I could toss something in there easy enough. 

Good to see the basics now working.  Thanks!!

[SJL-Instruments]

Good catch!!  It is now working as expected.  2ns of recording a 2GHz signal with 10ps resolution.  Calibration is ran every half second with linear interpolation. 

We've been there before too  . Glad your custom software is working now!

I would like to know more about how you perform the fit. 

When you perform your Gaussian fit, you truncated the CDF within 10-90%) then  mirror the CDF, then fit to that shape?  I assume you are not fitting to the CDF's S shape directly.

You can fit to the CDF's S shape directly after truncating all points between 0.1 and 0.9. This works fine but is processor-intensive. You may also want to experiment with reducing the truncation bounds (e.g. to 0.2-0.8 ). Narrower bounds will use fewer samples and thus increase noise, but will also improve robustness to outliers.

In the official software we use a more efficient method that turns out to be equivalent to first-order (in a precise statistical sense) - more details are in our response #97:

We don't mirror the CDF, but instead apply the inverse CDF to the data, such that a perfect Gaussian error CDF would become a straight line. When you do this, the points on the edges will have their noise significantly amplified, and you need to weight them by 1 over the squared derivative of the inverse CDF to avoid blowing up the fit. The points are truncated to the 10-90% CDF region, as well as dropping any points that are more than 2 standard deviations from the central value determined via the interpolation method.

[joeqsmith]

Checked your specified rise time.  35 and change, pretty impressive.  Plan is to run this through that coax filter and see if you can de-embed it. 

https://www.eevblog.com/forum/testgear/show-us-your-square-wave/msg5284957/#msg5284957

[points2]

Checked your specified rise time.  35 and change, pretty impressive.  Plan is to run this through that coax filter and see if you can de-embed it. 

It looks like you appreciate this device 

Apart from your exchange with SJL vs high level stuff (please go on, it is usefull whatever our level in the field)
=> what's your feedback about the perf of the GigaWave you got (2/4/8 CH ?)

I'm on the waiting list... waiting for EU approval 

[luudee]

So if you do 1 Tsample/s at 12 bits, thats 12 Tbits/sec ?!  How do you transfer that over a 40 gb/s USB ?!

rudi

[Berni]

So if you do 1 Tsample/s at 12 bits, thats 12 Tbits/sec ?!  How do you transfer that over a 40 gb/s USB ?!

rudi

1 TS/s refers to the timing resolution of the reconstructed waveform. To be fair these are sort of meaningless numbers once you get to timing resolutions this high, the 6GHz bandwidth is the impressive part.

Actual sample rate is 25MS/s since this is a sampling scope, not a real time scope.

[SJL-Instruments]

Checked your specified rise time.  35 and change, pretty impressive.  Plan is to run this through that coax filter and see if you can de-embed it. 

https://www.eevblog.com/forum/testgear/show-us-your-square-wave/msg5284957/#msg5284957

Thanks! Yep, the typical rise time on the datasheet is conservative.

S-parameter import is working with live de-embedding in the software. UI still in progress (we'd like to show the reconstructed step response, display the calculated the system risetime, etc), but at its core you just click "de-embed" and import an s2p file. Should be out by Sunday.

1 TS/s refers to the timing resolution of the reconstructed waveform. To be fair these are sort of meaningless numbers once you get to timing resolutions this high, the 6GHz bandwidth is the impressive part.

Actual sample rate is 25MS/s since this is a sampling scope, not a real time scope.

We would say that 1 TS/s is "overkill" for 6 GHz, but not meaningless. The device can physically take samples with sub-ps average timing reproducibility. This is important in sampling oscilloscopes, where in general sinc interpolation is not possible (for multi-valued signals) and you cannot Nyquist your way into higher displayed timing precision.

But as you said, at some point bandwidth is bandwidth and you can't de-embed your way into creating bandwidth where it doesn't exist. 

Max trigger rate is 25 Mtrig/s (limited only by min 40 ns holdoff), but this is not a "sample rate" in the way you're used to (we have a unique architecture). 4 MSa/s is a rough conversion, but see Section 2.1.2 "CDF Sampling" in the manual for details:
https://www.sjl-instruments.com/user-manual.pdf

[joeqsmith]

Checked your specified rise time.  35 and change, pretty impressive.  Plan is to run this through that coax filter and see if you can de-embed it. 

It looks like you appreciate this device 

Apart from your exchange with SJL vs high level stuff (please go on, it is usefull whatever our level in the field)
=> what's your feedback about the perf of the GigaWave you got (2/4/8 CH ?)

I'm on the waiting list... waiting for EU approval 

you said earlier : Shahriar's review is queuing... and we reveiw is expected in "a while"
Speed up the process and send your product to any guys (many experts, with many posts & high reliability) in this forum. Pretty sure sure they will do a far better review than Shahriar, because quick & relevant vs the potential of your device for hobbyist.
Don't get me wrong, Shahriar reviews are 1st-class... but it's all about "pro" stuff @ price tag way above the hobbyist budget (see its last videos) ; but any hobyist can learn form him, and that's ok.
All  the best 

It seems they took your comment to heart as SJL provided me with one of the early 4 channel DSOs to review.  You can see a photo of it in the previous link I provided where I measured a pulse to check the performance.  I have been working on putting together a video, which is what is driving the dialog here.   

Once I have the delay line assembled and characterized, and the software adds support to de-embed, I can start trying some other tests.  There are other features I would like to see added to the software before getting into it too deep.    Someone asked about stability of the edge over time for example.  There's not a good way to do this today but it is one of the things I had requested they add.   Of course, there is always the option to write custom code to run some of these experiments as well, but I would rather utilize their software. 

[joeqsmith]

Checked your specified rise time.  35 and change, pretty impressive.  Plan is to run this through that coax filter and see if you can de-embed it. 

https://www.eevblog.com/forum/testgear/show-us-your-square-wave/msg5284957/#msg5284957

Thanks! Yep, the typical rise time on the datasheet is conservative.

S-parameter import is working with live de-embedding in the software. UI still in progress (we'd like to show the reconstructed step response, display the calculated the system risetime, etc), but at its core you just click "de-embed" and import an s2p file. Should be out by Sunday.

Fantastic.  I should have everything ready to go by then.   For the Tr, that coax isn't doing it any favors.

***
Are you planning to allow one Touchstone file for each channel?   For the coax model, did you allow to enter a single value for the insertion loss?   

Are you going to support a variable gain rather than just having it fixed? 

[SJL-Instruments]

Are you planning to allow one Touchstone file for each channel?   For the coax model, did you allow to enter a single value for the insertion loss?

The de-embedding settings will be independent for each channel (i.e. yes, you can have different Touchstone files for every channel). You will be able to either import s-parameters, or specify the list of everything (coax cables, splitters, attenuators, etc) in the chain. Coax cables will have a parameter for insertion loss, and you can specify multiple cables between DUT and scope.

Are you going to support a variable gain rather than just having it fixed? 

Could you clarify what you mean? For splitters/attenuators/cable insertion loss/etc you will be able to enter in the loss in dB.

[joeqsmith]

De-embed sounds perfect. 

As the setup gets more complex, having a way to save all the settings (including the links to the Touchstone files) becomes more important. 

If you get everything done on the list and are looking for something to add,  please consider some sort of auto edge search.  The software would start with some defined sweep range, using very low resolution, search for a edge.  Center around that and increase the resolution.   Maybe you could also support searching for the highest or lowest peak.  Other?  It's a bit of a pain to hunt down signals.  I set the samples to 4 with several ns per division, find what I want, drag it to the center, manually zoom in a bit, fine tune the center, rinse and repeat until I get what I want.   Having a way to automate this would be handy IMO. 

Could you clarify what you mean? For splitters/attenuators/cable insertion loss/etc you will be able to enter in the loss in dB.

As far as I know, your software only allows a fixed volts per division for the vertical axis.  I want to be able to set this to what ever I want.  I will use this with my scopes to make better use of the plot area or overlay different channels that have signals with different gains.  Once we moved away from mechanical clunky rotary switches,  I suspect most DSOs supported this.   

[joeqsmith]

With LabView sorted, I can have a look at temperature drift.  Manual states 50C operating...

[SJL-Instruments]

As the setup gets more complex, having a way to save all the settings (including the links to the Touchstone files) becomes more important. 

Yep, this should hopefully come out in the next update (together with waveform save/recall).
This has been implemented in v2.5.5 (released 2024-01-21).

If you get everything done on the list and are looking for something to add,  please consider some sort of auto edge search.  The software would start with some defined sweep range, using very low resolution, search for a edge.  Center around that and increase the resolution.   Maybe you could also support searching for the highest or lowest peak.  Other?  It's a bit of a pain to hunt down signals.  I set the samples to 4 with several ns per division, find what I want, drag it to the center, manually zoom in a bit, fine tune the center, rinse and repeat until I get what I want.   Having a way to automate this would be handy IMO. 

Got it - added to the list. The UI for this needs some careful thought.

As far as I know, your software only allows a fixed volts per division for the vertical axis.  I want to be able to set this to what ever I want.  I will use this with my scopes to make better use of the plot area or overlay different channels that have signals with different gains.  Once we moved away from mechanical clunky rotary switches,  I suspect most DSOs supported this.   

Thanks for the clarification. We'll probably implement this by changing the dropdown into a textbox when the advanced settings panel is opened. Using the scroll wheel on the channel marker will snap to the nearest predefined value (if a custom value was entered). What are your thoughts on this?

With LabView sorted, I can have a look at temperature drift.  Manual states 50C operating...

Looking forward to seeing your results.

[joeqsmith]

For input on your UI's look and feel, outside of running a poll, you could check out some of the software for the large companies.  IMO, anything to reduce keystrokes and not requiring a cheat sheet of hot keys is a plus.

Temperature testing at home is a very slow process.     

[joeqsmith]

Adjustable delayline for the Gigawave provides pretrigger of 10.5 to 11.5. 

[joeqsmith]

Labeled the connectors and added some rubber feet.   I do like these extruded aluminum boxes. 

[joeqsmith]

Showing the GigaWave with attached delayline.  LiteVNA was used for a signal source.  Shown with the delayline set to its minimum and maximum values. 

[joeqsmith]

Just a short update on my review of the GigaWave sampling oscilloscope.   So far all I have managed to create was the unboxing.    There is a lot going on behind the scenes as they continue to make improvements for me.   Their documentation is also shaping up nicely.   

As promised, SJL has provided me with a pre-release which supports s-parameter de-embedding.   I used the LiteVNA + Solver64 to sweep my delayline from 5kHz to 8GHz to create a Touchstone file.  The LiteVNA uses harmonics above 6GHz and the data is pretty poor.   Still, importing the file into their GigaWave software, it appears to work correctly.   For the review, I'll use my Agilent PNA to properly characterize the delayline.   

It all takes time.  Hope to begin working on the actual video in another week. 

[SJL-Instruments]

Showing the GigaWave with attached delayline.  LiteVNA was used for a signal source.  Shown with the delayline set to its minimum and maximum values.

Nice work with the analog delay line! 

As promised, SJL has provided me with a pre-release which supports s-parameter de-embedding.   I used the LiteVNA + Solver64 to sweep my delayline from 5kHz to 8GHz to create a Touchstone file.  The LiteVNA uses harmonics above 6GHz and the data is pretty poor.   Still, importing the file into their GigaWave software, it appears to work correctly.   For the review, I'll use my Agilent PNA to properly characterize the delayline.

Glad to hear that de-embedding and s-parameter import are working. As promised, we've now publicly released v2.5.5 of the software which contains this feature:
https://www.sjl-instruments.com/software/

The accompanying manual has also been significantly expanded (revision H4, refresh if not updating for you):
https://www.sjl-instruments.com/user-manual.pdf

[joeqsmith]

... as I like to trigger a LVCMOS edge and analyze the variations of like 20%..80% rise time over time as also some Chatter.

Looking at 5ps resolution of LiteVNA output using their supplied cable.  The min/max are shown to provide you with some idea on the variance.  This is roughly 1 hour of data.  Also shown is the 3D graph of all of the sweeps, along with the baseline subtracted. 

My software does not make use of the glitch detection mentioned in the latest manual, although it was my collecting over long periods like this that raised the question about the glitches. 

[SJL-Instruments]

My software does not make use of the glitch detection mentioned in the latest manual, although it was my collecting over long periods like this that raised the question about the glitches. 

For transparency, the relevant manual section is 4.3.3 ("single-point upsets") - a small fraction of returned CDFs may have an error in one point. These errors can be caught by looking for non-monotonic CDFs (which is the workaround mentioned in the manual).

The official software implements this workaround, so this primarily affects users who directly query the serial interface. We are tracking down the root cause of the glitches, and will issue a firmware update when it is resolved.

[joeqsmith]

This was one of the plots showing the glitch problem using my software.  The Gigawave software did not allow for min/max detection and I had not noticed the problem until I started writing my own.  I assumed it was a bug in my code, but I was eventually able to capture a few glitches using the released software.    SJL was then able to replicate the problem with one of their units.   

As it stands, glitches appear more often towards the start of the sweep and are negative going.  I have seen positive glitches throughout the sweep but these seem less prevalent.     

While I have tried their latest software, there is no min/max function and I have to watch the screen looking for a glitch.   It appears to correct it but until we get some way to track these kinds of problems, I am not certain.

I had thought about implementing their error checking/recovery but I wasn't sure how to interpret the manual.   Using their example in 4.3.2, where they show 15 pairs, I would assume they run through all four conditions for 14 sets.   This assume "either of" meant to "OR" the two "ANDed" checks.  An example would have helped remove any ambiguity. 

the issue can be circumvented by discarding and retaking CDF data that meets either of the following two criteria:
• Two neighboring voltages V1, V2 satisfy V2−V1 >5 mV and F(V2;Δt)−F(V1;Δt) < −0.1.
• Two neighboring voltages V1, V2 satisfy V2 > V1 and F(V2;Δt) − F(V1;Δt) > 0.9.

For the review, I plan to use their software and decided to wait for them to solve it.   While they seem confident the problem is firmware, it seems the have not yet found the root cause and I would not rule out hardware.  It will be interesting to hear what they find. 

There are a few other minor problems I ran into.  High offset voltage for example.  The plan is to add a way to correct for this in the software.  The one concern I have raised was how they plan to de-skew the channels.  While they have made a lot of progress, it's a new product.  Based on how responsive they've been, I'm confident any concerns I have will be addressed as the product matures.   

[SJL-Instruments]

I had thought about implementing their error checking/recovery but I wasn't sure how to interpret the manual.   Using their example in 4.3.2, where they show 15 pairs, I would assume they run through all four conditions for 14 sets.   This assume "either of" meant to "OR" the two "ANDed" checks.  An example would have helped remove any ambiguity. 

the issue can be circumvented by discarding and retaking CDF data that meets either of the following two criteria:
• Two neighboring voltages V1, V2 satisfy V2−V1 >5 mV and F(V2;Δt)−F(V1;Δt) < −0.1.
• Two neighboring voltages V1, V2 satisfy V2 > V1 and F(V2;Δt) − F(V1;Δt) > 0.9.

We've provided an example (attached) in the next manual revision. Let us know if this is clear. It should eliminate the glitches you're seeing.

The one concern I have raised was how they plan to de-skew the channels.

Just to clarify: We could make a test fixture that outputs two synchronized fast rising edges. You'd then connect CH1 to one output, CH2 to the other, and click a button. Repeat with CH3,CH4,etc in place of CH2. This would compensate for any probe length mismatches. Would this fit the bill?

Note that the inherent channel-to-channel skew is 15 ps max without any deskew. If a deskew offset is used, then data acquisition will be slower (and depend on the number of active channels), as data can no longer be acquired in parallel for all channels.