Pocket-Sized 6 GHz 1 TS/s ET Scope

[SJL-Instruments]

For automated tests, we have an open-source Python API available on the software page that exposes (in principle) the same functionality as the main software. (We know isn't quite the same thing as an interface toolkit.) EDIT 2024-01-13: The serial interface is now documented in Section 4 of the manual.

Yes, the interface currently allows saving only one trace at a time. We will improve this feature to support multi-channel export by the end of the week.
Implemented as of 2024-01-11.

We'd like to clarify what you mean about showing all the data: samples are taken while the trigger-to-sample delay is increased incrementally from t_min (left screen) to t_max (right screen). The data on the screen is the only data that can be reasonably assumed to be up-to-date (within a couple seconds). For example, if you unplug the signal source and then zoom out, the revealed data will be stale.
We choose to erase this potentially stale data. Keeping this data is an equally consistent option. Is this what you are proposing?

By "time marker," you mean a marker at T=0, correct?
EDIT: Implemented 2024-01-11.

The minimum trigger-to-sample delay is 11 ns. We recognize this disqualifies some measurement setups.
During development, we made prototypes with minimum trigger-to-sample delays of ~2 ns, but either at the expense of (1) worse time accuracy of ~3 ps RMS and thus worse ENOB, (2) significantly higher cost, or (3) exceeding USB 3 power budget. We chose lower cost, higher ENOB, and power-over-USB with 11 ns dead time.
(There isn't a good way around the delay itself - any sequential sampling scope will not be able to view the edge it is triggering on, without a synchronized clock signal or an analog delay line.)

Low rep-rate signals:
There are three ways to speed up acquisition for low-rep-rate signals:
1. Decrease timebase resolution (pts/div option in "Timebase"),
2. Decrease number of samples per CDF. [Default 30, not currently exposed in software]
3. Decrease the number of triggers per CDF sample. [Default 4096, not currently exposed in software]
The second option gives limited speedup since you really need >=10 samples to get something meaningful.
The third option defaults to 4096 triggers per sample and decreases with increasing trigger holdoff to maintain roughly constant sweep rate.

We will expose these options to the user (next update, by EOW now implemented). As they affect the reconstruction timescale [User Manual Sec 2.2] and other details, there are also some subtleties we need to explain in the documentation.
(This is one of the things that we hope to demonstrate better in our planned videos).

An ignition system @ 1 ktrig/s would take 30 seconds per sweep @ 3 triggers/sample for 1 kpts @ 10 samples/CDF.
A source @ 120 ktrig/s would take 8 seconds per sweep @ 30 triggers/sample for 1 kpts @ default 30 samples/CDF.
(For your Tektronix pulse source, you would need to tap into a >11 ns pretrigger for CH1 and send the rising edge into CH2.)

Curious to hear your honest opinions on the above.

Edit re: mask testing. We currently do not have this implemented in software. We have this planned, and the firmware has provisions for fast mask testing (i.e. direct counts of mask failures, which is important when you are trying to count rare events).

Edit 2 re: Rewrite the discussion on low rep rates.

[mawyatt]

Oooooh you're directly measuring the CDF not the PDF?

Sounds like you built the concept I tossed over years ago called FREESAMPLE (as in "free/open source sampling scope").  I have an incomplete design https://github.com/azonenberg/freesample if you're curious but realized I didn't know enough about high speed design at the time and tabled it. I had successfully prototyped the concept at 10 Gsps in a PMOD hanging off a Xilinx FPGA but never took it to its logical conclusion so I'm happy someone else is exploring the technology.

Your docs are light about internal details and I understand if you don't want to share all your secrets yet but here's my crack at theory of operation based on how my design worked: Variable delay line after trigger comparator (my design had a CDR PLL option as well, not sure if you have that... looks not?) driving the latch port of a high speed latching comparator fed by the signal. At the time I did my design the best option was the Hittite (now ADI) HMC674/675 which had around 10 GHz analog BW. Other input of the comparator driven by a DAC (12 bits in your case).

Each trigger collects one bit of data: the input was or was not greater than Vdac at time offset T.

Repeat a large number of times and divide by the number of triggers to get the probability of the signal being less than Vdac at time T, then sweep Vdac and T across the display range to measure the CDF of the signal.

Partial derivative of CDF with respect to dV then gives the PDF, aka intensity graded waveform.

EDIT: Not sure how your capture system works. The advantage of my architecture was that if you went with the PLL based sampler rather than the delay line sampler you'd get multiple samples per trigger at the PLL output frequency (which could be divided down a lot from your symbol rate, say one sample per 8 UIs or something). You could then capture this with an FPGA input at fairly high rates. I forget the details but I think I was aiming for circa 1 Gsps realtime (1 bit) sample rate using a 7 series ISERDESE2. This approach also avoids jitter getting too high due to excessive analog delay (since you can delay by fractional or integer PLL cycles to get arbitrarily long delays) and allows arbitrarily deep memory.

Am I pretty close?

At the time did you look into the Hittite HMC661 Sampler?

The origins of which date back to 1999~2000 when we were developing the first RF/MW SoC and worried about Digital and Analog/RF isolation/corruption. As a "Plan B" we employed Q Dot to develop an Emitter Follower based Sampler in IBM SiGe to sample the MW signal between the digital clock edge "quiet time". Plan B wasn't required as we developed and patented a chip isolation scheme that worked, however the Sampler also worked well and became a product after Semtech acquired Q Dot and later sold to Hittite. Q Dot became a means for Hittite moving into SiGe technology.

Best,

[joeqsmith]

For automated tests, we have an open-source Python API available on the software page that exposes (in principle) the same functionality as the main software. (We know isn't quite the same thing as an interface toolkit.)

Yes, the interface currently allows saving only one trace at a time. We will improve this feature to support multi-channel export by the end of the week.

Thanks on both of these.  I'll check into it the API. 

We'd like to clarify what you mean about showing all the data: ...

By "time marker," you mean a marker at T=0, correct?

Assuming you define T=0 as the trigger, then yes.  I expect to be able to see data before and after the trigger but it seems this isn't possible with your oscilloscope.

My comments about the displaying the various channels on separate graphs is common. Having four  traces on a single graph can get cluttered. 

The minimum trigger-to-sample delay is 11 ns. We recognize this disqualifies some measurement setups.
...(There isn't a good way around the delay itself - any sequential
sampling scope will not be able to view the edge it is triggering on, without
a synchronized clock signal or an analog delay line.)

My old sampling scope uses RIS. I recently used it to demonstrate using a low cost VNA for TDR/TDT measurements.  Time stamped:

https://youtu.be/9CwQ5Z7XF0w?t=1127

I am surprised by your 20 page manual.  The software shown in that video not a commercial application and is offered free of charge with a 200 page manual. 

Low rep-rate signals:
...
We will expose these options to the user (next update, by EOW). As they affect the reconstruction timescale [User Manual Sec 2.2] and other details, there are also some subtleties we need to explain in the documentation.
(This is one of the things that we hope to demonstrate better in our planned videos).

Thanks.

An ignition system @ 1 ktrig/s would take 30 seconds per sweep @ 3 triggers/sample for 1 kpts @ 10 samples/CDF.
A source @ 120 ktrig/s would take 8 seconds per sweep @ 30 triggers/sample for 1 kpts @ default 32 samples/CDF.

Consider a gasoline engine may idle at 600RPM, or 60RPS or 60Hz trigger.  I assume 10X slower trigger rate = 300 seconds. I think I would just need to try some of the previous work arounds you mention.   I think the bigger problem is the lack of a pretrigger to see what is going on.   

(For your Tektronix pulse source, you would need to tap into a >11 ns pretrigger for CH1 and send the rising edge into CH2.)

Curious to hear your honest opinions on the above.

I had modified that old tunnel diode pulser I mentioned to replace the trigger connector with an SMA. The trigger preceeds the rising edge by 85ns.  I assume I would just trigger on Ch1 and delay 85ns with edge shown on Ch2.  Shouldn't require any changes.  You can't use a level trigger with this device.  Normally, like with an ignition signal, there is no good way to create a pretrigger and the signals are not stable enough to delay a full period to capture the pre and post trigger data.  So we would never see what the rise time for example looks like.   

[SJL-Instruments]

My comments about the displaying the various channels on separate graphs is common. Having four  traces on a single graph can get cluttered. 

Got it. This will go into the next software update, or the one after.

I am surprised by your 20 page manual.  The software shown in that video not a commercial application and is offered free of charge with a 200 page manual.

Yes, our software does not have nearly as many features as LeCroy's. We are actively working to improve it, but do not have the resources of a large company. One of the motivations for this forum post is to get feedback on which features we should prioritize.
(On the flip side, we would argue that our software has little to no learning curve, for precisely this reason.)

I assume I would just trigger on Ch1 and delay 85ns with edge shown on Ch2.  Shouldn't require any changes.

Should work exactly as you expect.

Normally, like with an ignition signal, there is no good way to create a pretrigger and the signals are not stable enough to delay a full period to capture the pre and post trigger data.  So we would never see what the rise time for example looks like.

In that case, a sequential sampling oscilloscope like the GigaWave is not suitable - you need random sampling. We don't think random sampling is viable at this bandwidth and price point (at least for a new, commercial product).

[perdrix]

I am correct to think that this is for repetitive signals only, not single shot 6GHz?

D.

[Randy222]

I think it's a neat product, but outside my budget. Niche market for sure, but even that, probably still limited audience.
I would be more interested if it could at cover wifi7 bands.
Also, why does the silkscreen on device say +-950mV(max), but the manual print says +-1.2V(max)?
Also, considering it reaches into GHz, I would like to see some specs listed in dBm units, but that's just me.

[SJL-Instruments]

@perdrix Yes, this is a sequential sampling oscilloscope. It builds up a waveform over many triggers, and can only view data after the trigger (not before).

@Randy222 The ±1.2V in the manual is the absolute maximum rating. The usable signal range is ±950 mV (actually ±1V, datasheet is conservative). [Anecdotally, we've sent 5V into a test unit without damage.]
For an arbitrary (non-sinusoidal) waveform, there is no one-to-one correspondence between Vmax and dBm.
Applying a constant 950 mV corresponds to 12.6 dBm power, but a 2.4 Vpp sine wave (at the absolute max rating) is only 11.6 dBm.

[Randy222]

@perdrix Yes, this is a sequential sampling oscilloscope. It builds up a waveform over many triggers, and can only view data after the trigger (not before).

@Randy222 The ±1.2V in the manual is the absolute maximum rating. The usable signal range is ±950 mV (actually ±1V, datasheet is conservative). [Anecdotally, we've sent 5V into a test unit without damage.]
For an arbitrary (non-sinusoidal) waveform, there is no one-to-one correspondence between Vmax and dBm.
Applying a constant 950 mV corresponds to 12.6 dBm power, but a 2.4 Vpp sine wave (at the absolute max rating) is only 11.6 dBm.

?
DC and RMS(sine) should be the same. 950mV(dc) is not same as RMS of 2.4Vpp sine.
The device can sink 12.6dBm in DC, but not 12.6dBm sine wave?

[SJL-Instruments]

The ratings for absolute max and usable range are properly in volts, and you should look at Vmax to gauge your application.
For an extreme example, you could send in a 10 V, 1 ns pulse every microsecond, which would eventually blow up the scope, despite only reaching 3 dBm average power.

You can use 10 dBm as a rough guideline for a CW waveform, but for anything odd, check Vmax. If you don't know Vmax, you can try a series of decreasing SMA attenuators until the signal is in range.

[Marco]

Normally, like with an ignition signal, there is no good way to create a pretrigger

A comparator and 5 meters of coax.

[joeqsmith]

Normally, like with an ignition signal, there is no good way to create a pretrigger

A comparator and 5 meters of coax.

Delaying the drive signal to the coil's primary using coax may be an option, assuming it doesn't cause problems with any of the EMCs fault detection.   You may be able to do something similar for other signals as well.  Say a simple digital gate.  You could have two probes attached to the source with different lengths of coax to derive the pre-trigger.   In some cases loading of a single probe may be bad enough and now we compound that problem.  Not to mention messing with the signal we are trying to measure.   It's just not something I have ever thought about (needing a pre-trigger).   

If I just wanted to say look at that vintage Tektronix pulser, I'm sure I could do that but it is hardly justification for purchasing such an instrument. 
Of course it could be used to look at high frequency oscillators where the signal is stable enough.  Then use the delay to see what is going on.   Still, not very useful as I would normally want phase information and other details for a clock.   

If probing a custom circuit, maybe you could create a separate pre-trigger to keep it isolated from the signal you are wanting to measure.  You would need to consider it in the design phase.   

I am surprised by your 20 page manual.  The software shown in that video not a commercial application and is offered free of charge with a 200 page manual.

Yes, our software does not have nearly as many features as LeCroy's. We are actively working to improve it, but do not have the resources of a large company. One of the motivations for this forum post is to get feedback on which features we should prioritize.
(On the flip side, we would argue that our software has little to no learning curve, for precisely this reason.)

Agree, that 40+ year old LeCroy DSO does offer some very nice features not found on even modern products.   But the point I was trying to make is the software and manual mentioned was created by one person.   Well, then there are the countless papers published by the leaders of the industry.   I give them credit for all of my math.   

[joeqsmith]

Another possible low cost sampling scope.  $1000USD 11GHz.

https://www.fastsampling.com/

An old kick start from 10 years back:
https://www.kickstarter.com/projects/1855991221/10-ghz-usb-oscilloscope


Thinking about the coax delay line, using a resistive splitter and maybe a couple of attenuators to help with the matching/isolation.  Still, you are giving up a lot.     

https://www.eevblog.com/forum/testgear/most-affordable-way-to-get-a-really-fast-oscilloscope/

[SJL-Instruments]

Agree, that 40+ year old LeCroy DSO does offer some very nice features not found on even modern products.   But the point I was trying to make is the software and manual mentioned was created by one person.   Well, then there are the countless papers published by the leaders of the industry.   I give them credit for all of my math.   

Apologies, we misread and thought you were referring to LeCroy's software. Yes, Solver is impressive work (and I have personally used it - thank you for developing it).
That said, our software has been around for 1/10 as long as solver. At this stage, our users have a lot of say in what features get implemented first, so we really do value your feedback.

Delaying the drive signal to the coil's primary using coax may be an option, assuming it doesn't cause problems with any of the EMCs fault detection.   You may be able to do something similar for other signals as well.  Say a simple digital gate.  You could have two probes attached to the source with different lengths of coax to derive the pre-trigger.   In some cases loading of a single probe may be bad enough and now we compound that problem.  Not to mention messing with the signal we are trying to measure.   It's just not something I have ever thought about (needing a pre-trigger).   

Delaying the trigger to the DUT works great (when possible). In our experience, trying to delay the analog waveform itself is not possible without distortion, and we don't recommend it.

[joeqsmith]

They talk  about using the delay line for a pre-trigger in their manual:
https://www.fastsampling.com/Products/DS800E/DS800Manual17.pdf

Makes sense but at a cost..

[SJL-Instruments]

If you decide to go down the analog delay line route, 12ft of LMR-600 cable will generate a 14ns delay with ~1 dB loss @ 6 GHz. This may be an acceptable level of degradation for some applications.

[joeqsmith]

If you decide to go down the analog delay line route, 12ft of LMR-600 cable will generate a 14ns delay with ~1 dB loss @ 6 GHz. This may be an acceptable level of degradation for some applications.

Plus an additional 6dB for the splitter and possible other attenuators.  I think this is how I would proceed, at least for the cases we are talking about. 

***
Maybe add another 13-14dB to make the math work out to a nice /10.  I don't remember if your software supports any divider ratio like my other scopes offer.   If not, you may want to consider adding it.   Then having a way to compensate for the added delay to fudge the T0.  Basically getting me a time marker based on the added delay for the trigger shown on the graph. 

[SJL-Instruments]

Yes, you can enter an arbitrary probe attenuation. And now that you mention it, it might be useful to let the user specify it in dB as well.
We'll add that and the extra timebase delay option to the next update.

edit: Implemented as of 2024-01-11.

[Marco]

trying to delay the analog waveform itself is not possible without distortion, and we don't recommend it.

Do you have a measurement mode for signals with unknown jitter? The search approach is slow to begin with, trying to determine a signal range rather than level will do it no favours. An advantage for instantaneous sampling.

The output of a triggered sparkgap will jitter, so I was suggesting on triggering on the attentuated output and delaying the same output. Linear distortion can be corrected for.

[SJL-Instruments]

There isn’t a way to stabilize a signal with unknown jitter relative to trigger - this is unfortunately an architecture limitation, as you mentioned.

Yes, triggering off the waveform itself and viewing a delayed copy will work. If the waveform is reproducible enough (w.r.t. trigger point) to give a clean, single-valued trace, you can undo the signal distortion if you know the transfer function of the delay line.

If the variation is significant, however, there is no way in general to accurately undo the distortion given only the probability density of the waveform.

[joeqsmith]

Yes, you can enter an arbitrary probe attenuation. And now that you mention it, it might be useful to let the user specify it in dB as well.
We'll add that and the extra timebase delay option to the next update.

Thanks.  These features should prove useful.

[JohnG]

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.

The ability to control the software, and hopefully extract data through the same, is a requirement.

FWIW, I used an analog delay with it as mentioned above. It works, but it is not so easy to correct for cable losses due to "dribble-up". Part of the problem is that the frequency response of a lossy practical transmission line are not represented by a finite rational function, because the losses are due to eddy currents. There are some ways around this, i.e. de-embedding, but this is not trivial. 

Come to think of it, that would be a mighty fine feature for the software:).

John

[joeqsmith]

I wondered if they were still in business.  You can download the SJL's software and run it in demo mode to get a feel for it.  I have not looked at Fastsampling's software but from your post, you my find SJL's on the opposite end of the spectrum. 

For your scope:

If bandwidth required does not excide 4GHz then input connection can be simplified and trigger input
power divider can be used.

They go onto talk about the 4' or more of coax.  Indeed, there may be a way to characterize it and back it out.  Have you dug into the math?  If so, can you provide any details?

***
I did find this article:   
https://www.edn.com/rescaling-oscilloscope-signals-and-de-embedding-cables/

SLJ, have you considered creating a software interface document for the product that would provide details on how to directly control it?

[hpw]

Pretty close, yes! Attached is a picture of the RF side of the board if you'd like to take a stab at it.

Did run your demo, as all are stable signals... as I like to trigger a LVCMOS edge and analyze the variations of like 20%..80% rise time over time as also some Chatter.

Is this picture below in red the time base oscillator??

Hp

[SJL-Instruments]

Yes, that is the reference timebase (2.5 ppm TCXO).
20-80% risetime is available as a built-in measurement. It is possible to track the long-timescale variation of the risetime, but not the short-timescale fluctuations, since each sweep takes a few seconds.
For 3.3V LVCMOS signals we recommend a 12 dB inline attenuator with x4 probe attenuation in the software.

[JohnG]

They go onto talk about the 4' or more of coax.  Indeed, there may be a way to characterize it and back it out.  Have you dug into the math?  If so, can you provide any details?

I have not done the math. I solved my issues well enough by getting a lower loss cable, but in the end I would have preferred to do some de-embedding. Since most de-embedding tools look for s-parameter models of the network to be de-embedding, I imagine that the process involves an FFT to convert the signal to be corrected into the frequency domain, passing it through some sort of inverse of the supplied model, and converting back to the time domain. My math skills are pretty rusty at this point.

Maybe this is an answer: https://github.com/TeledyneLeCroy/SignalIntegrity/wiki

John