Pocket-Sized 6 GHz 1 TS/s ET Scope

[SJL-Instruments]

Hope this is allowed here - we'll keep it brief.

We're a small US company that has developed a series of 6 GHz USB sampling oscilloscopes.
Our main goal is to offer access to the picosecond regime (>= 1TS/s ET) at a competitive price (~$2k USD $1500 with hobbyist discount).

Headline features:
- 1 ps time resolution (1 TS/s ET sampling.) Most units achieve ~0.3 ps reproducibly.
- 12-bit vertical resolution, 40 ps rise time
- Edge trigger on channel (rising/falling edge with adjustable level, full bandwidth).
- Pocket-sized, powered over USB C. About the size and weight of a phone.
- Excellent build quality - body is machined aluminum 6061. We are right-to-repair friendly.
- Large portion of manufacturing done in-house (USA) - board-level assembly, laser engraving, even the packaging!

We understand this is a very niche instrument - but we hope we struck a good balance of price and capability within this niche. Curious to hear your feedback (good or bad)!

***
Update 2024-02-18: joeqsmith has now published a quite thorough review of the 4-channel model. You can watch it below:

***
Update 2024-02-28: Shahriar (The Signal Path) has now published his review:

[nctnico]

Any datasheet available?
How many channels does it have? What is the trigger jitter like? What is the realtime samplerate?

[SJL-Instruments]

Section 1 of the User Manual has all the specs you'd find in a datasheet: https://www.sjl-instruments.com/user-manual.pdf

2-, 4- and 8- channel models are available. (The 8-channel model has a 4-6 week lead time, others ship for free next business day.)

Intrinsic trigger jitter is ~4 ps. Due to the RMS jitter of the delay generator, the effective trigger jitter increases with sqrt(T). User manual Section 2.3 has the formula.
(See also the upper right plot on the calibration sheet: https://www.sjl-instruments.com/sample-calibration.pdf)

Realtime trigger rate is 25 Mtrig/s. This is limited only by the minimum holdoff (40 ns). Note that this is not equivalent to the "sample rate," as the scope uses a rather unique architecture (see Section 2.1 of User Manual).

[TheSteve]

Please consider sending one to Shahriar at TheSignalPath if he is willing to perform a review.

[SJL-Instruments]

Yep, we already sent one to Shahriar 
Understandably, he has a long backlog to get through, so the video may not be out for a while.

[azonenberg]

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?

[SJL-Instruments]

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

The general idea has been floating around for a while (e.g. the Tektronix BERTScope). The hard part is the sub-ps timebase precision (months of aging trials, and calibration takes several hours per device). Achieving an accurate, full-bandwidth edge trigger isn't trivial either.

(By the way, internally everything is 16-bit. Since the ENOB is only ~8.5 at 100 MHz, though, it seemed disingenuous to advertise a 16-bit scope.)

No CDR PLL at the moment - we may offer an external one in the future. You can make a "pseudo-eye-diagram" with just an edge trigger, though.

Re: your edit. We tried this, but it turns out to not save much time in practice (since the samples you want are spaced much more densely than 1 ns).

[coromonadalix]

Is it me,  but seem very poor on input parts protection, impedance ??


ah some similarities against the picoscope  gui   i hope it is configurable, and  not blocked to the "dark" theme,   some colors are almost unreadable

[SJL-Instruments]

Yes, the inputs are ESD-sensitive - this is mentioned in the manual. It's hard to do ESD protection at these frequencies without affecting performance.
(If you do blow up an input, though, it's a free warranty repair.)

Thanks for the feedback on the GUI. We'll add a light theme and check all the text against accessibility guidelines.

[azonenberg]

Let's see, I see a Spartan-7 FPGA, Tag-Connect JTAG connector, USB-C port, and a bunch of QFNs that aren't in focus enough to read part numbers. The SMAs look to be edge launch but with through-board ground/mechanical pins similar to Amphenol RF 901-10510-2 but not that exact part.

The IC next to each input is probably the comparator, and the one near the center of the board is probably a 1:4 buffer to send the sampling clock out to each one.

The leftmost port has some extra circuitry that seems to connect back to the clocking structure so it's probably the only one that can be used as a trigger. First chip behind the comparator is probably a 1:2 buffer sending one leg to the FPGA and one to the delay line for the clock.

Then another buffer or mux or something, with one leg going to the FPGA and the other to the main clocking system. The TSSOP also looks like it might be a 2:1 mux (selecting either the undelayed or delayed clock perhaps?) and the ON SEMI chip might be the actual delay line. Whatever it is, it has ECL/PECL outputs (load resistors to ground plane right at source, then differential terminator at the sink side by the TSSOP). I can't read the full part number but the pinout and package are consistent with the MC100EP195 which has ECL outputs.

Definitely a more cost optimized architecture than my "no holds barred" design which called for a LMK04806 PLL and a HMC856 delay line after it for fine phase shifting. That delay line alone is probably as expensive as your whole BOM.

[azonenberg]

As far as protection goes there are some pretty low capacitance ESD diodes you might want to look at that would be better than nothing, SZESD7471N2T5G claims 350 fF for the diode itself (assuming you do a good layout and probably cut away some ground plane to avoid adding excess capacitance that way). I'm considering that for some upcoming designs that will run up to 10 Gbps.

[JohnG]

350 fF is -j76 ohms at 6 GHz. If the design was 6 GHz without protection, it will be closer to 5 GHz with protection, not counting any stray inductance. That's a substantial hit.

John

[JohnG]

Speaking of bandwidth, any chance there is something higher bandwidth in the works? Asking for a friend

John

[SJL-Instruments]

@John - We don't want to say much about that at the moment  What bandwidth did you have in mind?
Note that the 0.35/tau bandwidth for the GigaWave is usually around 10 GHz. (The datasheet "typical" 8 GHz is conservative.) The advertised 6 GHz is very conservative. Since the response is not quite Gaussian, the effective number depends on your application.

[mawyatt]

Interesting, nice work

This architecture seems like a subset of the Non-Uniform-Sampling (NUS) ADC concepts championed by Dr Mike Chen at USC back in 2000s.

With the NUS ADC the input signal in quantized in both amplitude and time, which offers some unique features/characteristics (like post Anti-Aliasing filtering) as shown in the references below.



https://ieeexplore.ieee.org/abstract/document/6503693

Here's a low resolution image we took long ago of an early developmental Non-Uniform Sampling ADC chip fabricated in 65nm TSMC CMOS.

Best,

[KE5FX]

Nifty.  Seems like a natural for TDR applications, especially if additional input protection is provided in a later model.  Any plans for a built-in stimulus source?

[SJL-Instruments]

@KE5FX Thanks!

A standalone TDR device is on the map. The architecture can be significantly simplified since you control the trigger source. Probably $1k-2k for a few-channel device.

We have limited resources, though, so our focus for now is customer/software support for the GigaWave. Our guess is that there's a broader audience for scopes than TDR. (We could be wrong, though!)

For an external stimulus source, Leo Bodnar's pulser gives essentially optimal performance per dollar.

[JohnG]

@John - We don't want to say much about that at the moment  What bandwidth did you have in mind?
Note that the 0.35/tau bandwidth for the GigaWave is usually around 10 GHz. (The datasheet "typical" 8 GHz is conservative.) The advertised 6 GHz is very conservative. Since the response is not quite Gaussian, the effective number depends on your application.

Got me, I don't really have a sound idea, other than substantially more than 6 GHz - at least 2x and probably 3x or more. I have been looking at using TDR in order to learn about and then implement better transitions for connectors (mostly SMA and MMCX), as well as improving some probing points on some of my designs. These are basically transmission line probes built into a PCB. They work surprisingly well, but I'm starting to see some higher frequency junk (at least 5-6 GHz) and I don't have a good idea how real it is and if I need to do or can do anything about it.

The circuits are power pulse circuits, so there are also resonances in the feed networks and the impedances are low due to the high currents required. I'd also like to use TDR here to see if it can help me locate problem areas with less guesswork.

It's hard for me to justify expensive equipment to my company for this because I don't know enough about this topic, and the circuits fall well outside of the usual signal-level stuff. I have a budget 6 GHz VNA now, and a decent, if rather old, 6 GHz real-time scope (SDA 6020), and it's not enough. A relatively affordable way to get to something higher BW might withstand budgetary scrutiny.

Sorry for the vague answer, but this is new territory for me.

John

[points2]

Hi,
I saw your post just after you posted... I jumped on your web site...
nice ! 

We understand this is a very niche instrument

A sampling scope from A-brand @ A-brand price is a nice market, for sure !
But at 2-3kEur, it can be a dedicated instrument, a "dead-cheap" alternative to high-end benchtop (high BW, high sampling rate).
(I think... I admit I'm a noob compared to the experts that posted earlier  )

- but we hope we struck a good balance of price and capability within this niche. Curious to hear your feedback (good or bad)!

Do you plan to release a video (youtube ...) to demo the device & see how it behaves ?

[joeqsmith]

Yep, we already sent one to Shahriar 
Understandably, he has a long backlog to get through, so the video may not be out for a while.

Look forward to seeing it.

[SJL-Instruments]

@points2 re: the video. Yep, something basic (unbox, measure a few signals, eye diagram) is in the works.
Of course, Shahriar's review will be 30 dB better in quality than anything we can make. (And more importantly, unaffiliated.)

[points2]

Hi,

@points2 re: the video. Yep, something basic (unbox, measure a few signals, eye diagram) is in the works.

"basic" !?
Your product has not the price tag of a tinySA / LiteVNA / tinyPFA / etc.. I bought 2 items of each without headache vs the expenses.
Your product is not a 100Eur device, it is 3k (VAT incl.) ; thus not the kind of device any hobbyist pays to check how it works and how it performs.
1ST => be customer oriented : do as many videos as you can to explain the device / perfs / capabilities...  a basic unboxing & playing fast with the device in a few min video worths nothing.
The picoscope 9402-05 is the match. x4 more expensive, ok, but capabilities are quite ok.
In this niche market, please do explain how this x4 ratio in price, is 1:1 in some measurements or 1:2 in some other measurements... etc..

Of course, Shahriar's review will be 30 dB better in quality than anything we can make. (And more importantly, unaffiliated.)

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 

[joeqsmith]

... thus not the kind of device any hobbyist pays to check how it works and how it performs.
1ST => be customer oriented : do as many videos as you can to explain the device / perfs / capabilities...  a basic unboxing & playing fast with the device in a few min video worths nothing.  ...
....
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) ...

Tend to agree with above statements.  I think if I were wanting to compare it, it would be with something like the iC227 below.

I still use my old sampling scope to look at ignition waveforms.  Sure, it's 40 years old but it's well made and able to handle a pretty tough environment.  Making these measurements with the OPs product may pose a unique problem as they chose USB for an interface.   In my experience, that bus is prone to failure in high noise environments, such as looking at ignition sources. 

The iC227 is an 11GHz bandwidth Sequential Sampling Oscilloscope. Our Price: $3,762.75
https://us-shop.ichaus.com/mobile/Product.aspx?ProductCode=iC227_Dual_11GHz-_Oscilloscope

[SJL-Instruments]

Points taken. To start, we now have an outline for ~8 detailed videos on specific topics with demos. We'll spend the next week planning these in more detail and hopefully starting production.
In full honesty, we cannot promise a fixed timeframe for this, but we understand if you want to withhold purchasing until they're out.

Re: The iC227. We do not have this device, but from the datasheet:
1. The timing precision of the iC227 is 0.5% FS (5000 ppm), vs 15 ppm typical for the GigaWave.

2. The timebase of the iC227 is calibrated and stored in a LUT.
For the GigaWave, we have developed a quite detailed model of the timing of the delay chip that is robust against temperature variation and year-scale aging. We calibrate the dominant parameters in the model once at the time of manufacture (this is the several-hour part), and perform a fast recalibration at each sampled delay during use. The precision is reliably 2 ps RMS @ 20 ns without the fast recalibration step, and ~0.2 ps RMS with this step.
We can only speculate on the iC227, but we would be very surprised if a LUT held better than 10 ps precision over an hour (or if the device is bumped). (The claimed 1 ps is believable immediately after calibration.)

3. The GigaWave is capable of intensity grading (e.g. eye diagrams and modulated signals).

4. (Subjective) We would argue that our software is easier to use (you can drag channel/trigger markers vertically, and scroll/pinch to zoom timebase and vdiv). We have more measurements, FFT, and data export. We are also actively implementing feature requests.

5. We could not find anything like the iC227 with more than 2 channels.

We hope this addressed your concerns. Thanks again for your feedback and steering us in the right direction.

[joeqsmith]

I have downloaded and installed your software for Windows.  Is there an interface tool kit that will allow me to run it using my own software?  For example, say I want to use it as part of some automated test. 

Looking at the manual and software, it appears that the export feature only saves the data that is currently on the screen.  It also appears that it does not allow all of the traces to be saved to a single file.  Can you confirm? 

The software seems very easy to drive.   When I look at the demo mode, I can see the trigger level marker on the plot but I don't see a time marker.   If I pan to the left, it seems to not show data at time 0, but rather 11ns.  Rather than having all the data on a single graph, why not allow more options? 

3. The GigaWave is capable of intensity grading (e.g. eye diagrams and modulated signals).

I could not figure out how to setup a mask.  Is that not supported?

Looking at the manual, I noticed the following comment:

The main limitation of the GigaWave™ architecture is for signals with infrequent trigger opportunities (500 ktrig/second or lower).

A typical ignition system for example would be less than a kHz.  I have a very old Tektronix pulse generator head that will produce a <25ps edge.  The pulse period is about 120kHz.     

[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

[SJL-Instruments]

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

We could certainly do that. The de-embedding calculation itself isn't bad, but the UI requires some thought. The user would need to import s-parameters from a VNA trace.
edit: Implemented as of 2024-01-21.

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

To clarify, by "it" do you mean the product (i.e. a programming manual for the serial interface), or the software (some way to programmatically control the desktop software)?

[joeqsmith]

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

To clarify, by "it" do you mean the product (i.e. a programming manual for the serial interface), or the software (some way to programmatically control the desktop software)?

It, meaning your products serial interface.

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

I only skimmed that article I linked but it appeared they suggest at least some scopes allowed you enter the data rather than using s-parameters.   They are using a product made by Teledyne LeCroy. 

The user interface for the cable de-embedding feature requires a description of the cable including its length, propagation velocity, and frequency response. The frequency response can be entered either as the S21 s-parameter forward transfer function as a table or as attenuation per 100 feet as a function of frequency by supplying the constants A1 and A2 from the manufacturer’s frequency response equation.

***
Looking over my coax, I have some RG223 and RG400.  Attached showing a section a bit longer than needed.  It does a fine job filtering that edge.   I wonder with your scope if that 4GHz was based on the length they required for their delay. 

[SJL-Instruments]

It, meaning your products serial interface.

Sure, we'll add a "Serial Interface Programming Guide" section to the user manual (ETA 2 weeks published as of 2024-01-13).
We'll preemptively warn you that the main acquisition commands return dense binary data to minimize communication time. Parsing it is annoying.
We recommend using the Python API, as it's essentially just a wrapper on the serial interface that does this parsing for you.

I only skimmed that article I linked but it appeared they suggest at least some scoped allowed you enter the data rather than using s-parameters.   They are using a product made my Teledyne LeCroy. 

Thanks for this; we'll look into implementing these options.

[joeqsmith]

I have a Signal Hound SA that uses USB 3 that I have written some software for.  When I first looked into it, I remember them having a similar comment, warning that the data is coming in fast and a lot of it.    

Look forward to to see what you come up with for handling the delay line.   I doubt many people would have access to a VNA to measure the S-parameters for their delay line.   Maybe that could be an accessory along with the splitter.   This would give you some control over it. 

***
From the SH manual, time embellishes all:

If you wish to retrieve all samples, it is the responsibility of the users application to poll the samples via fast enough to prevent the circular buffers from filling and eventually having to drop data. We suggest a separate polling thread and synchronized data structure (buffer) for retrieving the samples and using them in your application.

Home made delay line improves the rise time slightly (was 900, now  600ps).  Takes forever to to reach steady state.   Too bad the pre-trigger requirement wasn't more in the order of <1ns. 

[hpw]

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.

OK, I understand, so it will not my purchase, as to measure 10Mhz 120dBc @1Hz clock distributions clocks.   

[joeqsmith]

A short article attempting to compare random and sequential sampling:

https://www.apexwaves.com/blog/random-sampling-vs-sequential-sampling/

There is really no meat on the bone.  The summarize with: 

Nevertheless, the advantages of this method in practice outweigh the advantage of the random-sampling method.

, but it you take the time to read the page and a half, they never explain what these advantages are.   They do however explain the short comings.     

This 20+ year old article talks about sequential sampling and where it fits in.   

This capability makes such scopes the instruments of choice in applications of rapidly growing importance-electro-optics, for example.

Of course, they are talking about 50GHz BW, not 6 like the product we are discussing. 
https://www.edn.com/50-ghz-bandwidth-sequential-sampling-dsos-test-10-gbps-network-components/

Outside the scope of this thread, but while searching for articles, I found this set of slides that mentions Teledyne LeCroy's Digital Bandwidth Interleave (DBI).  I made a video that went over this technique based on their patents.   In order to demonstrate how it works, I wrote a simulator for it (starts about 6min in). 

https://keysightevent.com/191023/handout/pdf/c/3.%20Digital%201_High-Speed%20Oscilloscope%20Fundamentals.pdf

[nctnico]

I still don't see why this oscilloscope can only show the part of the signal after the trigger. The 'good old' Tektronix TDS500 series use sequential sampling as well and have no problem showing the signal before and after the trigger point. It seems Tektronix' acquisition system is free-running and timestamping the sample where the trigger occured. After that they phase-shift the sampling clock and take another acquisition.

[SJL-Instruments]

The 'good old' Tektronix TDS500 series use sequential sampling as well and have no problem showing the signal before and after the trigger point. It seems Tektronix' acquisition system is free-running and timestamping the sample where the trigger occured. After that they phase-shift the sampling clock and take another acquisition

We consider "sequential sampling" to refer to any technique where the sampling action is caused by the trigger.
Taking timestamped samples (independent of trigger) and later reconciling with trigger events would fall under random sampling. (See https://w140.com/tekwiki/wiki/Sampling_oscilloscope)
(Phase-shifting a periodic clock as you described is an interesting technique, in some respects a "subsampled version" of RIS.)
Some (very) early Tektronix sequential sampling scopes actually contained an analog delay line - tweaking the compensation network for these was an art.
https://groups.io/g/TekScopes/topic/tektronix_delay_line/7629123

but it you take the time to read the page and a half, they never explain what these advantages are.   They do however explain the short comings.

We tend to agree. In most cases, random sampling provides more flexibility with your trigger setup - but  6 GHz random sampling scope will be 4x the price. Our hope is to provide a lower-cost alternative without compromising on bandwidth. The pretrigger requirement is really the only limitation w.r.t. random sampling (albeit a significant one).

On another note, we have released v2.5.4 of the software containing the promised features for this update. (Except for light mode - next update.)
https://www.sjl-instruments.com/software/

Coax de-embedding is working fairly well (see attached). If you're interested, the math is in "Transient Analysis of Coaxial Cables considering Skin Effect" by Wignington & Nahman.

The UI will just require you to enter cable length and type.
If the type you want isn't available, you can also enter the attenuation data at a few frequencies.
The results still need to be validated further, so it'll be rolled out next update [likely end of next week].

[joeqsmith]

Coax de-embedding is working fairly well (see attached). If you're interested, the math is in "Transient Analysis of Coaxial Cables considering Skin Effect" by Wignington & Nahman.

The UI will just require you to enter cable length and type.
If the type you want isn't available, you can also enter the attenuation data at a few frequencies.
The results still need to be validated further, so it'll be rolled out next update [likely end of next week].

Thanks for the fast turn around on this. 

Does your software also account for the splitter or does it assume it is perfect?   Assuming a 6dB resistive splitter, any advantage to using an attenuator at the scope's trigger input to prevent reflections from perturbing the measurement signal?   If a person did have access to a VNA to fully characterize their setup, any plans to support s-parameters as well?   

[SJL-Instruments]

Compensation for the splitter will come out at the same time as s-parameter import (probably not next update, but the one after implemented 2024-01-21). Coax distortion is dominated by skin effect, and so is quite well characterized by conductor material and geometry (i.e. cable type). Not so with splitters - the imperfections "are what they are," and just need to be measured.

Assuming a 6dB resistive splitter, any advantage to using an attenuator at the scope's trigger input to prevent reflections from perturbing the measurement signal?

Yep, adding a (well-matched) attenuator will reduce reflections, if you can afford the loss in SNR.
This is more important on the delayed signal input (since the coax to the trigger input should be pretty short).

[joeqsmith]

Wasn't sure how good your port match is. 

[points2]

Hi,
This post is from a noob that thought he understood some part of what the device can do... but when joey/ntcnico etc  start posting... I lost again

A few questions at noob level, concerning the use of this "special" device, just to try to get a clearer picture about what it can do :

1. given its limiation due to the way it works => it is a big bargain vs any all-in-one DSO on the market ? correct ?

2. it is a device that works on repetitive signal (linked to the way it works). What kind of repetitive signal this device loves to trigger ?

2.1. Ethernet signal : my SDS2504++ (500M BW DSO) can trigger an ethernet signal (100Mb is easier to probe the 125MHz than the bi-directional 1Gb) ? but regarding signal between IC & SFP 1Gb (signal @ 1.25GHz), this device can do it ? (given that I have 1GHz active probes, PMK Tetris)
2.2. oscillators analysis ? to check freq stability, a TinyPFA is more precise by 1e3 min order of magnitude... Correct ?
2.3. regarding any "fast" digital signal, to analyse in the time-domain, this scope is more "precise" than any DSO (like my SDS2504X+) thanks to its much lower rise. Correct ?

I'm interested in the jitter (eye-diagram, or pseudo-eye-D) of some basic digital signal :
- USB 2.0 is based on 480MHz signal (SA snifing) => this device can help to get a +/- clear picture of the signal ?
- HDMI 1.4 is based on 650MHz (wrong figure but close, I can't remember the right one) signal (SA snifing) => this device can help to get a +/- clear picture of the signal ?

3. Channel 1 is labeled "trigger". This feature blurs me...
3.1. Why ? a "noob-level" reply is requested, please 
3.2. This "scope" doesn't work like a DSO, but you can plug any probe and you got the pattern on the screen... yes/no ?
3.3 Channel 1 is labeled "trigger" => does it mean that the scope is not able to find by itself that the main pattern is at 125MHz for instance, and then lock to it, do the sampling => and presents the signal on the screen ?

4. what's the trigger jitter of this scope ?

Thanks to anyone to answer these low-level questions... 
Maybe I'm wrong but I see this device as a dead "cheap" alternative to upgrade (to be an add-on, restricted to some signals) a hobbyist-level DSO like a SDS2504X+ (sticker on the scope is 2104X+ of course.. a gem this DSO...)

Thanks for feedback
PS : if I'm wrong here & there => be rude & correct => I just want to learn 

[SJL-Instruments]

Wasn't sure how good your port match is. 

Not the best, to be honest: -17 dB @ 3 GHz (although we don't characterize this on a per-unit basis).
We have a design with better matching (-30 dB) at the cost of 2x noise floor. We opted for the lower-noise design, since you can get essentially the same results with a 6 dB attenuator (but not the other way around).

Thanks points2 for your detailed questions. We'll try to keep our answers succinct but clear.

1. given its limiation due to the way it works => it is a big bargain vs any all-in-one DSO on the market ? correct ?

Yes, if your signal is repetitive (i.e. you can trigger many times - no one-shot signals), and you can pre-trigger or delay your signal.
This is explained in more depth in Section 2.1 of the manual.
If you need to do serial decoding, you need a real-time DSO (or a logic analyzer).
If you're (for example) doing something weird with nanosecond laser pulses, where usually you have high rep rates, the GigaWave will likely do the job.

2.1. Ethernet signal : my SDS2504++ (500M BW DSO) can trigger an ethernet signal (100Mb is easier to probe the 125MHz than the bi-directional 1Gb) ? but regarding signal between IC & SFP 1Gb (signal @ 1.25GHz), this device can do it ? (given that I have 1GHz active probes, PMK Tetris)

Yes, you can trigger on this signal. You can't decode the data (use a logic analyzer), but you can check signal integrity (pseudo-eye-diagram, real eye diagram if you have CDR).

2.2. oscillators analysis ? to check freq stability, a TinyPFA is more precise by 1e3 min order of magnitude... Correct ?

Yes, oscillator stability/jitter/etc is better-suited for frequency-domain tools. The exception is rise/fall time - the GigaWave is great for that.

USB 2.0 is based on 480MHz signal (SA snifing) => this device can help to get a +/- clear picture of the signal ?
- HDMI 1.4 is based on 650MHz (wrong figure but close, I can't remember the right one) signal (SA snifing) => this device can help to get a +/- clear picture of the signal ?

Yes, the GigaWave can generate an eye diagram for these protocols (see caveat on CDR above).
Jitter analysis/mask testing is planned but not yet implemented. We understand if you want to wait for this feature before purchasing.

3. Channel 1 is labeled "trigger". This feature blurs me...
3.1. Why ? a "noob-level" reply is requested, please 

To offer this bandwidth at this price, only Channel 1 has trigger hardware. It is a real channel (i.e. you can plug in a sine wave to CH1 and look at it). You will need to swap around cables to trigger on a different channel.

3.2. This "scope" doesn't work like a DSO, but you can plug any probe and you got the pattern on the screen... yes/no ?

Yes, with the caveats that you can only trigger on CH1, and the signal must be repetitive. (i.e. think about which channel will be the trigger before you set up the cables.)
You can (for example) feed in a clock signal directly to CH1. It will show up, and you can measure its risetime and jitter.
If nothing's plugged into to CH1, nothing will happen.

3.3 Channel 1 is labeled "trigger" => does it mean that the scope is not able to find by itself that the main pattern is at 125MHz for instance, and then lock to it, do the sampling => and presents the signal on the screen ?

If you plug in a 125 MHz square wave into CH1, you'll see a 125 MHz square wave.
If you plug in a 125 MHz data signal, you'll get something resembling an eye diagram (not a "true" eye diagram, though).
If you want to see a repetitive pattern, you'll need some auxiliary clock signal that repeats once per period of the pattern. Then plug the pattern into CH2 and the auxiliary clock into CH1.

4. what's the trigger jitter of this scope ?

Typically 4 ps RMS. This is calibrated per-device, and is listed on the accompanying calibration sheet.
Do note that the effective jitter increases with the timebase delay (i.e. for best jitter, keep the signal before 100 ns on the timebase). The exact formula is in Section 2.3.


In summary:
- This device does not replace a DSO. If you need to look at rare events, or single-shot info, you should buy a realtime DSO.
- If you don't need the bandwidth, buy a realtime DSO or a random sampling scope. The price decreases exponentially with bandwidth.
- But, if your application allows for repetitive triggers, and you're looking at the overall behavior (not single-shot), the GigaWave might work. Things like rise/fall times of clocks, eye diagrams for signal integrity, and any experimental/oddball application requiring picosecond timing are all great applications for the GigaWave.

Thanks for the detailed questions - hope this cleared things up a bit!

[points2]

Hi SLS,
many thanks for your reply, that can help others : Cool !
Sorry again vs the "very jittery" way I exposed "simple" stuff.. so far away from the maestros (joey & many others  )
KRgds

[SJL-Instruments]

It, meaning your products serial interface.

We received a few other requests, so we bumped up the priority of the serial interface guide.
It is now available in Section 4 of the User Manual. (Refresh if it's not updating for you.)
https://www.sjl-instruments.com/user-manual.pdf

Let us know if anything is unclear.

[joeqsmith]

Thank you for taking the time to document the command set.   I had a short conversation with the designer of the LibreVNA.  They also use USB but with a custom class.  Because I never ended up getting one, I spent minimal time looking into it.  I can tell you that your simulated serial interface is a LOT simpler to implement.  The basic command set suggests it would be fairly easy to develop custom software for it. 

[joeqsmith]

After looking at so many low cost VNAs, I am curious what you have done for the connectors.  The  How many mate cycles are they rated for?  Are there concerns about torquing the SMAs? 

Left, my original NanoVNA.  Center, Mini-Circuits attenuator.  Right, my original LiteVNA.    Even though these are inexpensive, I still clean the connectors and minimize how much I touch them.  I also tend to keep the cables attached to them so these have not had a lot of mate cycles.  It does appear that the LiteVNA used a higher quality part.  When you are trying to sell a product for under $150, it is difficult to make a profit using 3.5mm end launch connectors.   

I have never broke a connector by torquing them with normal use.   I've had several people write me suggesting otherwise.  Any concerns on your product?

[SJL-Instruments]

Thanks for asking. The exact connector we use is 901-10512-1 from Amphenol, rated for 26.5 GHz and min 500 cycles (full torque). This is about the best quality you can get for a brass SMA connector.

Torquing the SMAs (with a torque wrench) is not a concern. The aluminum housing is machined to close tolerances, so that the torque is transferred through the housing and does not flex the PCB more than a few thousandths of an inch.

However, if you open the case, torquing against the bare PCB may cause damage.

If anything does occur, worn/broken connectors are also a free warranty repair. Connector savers are always an option if you're paranoid.

[joeqsmith]

My Signal Hound uses USB 3.  It reminds me of Longfellow, There was a little girl.  When she was bad she was horrid.  That pretty much sums up my experiences with USB. 

While I typically like headless equipment, the main problem all of them seem to have, they are headless..     What happens is my PC is on my desktop and what I want to look at is on the bench.   The cable supplied with my Signal Hound was maybe 2' long.  They recommend a direct connection to the PC and warn against   extension cables or use of powered hubs.   How do I use it?  With a powered hub and extension cable.  Took some trial and error to get it stable, or as stable as USB can be. 

Looking at your manual to see what is included, I see no mention of cables.  Assuming you provide one, how long is it?  What interface connector is provided to connect to the PC?  My two PCs for example support USB3.0 type A connectors.  If you don't supply adapters/cables, and if it is critical, what guidelines do you offer? 

[joeqsmith]

How about adding some basic measurements beyond what you have.  P-P for example.   Maybe have a look at what other scopes offer for basic measurements.   I like how even my 80's LeCroy can at the touch of a button throw up a hand full of parameters.   If you don't like those, they offer a pretty broad spectrum of measurements they can make. 

I think John's comment out his 11GHz $1000 DSO

I find it difficult to use, mainly because of the software.

is a case where the UI is VERY important and can brake a product.  Limited features to achieve a simple interface is not IMO a good solution.  I want something feature rich, just easy to drive.   As you said, your software is easy to drive and doesn't require a users to read a novel to run it.  But it also lacks a lot of basic functions.   

****
Let me give you an example of what I consider a problem with your UI.  Say I have some signal that I want to look at.  I have some pre-trigger and want to find the falling edge.  I can't just capture unlimited data so I need to change the delay (timebase position) manually to hunt for it.   In order to do this, I have to type in the delay I want.  There is no inc/dec key.  No way to select how much to inc/dec by.... All manual and very painful.   That, or I am not understanding how it works.   I would expect all of the controls to have an easy way to adjust then outside of typing in the values.  Your trigger level for example allows me to set it by dragging the pointer.

[SJL-Instruments]

Looking at your manual to see what is included, I see no mention of cables.  Assuming you provide one, how long is it?  What interface connector is provided to connect to the PC?  My two PCs for example support USB3.0 type A connectors.  If you don't supply adapters/cables, and if it is critical, what guidelines do you offer? 

The accessory list is provided on the homepage - we'll add it to the manual as well (edit: done), thanks for catching that.
We currently provide a 3' USB-C to USB-C cable and a hex key (for opening/repairing the device).
We don't currently provide a USB-A adapter, but we'll do that in the future - thanks.

We have a sizable factor of safety built into the USB power draw, and we only need USB 2.0 FS comms (12 Mbaud, the "heavy lifting" occurs device-side). We have run the GigaWave over a USB extension cord without issues. It will be interesting to see whether the device runs into issues near your ignition system, but we think it has a good chance of working (fingers crossed).

How about adding some basic measurements beyond what you have.  P-P for example.   Maybe have a look at what other scopes offer for basic measurements.   I like how even my 80's LeCroy can at the touch of a button throw up a hand full of parameters.   If you don't like those, they offer a pretty broad spectrum of measurements they can make. 

I think John's comment out his 11GHz $1000 DSO

I find it difficult to use, mainly because of the software.

is a case where the UI is VERY important and can brake a product.  Limited features to achieve a simple interface is not IMO a good solution.  I want something feature rich, just easy to drive.   As you said, your software is easy to drive and doesn't require a users to read a novel to run it.  But it also lacks a lot of basic functions.   

Thanks for the pointers. We'll implement all the standard measurements (likely by next update).
For P-P specifically, the software already implements this measurement (choose the "Vertical" category when adding a measurement).

Let me give you an example of what I consider a problem with your UI.  Say I have some signal that I want to look at.  I have some pre-trigger and want to find the falling edge.  I can't just capture unlimited data so I need to change the delay (timebase position) manually to hunt for it.   In order to do this, I have to type in the delay I want.  There is no inc/dec key.  No way to select how much to inc/dec by.... All manual and very painful.   That, or I am not understanding how it works.   I would expect all of the controls to have an easy way to adjust then outside of typing in the values.  Your trigger level for example allows me to set it by dragging the pointer.

You can use the scroll wheel (or on touchscreen, pinch horizontally) to zoom out the timebase until you see the falling edge. (Drag the holdoff marker to the right if it doesn't appear within the trigger holdoff.) Then zoom in onto the falling edge, dragging horizontally to shift the timebase. This will center the falling edge nicely with a usable zoom level - no need to type anything.

Of all the controls currently exposed in the main view, only the timebase resolution (points/div) and the trigger direction (rising/falling) actually require you to go click on the setting itself. We'll rewrite the manual to be more clear about all this. We've laid out the controls more clearly in revision H3 of the manual.

Please let us know of any other "basic features" you think are missing - this feedback is extremely helpful.

[joeqsmith]

Thanks, I now see that mouse wheel and selecting the screen and dragging will set the Base and Position.  Same for dragging the offsets.  This is actually quite usable.   My monitors do not support touch but that is good to know if I were to use a tablet to run it.    Also, very good to know about the USB 2.  Sorting a good cable should not be a problem then. 

I had completely missed the Vertical measurements.    

How do I save a waveform to memory and recall it, overlay?  How do I enable persistence?   

***
If you could stream the sweeps to disk and publish the format, that may also be helpful. 
Adding histograms would also be nice to have.   
Allow user to change the measurements rather than having to delete them and create new.
Add markers to waveform showing where the measurements are made.  For example show where the 20/80% points are.

[SJL-Instruments]

How do I save a waveform to memory and recall it, overlay?  How do I enable persistence? 

We don't have these options implemented yet - we'll queue them up for next update (or the one after).
Our immediate thought is to put the waveform save/recall/overlay in the File menu, and persistence as a checkbox in the advanced options for each channel.
Is there an existing UI for these that you particularly like? (This question also applies to your suggestions below.)

If you could stream the sweeps to disk and publish the format, that may also be helpful.
Adding histograms would also be nice to have.   
Allow user to change the measurements rather than having to delete them and create new.
Add markers to waveform showing where the measurements are made.  For example show where the 20/80% points are.

Many thanks for these suggestions. We've added them to the todo list - ETA hopefully 2 weeks for all of these.

[joeqsmith]

Many thanks for these suggestions. We've added them to the todo list - ETA hopefully 2 weeks for all of these.

Big thanks!     

Is there an existing UI for these that you particularly like? (This question also applies to your suggestions below.)

Maybe you could make a poll on this site asking for this kind of input.  Keep it generic and I am sure countless people will provide you with their opinions.   

[points2]

Hi SLJ,
more questions 

1. the USB plug => is type-C
but you provide an adapter usb-C to USB-A
1.1. Does it mean that the USB link is USB.2 ?
1.2. Did you test the performance of the device with different "power supply" :
for instance
=> the USB link
vs
=> a tweaked USB link that enable to get power from an external PS, for instance a "nice" linear PS (less noisy than the power coming from a hub / PC...)

2. Trigger frequency : internal vs external.
I guess this question is valid to any sampling scope... (?)
Is it better to rely on (your advice) =>
2.1. the hardware to find out the trigger frequency & stick to it (timebase + PLL ; given that both have their own jitter)
2.2. OR, using an external clock signal (that match the frequency to trigger) ; for instance, a DIY clock based on a "good" tcxo ? (as I don't deal with >100 different frequencies,    , it is cheap to buy a fixed-frequency oscillator from a vendor..., and quite easy to get a rather good stability)
thanks

[hpw]

IMHO, the crappy TXCO is here a limitation factor.

As no external connection for any better reference OXCO to connect. 

As 1Ts/s as 1ps sampling rate, IMHO any 1...5ps deviations will be hard to analyze. Or any live measurements Videos convince.

 my 2 cents

Hp

[SJL-Instruments]

1.1. Does it mean that the USB link is USB.2 ?

The USB communications are USB 2.0 FS (12 Mbaud) but the device requires USB 3.0 power levels (900 mA @ 5V). The actual power draw is around 650 mA @ 5V to allow for a factor of safety (e.g. running over a USB extension cord).
The USB 2.0 spec only allows 500 mA @ 5V, so the device requires a USB 3.0 port. (Many USB 2.0 ports can deliver more power than specified, but don't risk it.)

1.2. Did you test the performance of the device with different "power supply" :
for instance
=> the USB link
vs
=> a tweaked USB link that enable to get power from an external PS, for instance a "nice" linear PS (less noisy than the power coming from a hub / PC...)

We have seen no observable effect with different USB power supplies. Your standard laptop/desktop/tablet USB power is almost certainly fine.

2. Trigger frequency : internal vs external.
I guess this question is valid to any sampling scope... (?)
Is it better to rely on (your advice) =>
2.1. the hardware to find out the trigger frequency & stick to it (timebase + PLL ; given that both have their own jitter)
2.2. OR, using an external clock signal (that match the frequency to trigger) ; for instance, a DIY clock based on a "good" tcxo ? (as I don't deal with >100 different frequencies,    , it is cheap to buy a fixed-frequency oscillator from a vendor..., and quite easy to get a rather good stability)

Not quite sure what you mean here - there is no PLL in the hardware. The trigger is just an edge trigger, behaving the same as with any other scope.
If you're referring to eye diagrams in particular, you need to do clock data recovery (CDR) to obtain a clock signal that (to some extent) tracks the jitter of the data signal. If you want to do this 'properly,' you'll need to get into some weeds about e.g. choosing PLL bandwidth - lots of reading to do.
Trying to match the data frequency with an independent oscillator is likely to cause headaches. Using a simple edge trigger will force the jitter to "zero" (really, the trigger jitter) on one edge of the pseudo-eye-diagram, and so increase the jitter on the other edge. (It also "looks like" a 01 or 10 serial trigger - you need to look a few eyes down the line.) It can be useful to get a qualitative sense of your signal integrity, but shouldn't be used to quantitatively characterize your signal.

IMHO, the crappy TXCO is here a limitation factor.

As no external connection for any better reference OXCO to connect. 

As 1Ts/s as 1ps sampling rate, IMHO any 1...5ps deviations will be hard to analyze. Or any live measurements Videos convince.

 my 2 cents

Hp

A better reference wouldn't help for two reasons. The current typical timebase precision is 15 ppm, which is 1.5 ps at 100 ns. The effective jitter floor (Section 2.3 in manual) at 100 ns delay is ~8 ps RMS. What actually happens in practice is the 1.5 ps deviation "gets absorbed" into the measured effective jitter and increases the value of alpha (technically, only the portion of the phase noise integrated up to the sampling timescale, Section 2.2.2). So decreasing the reference phase noise at 10 kHz and up doesn't do much (since it adds in quadrature, it will still be ~8 ps RMS).

A larger issue is that the timebase is used to continuously calibrate the delay generator, which can only hold 15 ppm precision. In that light, the 2.5 ppm TCXO precision is plenty, and improving the phase noise below 10 kHz wouldn't help either. We think that beating this would require a completely different architecture (e.g. TDC random sampling), and drive up the price a lot.

[joeqsmith]

How do I save/recall  the settings?  Is there an option to have the program use the last settings? 

[SJL-Instruments]

How do I save/recall  the settings?  Is there an option to have the program use the last settings? 

The software currently doesn't support this. We'll add this to our queue as well - thanks for the suggestion.
This has been implemented as of v2.5.5 (released 2024-01-21).

[joeqsmith]

Your documentation mentions different firmware revisions.  How are you making these available and what tools are in place to upgrade the product in the field?  Or are you requiring that the product is returned to be upgraded?   

[SJL-Instruments]

Your documentation mentions different firmware revisions.  How are you making these available and what tools are in place to upgrade the product in the field?  Or are you requiring that the product is returned to be upgraded?   

We'll first note that the reason we don't have this procedure currently documented is that it is not an issue yet. All devices are on the latest firmware revision except for one review unit which will eventually be sent back.

In the future, our plan is to allow the user to either (a) request the firmware file from us and flash it themselves, or (b) return it for upgrade. If the user does not have the necessary hardware, we will send a kit for free upon request. We will document the upgrade procedure and hardware shortly before the next firmware version is released.

The request for the firmware is technically necessary, as the firmware file is device-specific. This has to do with how we achieve the specified 1 ps delay precision.

Let us know your thoughts. This procedure isn't set in stone yet.

[joeqsmith]

From your post, I get the feeling the case must be opened to use this hardware you mention.

I would have thought any calibration data would be stored into an isolated area.  If it is not, that you would have tools to merge it with the firmware. 

Are you considering the FPGA part of the firmware?   Or is everything done in the FPGA?   If so, is that the tools you are referring to?

[SJL-Instruments]

From your post, I get the feeling the case must be opened to use this hardware you mention.

I would have thought any calibration data would be stored into an isolated area.  If it is not, that you would have tools to merge it with the firmware. 

Are you considering the FPGA part of the firmware?   Or is everything done in the FPGA?   If so, is that the tools you are referring to?

Yes, the case must be opened, and we provide the tool to do so with all orders.

There is an FPGA and an STM32 MCU that can both be flashed over the Tag-Connect debug header. The hardware would likely consist of the appropriate Tag-Connect cable and ST-Link. The device-specific portion is only partially calibration data - creating the unique part of the firmware essentially requires compiling from source.

We do not anticipate needing to upgrade the FPGA firmware, but a similar policy would apply. The FPGA firmware is not device-specific, and we will have the bitstream downloadable directly from our website if an update is needed.

[joeqsmith]

Reading your manual and thinking to write some simple software to try it out.   I'm curious with the calibration, you talk about when the device has reached steady state that the need for calibration every second reduces.   With that in mind, do you have a way to monitor the Xilinx or other parts for temperature?   The manual does not mention this and I don't see it in your software.

The commands seem fairly easy to follow, until I get to the Acquire CDF (R) command.    I assume the software pulls the data for what ever channels are selected and increments the delay, runs a cal, pulls the next data, repeating the cycle for however much data we want.   

The binary data consists of d chunks of 3Nch bytes each, where Nch is the number of channels requested via the bitmask. Each chunk contains Nch three-byte entries, each representing a single CDF value F(V ;Δt) for each requested channel.

No problem...

The first two bytes of each entry represent the voltage V on a scale from –1.5 V (0x0000) to +1.5 V (0xFFFF) in big-endian format.

No problem...

The third byte represents the value of F(V ;Δt) multiplied by 255.

I'm lost. 2.2.1 doesn't explain things in simple enough terms with enough detail for me to follow along with my limited math skills.  An example in plain text would be helpful.   

Or, do I need to find a stats book and start reading? 

[SJL-Instruments]

Reading your manual and thinking to write some simple software to try it out.   I'm curious with the calibration, you talk about when the device has reached steady state that the need for calibration every second reduces.   With that in mind, do you have a way to monitor the Xilinx or other parts for temperature?   The manual does not mention this and I don't see it in your software.

When using the serial interface, we only guarantee proper operation when calibrating once per second or faster (i.e a 6% duty cycle of calibration, 60 ms every second).
We do not recommend decreasing the calibration frequency even in thermal steady-state.
The comment about steady-state in the manual is rough guidance for those who want/need to push this frequency down - we then no longer guarantee 1 ps timing accuracy, and it's up to you to check if the resulting accuracy is sufficient for your application.
There are not thermometers to measure individual chips. From our testing, no arrangement of thermometers was anywhere near as accurate as "using the delay chip itself" as a thermometer - this is what we do in practice.

For the next manual revision, we have modified this section as follows:

The 1 ps timing precision of the GigaWave is guaranteed only up to one second after this com-
mand is issued. We therefore recommend issuing this command at least once per second. If
data acquisition (R) takes more than one second, the CAL command must be issued immediately
before the corresponding delay (D) and data acqusition (R) commands.
If the device is in thermal steady-state (∼5 minutes after warmup), the 1 ps precision can often
be maintained for up to 30 seconds without recalibration. If calibrating at a reduced frequency,
the 1 ps specified accuracy is not guaranteed, and it is the user’s responsibility to verify that the
timing precision meets the application requirements.

The commands seem fairly easy to follow, until I get to the Acquire CDF (R) command.    I assume the software pulls the data for what ever channels are selected and increments the delay, runs a cal, pulls the next data, repeating the cycle for however much data we want.   

The R command only takes data and does not perform a cal or increment the delay. For example, in normal operation the official software more-or-less issues the sequence:
CAL D R D R D R ... D R CAL D R D R D R ... D R ... (you get the picture)
This gives you lots of flexibility on which delays you want to take data at.

The third byte represents the value of F(V ;Δt) multiplied by 255.

I'm lost. 2.2.1 doesn't explain things in simple enough terms with enough detail for me to follow along with my limited math skills.  An example in plain text would be helpful.

Or, do I need to find a stats book and start reading? 

The cumulative distribution function (CDF), denoted F(V; Δt), gives the probability that the signal at the post-trigger delay Δt is less than V.
If you're trying to measure a sine wave, for example, you'd expect F(V; Δt) at any fixed Δt to be equal to zero for V < V0 and equal to one for V > V0, where V0 is the actual voltage of the sine wave at Δt. In other words, a step function at V0.

For single-valued signals (e.g. a simple periodic waveform), you can more-or-less average the two neighboring voltages where F(V; Δt) first goes from <0.5 to >0.5 to find the location of the step (V0). (The software does something fancier, fitting a Gaussian error function.)

For more intricate stuff (e.g. eye diagrams), you would need to take the derivative with respect to V to obtain the probability density function. In practice, you'd implement this as a finite difference (F2-F1)/(V2-V1).

We've added this explanation as well as an example program to the next manual revision (see attached).

Hope that cleared things up a bit - let us know if not.

[joeqsmith]

I tell people that when I wrote that software for the VNAs, the time spent actually writing/maintaining the software is very little when compared to researching all the math behind it.   And while there are many good papers on-line, published by the leaders of the industry, they are not perfect and so you run into bugs, compounding the problem.   

Your example code does the easy part.  Collecting all the chunks.  It's what you do with these chunks that I would have liked to see a simple walk through.  If your example code were to set the Q (samples per CDF) to 30, we get 30 chunks for each sample interval consisting of 30 voltages and 30 F(V ;Δt) multiplied by 255.    In your example of 5ns @ 100ps resolution, you end up with 50 of these sets of chunks.  Now we do something with this mess to get it back to a meaningful signal.   That IMO, it the part that would be good to include. 

No doubt, the stats book is one option.  Like the VNA, certainly possible to do that research.  I'm looking for a shortcut.  If there is one trait I have, it's being lazy. 

[SJL-Instruments]

We've attached an explicit example of how to process each chunk.
We describe simplest method that gets you a viewable waveform - it should be a good first "test" if you're writing custom software.

This will be added to the upcoming revision of the manual. Let us know if this explanation is clear.

[joeqsmith]

Big thanks.  I took decided to go ahead and attempt to talk with it.  How hard can it be? 

I have not divided the CDF values by 255 yet.  The waveform is not using the 0.5 CDF but rather just the average of the three center values.   I'll go ahead and add that along with time axis.   Doesn't seem to bad to code up.   

For single-valued signals (e.g. a simple periodic waveform), you can more-or-less average the two neighboring voltages where F(V; Δt) first goes from <0.5 to >0.5 to find the location of the step (V0). (The software does something fancier, fitting a Gaussian error function.)

Do you always use a Gaussian fit to get the centroid?

[SJL-Instruments]

Nice work with the custom software! 

Do you always use a Gaussian fit to get the centroid?

A bit complicated, but details if you're interested: to a first approximation, you can use the interpolation procedure we described in the last post. This usually gets you close, but the noise performance is poor since you're only using two samples.
Fitting a Gaussian error function is theoretically the best thing to do (in the sense of Fisher information), but in practice is overly sensitive to outliers on the wings. What we've found works well in practice is to fit a line to the inverse Gaussian CDF applied to the data, but truncated within a certain region (say 10-90%) of the CDF, with the truncation also seeded by the interpolation method. (This is also faster on the CPU.) You need to weight samples with some care to maintain equal sensitivity to all values (which minimizes the total propagated noise, and improves outlier robustness).

This gives a significantly lower noise floor than the interpolation method alone, but is still robust to spurious errors.

[joeqsmith]

I didn't want you to feel that your posts and updates to the manual were a wasted effort.   It was an evenings work to see that GHz sinewave.  Says a lot about your choice of a protocol. 

The remaining parts for the delay line arrived today.  I plan to assemble it over the weekend, so no rush on the s-parameter support.   

[Kean]

I have no need for such a scope, but it is certainly interesting to read about it and see the great interaction here.  As usual, Joe dives right in.

In the above example of processing the chunks of data titled "4.3.2 Example", the commentary mentions 0.476 mV - but I am pretty sure that is meant to be 0.476 V or 476 mV?

[SJL-Instruments]

In the above example of processing the chunks of data titled "4.3.2 Example", the commentary mentions 0.476 mV - but I am pretty sure that is meant to be 0.476 V or 476 mV?

You're right, keen eye! Thanks for catching that.

[joeqsmith]

I suspect there is still some critical component I am missing.  If I power up the GigaWave and attempt to control it with my software, it appears like it does not run.  All the commands seem to return a valid response and the it sends back data but there its a flat line.  Almost like it is not running.   If I run your software first, then I can run my software and everything works.  I can disconnect, restart and it works just fine.  It acts like there is a command you are sending that I am not that sets the data collection into motion.  Or, perhaps there is an order to commands that are sent to kick it off.

***
I'm sure all these problems are on my side of things.  Not being a programmer by any stretch of the word...

Another thing I noticed as I increase the resolution of the delay something happens with the DSO and it starts to complain about no triggers.   If I increase the trigger holdoff time, it appears to correct it.  I have been testing with a 1GHz source, and I need to push this this number out to 1us for example to use a resolution of 20ps, for example.  The first several reads are always correct.  How soon it fails depends on the combination of the holdoff and resolution  (how much I increment the post trigger delay by. 

[SJL-Instruments]

I suspect there is still some critical component I am missing.  If I power up the GigaWave and attempt to control it with my software, it appears like it does not run.  All the commands seem to return a valid response and the it sends back data but there its a flat line.  Almost like it is not running.   If I run your software first, then I can run my software and everything works.  I can disconnect, restart and it works just fine.  It acts like there is a command you are sending that I am not that sets the data collection into motion.  Or, perhaps there is an order to commands that are sent to kick it off.

Thanks, we are able to reproduce this problem. This is due to some parameters in the R command that we forgot to document (and are only needed once). 

Updated documentation is attached, and will be added to the next revision of the manual. We also caught another minor mistake - the returned value is actually 1 - F(V; ∆t).

We have now tested the example program with a just-plugged-in scope and were able to see a 1 GHz sine wave. Let us know if you still run into issues.


***

Another thing I noticed as I increase the resolution of the delay something happens with the DSO and it starts to complain about no triggers.   If I increase the trigger holdoff time, it appears to correct it.  I have been testing with a 1GHz source, and I need to push this this number out to 1us for example to use a resolution of 20ps, for example.  The first several reads are always correct.  How soon it fails depends on the combination of the holdoff and resolution  (how much I increment the post trigger delay by. 

Unfortunately, we can't reproduce this problem - modifying the example program to take 101 samples between 15 ns and 15.1 ns (i.e. 1 ps resolution) works as intended with a just-plugged-in scope. Could you report if the read failure is persistent (i.e. if you retry the command a few times, does it fail every time after the first)?

[Kean]

Updated documentation is attached, and will be added to the next revision of the manual. We also caught another minor mistake - the returned value is actually 1 - F(V; ∆t).

Rather than s8 & e8, should those be s0...s7 and e0...e7? (for an 8 channel model).

Also having "Rx s0 s1 s2 s3 e0 e1 e2 e3" as the example command format was confusing to me, as that assumes a 4 or 8 channel model with a specific bitmask with 4 enabled channels.
Maybe "Rx s0 ... e0 ..."?

Or I may have misunderstood the syntax completely.

[SJL-Instruments]

Updated documentation is attached, and will be added to the next revision of the manual. We also caught another minor mistake - the returned value is actually 1 - F(V; ∆t).

Rather than s8 & e8, should those be s0...s7 and e0...e7? (for an 8 channel model).

Also having "Rx s0 s1 s2 s3 e0 e1 e2 e3" as the example command format was confusing to me, as that assumes a 4 or 8 channel model with a specific bitmask with 4 enabled channels.
Maybe "Rx s0 ... e0 ..."?

Or I may have misunderstood the syntax completely.

Thanks again - that should indeed be s7 and e7. The number of parameters does not depend on the bitmask, only the model.
We've explicitly written out the format now (see attached) - hopefully that eliminates any confusion.

[joeqsmith]

I was confused by the R1 10000 10000 50000 50000 command.  It appears to me that you are telling it you only have one channel enabled but are setting the limits for two channels.   

Does the number of channels selected have no purpose in this context?  Are you in this example showing that you have a 2-channel scope and are just setting the limits for both as a one time setup (assuming they do not change) and later requesting the number of channels (1 and/or 2) to read?

Unfortunately, we can't reproduce this problem - modifying the example program to take 101 samples between 15 ns and 15.1 ns (i.e. 1 ps resolution) works as intended with a just-plugged-in scope. Could you report if the read failure is persistent (i.e. if you retry the command a few times, does it fail every time after the first)?

Once it failed, it continues to fail every time.  Is there a reason I couldn't request any number of samples I want?  If I keep the delays and resolution the same where it would fail, I can reduce the number of requested samples and it ran fine.  I was assuming there was no limit to how many requests I make.   I thought it may have something to do with my asynchronous calibration command, so I disabled that and it has no effect.  It's almost like I am causing some overflow condition by asking for too much data.   I tried to throttle how fast I send these requests but I currently wait for the end of the frame before changing states.

We also caught another minor mistake - the returned value is actually 1 - F(V; ∆t).

To be clear, we take the (1 - (third number from each chunk divided by 255)) to get the 0-1 you show in your example?  You are not wanting to add 1 to the third number divided by 255.   Examples are good.     

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.

[SJL-Instruments]

I was confused by the R1 10000 10000 50000 50000 command.  It appears to me that you are telling it you only have one channel enabled but are setting the limits for two channels.   

Does the number of channels selected have no purpose in this context?  Are you in this example showing that you have a 2-channel scope and are just setting the limits for both as a one time setup (assuming they do not change) and later requesting the number of channels (1 and/or 2) to read?

Internally, the scope takes data on all channels in parallel, and the requested ranges change what physically happens in the hardware. The bitmask only chooses which data to include or omit in the serial response.
We chose this interface so that you can issue one range command at the start for all channels, and later issue only short commands depending on which channels you want selected.

Unfortunately, we can't reproduce this problem - modifying the example program to take 101 samples between 15 ns and 15.1 ns (i.e. 1 ps resolution) works as intended with a just-plugged-in scope. Could you report if the read failure is persistent (i.e. if you retry the command a few times, does it fail every time after the first)?

Once it failed, it continues to fail every time.  Is there a reason I couldn't request any number of samples I want?  If I keep the delays and resolution the same where it would fail, I can reduce the number of requested samples and it ran fine.  I was assuming there was no limit to how many requests I make.   I thought it may have something to do with my asynchronous calibration command, so I disabled that and it has no effect.  It's almost like I am causing some overflow condition by asking for too much data.   I tried to throttle how fast I send these requests but I currently wait for the end of the frame before changing states.

There is no limit on the number of samples you can take. (In fact, there should be nothing "stateful" in the firmware, and issuing the R command repeatedly should result in identical behavior.)
Does the point of failure always occur at the same number of samples? If so, then this may be caused by the serial buffer filling up. When implementing the example program, we issue a read immediately after sending each command to clear all serial buffers. We can take an arbitrary number of samples without issue.
The timing shouldn't be critical, and no throttling is done in our official software.

We also caught another minor mistake - the returned value is actually 1 - F(V; ∆t).

To be clear, we take the (1 - (third number from each chunk divided by 255)) to get the 0-1 you show in your example?  You are not wanting to add 1 to the third number divided by 255.   Examples are good.     

Yes, this is correct. We'll add this calculation to the example analysis.

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.

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]

There is no limit on the number of samples you can take. (In fact, there should be nothing "stateful" in the firmware, and issuing the R command repeatedly should result in identical behavior.)
Does the point of failure always occur at the same number of samples? If so, then this may be caused by the serial buffer filling up. When implementing the example program, we issue a read immediately after sending each command to clear all serial buffers. We can take an arbitrary number of samples without issue.
The timing shouldn't be critical, and no throttling is done in our official software.

Ok, I will need to dig into it.  I am waiting for the GigaWave to acknowledge each request before sending another.  I never clear out the PC's serial buffers and assume you can take the data as fast as I send requests.   I would think that waiting for the ack would throttle it.    I'll get back with you on it. 

***
It repeats at the same location which is dependent on the Trigger Holdoff.   GigaWave will start to send "NO TRIG ZERO SJLI" or "NO TRIG TIMEOUT n SJLI".   With Trigger Holdoff set to 50, it will start kicking out these messages very soon.  Set it to 500, and it will run for a long time.   I don't see why this would cause any problems with a GHz waveform.  Both values are certainly longer than the 1ns period.   

I am sending the R command separate without setting up the trigger and see the error as expected but it seems fine and will start the collection.  So, this was the reason it would not initially start without running your program first. 

***
Moving the R level setting into the first Read command as your example shows has no effect.  It still behaves the same.  I'm sure I am missing something obvious.

[SJL-Instruments]

It repeats at the same location which is dependent on the Trigger Holdoff.   GigaWave will start to send "NO TRIG ZERO SJLI" or "NO TRIG TIMEOUT n SJLI".   With Trigger Holdoff set to 50, it will start kicking out these messages very soon.  Set it to 500, and it will run for a long time.   I don't see why this would cause any problems with a GHz waveform.  Both values are certainly longer than the 1ns period.   

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.

If you are able to, it would be helpful to provide a text file listing of all the serial commands you're sending in order.

Moving the R level setting into the first Read command as your example shows has no effect.  It still behaves the same.  I'm sure I am missing something obvious.

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.

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

[joeqsmith]

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?

The probes themselves may have a fair amount of skew.  You could use a single output, rotating through each channel and then aligning them.   

A more pressing problem is that the new software does not always seem to catch the glitches.    They still appear to happen towards the start of the sweep as before. 

[SJL-Instruments]

The probes themselves may have a fair amount of skew.  You could use a single output, rotating through each channel and then aligning them.

The difficulty here is that CH1 needs to see a trigger to view any waveform on the other channels (so two outputs are needed). The solution we proposed aligns each probe to CH1 in turn (thus eliminating the probe-to-probe skew). Or perhaps we're misunderstanding your proposal.

A more pressing problem is that the new software does not always seem to catch the glitches.    They still appear to happen towards the start of the sweep as before. 

Thanks for catching this - we'll see if we can reproduce this with extended testing. We've increased the urgency of the debugging/firmware fix. Do you ever see any glitches from the software after 12 ns?

***
And just to double-check - you are using v2.5.5 downloaded from the website, not any of the v2.5.5 pre-release versions we sent, correct?

[joeqsmith]

One possible clue is that when I mentioned that the glitches are commonly negative, it seems to depend on the level of the signal when it first starts acquiring data. 

[joeqsmith]

The probes themselves may have a fair amount of skew.  You could use a single output, rotating through each channel and then aligning them.

The difficulty here is that CH1 needs to see a trigger to view any waveform on the other channels (so two outputs are needed). The solution we proposed aligns each probe to CH1 in turn (thus eliminating the probe-to-probe skew). Or perhaps we're misunderstanding your proposal.

Yes, that is correct. I agree with your original proposal.     

A more pressing problem is that the new software does not always seem to catch the glitches.    They still appear to happen towards the start of the sweep as before. 

Thanks for catching this - we'll see if we can reproduce this with extended testing. We've increased the urgency of the debugging/firmware fix. Do you ever see any glitches from the software after 12 ns?

I can't say for sure without an automated way to collect the min/max.  But, yes it does happen most often between 11 and 12 ns.   

[joeqsmith]

To be clear again, my software makes no attempt to correct these glitches.  Your software may behave differently  What I can show you with my software is the min/max capturing six different events and they all occur prior to 12ns.   If I allow it to run long enough, I will see glitches in other areas but the majority happen towards the start of the sweep. 

[SJL-Instruments]

One possible clue is that when I mentioned that the glitches are commonly negative, it seems to depend on the level of the signal when it first starts acquiring data. 

To be clear again, my software makes no attempt to correct these glitches.  Your software may behave differently  What I can show you with my software is the min/max capturing six different events and they all occur prior to 12ns.   If I allow it to run long enough, I will see glitches in other areas but the majority happen towards the start of the sweep.

Thanks for this information - it's useful as we try to trace the issue. We can reproduce this behavior when directly querying the serial interface.

Just to confirm, you're using v2.5.5 downloaded from the website, correct?
So far, we can reproduce the glitches between 11-12 ns with the last pre-release version (v2.5.5_preview2) we sent you, but not with the latest (website) version. We increased the strictness of the check prior to the public release.

[joeqsmith]

A more pressing problem is that the new software does not always seem to catch the glitches.    They still appear to happen towards the start of the sweep as before. 

Thanks for catching this - we'll see if we can reproduce this with extended testing. We've increased the urgency of the debugging/firmware fix. Do you ever see any glitches from the software after 12 ns?

***
And just to double-check - you are using v2.5.5 downloaded from the website, not any of the v2.5.5 pre-release versions we sent, correct?

You should always have some way distinguish your versions of software that you let out.  If you make any changes, I would roll it to make it easier to track.  I wasn't even aware you had made further changes so I just downloaded the latest. 

It behaves a lot different than the previous two versions of 2.5.5.   It has never been this unstable towards the start of the sweep.   

[SJL-Instruments]

You should always have some way distinguish your versions of software that you let out.  If you make any changes, I would roll it to make it easier to track.  I wasn't even aware you had made further changes so I just downloaded the latest.

Noted - in the future, we'll add a visible marker to any pre-release versions we send.

It behaves a lot different than the previous two versions of 2.5.5.   It has never been this unstable towards the start of the sweep.

Thanks for the information. What kind of signal are you putting into CH1? We'll see if we can reproduce this behavior.

[joeqsmith]

We increased the strictness of the check prior to the public release.

Testing the pre-release software in private was a good idea, IMO.  I just assumed when you released it, you had made no additional changes or you would have ran those by me first. 

Thanks for the information. What kind of signal are you putting into CH1? We'll see if we can reproduce this behavior.

Interesting you ask as it means that you suspect the glitches are shape dependent.  This doesn't give me a lot of comfort as I am always going to be questioning if what I am seeing is real or not.  With that in mind, I do believe that the settings at least have something to do with it.  Assuming that the software I downloaded last night is still the most recent 2.5.5, here are two images.  I used the LiteVNA64 as the source (its normally sitting on the desk and makes a convenient source).  It was set to 150MHz CW.  Using the supplied cable attached directly to channel 1 of the GigaWave. 

Notice if I set the Base to 1ns/div with 32pts/division, we see how unstable the start of the sweep is (below 12ns).  If I change the Base to 2ns/div and 64pts/division (to achieve the same resolution), the displayed waveform is stable below 12ns.  Again, without a min/max or some means to detect these glitches, I can't tell you if it never glitches.   

You used the phrase "... small fraction of returned CDFs may have an error".  I suspect our views on what a small fraction means, differ.  Say for example I want to look at a noise free signal and there is nothing in the environment that can cause an discontinuity in the measurement.  Everything is perfect but, we don't know that.  Now the scope shows the signal has a glitch.   Maybe it's once an hour.  Maybe once a day.   I'm sure many of us have hunted problems like these.   This glitch problem IMO, is the biggest issue you have going.  I'm sure it can be solved but I don't think spending time trying to filter it is a good solution, or use of your time. 

[SJL-Instruments]

Interesting you ask as it means that you suspect the glitches are shape dependent.  This doesn't give me a lot of comfort as I am always going to be questioning if what I am seeing is real or not.

You used the phrase "... small fraction of returned CDFs may have an error".  I suspect our views on what a small fraction means, differ.  Say for example I want to look at a noise free signal and there is nothing in the environment that can cause an discontinuity in the measurement.  Everything is perfect but, we don't know that.  Now the scope shows the signal has a glitch.   Maybe it's once an hour.  Maybe once a day.   I'm sure many of us have hunted problems like these.   This glitch problem IMO, is the biggest issue you have going.  I'm sure it can be solved but I don't think spending time trying to filter it is a good solution, or use of your time. 

Yes, we're on the same page about this. We've put everything else on pause to fix the problem.

We've traced down the problem to a CDC bug in the FPGA. Patching this and running overnight, we took 10 million samples with no errors (no software filtering). This seems promising so far. We'd like to add CRC checks and test to a higher confidence level before declaring the problem "solved," but we'll be in contact shortly about the firmware upgrade procedure.

[joeqsmith]

We've traced down the problem to a CDC bug in the FPGA. Patching this and running overnight, we took 10 million samples with no errors (no software filtering). This seems promising so far. We'd like to add CRC checks and test to a higher confidence level before declaring the problem "solved," but we'll be in contact shortly about the firmware upgrade procedure.

I'm surprised you would have CDC problems with the S7.  I would have thought the tools would do a decent job identifying these problems.

Good to hear you found it.  Send the tools and I will upgrade the hardware.  I'll postpone working on the review until it's resolved.   Consider sending the tools to SignalPath channel as well. 

[joeqsmith]

While digging out my old Xilinx programming adapter for you,  I thought why not set up some simple circuits with an FPGA to make use of the 4 channels.  Shown is a pseudo random sequence generator.  Channel 1 is the clock/2,  Channel 2 is the clock,  Channel 3 in the enable, Channel 4 is the SRS.    Looking at channel 1 and comparing 2.5.3 and the 3rd revision of 2.5.5.  Notice first that both show unstable at the 3rd low state.  The latest shows the 1st & 3rd but the amplitude is lower.   

So there are cases where the glitches can happen after 12ns and happen often and the new filtering may have been causing more problems.  I guess we wait until the updates and see if it solves all these little oddities. 

[joeqsmith]

While I can confidently state that this particular FPGA is not capable of producing a 4 voltage level output, the scope shows otherwise.   Could very well be caused from your timing violation. 

You can almost make out an eye pattern..

[SJL-Instruments]

We've just sent you the updated firmware files, and a pre-release draft of the firmware update documentation. When the Tag-Connect cable arrives, let us know if it fixes the glitches you're seeing.

We're continuing to test the firmware fix, and will release it publicly once we're confident the problem is resolved (likely sometime next week). We've also paused all sales until then.

You can almost make out an eye pattern..

There's a brightness slider in the extended channel settings that might help make the pattern more visible.

[joeqsmith]

Personally, I applaud your decision. 

I'll let you know once the cable shows up.   

[joeqsmith]

I have no problems at all with your instructions and programming for both devices went smooth.  I could not find an Info command in your software, so attached shows the returned values using my software.   Assuming this appears correct to you, the next question is what software version do you want me to test with?  I assume not the latest with the attempts to correct the problems.  Do you have something newer that backs out those changes but has the latest features?   From my own software, is there anything I need to be aware of? 

Just want to make sure I am testing with what you are expecting.   

[SJL-Instruments]

I have no problems at all with your instructions and programming for both devices went smooth.

Good to hear that the documentation is clear and the process went smoothly.

I could not find an Info command in your software, so attached shows the returned values using my software.

We'll add this to the next version of the software - good catch. Your version info looks as expected.

Assuming this appears correct to you, the next question is what software version do you want me to test with?  I assume not the latest with the attempts to correct the problems.  Do you have something newer that backs out those changes but has the latest features?

We have just released minor update v2.5.6 on our website which removes the software filtering (but is otherwise identical to v2.5.5).

From my own software, is there anything I need to be aware of?

When using the interpolation method to extract voltages from the CDF:
1. Apparent spikes may appear even when the returned CDF data is perfectly correct. A simplified example is attached (example 1). This is only a problem when few (<20) samples per CDF are taken.
2. If two or more voltages in the CDF are equal, sort the corresponding CDF values (for that voltage value) from lowest to highest. If the interpolation is done in an incorrect order, a large apparent spike may result (example 2, attached).

These considerations do not apply if you directly fit an error function to the CDF data.

We just discovered effect (2) recently, so we may send you an updated firmware file tomorrow that implements this sorting for you.

[joeqsmith]

...
We just discovered effect (2) recently, so we may send you an updated firmware file tomorrow that implements this sorting for you.

No problem.

In the mean time, I did run it overnight using my software with the LiteVNA attached for a source and no faults were recorded.  It's not an extensive test and I will holdoff doing anything more complex until you send the next update to address these last couple of problems. 

Congratulations on finding the root cause and correcting it in such short order. 

[joeqsmith]

Just a quick check using two channels showing two clocks does indeed cause random glitches.  So it appears I am able to replicate these other problems you mention. 

[SJL-Instruments]

Just a quick check using two channels showing two clocks does indeed cause random glitches.  So it appears I am able to replicate these other problems you mention. 

Does this still occur when the trigger level is placed in the middle of the clock high & low levels?
This might be due to the trigger catching the wrong feature (a small wiggle) and sampling a different time.

[joeqsmith]

I had set the trigger to the mid point when I collected this data.  This was prior to the patch you just provided.  That is now installed and running.   I've been trying different settings and so far so good!!!!  The product has never worked so good!!!   

I suggest adding the min/max (persistence) or what ever means you like to capture such an event.  While it appears this has taken care of the problem, I will not know for sure without having some way to detect it besides watching paint dry on the screen.   I certainly could use my software but really would like to see the whole system working now.   

Again, GREAT JOB!!!   

[SJL-Instruments]

I had set the trigger to the mid point when I collected this data.  This was prior to the patch you just provided.  That is now installed and running.   I've been trying different settings and so far so good!!!!  The product has never worked so good!!!   

Again, GREAT JOB!!!

Thanks - this has been a stressful week for us, but glad it's finally resolved. 
Do let us know if any other issues crop up. Our testing so far has found no further issues, and we're hoping to resume sales by Tuesday.

I suggest adding the min/max (persistence) or what ever means you like to capture such an event.  While it appears this has taken care of the problem, I will not know for sure without having some way to detect it besides watching paint dry on the screen.   I certainly could use my software but really would like to see the whole system working now.   

We'll add that in to the next software revision. Our priority is still our ongoing testing of the firmware patch, but if all goes smoothly we should release a software update by end of next week.

To support our existing customers, we've released manual revision H5 and the firmware upgrade guide on our website. We will be reaching out to everyone in the next day or so to inform them of the fix, and get the flashing hardware shipped out to those who need it.

[joeqsmith]

I'm running some of the other combinations now that had caused problems and am not seeing any glitches.  I did try the intensity setting to get a better view of the eye.  Works good.   

Of course all this means that I will need to resume working on the video again...  Remember, you asked me to do a review..    

***
Simple question for a change.  On the supplied calibration sheet, you use parenthesis on several of the measured values. For example THD you may have -58.4(3)dB.   Normally I would assume these refer to some additional notes but there are none.  What do these values mean?

[SJL-Instruments]

Simple question for a change.  On the supplied calibration sheet, you use parenthesis on several of the measured values. For example THD you may have -58.4(3)dB.   Normally I would assume these refer to some additional notes but there are none.  What do these values mean?

These denote the statistical uncertainties on the measured values: https://physics.stackexchange.com/questions/158589/uncertainty-in-parenthesis
This gives you an idea of the variation in the reported parameter across the range of specified operating conditions.
We'll add a note clarifying this in the future.

[joeqsmith]

...These denote the statistical uncertainties on the measured values: https://physics.stackexchange.com/questions/158589/uncertainty-in-parenthesis...

The one comment could have been written be me.   

Excuse me, but do you have any sources that use this kind of method and/or this notation?

I too have never seen this notation used outside of the link you provided.  From your comment, I assume it is common practice for those working with stats.  I agree, having some sort of note about it and how to interpret it would be helpful. 

[SJL-Instruments]

To avoid confusion, we've switched to the more explicit notation shown in the attached image. Hopefully this is more clear.

[joeqsmith]

It's been running since that last update and I have not detected a single glitch.  I let it run overnight again using my software.  This time collecting a wider range.  I really have only been focusing on this one problem but I ran several tests with it yesterday and nothing else showed up. 

For the manual, you may want to remove the "Single-Point Upsets".    Also consider adding some additional details to the manual for the R(Acquire CDF) command.  When more than one channel is selected, the manual states:

The binary data consists of d chunks of 3Nch bytes each, where Nch is the number of channels requested via the bitmask. Each chunk containsNch three-byte entries, each representing a single CDF value F(V ;Δt) for each requested channel.   

It wasn't clear to me how this data was formatted.   I convert the entire chunk array (which includes data for all selected channels) to form a voltage/CDF array.  I then decimate the data  V1_Ch1,CDF1_Ch1;  V1_Ch2,CDF1_Ch2;  ... V1_Chn,CDF1_Chn;   V2_Ch1,CDF2_Ch1;  V2_Ch2,CDF2_Ch2;  ... V2_Chn,CDF2_Chn;   ...
where Ch is the channel number, Vt and CDFt  are the voltage and CDF for a specific sample.   I thought it may have sent all of the data for the first channel, then the second rather than interlace them. 

[SJL-Instruments]

For the manual, you may want to remove the "Single-Point Upsets".   

In the current revision (H5) of the manual, we changed this section to link to the firmware upgrade instructions. We'll remove the section once we've confirmed everyone is on the patched version.

It wasn't clear to me how this data was formatted.   I convert the entire chunk array (which includes data for all selected channels) to form a voltage/CDF array.  I then decimate the data  V1_Ch1,CDF1_Ch1;  V1_Ch2,CDF1_Ch2;  ... V1_Chn,CDF1_Chn;   V2_Ch1,CDF2_Ch1;  V2_Ch2,CDF2_Ch2;  ... V2_Chn,CDF2_Chn;   ...
where Ch is the channel number, Vt and CDFt  are the voltage and CDF for a specific sample.   I thought it may have sent all of the data for the first channel, then the second rather than interlace them.

We've added the attached example to the next manual revision - let us know if it's clear.

[joeqsmith]

When no trigger is present, the scope will trigger off its internal clock (>100 Mtrig/s) until a valid
trigger source returns.

With nothing attached to the scope's trigger your software will continue to sweep.  Connecting a DC signal to the scope's inputs, you are certainly reading the correct data.  When I try this with my software, the scope never appears to send data unless there is a valid trigger.  Is there another command you are using to force the scope to send the data?

*** Using your software, if there is no trigger when I start, it begins to sweep.  Normal.   If I apply a single trigger event, the software stops sweeping and waits for further triggers.  It never returns to what ever state it was in that allowed it to collect without triggers.   I don't see anything in the software menus that allows me to control this.   Assuming this is how you have designed it to behave,  could you maybe provide further details to the manual explaining it beyond that one sentence?  *** 


Also, while experimenting with my own software and yours, I got the scope into some mode where when I attempt to run your software, I get the attached  error.   Your software would come up to the main menu but that dialog would remain.    I could exit your software and restart and would get this same error.  Eventually, I pulled the USB connection to the scope (power cycling it) which cleared the problem.   I am not a fan of having to power cycle any device to clear an error.  I don't want to be driving down the highway and have to pull over to yank the battery cable to reset the engine's computer.

[SJL-Instruments]

With nothing attached to the scope's trigger your software will continue to sweep.  Connecting a DC signal to the scope's inputs, you are certainly reading the correct data.  When I try this with my software, the scope never appears to send data unless there is a valid trigger.  Is there another command you are using to force the scope to send the data?

There is a command that selects the internal clock source as the trigger (X1 sets internal source, X0 sets to normal trigger mode). For each acquisition, the software first tries in normal mode, and if no trigger is detected, issues the X1 command and retakes the CDF.

See attached image - we'll document this command in the next manual revision.

It never returns to what ever state it was in that allowed it to collect without triggers.

The software should automatically return to the internal trigger ("wait") mode if no triggers are detected (e.g. the signal source is removed). What happens when you try this - does the software freeze?

Also, while experimenting with my own software and yours, I got the scope into some mode where when I attempt to run your software, I get the attached  error.   Your software would come up to the main menu but that dialog would remain.    I could exit your software and restart and would get this same error.  Eventually, I pulled the USB connection to the scope (power cycling it) which cleared the problem.   I am not a fan of having to power cycle any device to clear an error.  I don't want to be driving down the highway and have to pull over to yank the battery cable to reset the engine's computer.

We can reproduce this error if some data remains in the serial buffer prior to starting our software.
We'll send you a preview build shortly that clears the buffers on startup - you can see if this fixes the problem.

[joeqsmith]

There is a command that selects the internal clock source as the trigger (X1 sets internal source, X0 sets to normal trigger mode). For each acquisition, the software first tries in normal mode, and if no trigger is detected, issues the X1 command and retakes the CDF.

See attached image - we'll document this command in the next manual revision.

Please take the time to document ALL of the commands.  Even if you have commands you feel are not something customers would/should use, they may still prove helpful.   

*** Sending X1 or X2, it responds with OK Xn.  Sending X1 followed with R, I do not get any data.  There must be more to it. 

The software should automatically return to the internal trigger ("wait") mode if no triggers are detected (e.g. the signal source is removed). What happens when you try this - does the software freeze?

The software displayed Wait but it stopped sweeping.  I could apply a trigger signal and it remained in Wait.  I can't tell you for sure that it froze.  I have yet to perform a three finger solute to shake your software loose.  I exited the software and restarted and it worked as normal.  I can tell you that I am having a difficult time replicating it.     

[joeqsmith]

Using my software to collect all four channels with min/max active.   I run the RF generator into a splitter then into each channel.  Using 0dBm, 1GHz.   

1) zoomed out showing 46 sweeps, 5ps resolution for 1ns.  I make no attempt to align the channels and we can see that one channel is a bit off compared with the others like I had mentioned.

2)  Looking at the minimum values of the peak area.  Note how channel 1 is smooth where the others have some sort of pattern to them. 

3) Looking at the maximum, we can see they are all smooth. 

If I reset the collection and watch it, I can see when it will create a single mini-glitch.  They are much smaller in amplitude than the original glitches.   This appears very reproducible.   Nothing special with the cables, splitter or RF gen.  Have you seen these smaller spikes?

[SJL-Instruments]

Please take the time to document ALL of the commands.  Even if you have commands you feel are not something customers would/should use, they may still prove helpful.   

Got it - there are two remaining serial commands we'll document in the next revision: set CDF epsilon (section 2.2.1), and direct CDF measurement at V,t.

*** Sending X1 or X2, it responds with OK Xn.  Sending X1 followed with R, I do not get any data.  There must be more to it.

We were able to get CDF data with the following procedure:
1. Plug in the scope.
2. Issue command X1.
3. Issue command R1 10000 10000 10000 10000 50000 50000 50000 50000.
Does this sequence fail to return data on your unit?

The software displayed Wait but it stopped sweeping.  I could apply a trigger signal and it remained in Wait.  I can't tell you for sure that it froze.  I have yet to perform a three finger solute to shake your software loose.  I exited the software and restarted and it worked as normal.  I can tell you that I am having a difficult time replicating it.     

The software is separated into a frontend and backend process. We can reproduce this behavior if we manually kill the backend process. We'll see if there's any code path that would crash the backend. (And also add code to restart it automatically, as a failsafe.)

In principle, this frontend/backend separation should also prevent the UI from freezing up, no matter what the scope does (i.e. the "three-finger salute" should never be needed).

[SJL-Instruments]

1) zoomed out showing 46 sweeps, 5ps resolution for 1ns.  I make no attempt to align the channels and we can see that one channel is a bit off compared with the others like I had mentioned.

This is consistent with the specified max THD of the scope at 1 GHz - it's limited by Channel 1 at early times (11-12 ns). All other channels perform better than spec.

2)  Looking at the minimum values of the peak area.  Note how channel 1 is smooth where the others have some sort of pattern to them. 

3) Looking at the maximum, we can see they are all smooth.

If I reset the collection and watch it, I can see when it will create a single mini-glitch.  They are much smaller in amplitude than the original glitches.   This appears very reproducible.   Nothing special with the cables, splitter or RF gen.  Have you seen these smaller spikes?

These effects are from the input hysteresis interacting in a subtle way with the delay generator.
This is what limits the specified noise floor of the scope. The actual RMS noise in the smooth regions is about 5x better than specs (200 uV RMS).
Getting rid of it completely would likely require a different architecture and push the price up significantly.

[joeqsmith]

As it continues to run, it's interesting that channel 1 never exhibits these downward spikes where the other three do.  It never happens in the valley, only the peak.  I would not have noticed it as I was only ever looking at channel 1 with my software until today.   I'll take your word for it that it is the expected behavior from your design perspective.  As a user, I would be concerned it was my signal generator causing this, then spending time hunting down a problem that isn't there.   

[joeqsmith]

*** Sending X1 or X2, it responds with OK Xn.  Sending X1 followed with R, I do not get any data.  There must be more to it.

We were able to get CDF data with the following procedure:
1. Plug in the scope.
2. Issue command X1.
3. Issue command R1 10000 10000 10000 10000 50000 50000 50000 50000.
Does this sequence fail to return data on your unit?

I was using 0 65535 rather than 10000 and 50000.  I also had the first 4 channels enabled.  I tried it with your settings and get the following:

NO TRIG ZERO SJLI

So no difference.  I assume X1 is sent with no other payload and terminated normally.  The fact it returns an OK it seems correct.  If X1 is selected and I supply a trigger, it does trigger normally.  It behaves the same for X0 and X1.   I'm sure I am missing something simple as your software appears to work correctly.

[SJL-Instruments]

So no difference.  I assume X1 is sent with no other payload and terminated normally.  The fact it returns an OK it seems correct.  If X1 is selected and I supply a trigger, it does trigger normally.  It behaves the same for X0 and X1.   I'm sure I am missing something simple as your software appears to work correctly.

That's odd. Are you sending any commands in between? Sending a D command will reset to normal trigger mode (X0) - see our reply #154.
Our software issues exactly this sequence (X1 then R).

[SJL-Instruments]

As it continues to run, it's interesting that channel 1 never exhibits these downward spikes where the other three do.  It never happens in the valley, only the peak.  I would not have noticed it as I was only ever looking at channel 1 with my software until today.   I'll take your word for it that it is the expected behavior from your design perspective.  As a user, I would be concerned it was my signal generator causing this, then spending time hunting down a problem that isn't there.   

The data you posted in #156 is within specified behavior, but a bit on the worse side (~5 mV min-max spread after 50 sweeps). The data in #159 is not within specifications (~15 mV min-max spread).

We are running a test unit in the same configuration as you (~240mVpp @ 1 GHz on all channels), and so far (300 sweeps) our min-max spread on all channels does not exceed 1.1 mV. This is using the interpolation method - doing an error function fit pushes the noise even lower.

Can you send the raw CDF data from some of the worst samples (~15 mV off)? What holdoff and trigger level are you using?

[joeqsmith]

So no difference.  I assume X1 is sent with no other payload and terminated normally.  The fact it returns an OK it seems correct.  If X1 is selected and I supply a trigger, it does trigger normally.  It behaves the same for X0 and X1.   I'm sure I am missing something simple as your software appears to work correctly.

That's odd. Are you sending any commands in between? Sending a D command will reset to normal trigger mode (X0) - see our reply #154.
Our software issues exactly this sequence (X1 then R).

Yes, I always send the D prior to sending R.  Good to know it resets the trigger mode.  May want to consider adding that note to the manual. 

I am trying it now and it appears to be working correctly. 

[joeqsmith]

We are running a test unit in the same configuration as you (~240mVpp @ 1 GHz on all channels), and so far (300 sweeps) our min-max spread on all channels does not exceed 1.1 mV. This is using the interpolation method - doing an error function fit pushes the noise even lower.

I'm using 30 samples, linear fit interpolation . 

Can you send the raw CDF data from some of the worst samples (~15 mV off)?

If I use your software to stream all the data to disk and let it run for a half hour, could you track it down from that?   

[SJL-Instruments]

If I use your software to stream all the data to disk and let it run for a half hour, could you track it down from that?   

Currently the streaming does not support raw CDF data. We'll patch it shortly and send you a version that does.

[joeqsmith]

Installed and running.  I have it recording all four channels.   If you have a way to sift through all of that data, I can send you the worse case ones, or I can compress the whole directory and send it.  I'll let it run a half hour. 

[SJL-Instruments]

Installed and running.  I have it recording all four channels.   If you have a way to sift through all of that data, I can send you the worse case ones, or I can compress the whole directory and send it.  I'll let it run a half hour. 

Thanks. Compressing the whole directory is fine - it provides more statistics anyway.

[joeqsmith]

No problem.  You should have it.

[SJL-Instruments]

We received it - thanks.
Analyzing the saved voltages, the largest min-max spread on any channel, at any time, was 6.7 mV. (This is the max over 119 sweeps * 736 pts/sweep * 4 channels = 366kpts.)
(All the data is plotted in the below images.) Channels 1 and 2 plotted (4-attachment limit).

The residuals (deviation from the average trace) are all within nominal specs. The noise is larger when the signal has a larger slope - this is caused by timing jitter translating into voltage jitter.
The RMS noise was well below 1 mV on all channels.

Overall, we didn't see anything out of the ordinary - no spikes. You can reproduce this analysis if you'd like (voltages are saved as a standard CSV).

I'm using 30 samples, linear fit.

Could you describe precisely how you implemented the linear fit? Is it as described in Section 4.3.2?

[joeqsmith]

It's VERY possible the problem is in my software, which is why I wanted to use yours to collect the data.  Best to divide these problems in half.

I am not fitting the data.  Rather I simply use linear interpolation.  Corrected previous statement, there is no fitter  Using this, with a 1GHz full scale signal applied, I measure -36.6dB for THD.  The published measured value was -37.65 +/-12dB.  Being the lazy person I am, I called it a day.   

Let me try adding a gaussian fit like was first mentioned and see if it improves things.   

***
A new day. 

From the manual:

you can recover the signal voltage V0 by interpolating between the two neighboring voltages where F(V ;Δt) first transitions from below 1/2 to above 1/2.

...
2. If two or more voltages in the CDF are equal, sort the corresponding CDF values (for that voltage value) from lowest to highest. If the interpolation is done in an incorrect order, a large apparent spike may result (example 2, attached).

These considerations do not apply if you directly fit an error function to the CDF data.

We just discovered effect (2) recently, so we may send you an updated firmware file tomorrow that implements this sorting for you.

...

Do you always use a Gaussian fit to get the centroid?

A bit complicated, but details if you're interested: to a first approximation, you can use the interpolation procedure we described in the last post. This usually gets you close, but the noise performance is poor since you're only using two samples.
Fitting a Gaussian error function is theoretically the best thing to do (in the sense of Fisher information), but in practice is overly sensitive to outliers on the wings. What we've found works well in practice is to fit a line to the inverse Gaussian CDF applied to the data, but truncated within a certain region (say 10-90%) of the CDF, with the truncation also seeded by the interpolation method. (This is also faster on the CPU.) You need to weight samples with some care to maintain equal sensitivity to all values (which minimizes the total propagated noise, and improves outlier robustness).

This gives a significantly lower noise floor than the interpolation method alone, but is still robust to spurious errors.

Attached plot shows a typical CDF values (WHITE) that appear out of order.  The GigaWave has all the recent patches.   If I don't sort them, and weigh CDF values that are outside of the 5-95% at 0 (no effect), all others inside the window weighted at 1, then run a linear fit (RED).   Then interpolate the fitted data to find the centroid index.  Use that index and linear interpolation to determine the voltage.  The two numbers are close.    Also shown using 10/90% window, same weighting, with sorting CDF.

First, do I always need to sort the CDF values?  Is there a problem that I am seeing what appears to be out of order data? 

With this calculation being crucial, it seems that for anyone wanting to reproduce the result obtained using your software,  your conversion needs to be well documented. 

[joeqsmith]

Plot comparing the linear and gaussian fit with sorted CDF and 10/90% window, 0 weight for anything outside.  Again, linear interpolation used to locate mid point. 

I have not tried these in my software to see which is more robust.  Rather I would like to replicate what your software does. 

At some point, when I start working on the review (remember the review?),  I am guessing there will be tests I want to conduct that your software does not support.  For example, maybe I decide to show the THD.  Your software does not have this feature built-in.   To automate such measurements, my software will need to replicate your results.   

[SJL-Instruments]

First, do I always need to sort the CDF values?  Is there a problem that I am seeing what appears to be out of order data?

Do not sort the CDF data. The out-of-order points are expected, and result from noise in the signal. (More precisely, the integrated portion of the low-frequency content up to the sampling timescale, Section 2.2.2.)
If you set Nmin=Nmax=N0 (fixed triggers per sample), the noise in the CDF will go to zero as N0 -> infinity.

Plot comparing the linear and gaussian fit with sorted CDF and 10/90% window, 0 weight for anything outside.  Again, linear interpolation used to locate mid point.

I have not tried these in my software to see which is more robust.  Rather I would like to replicate what your software does. 

You should not fit a line or a Gaussian to the CDF data. You should fit a Gaussian error function, of the form:

f(x) = 1/2 (1 + erf(A(x-x0)))

where A and x0 are free parameters. The fitted value of x0 is the extracted voltage.


We've added a section laying this out clearly in the next manual revision (see attached image).
There have been enough updates that we've released revision H6 of the manual, which contains this explanation.

[joeqsmith]

Thanks.  This helps.   

Could you do me a favor and write a simple program that maybe reads one of the streamed CSV files from your software, performs the calculations (identical to how your software works) and shows the result?  I wouldn't care if you released the source or not although it may be helpful to have it.  Basically, I want to prove that we obtain the same results. 

Reminds me of a few years ago, I ran into a similar problem where a coworker was using MatLab's filtfilt function and I was attempting to replicate their algorithms.

https://www.eevblog.com/forum/chat/matlab-zero-phase-digital-filtering-question/msg4429354/#msg4429354

I got lucky in that case as someone had found a document that detailed how it worked.  I did something similar where I fed data through both algorithms to prove out my math. 

***
Another option you may want to consider is where you provide interface libraries for the different OSs you support.  This would give you total control over the algorithms and takes that burden away from customers.   Personally, I see it as a wash, as long as you provide enough detail to implement your exact algorithms. 

Also, personally I like having the PC make all of these calculations rather than the embedded system.  Why not leverage the latest PC technology.  I have to believe it also makes your job much easier by minimizing the complexity of the firmware.  I think about that NanoVNA and just how unstable that firmware was.   

[SJL-Instruments]

Could you do me a favor and write a simple program that maybe reads one of the streamed CSV files from your software, performs the calculations (identical to how your software works) and shows the result?  I wouldn't care if you released the source or not although it may be helpful to have it.  Basically, I want to prove that we obtain the same results. 

Here's an open-source CoLab notebook that implements both the linear interpolation and curve fit methods:
https://colab.research.google.com/drive/1wAReesZiEhuauzbm_8LAfhkgA2IYOyij?usp=sharing

There's a sample file in the notebook if you just want to check your code.
If you want to use your own data, you will need to select "Raw CDF Data" when exporting/streaming to get a .npz file. The CSV files only contain the extracted voltage information (no CDFs).

You might want to check your linear interpolation code as well - we didn't see any spikes even when re-analyzing all our past data using linear interpolation. (The noise was a bit higher, though.)

Another option you may want to consider is where you provide interface libraries for the different OSs you support.  This would give you total control over the algorithms and takes that burden away from customers.   Personally, I see it as a wash, as long as you provide enough detail to implement your exact algorithms. 

Our Python API is cross-platform and implements the curve fitting algorithm. We understand not everyone wants to use Python, though - the description in manual revision H6 is hopefully clear enough to implement yourself.

Also, personally I like having the PC make all of these calculations rather than the embedded system.  Why not leverage the latest PC technology.  I have to believe it also makes your job much easier by minimizing the complexity of the firmware.  I think about that NanoVNA and just how unstable that firmware was.   

That's our philosophy as well. Software is much easier to update, lowers the end-user cost of the hardware, and gives the user more flexibility if they need it (as you've been doing in LabView).

[joeqsmith]

Consider that my math skills are about the level of Jethro Bodine's (Beverly Hillbillies, sixth grader dropout),  it will take a lot of effort on my part to work through it. 

I don't like that you are not seeing a problem with linear interpolation.  That tells me we are missing something.  Let's minimize the variables.  The attached were created using your latest software/firmware/FPGA.  Same Marconi RF generator, Pasternak splitter and cables.  Using different settings than before.  Note how it glitches positive on the rise and negative on the fall.  Also note, all four glitch synchronously. 

Your software works a little different than mine and the settings appear to make a difference.  Or, maybe something else is going on. 

[SJL-Instruments]

I don't like that you are not seeing a problem with linear interpolation.  That tells me we are missing something.  Let's minimize the variables.  The attached were created using your latest software/firmware/FPGA.  Same Marconi RF generator, Pasternak splitter and cables.  Using different settings than before.  Note how it glitches positive on the rise and negative on the fall.  Also note, all four glitch synchronously. 

Can you send us raw CDF data from when this occurs? Choose the "Raw CDF Data" option in the stream or export dialog (v2.5.7 preview 2). The file you attached only contains CSV with the extracted voltages.

***

The fact that all four glitch synchronously looks like a timing issue (i.e. it's returning correct CDF data at an incorrect time). The four small spikes in your data are consistent with the timing being late by either 25 ps or 12 ps.

We've never seen this happen before, so there's no check for this in firmware. It's easy to add one - we just didn't think it would be necessary.
We have a few ideas about the root cause, but more data would be very helpful - particularly if you phase-shift one of the channels. This would make a timing error unambiguous.

[joeqsmith]

For example, while streaming I drag the screen you are expecting it to error out?   It is very possible this is what happened in this case. 

I can certainly start providing you with data using your NPZ format, however without being able to view the data, I have no way to know if I would be sending you anything useful.   It keeps getting back to the lack of some sort of min/max function. 


For the custom software, baby step 1,  showing raw CDF, Gaussian error applied and inverse Gaussian error applied.  Is this what you are expecting?

[SJL-Instruments]

For example, while streaming I drag the screen you are expecting it to error out?   It is very possible this is what happened in this case.

Yes, if you drag the screen, the timebase will get reindexed, and occasionally the newest sample will get put in the wrong place. This is known behavior.
If you see the small spikes with our software without touching the screen, then we need to investigate further.

I can certainly start providing you with data using your NPZ format, however without being able to view the data, I have no way to know if I would be sending you anything useful.   It keeps getting back to the lack of some sort of min/max function. 

For diagnosing a timing error, the CSV voltage information is enough (especially if the channels have different phases). Based on our internal testing, and the data you provided in #168, we're confident the CDF routine has no issues. (In which case the NPZ doesn't give much additional information.)

For the custom software, baby step 1,  showing raw CDF, Gaussian error applied and inverse Gaussian error applied.  Is this what you are expecting?

We can't tell in detail without zooming into the interesting area. But you should either:
1. Fit a Gaussian error function directly to the CDF data, or
2. Apply the inverse Gaussian error function to the CDF data and then fit a line with proper weights.
Both approaches are equivalent (to first-order).
The Gaussian error function should never be applied to the data.

It will also help the fit stability (particularly with method 2) if you discard all data where the CDF is <0.1 or >0.9.

[joeqsmith]

Got it.  No dragging.   If I am able to find a glitch using your software, I will send both formats.   

We can't tell in detail without zooming into the interesting area. But you should either:
1. Fit a Gaussian error function directly to the CDF data, or
2. Apply the inverse Gaussian error function to the CDF data and then fit a line with proper weights.
Both approaches are equivalent (to first-order).
...

It will also help the fit stability (particularly with method 2) if you discard all data where the CDF is <0.1 or >0.9.

From the 4.3.3 example, there are only three data points that meet that criteria.   Showing the raw plus two methods for these three points.   Using least squares for linear fit of the inverse Gaussian Error.   

The Gaussian error function should never be applied to the data.

Totally lost me but I suspect based on your comment about them being the same, there is something wrong with what I have shown. 

[joeqsmith]

Looking at the previous data I provided, you only plotted channels 1&2.  Also note that you only plot 119 of the 150 sweeps.   I wrote a simple viewer for your CSV files to show all of the data and have included the data for channel 3.   I assume these micro glitches toward the peak are considered normal based on your previous statements. 

[SJL-Instruments]

Looking at the previous data I provided, you only plotted channels 1&2.  Also note that you only plot 119 of the 150 sweeps.   I wrote a simple viewer for your CSV files to show all of the data and have included the data for channel 3.   I assume these micro glitches toward the peak are considered normal based on your previous statements. 

The zip file you provided contains only 119 files - perhaps some of them were excluded.
Based on your plot, the largest spike is ~5 mV from the mean over 150 sweeps. We consider this within specification (but on the worse side).
If there is a timing issue, then this would also explain why all the spikes are downwards. (But doesn't explain why they're at the peak only.)

From the 4.3.3 example, there are only three data points that meet that criteria.   Showing the raw plus two methods for these three points.   Using least squares for linear fit of the inverse Gaussian Error.   

Totally lost me but I suspect based on your comment about them being the same, there is something wrong with what I have shown. 

The inverse Gaussian error function (as described in 4.3.4) should send 0.5 to 0. As a sanity check, verify that:
g(0.5) = 0
g(0.8 ) = 0.5951
g(0.2) = -0.5951
where g(x) = erf^-1(2x-1) as defined in 4.3.4 (implementation note 1).

If you perform a linear fit, it must also be weighted according to 4.3.4 implementation note 1 - otherwise the outer points will blow up the fit.

[joeqsmith]

1  Start by selecting only CDFs that meet: "The fit is performed only on the subset of entries satisfying 0.1 < F < 0.9 for numerical stability."
2) g(x) = erf^-1(2x-1) is then calculated for the CDF subset.
2) run a linear fit on this data using some sort of weighted numbers. 
3) For the weights, we take the derivative of CDF raised to ^-2
4) multiply the weights by step 2

The inverse Gaussian error function (as described in 4.3.4) should send 0.5 to 0. As a sanity check, verify that:
g(0.5) = 0
g(0.8 ) = 0.5951
g(0.2) = -0.5951

That much I can verify.  See attached.   

[SJL-Instruments]

1  Start by selecting only CDFs that meet: "The fit is performed only on the subset of entries satisfying 0.1 < F < 0.9 for numerical stability."
2) g(x) = erf^-1(2x-1) is then calculated for the CDF subset.
2) run a linear fit on this data using some sort of weighted numbers. 
3) For the weights, we take the derivative of CDF raised to ^-2

Yes, this should work (if in step 3 you mean g'(F)^-2). The extracted voltage is then just the x-intercept of the fitted line. This is how it's done in the software.

The derivative of g should always be positive - if the blue line is g'(F), then that part looks incorrect. As a check, you should have g'(0) = 1.772.
You should not take the derivative of the CDF - you want the derivative of g evaluated at the CDF.

[joeqsmith]

1  Start by selecting only CDFs that meet: "The fit is performed only on the subset of entries satisfying 0.1 < F < 0.9 for numerical stability."
2) g(x) = erf^-1(2x-1) is then calculated for the CDF subset.
2) run a linear fit on this data using some sort of weighted numbers. 
3) For the weights, we take the derivative of CDF raised to ^-2

Yes, this should work. The extracted voltage is then just the x-intercept of the fitted line. This is how it's done in the software.

The derivative of g should always be positive - if the blue line is g'(F), then that part looks incorrect.

Well you say that but don't underestimate my ability to screw things up! 

I suspect I have an error in (g'(F))^-2.   

If I multiply the weights after the least squares, shown in fitter 5. 

 

[SJL-Instruments]

The weights shouldn't multiply anything. They should be used to perform a weighted least squares fit to the line.
(i.e. pass g'(F)^-2 into the weight input of the LabView Linear Fit VI.)

A closed-form formula for g' is g'(x) = sqrt(pi) * exp(g(x)^2).
To get the appropriate weights, evaluate g'(F)^-2 at each CDF value F.

[joeqsmith]

Opps,  got the weights.   I'm still stuck on the g'(0) = 1.772.  Guessing you are not suggesting the derivative of 0. 

Remember when using a scope meant adjusting a few knobs?   

[SJL-Instruments]

You can use the formula g'(x) = sqrt(pi) * exp(g(x)^2).
In other words, g'(x)^-2 = exp(-2 g(x)^2)/pi. Put that directly into the least-squares weight.
You've already computed g(x) at every point, so this should be a small change.

Remember when using a scope meant adjusting a few knobs?   

LabView interface is now on our todo list. 

[joeqsmith]

If correct ...

[SJL-Instruments]

If correct ...

Weights should read 0.3183, 0.1568, 0.1568. (i.e. exp(-2x^2)/pi applied to InvGauErr.)
Not sure what leastsq means. It's not really meaningful unless you run it on actual data.

[joeqsmith]

So the weights now come out correctly.  Least squares fit?

[SJL-Instruments]

So the weights now come out correctly.  Least squares fit?

Run some actual CDF data (e.g. the data in example 4.3.2). Fit InvGauErr on the y axis versus voltage on the x axis, with the computed weights. You'll get a straight line intersecting the x axis. The intersection point is the voltage you want.

[joeqsmith]

If you get the same results, the next question I have is there any difference between this and what your software is doing?

It's too bad but I really don't see a future for LabView. 

[SJL-Instruments]

If you get the same results, the next question I have is there any difference between this and what your software is doing?

Looks good to us. This is exactly what the software implements.

We also have a check that the extracted fit voltage lies between the 25th and 75th percentile of the CDF. If not, we revert to using the interpolation method. This only matters at low triggers/sample or samples/cdf, when the data is very noisy and the fit might blow up.

If you keep Nmax above 500 and K above 20, this shouldn't be an issue.

[joeqsmith]

Painful for you I'm sure but I appreciate you hanging in there. 

Also, this entire time I have been running tests looking for a single glitch using your software (and not touching the screen) and everything is clean.  I tried all sorts of settings.   

I think the next step is to roll the fitter into my software and see if it remains stable.     

[SJL-Instruments]

Painful for you I'm sure but I appreciate you hanging in there. 

Nope, glad to hear it was useful! If nothing else, hope you learned something. 

Also, this entire time I have been running tests looking for a single glitch using your software (and not touching the screen) and everything is clean.  I tried all sorts of settings.   

Great to hear. Our internal testing has found no further problems either (and we tried quite hard to cause problems). We're resuming sales as of tomorrow (Tuesday) morning.

[joeqsmith]

Certainly learning more about your product. 

I have the fitter installed now and running the same settings as before.   I'll let you know how it goes.

Review wise,  I think we are about a week behind what I had planned.  Once things get back to normal for you, I think the next step is start knocking off some of those features.  Maybe another week and we can get back to creating that video. 

Here's a spoiler....

[joeqsmith]

Originally, I was seeing glitches within 50 sweeps.  With the new fitter, it is now at 639 with the same settings as before and no signs of any problems. 

***
Does your hardware support a low power draw mode?  Basically, I want to turn it off when not in use without having to pull the cable. 

Do you have any plans to add THD measurements to verify performance?

There is nothing in the calibration sheet or manual that talks about the linearity. 

Thinking about the inputs, any idea where they start to compress? 

[SJL-Instruments]

Does your hardware support a low power draw mode?  Basically, I want to turn it off when not in use without having to pull the cable. 

No, this is not supported. The maximum power draw of the device is 4 W.

Do you have any plans to add THD measurements to verify performance?

We can certainly add this, and measurements of all harmonic powers, to the FFT utility.
Note that the calibration sheet THD/ENOB are obtained via a time-domain regression, which does not depend on a choice of FFT window or having an integer number of periods. If using an FFT, you should use a large integer number of periods for accurate results.

There is nothing in the calibration sheet or manual that talks about the linearity.

To clarify, you mean the DC linearity?

Thinking about the inputs, any idea where they start to compress?

The inputs do not compress - they're not sent through an amplifier. We have found the THD to be largely independent of signal amplitude.

[joeqsmith]

My Signal Hound products are the same in that you can not turn them off.  To work around it, they are ran from a powered hub. 

It would be nice to have some of the features mentioned for the review as I would rather avoid having to use my software.   At the same time, I understand that completing that list of features is going to take some time. 

Yes, DC linearity.   There was a reason I asked about this undocumented X1 command...

The inputs do not compress - they're not sent through an amplifier. We have found the THD to be largely independent of signal amplitude. 

From that, I assume it is linear up to where it starts to clip.   Any idea what the recovery time is?  Can I drive the input into saturation without damaging it? 

[SJL-Instruments]

It would be nice to have some of the features mentioned for the review as I would rather avoid having to use my software.   At the same time, I understand that completing that list of features is going to take some time.

Yep, we're aiming to have the most useful features implemented by Saturday.

Yes, DC linearity.   There was a reason I asked about this undocumented X1 command...

From that, I assume it is linear up to where it starts to clip.   Any idea what the recovery time is?  Can I drive the input into saturation without damaging it? 

DC linearity is 0.1%, although we don't characterize this on a per-unit basis.
There is no recovery time as the signal does not clip. This is inherent to our choice of architecture. You can apply any signal within the absolute maximum range (±1.2V) indefinitely.
(The official software soft-clips the signal to 1.1V, but this isn't a hardware limit.)

[joeqsmith]

I think you are stating that as long as the signal remains within some defined limits, the front end will not saturate, clip or compress.  I guess you could say that about any circuit.   That is not what I am asking.   Early on you mention driving it with 5V.  Far outside the specified limit.  What happens under this condition?

[SJL-Instruments]

I think you are stating that as long as the signal remains within some defined limits, the front end will not saturate, clip or compress.  I guess you could say that about any circuit.   That is not what I am asking.   Early on you mention driving it with 5V.  Far outside the specified limit.  What happens under this condition?

We haven't characterized this in detail, as it's outside the absolute maximum operating conditions.
We still expect zero recovery time and no compression, as there is no amplifier to saturate.
If the signal exceeds 1.5V, you will not be able to measure it, since the CDF query voltage ranges only from -1.5V to 1.5V.

The accuracy within the operating band (±950 mV) will likely remain unaffected even if the signal itself goes up to ±2V. Beyond that, the frontend chip may eventually experience thermal failure, and the input will fail open (high-impedance). You can probably get away with larger spikes if they are infrequent.

Any damage to the frontend is covered by warranty.

[joeqsmith]

Can you provide a sketch of the front end?

[SJL-Instruments]

Can you provide a sketch of the front end?

The frontend consists of a latched comparator with the signal sent into one input and the other input held at the CDF query voltage.
If you're asking about the saturation recovery time of the comparator (which contains a limiting amplifier), it's independent of the overdrive voltage and equal to the 40 ps rise/fall time of the scope.
(It's in this sense that there's zero recovery time - it doesn't depend on what signal you put in.)

[joeqsmith]

If the signal exceeds 1.5V, you will not be able to measure it, since the CDF query voltage ranges only from -1.5V to 1.5V.

(The official software soft-clips the signal to 1.1V, but this isn't a hardware limit.)

When you applied your 5V signal, I assumed you did not have the software limit.  What does the GigaWave read?  1.5V? I assume with X1, you can force the trigger and would think it would limit at the +/-1.5V. 

Any damage to the frontend is covered by warranty.

If it were a handheld DMM that should be somewhat robust,  you should have some concern.  If I damage your scope with my testing, it will not be intentional.  With all the high voltages I play with, I have never damaged any of my equipment.  I did loose a good amplifier last year when working with those microwave horns without a wrist strap.  Who would have guessed....    

***
Attached showing the data from last night after updating the fitter.   

[SJL-Instruments]

The reading would depend on how you processed the data - all of the returned CDF values would be zero, indicating that the signal exceeds the requested upper bound. The official software would clip it to 1.1V.

What’s your setup for the overnight data? Internal trigger with all inputs shorted?

[joeqsmith]

What’s your setup for the overnight data? Internal trigger with all inputs shorted?

Marconi 2024 (1GHz) to Wilkinson to GigaWave to PC to LabView

See PE2012
https://www.pasternack.com/sma-4-way-50-ohm-rf-power-dividers-category.aspx

External trigger. 

[SJL-Instruments]

Marconi 2024 (1GHz) to Wilkinson to GigaWave to PC to LabView

See PE2012
https://www.pasternack.com/sma-4-way-50-ohm-rf-power-dividers-category.aspx

External trigger. 

Got it - so in #205, you're plotting with the mean waveform subtracted?
Since the small spikes you're seeing are on CH2 and CH3 only, this rules out a timing problem.
We've been unable to reproduce the small spikes so far using the same signals.

It's odd that they only occur on CH2 and CH3. You can try running with a falling-edge trigger to see if the spikes then appear on CH1.
Internally, CH4 has a different polarity from CH2/CH3 and is inverted in firmware. A falling-edge trigger will invert CH1 internally.

[joeqsmith]

I wasn't too concerned by this bit of noise. 

Got it - so in #205, you're plotting with the mean waveform subtracted?

That data represented about an hour.  I took the mean for each individual channel for that entire 1 hour data set.  I then subtract each mean from their respective channel.

Since the small spikes you're seeing are on CH2 and CH3 only, this rules out a timing problem.
We've been unable to reproduce the small spikes so far using the same signals.

It's odd that they only occur on CH2 and CH3. You can try running with a falling-edge trigger to see if the spikes then appear on CH1.

The previous data was taken using the falling edge but I can repeat the test with the rising edge if you like.  I'm not big on changing multiple variables at once but I'll double the input voltage as well.  Manual states edge amplitude is 200mVp-p min and my test signal was about 250mVp-p.   Still you don't think it is timing.  Also, the scope was off all day as well and the office is much cooler.       

Internally, CH4 has a different polarity from CH2/CH3 and is inverted in firmware. A falling-edge trigger will invert CH1 internally.

Sharing a bit of insider information....

[joeqsmith]

I ran a few tests to try and help answer what is going on with noise.   

For starts, rotate the original date where we are looking at the sweep time rather than the number of sweeps.  Again, subtracting off the mean as previously described.   Note how channels 2,3&4 show the disturbance around 11.75ns.   

[joeqsmith]

As I mentioned, I repeated the test doubling the input voltage and using the rising edge trigger.  Showing about 2.5 hours of data.  The p-p noise is greatly improved.

[joeqsmith]

To try and narrow down why we are seeing this improvement, the input signal was returned to the same level that was used during the original test but the trigger remained set to the rising edge.   Here we are looking at about 5 hours of data. 

[joeqsmith]

So, is it the trigger edge?  Time to repeat the original test using the same signal levels and falling edge.   I let it run about a half hour longer than the original test.   

[joeqsmith]

I'm at a loss of what to suggest.   Same cables, generator, scope, splitter, PC, USB port, software...  Scope and splitter resting on a ground plane next to my VNA.   The setup wasn't taken apart between tests.   I wasn't playing with my spark gap transmitter, ignition systems or anything else I would expect would cause a disturbance. 

The only thing that has really changed is or course, its a different day and the office temperature was lower.  As you know, I had tried to look at the stability with temperature but at that time we did not have the new FPGA/firmware.  I plan to repeat these tests once your software has evolved.  Maybe that has something to do with it. 

Let me know if you have any ideas. 

***
If the setup is not clear, see attached sketch.

[SJL-Instruments]

Thanks for the detailed experiments. The noise level in the last three results are consistent with our test units. We have run a few temperature tests after the firmware update and saw nothing unusual, but it will be interesting to see your results.

Your results from #210 again rule out any timing issue (since CH1 is clean), and anything to do with the internal inversion (since CH4 behaves similarly to CH2, CH3).

I plan to repeat these tests once your software has evolved.  Maybe that has something to do with it. 

We think the software is an unlikely culprit - all channels are processed in the same way at all delays.

[joeqsmith]

Thanks for the detailed experiments. The noise level in the last three results are consistent with our test units

No problem. Wish things would have repeated.  You can see from the first and last data sets how channel 1&4 matched up very close to the original data.   

Your results from #210 again rule out any timing issue (since CH1 is clean), and anything to do with the internal inversion (since CH4 behaves similarly to CH2, CH3).

Signal generator is common across all 4 channels.  Doubt the 4 cables or splitter is bad. 

We think the software is an unlikely culprit - all channels are processed in the same way at all delays.

Can you think of anything with the hardware that could cause this?  I'm not referring to the FPGA but the physical hardware like soldering, artwork, contamination.     

[SJL-Instruments]

Can you think of anything with the hardware that could cause this?  I'm not referring to the FPGA but the physical hardware like soldering, artwork, contamination.     

Nothing special happens in the hardware at 11.8 ns - a physical issue might cause a problem, but it's odd that the increased noise would only show up at one delay.

Your unit was from our first small-run batch (earmarked for test/review only). Since we improve our process and QA with each run, the first batch is also the most likely to have physical issues. We've sent you an email with more specifics on which chips/etc might cause a problem. But any physical issue we can think of would cause random spikes everywhere, not just at one time.

[joeqsmith]

Can you think of anything with the hardware that could cause this?  I'm not referring to the FPGA but the physical hardware like soldering, artwork, contamination.     

Nothing special happens in the hardware at 11.8 ns - a physical issue might cause a problem, but it's odd that the increased noise would only show up at one delay.

Your unit was from our first small-run batch (earmarked for test/review only). Since we improve our process and QA with each run, the first batch is also the most likely to have physical issues. We've sent you an email with more specifics on which chips/etc might cause a problem. But any physical issue we can think of would cause random spikes everywhere, not just at one time.

Like all multifaceted problems, it takes time to peel away the layers of the onion.   I suspect we are not dealing with so much an 11.8ns time, but rather what was happening with the signal at that time.  When I attempted to measure channel 1's return loss, it was unstable.  Reworking the connector solved that.  Now, channel 1 appears to be the most stable.  After your updates to the FPGA and firmware, I have yet to see anything I would consider a glitch on that channel after several hours of testing. 

Upon further inspection, I have some concerns with the soldering which I plan to address.  I wonder with the spikes showing at the peak apex of the sinewave, are we dealing with a noise problem in the hardware.  With it being a prototype I am not at all concerned about your production soldering.  Of course, this means I will be removing the PCB from the case to address any bottom side issues as well.  If after rework I continue to see any problems, I may have a look at the BGA. 

On the upside, you have time to work on your software.  I want both of us to have full confidence in that hardware before getting back to the review.

[joeqsmith]

Could you provide details on what all the self test entails?   

Thinking about my comment about it not being so much related to time but rather it being the positive apex of the signal, look at the last set of plots.  Note that the highest noise for all 4 channels is in that region.  Oddly we don't see that with the negative apex.  If you think the signal's shape is exacerbating the problem with this particular hardware, should we test it with say a squarewave?  Higher frequency?   

Basically, I am looking for your thought on proving out the hardware after rework.

[SJL-Instruments]

Could you provide details on what all the self test entails?   

The self-test verifies FPGA communication, checks the minimum and maximum range of the delay generator, checks the delay generator calibration is valid, checks that all channels are returning data (verify the CDF is >0.7 at 1V and <0.3 at -1V), and verifies that the internal trigger source is working.
The self-test does not verify any of the external trigger settings.

Thinking about my comment about it not being so much related to time but rather it being the positive apex of the signal, look at the last set of plots.  Note that the highest noise for all 4 channels is in that region.  Oddly we don't see that with the negative apex.  If you think the signal's shape is exacerbating the problem with this particular hardware, should we test it with say a squarewave?  Higher frequency?   

Basically, I am looking for your thought on proving out the hardware after rework.

To be honest, we're not sure, as we can't reproduce the noise spikes you're seeing with our test units. Higher frequency will increase sensitivity to timing jitter (but as CH1 is fine, that's likely not the problem). Given that a 1 GHz sine wave is known to reveal the issue on your unit (at least sometimes), we'd recommend staying with this signal to keep things consistent. But if you find a signal that reliably causes increased noise, we'll see if we can reproduce your results.

[joeqsmith]

Thanks for the added details on the self test.    Attached showing the raw data from #210. 

***
Spent a few hours today inspecting every joint (except the BGA) and reworking anything questionable (major).  Also cleaned it to remove all the loose balls and residue.   

It appears to have had some effect as the channels are not matched near as well.  Do you align the scopes for gain, offset, other...  Store in NVRAM?  Can this be performed outside of factory?  What tools are required? 

Of course, the big question is if it had any effect on the noise.  This is going to take some time to answer. 

[SJL-Instruments]

It appears to have had some effect as the channels are not matched near as well.  Do you align the scopes for gain, offset, other...  Store in NVRAM?  Can this be performed outside of factory?  What tools are required? 

We do not individually calibrate every channel - all the analog components are tightly toleranced to obtain good matching.
In what way are the channels no longer matched? (DC offset, THD, overall gain, etc.)

[joeqsmith]

It appears to have had some effect as the channels are not matched near as well.  Do you align the scopes for gain, offset, other...  Store in NVRAM?  Can this be performed outside of factory?  What tools are required? 

We do not individually calibrate every channel - all the analog components are tightly toleranced to obtain good matching.
In what way are the channels no longer matched? (DC offset, THD, overall gain, etc.)

Looking at post 197 showing all 4 channels prior to rework.  You can see, they were never really matched well.  After rework, they have spread apart even further.   I would need to run some tests to determine how much is due to gain vs offset but it sounds like it currently isn't  possible to correct for them anyway.  Are there plans to add some sort of alignment procedure to your software that could be saved?

https://www.eevblog.com/forum/testgear/pocket-sized-6-ghz-1-tss-et-scope/msg5306536/#msg5306536

The manual has a max offset with inputs shorted and a tolerance for the input impedance at 1GHz and we also now know your return loss is in the 17dBish range.   

Maybe it's not an issue for most users.  I wouldn't normally make measurements with the inputs shorted to ground or with a 1GHz signal.  It would be difficult for me to know how mismatched the channels really are when looking at them with your software.  I would wonder, how much is the scope contributing to the error compared with my signals.  Maybe there is a way to clarify this.

When you specify the maximum DC RMS (section 1.5), are you running internal trigger with all inputs shorted?   

****
In general, it appears that the gain has increased.  However, I suspect there may be more to it.  The attached data is for channel 2 only.  Yellow trace was from post 197 during the start of the collection.   The orange trace was taken the day after with the same settings.  Notice how the gain has increased.   Violet was taken after the scope had ran for about 3 hours after my rework.   

[joeqsmith]

Again, looking at channel 2.  Showing the first set of data after I reworked the board.  We are looking at sweeps on the X-axis, hourish of time.  This is subtracting the mean from the signal as previously described.  Note how the noise level decreases as it warms up.

[joeqsmith]

To get some idea how the gain changes with temperature, again, looking at channel 2.   Here is the start of the previous dataset, again the first test right after reworking the board with it cold.   I repeated this test about 3 hours later with the scope running other tests that entire time.  Notice, the gain did not change at all.   

It's possible that things were not stable prior to reworking the board.  That couple of hours I mentioned working on it wasn't an embellishment.   I would guess I touched 20 joints conservatively but most likely more in the order of 50. 

[joeqsmith]

Showing channels 1-4 at the start of run 6.  Again, this is after reworking the board and with it having been running for 3 hours.    We can clearly see there is a gain error but notice the spread of the positive apex is tighter than at the negative apex.  The scope has always behaved this way but that spread has opened up with the increase in gain.   I can't tell from looking at the manual if these are considered normal.   

[SJL-Instruments]

Looking at post 197 showing all 4 channels prior to rework.  You can see, they were never really matched well.  After rework, they have spread apart even further.   I would need to run some tests to determine how much is due to gain vs offset but it sounds like it currently isn't  possible to correct for them anyway.  Are there plans to add some sort of alignment procedure to your software that could be saved?

The next revision of the software has a one-click tool for trimming the DC offset.
This will of course not fix any gain error. You can try testing the DC linearity with the internal trigger to see if there's an overall scaling error. Global scaling error should be around 1%, with a linearity of around 0.1%.
The frequency-dependence of the gain error cannot in general be fixed for a sampling scope.

When you specify the maximum DC RMS (section 1.5), are you running internal trigger with all inputs shorted?   

The specification applies to measuring any stable signal and analyzing the resulting RMS deviations from the mean.
Running internal trigger with inputs shorted is a special case of this.

Again, looking at channel 2.  Showing the first set of data after I reworked the board.  We are looking at sweeps on the X-axis, hourish of time.  This is subtracting the mean from the signal as previously described.  Note how the noise level decreases as it warms up.

This is known behavior - after warmup, the RMS noise should be somewhat better than the specification.

Showing channels 1-4 at the start of run 6.  Again, this is after reworking the board and with it having been running for 3 hours.    We can clearly see there is a gain error but notice the spread of the positive apex is tighter than at the negative apex.  The scope has always behaved this way but that spread has opened up with the increase in gain.   I can't tell from looking at the manual if these are considered normal.   

The spread occurs primarily in the 11-11.5 ns region and should be unrelated to signal level. It should be lower after 12 ns.
This is known behavior and limits the minimum ENOB specification at 1 GHz.

[joeqsmith]

This is known behavior - after warmup, the RMS noise should be somewhat better than the specification.

The spread occurs primarily in the 11-11.5 ns region and should be unrelated to signal level. It should be lower after 12 ns.
This is known behavior and limits the minimum ENOB specification at 1 GHz.

Thank you very much for supplying those valuable tips!! 

You can try testing the DC linearity with the internal trigger to see if there's an overall scaling error. Global scaling error should be around 1%, with a linearity of around 0.1%. 

Before working with the internal trigger, I would want to implement your other correction as I assume the internal trigger is considered low.

We also have a check that the extracted fit voltage lies between the 25th and 75th percentile of the CDF. If not, we revert to using the interpolation method. This only matters at low triggers/sample or samples/cdf, when the data is very noisy and the fit might blow up.

If you keep Nmax above 500 and K above 20, this shouldn't be an issue.

Showing the same 4 sets of data for channel 3.   White was the initial testing from post 197,  Red was repeating this test prior to reworking the board, Green was taken when the scope was cold right after rework and Blue was after 3 hour warmup after rework. 

I am using the absolute values to provide you with a better view of the gain and offset as well as the different in noise levels between the positive and negative apex.   Note that noise is still higher in the positive region.  Maybe a bit of noise on one of the supplies.  Maybe it's normal.  It has always been there and guessing what aggravates the glitches. 

Verdict it still out on if these glitches will show up after rework.  The plan is to run the hardware up until the software is ready, or until I get bored watching it... Which ever comes first. 

[joeqsmith]

We also have a check that the extracted fit voltage lies between the 25th and 75th percentile of the CDF. If not, we revert to using the interpolation method.

Just to make sure, using your example from 4.3.3, the CDF for the fit voltage would be 0.500 which is within your 0.27&0.75 criteria, meaning use the Gaussian fit rather than interpolation?   

[SJL-Instruments]

Thank you very much for supplying those valuable tips!! 

We've added these notes to the next manual revision as well.

Before working with the internal trigger, I would want to implement your other correction as I assume the internal trigger is considered low.

Could you clarify what you mean by "the internal trigger is considered low"?
We'll send you a pre-release version of the software today or tomorrow that implements the DC offset trim.

Showing the same 4 sets of data for channel 3.   White was the initial testing from post 197,  Red was repeating this test prior to reworking the board, Green was taken when the scope was cold right after rework and Blue was after 3 hour warmup after rework. 

I am using the absolute values to provide you with a better view of the gain and offset as well as the different in noise levels between the positive and negative apex.   Note that noise is still higher in the positive region.  Maybe a bit of noise on one of the supplies.  Maybe it's normal.  It has always been there and guessing what aggravates the glitches. 

Thanks again for supplying this data. The noise from this plot is considered within specification - RMS deviation from mean waveform should be ~1 mV or lower. The zero-crossings are within the ±50 ps (±20 ps typ) global timebase shift specification.

Just to make sure, using your example from 4.3.3, the CDF for the fit voltage would be 0.500 which is within your 0.27&0.75 criteria, meaning use the Gaussian fit rather than interpolation?   

First compute the 0.25 and 0.75 percentile from the CDF using the interpolation method (i.e. the first and third quartiles in voltage). In this case, this would be at 0.474V and 0.477V. The check is to verify that the voltage obtained from the Gaussian error function lies within these two bounds.

[joeqsmith]

Before working with the internal trigger, I would want to implement your other correction as I assume the internal trigger is considered low.

Could you clarify what you mean by "the internal trigger is considered low"?

Your initial comment was:

This only matters at low triggers/sample or samples/cdf, when the data is very noisy and the fit might blow up.

You didn't define "low", but the manual states:

When no trigger is present, the scope will trigger off its internal clock (100 Mtrig/s) until a valid trigger source returns.

and also:

The main limitation of the CDF sampling technique is for signals with infrequent trigger opportunities (500 ktrig/second or lower).

By low, did you mean < 500ktrig/sec?  If so, internal trigger does not fall into that category? 
 

Thanks again for supplying this data. The noise from this plot is considered within specification - RMS deviation from mean waveform should be ~1 mV or lower. The zero-crossings are within the ±50 ps (±20 ps typ) global timebase shift specification.

Thanks.

Just to make sure, using your example from 4.3.3, the CDF for the fit voltage would be 0.500 which is within your 0.27&0.75 criteria, meaning use the Gaussian fit rather than interpolation?   

First compute the 0.25 and 0.75 percentile from the CDF using the interpolation method (i.e. the first and third quartiles in voltage). In this case, this would be at 0.474V and 0.477V. The check is to verify that the voltage obtained from the Gaussian error function lies within these two bounds.

   This is why I ask.  Something so simple, left to my own, I will get it wrong.    I have gone ahead and made this change and will try it out tonight. 

[SJL-Instruments]

Your initial comment was:

This only matters at low triggers/sample or samples/cdf, when the data is very noisy and the fit might blow up.

You didn't define "low", but the manual states:

When no trigger is present, the scope will trigger off its internal clock (100 Mtrig/s) until a valid trigger source returns.

and also:

The main limitation of the CDF sampling technique is for signals with infrequent trigger opportunities (500 ktrig/second or lower).

By low, did you mean < 500ktrig/sec?  If so, internal trigger does not fall into that category? 

Here we meant that the fit may give noisy results when the setting for "triggers per sample" (i.e. Nmin and Nmax in the Advanced CDF Settings) is low. This is unrelated to the trigger rate. Apologies for any confusion.

[joeqsmith]

Apologies for any confusion.

No problem.  Always best to ask.   

Before writing code to sweep the DC, I decided to try shorting the inputs.  Interesting, without that last change it will create NaNs.  I assume expected.  With the check added,  it has been running for about 15 minutes now without a fault.   So it does appear to be required in some cases.   You may want to include that in the manual as well.

[SJL-Instruments]

Before writing code to sweep the DC, I decided to try shorting the inputs.  Interesting, without that last change it will create NaNs.  I assume expected.  With the check added,  it has been running for about 15 minutes now without a fault.   So it does appear to be required in some cases.

Is this in your custom software, or our software? The check should not be required for shorted inputs - it's there only for low-sample situations where the data is very noisy. May be worth tracing down where the NaNs are coming from.

[joeqsmith]

Is this in your custom software, or our software? The check should not be required for shorted inputs - it's there only for low-sample situations where the data is very noisy. May be worth tracing down where the NaNs are coming from.

My software.  It's very possible I am still not understanding your fitter math.  Attached data is with short applied to channel 1.  No CDF data falls within the 0.9 to 0.1 range.  For now it just sets the NaN as you don't define what to do in this condition and I didn't ask.       

Sweeping DC (single ended only), appears. linear.

[SJL-Instruments]

My software.  It's very possible I am still not understanding your fitter math.  Attached data is with short applied to channel 1.  No CDF data falls within the 0.9 to 0.1 range.  For now it just sets the NaN as you don't define what to do in this condition and I didn't ask.       

Sweeping DC (single ended only), appears. linear.

Thanks for the clarification. In this situation, the official software reverts to the 0.5 CDF interpolation method.
***
In fact, we revert to the interpolation method unless there are at least 2 points in the 0.5-0.9 range and 2 points in the 0.1-0.5 range. This is to prevent single outliers from blowing up the fit.

[joeqsmith]

Thanks for that info.  I'll add that check to my software as well.  Goal of this software is really just to give me an easy way to test your hardware/firmware while I wait for your software to catch up.   

Tonight's test, collecting some long high res data sets.  Well... compared to my typical 1-4ns tests, its long...   

[joeqsmith]

In fact, we revert to the interpolation method unless there are at least 2 points in the 0.5-0.9 range and 2 points in the 0.1-0.5 range.

I want to make sure I understand this simple statement.  So 2 data points of 0.5 gives us 2 points in the 0.5-0.9 range and 2 points in the 0.1-0.5 range. Details details...

[SJL-Instruments]

In fact, we revert to the interpolation method unless there are at least 2 points in the 0.5-0.9 range and 2 points in the 0.1-0.5 range.

I want to make sure I understand this simple statement.  So 2 data points of 0.5 gives us 2 points in the 0.5-0.9 range and 2 points in the 0.1-0.5 range. Details details...

Luckily, this cannot happen, since the returned values are expressed as an integer fraction over 255 (odd). 

[joeqsmith]

Luckily, this cannot happen, since the returned values are expressed as an integer fraction over 255 (odd). 

So you want it coded as written where a value of 0.5 is included in both bins?  So 3 points minimum?

[SJL-Instruments]

So you want it coded as written where a value of 0.5 is included in both bins?

In our software, we check for 2 points satisfying 0.5 < x < 0.9 and 2 points satisfying 0.1 < x < 0.5.
Whether you include the endpoints has no effect on the behavior, since none of the values 0.1, 0.5, 0.9 can occur exactly given the serial encoding scheme.

[joeqsmith]

1.1 states the absolute input voltage is +/-1.2V or 2.4V full scale.  1.5 states vertical resolution is 12-bits or 560uV.   With this in mind, showing a 10MHz sine applied, 5ps resolution.  Please explain the steps.   

[SJL-Instruments]

1.1 states the absolute input voltage is +/-1.2V or 2.4V full scale.  1.5 states vertical resolution is 12-bits or 560uV.   With this in mind, showing a 10MHz sine applied, 5ps resolution.  Please explain the steps.   

We cannot reproduce these steps with the official software, looking at a similar timebase/voltage range and with a 10 MHz sine wave. (See attached screenshot.)
Can you see the steps using our software?

[joeqsmith]

Yes, I can show it with your software but the difference is the source.  We are seeing effects from my old Marconi 2024.  Time to ditch it and go with the old HP8640B cavity. 

[joeqsmith]

About 48 hours of running various settings, signals and the hardware appears stable. 

The new software seems to cover the basics.   If I change the waveform,  do I have to delete all the min / max waveforms and recreate them?  There is no simple reset?   Yes, I read the manual.  So, simple example.  Connect your LiteVNA to channel 1.  Set the Lite to 1GHz CW.   With your software, enable the min/max.   Now set the Base to 10ns / div.   Let it sweep.  Now set it to 100ps.    I am able to reproduce this. 

Now change the Base to 200ps then back to 100ps.  All it correct, except, note on the far right.       

[SJL-Instruments]

If I change the waveform,  do I have to delete all the min / max waveforms and recreate them?  There is no simple reset?   Yes, I read the manual.  So, simple example.  Connect your LiteVNA to channel 1.  Set the Lite to 1GHz CW.   With your software, enable the min/max.   Now set the Base to 10ns / div.   Let it sweep.  Now set it to 100ps.    I am able to reproduce this. 

Now change the Base to 200ps then back to 100ps.  All it correct, except, note on the far right.       

Thanks for the feedback. We'll add a "clear" button to the official release, and/or mark the waveform data as invalid after the timebase is changed. For now, you can change the formula (to e.g. "maxhold(CH1)+1"), press enter, and change it back. (Or you can delete and recreate the waveforms, as you stated.)

[joeqsmith]

Overall, the new software seems easy enough to use.    Manual is coming along.     

Maybe consider pressing the Min/Max Hold once they have been enabled, resets or erases the waveforms rather than adding more of them.   How many min max waveforms for channel 1 does one need?    

3.4.4 FFT does not mention the THD feature.   The software shows invalid.  Is it implemented and not documented, or just a place holder?

One person had asked about tracking the rise time.   Can you add histograms, averages, RMS.... to the measurements?    Currently you can only display 8 measurements.  You may need to make use of the upper right area of the display.   

Can histograms be added for math waveforms?

What is the limiting factor in the 200 mVPP trigger limit?  I assume you require a minimum of that value.    Consider that a resistive probe may be 20:1.  Even old TTL would not meet that level.   Maybe I am not understanding the spec.   

[SJL-Instruments]

Maybe consider pressing the Min/Max Hold once they have been enabled, resets or erases the waveforms rather than adding more of them.   How many min max waveforms for channel 1 does one need?    

We'll remove the button if both a minhold and maxhold for the channel are present. The user can modify the math expressions in the added channels, so we'd re-enable the button if one (or both) expressions are altered.

3.4.4 FFT does not mention the THD feature.   The software shows invalid.  Is it implemented and not documented, or just a place holder?

The THD will display as invalid if there isn't enough resolution to get an accurate measurement. You should have five full periods (ideally 10) to get a meaningful result. We'll clarify this in the manual.

One person had asked about tracking the rise time.   Can you add histograms, averages, RMS.... to the measurements?    Currently you can only display 8 measurements.  You may need to make use of the upper right area of the display.

It's easy enough to allow multiple rows of measurements at the bottom. Our first thought is to have a window open when you click a measurement, which allows editing of the measurement, as well as displaying the histogram, trend, average, RMS, percentiles, etc.
We can add an option to pin some or all of this information to the upper right as well.
(By default, the upper right area is unused so that the software can be docked to one half of the screen without issue.)

Can histograms be added for math waveforms?

Yes - we can likely get this in by tomorrow's release.

What is the limiting factor in the 200 mVPP trigger limit?  I assume you require a minimum of that value.    Consider that a resistive probe may be 20:1.  Even old TTL would not meet that level.   Maybe I am not understanding the spec.   

The trigger will work below 200 mVpp, but at a reduced bandwidth. At low amplitudes, you might need to bump the trigger level up or down by a few mV to get a stable trigger. The limit stated in the manual is a conservative guideline.

[joeqsmith]

Indeed, at 5.8GHz the required level is different than 1GHz.  Is the sensitivity vs frequency defined somewhere?   I assume that we can bias that 200mV anywhere as long as we stay within the common mode range (+/-950mV). 
   
0.2 X 20 (probe attenuation) or 4V swing which is CMOS.  Even if you work reliably at 100mvp-p, or a 2V swing, that rules out most logic?  Are you expecting it to work with say LVDS and a 20X resistive probe?    The manual doesn't  offer any suggestions or guidelines when it comes to probing.   

The THD will display as invalid if there isn't enough resolution to get an accurate measurement. You should have five full periods (ideally 10) to get a meaningful result. We'll clarify this in the manual.

Is the THD in your software calculated differently than the calibration certification?  If the settings are critical as far as replicating what you call out, you may want to define them.   

[SJL-Instruments]

Indeed, at 5.8GHz the required level is different than 1GHz.  Is the sensitivity vs frequency defined somewhere?   I assume that we can bias that 200mV anywhere as long as we stay within the common mode range (+/-950mV).

We do not have an official spec for sensitivity vs. frequency. To give you a rough idea, generally the GigaWave can trigger off 60 mVpp @ 1 GHz. The trigger level must be centered within the peak-to-peak range. The 200 mVpp edge can have any DC bias within the specified range.
   

0.2 X 20 (probe attenuation) or 4V swing which is CMOS.  Even if you work reliably at 100mvp-p, or a 2V swing, that rules out most logic?  Are you expecting it to work with say LVDS and a 20X resistive probe?    The manual doesn't  offer any suggestions or guidelines when it comes to probing.

We would not recommend using a 20x resistive probe - even a 0.3 pF input capacitance, which is the lowest we've seen for a 20x commercial resistive probe, presents as ~270 ohm @ 2 GHz. The fastest transition time we've found is ~80 ps for a 20x passive probe, which is twice the 40 ps spec of the GigaWave.
At that point, we'd recommend using a 5x probe which has a flat 250 ohm input impedance up to 6 GHz. We have such a design, and plan to include a few as a standard accessory in the future. We are actually considering open-sourcing this design.

A 5x probe with LVDS would give a ~70 mVpp swing, which we have found that the GigaWave can trigger on directly @ 2 Gbps. However, we would recommend using an external clock or CDR for generating an eye diagram.

The THD will display as invalid if there isn't enough resolution to get an accurate measurement. You should have five full periods (ideally 10) to get a meaningful result. We'll clarify this in the manual.

Is the THD in your software calculated differently than the calibration certification?  If the settings are critical as far as replicating what you call out, you may want to define them.   

The THD in the calibration certificate is obtained via a time-domain regression, not an FFT. With only a few periods, the THD calculated from the FFT will depend on the windowing method used and the timebase range. The time-domain method is immune to these considerations (and gives statistical uncertainties on the extracted parameters).
We will mention this, as well as the exact timebase settings used, in the manual.

[SJL-Instruments]

As promised, we have released v2.5.7 of the software which adds math channels, histograms, and various other improvements. The accompanying manual has also been updated (revision H7).

[joeqsmith]

Interesting idea about including probes.  5X is getting down there.  I try to keep loading under 10% error and use 10X (500ohms) in many cases.   100 ohm differential termination with another 200 to ground on each leg .... maybe...   I guess as long as people understand the limits of the trigger it's fine.  Leave it up to them to sort out if it can be used or not.  Consider you may be using a delay line with the 5X probe, knocking another 6dB off.   A lot to consider.  As you said, it's down to price point.   

After starting the software, set all offsets to 0.  Entering 50 for scale on channel 1 will randomly select 50 V/div or 50 mV/div.  I would expect it to be predictable and was surprised that 50V would be valid.  Seems easy enough to reproduce. 

I have had the software appear to hang.  Basically it was displaying wait, but appeared not to be updating the plots as nothing was being displayed on the graph for all 4 channels.  Nothing, meaning a blank screen.  I changed the scale to 500mV/div, and it remained blank.   Offsets all set to 0.   I increased the input voltage to 500mVp-p with no triggers.  10MHz.   All I did was exit the software and restart, everything was working as expected.  I have not been able to replicate this but I have seen the software hang like this before with an earlier revision.

I am curious if you are getting any feedback on the UI.  It's easy enough to run but IMO, not very smooth.   

It's a real pain to hunt down your waveforms with manually setting the offset and scale.  Typing in the scales rather than the drop down selection do allow me to set it to what ever I want, but now its a bigger time waste entering all that data.   

I would like to see this thing have some sort of intelligent mode where is autoscales the vertical, locks the start of acquisition to the left, changing the vertical scale resets or at least causes min/max to track.    It's the same with dragging the waveform to change the offset, the min/max doesn't track it. It's a constant close waveforms and recreate.    Or if I change the vert scale for channel 1, the scale for the min/max don't track it. 

Having that start of acquisition time moving all over based on the Base is a pain.  I am constantly dragging waveforms.   

It's very possible that your customers like the UI.  Consider I am up there in years and have used a lot of different scopes, it could just be my bias on how they should work.   Years ago, I looked at a brand new logic analyzer from HP.  That is all I have ever used and for the most part, they all drove the same.  Even with the touch screen and single knob.  This new thing was like they had fired the entire staff, brought in new management that had no idea what a LA was, and decided to make a product that worked (in their minds) better than the old systems.  Or they had no idea how their old products drove.  To me it seemed they were trying to target software people for the end user rather than hardware.    It was so bad, I gave a simple test to other EEs to see if they could run it.  In the end, the software was why I didn't procure it. 

A few years ago I wanted to buy a better VNA for home hobby use.  Get out of the 1970s...   I looked at Picotech.  Really liked the hardware.  Price was high but specs are good.  4-receiver....  Then I tried their software and ditched the idea.   I reached out to them last year to make a series of videos on their VNA but no bites.   

Point being, software for these is IMO, is every bit as important as the hardware.   If it drives different than every product out there, it may not get a lot of acceptance.   Again, MO. 

[SJL-Instruments]

Interesting idea about including probes.  5X is getting down there.  I try to keep loading under 10% error and use 10X (500ohms) in many cases.   100 ohm differential termination with another 200 to ground on each leg .... maybe...   I guess as long as people understand the limits of the trigger it's fine.  Leave it up to them to sort out if it can be used or not.  Consider you may be using a delay line with the 5X probe, knocking another 6dB off.   A lot to consider.  As you said, it's down to price point.

Yes, the loading is not ideal. The 5x probe prioritizes flatness over loading. Perhaps we could offer both 5x and 10x probes. At high frequencies, you become limited by the characteristic impedance of the probe tips themselves, which (thought of as a transmission line) are ~200 ohm. This is close enough to 250 ohm that a 5x probe is easy, but a 10x probe is harder to get right.

After starting the software, set all offsets to 0.  Entering 50 for scale on channel 1 will randomly select 50 V/div or 50 mV/div.  I would expect it to be predictable and was surprised that 50V would be valid.  Seems easy enough to reproduce.
...
It's a real pain to hunt down your waveforms with manually setting the offset and scale.  Typing in the scales rather than the drop down selection do allow me to set it to what ever I want, but now its a bigger time waste entering all that data.   

Entering "50" will give 50V/div, and entering "50m" will give 50 mV/div. We'll change this back to a dropdown in the next update, with an option to change it to a textbox if you need arbitrary scales. This change was made primarily for compatibility with high-voltage probes.

I have had the software appear to hang.  Basically it was displaying wait, but appeared not to be updating the plots as nothing was being displayed on the graph for all 4 channels.  Nothing, meaning a blank screen.  I changed the scale to 500mV/div, and it remained blank.   Offsets all set to 0.   I increased the input voltage to 500mVp-p with no triggers.  10MHz.   All I did was exit the software and restart, everything was working as expected.  I have not been able to replicate this but I have seen the software hang like this before with an earlier revision.

That's odd - nothing, as in the axis labels were gone also? Or only the traces?
Shortly after v2.5.7 released, we noticed that de-embedding did not work at 128 pts/div (screen would blank), and re-uploaded a patched version. This may or may not be the issue.

It's the same with dragging the waveform to change the offset, the min/max doesn't track it. It's a constant close waveforms and recreate.    Or if I change the vert scale for channel 1, the scale for the min/max don't track it. 

Got it - next update, we will implement the min/max so that it tracks the offset/scale properly. (And waveform persistence as well.)
The current way (with math channels) gives more flexibility, but is non-standard.

Having that start of acquisition time moving all over based on the Base is a pain.  I am constantly dragging waveforms.   
...
I would like to see this thing have some sort of intelligent mode where is autoscales the vertical, locks the start of acquisition to the left[...]

To clarify: the software currently references the "timebase position" to the center of the screen. Changing the base (or zooming in with the scroll wheel) will zoom in keeping the center of the screen fixed. This lets you put the event of interest in the center of the screen, and zoom in.
It was implemented this way by customer request.
Are you proposing that changing the timebase scale should instead keep the left side of the screen fixed? Or the T=0 marker fixed? It's easy enough to make this an option.

Point being, software for these is IMO, is every bit as important as the hardware.   If it drives different than every product out there, it may not get a lot of acceptance.   Again, MO. 

We agree with this - your feedback so far has been immensely helpful. We want to be as responsive as possible to customer feedback, to push the software in the right direction.

[joeqsmith]

After starting the software, set all offsets to 0.  Entering 50 for scale on channel 1 will randomly select 50 V/div or 50 mV/div.  I would expect it to be predictable and was surprised that 50V would be valid.  Seems easy enough to reproduce.
...
It's a real pain to hunt down your waveforms with manually setting the offset and scale.  Typing in the scales rather than the drop down selection do allow me to set it to what ever I want, but now its a bigger time waste entering all that data.   

Entering "50" will give 50V/div, and entering "50m" will give 50 mV/div. We'll change this back to a dropdown in the next update, with an option to change it to a textbox if you need arbitrary scales. This change was made primarily for compatibility with high-voltage probes.

I guess I wasn't clear.  Entering "50" does not always give 50V/div.  It will sometimes give 50mV/div.   Try setting channel 1 using 50m.  You should see 50 mV/div.   Now set it to 50.  Does it stay at 50 mV/div or does it change to 50 V?   Try it a few times.  It's not repeatable every time.   Appears random.

I have had the software appear to hang.  Basically it was displaying wait, but appeared not to be updating the plots as nothing was being displayed on the graph for all 4 channels.  ...

That's odd - nothing, as in the axis labels were gone also? Or only the traces?
Shortly after v2.5.7 released, we noticed that de-embedding did not work at 128 pts/div (screen would blank), and re-uploaded a patched version. This may or may not be the issue.

Sorry I did not take a screen capture.  It was showing wait.  Signal input was more than enough to trigger device.   Trigger level set to 0.   It was like the internal trigger was not working and it wasn't able to detect a valid trigger.   Restart of the software cleared it. 

To clarify: the software currently references the "timebase position" to the center of the screen. Changing the base (or zooming in with the scroll wheel) will zoom in keeping the center of the screen fixed. This lets you put the event of interest in the center of the screen, and zoom in.
It was implemented this way by customer request.
Are you proposing that changing the timebase scale should instead keep the left side of the screen fixed? Or the T=0 marker fixed? It's easy enough to make this an option.

Exactly.  I want to lock the timebase position to the left, center or right.  Adjusting anything else in the timebase would not effect its location.   

I would also like to be able to set the acquisition length rather than the samples per division.   I want to start at T0, or 11ns, record for 2ns with a resolution of 1ps.  Today, it's not that flexible.   

Point being, software for these is IMO, is every bit as important as the hardware.   If it drives different than every product out there, it may not get a lot of acceptance.   Again, MO. 

We agree with this - your feedback so far has been immensely helpful. We want to be as responsive as possible to customer feedback, to push the software in the right direction.

I downloaded the PicoTech software for their scope and tried it out. 

Is the THD in your software calculated differently than the calibration certification?  If the settings are critical as far as replicating what you call out, you may want to define them.   

The THD in the calibration certificate is obtained via a time-domain regression, not an FFT. With only a few periods, the THD calculated from the FFT will depend on the windowing method used and the timebase range. The time-domain method is immune to these considerations (and gives statistical uncertainties on the extracted parameters).
We will mention this, as well as the exact timebase settings used, in the manual.

Is there a reason why you do not implement the same method in your software as what was used to derive the calibration cert?

[SJL-Instruments]

I guess I wasn't clear.  Entering "50" does not always give 50V/div.  It will sometimes give 50mV/div.   Try setting channel 1 using 50m.  You should see 50 mV/div.   Now set it to 50.  Does it stay at 50 mV/div or does it change to 50 V?   Try it a few times.  It's not repeatable every time.   Appears random.

Got it. Entering 50 will give 50 mV/div if the setting was previously in mV/div. Entering 50V will always give 50V/div. This was intentional, and we can change this behavior. In any case, we'll revert to the dropdown in the next update unless a custom scale is requested.

Sorry I did not take a screen capture.  It was showing wait.  Signal input was more than enough to trigger device.   Trigger level set to 0.   It was like the internal trigger was not working and it wasn't able to detect a valid trigger.   Restart of the software cleared it. 

Thanks - we thought we tracked down this issue, but evidently it can still happen. We'll run more careful tests to see if we can reproduce this.

Exactly.  I want to lock the timebase position to the left, center or right.  Adjusting anything else in the timebase would not effect its location.   

I would also like to be able to set the acquisition length rather than the samples per division.   I want to start at T0, or 11ns, record for 2ns with a resolution of 1ps.  Today, it's not that flexible.

Got it - we'll add these options (hopefully by next update).

Is there a reason why you do not implement the same method in your software as what was used to derive the calibration cert?

Mostly due to the nonlinear fit being computationally intensive - it will be significantly slower than real-time. The FFT implementation gives the same result to within ~1 dB.

[joeqsmith]

This was intentional,

Really?  Personally, I'm not a fan of software that tries to outguess me.  If it units are volts and I enter 50, it should give me 50, not m,u,n...  It should always do the same thing.  But that's just MO.   

Showing screen capture of PicoTech's 9400 software.  This is the first time I have ever looked at their software and it seems fairly intuitive.  Note the time base settings.  Trigger would need to take on a new meaning with your product.   I like their quick button press for most settings returns them to center.   

Most of the menus are easy enough to locate.  Like any new UI, it would take me time to get used to.       

I'm not liking that it crashed after a few clicks.... 

[SJL-Instruments]

Really?  Personally, I'm not a fan of software that tries to outguess me.  If it units are volts and I enter 50, it should give me 50, not m,u,n...  It should always do the same thing.  But that's just MO.   

We had it implemented as you stated, and changed it after receiving complaints that e.g. typing 50 into the offset box would set it to 50V instead of 50mV.
If we have a box for the step size in the timebase, for example, if a user typed 10 they likely meant 10 ps or 10 ns instead of 10 s.
But for the vertical division, as you stated, it makes less sense. We could make an exception for this setting, but then the consistency would be lost (which is the worst of both worlds, in our opinion).
We are erring on the side of keeping the current behavior, just because we've received more feedback in that direction.

Showing screen capture of PicoTech's 9400 software.  This is the first time I have ever looked at their software and it seems fairly intuitive.  Note the time base settings.  Trigger would need to take on a new meaning with your product.   I like their quick button press for most settings returns them to center.   

Thanks for this. We'll take this into account, and look around at other software as well, when implementing the extended settings for the timebase. A quick reset button for each setting is easy enough to add.

[joeqsmith]

Really?  Personally, I'm not a fan of software that tries to outguess me.  If it units are volts and I enter 50, it should give me 50, not m,u,n...  It should always do the same thing.  But that's just MO.   

We had it implemented as you stated, and changed it after receiving complaints that e.g. typing 50 into the offset box would set it to 50V instead of 50mV.

Interesting.  The idea of using the previously set value to determine how to interpret the entry isn't user intuitive IMO.  I can't believe someone would want it work this way. 

I'm sure as sales grow, you will receive lots of opinions and I wouldn't be surprised if some of those are not how things typically work.   If I get 20 people to suggest you should scan right to left with the earliest time always on the right side, will you do it?   Just remember it's your product.   

[joeqsmith]

Thinking about your UI and idea of dragging waveforms.  Set up a waveform to say 400mV.  Now set the scale to 10mV/div.  Now try and drag the waveform into view.  If you release the mouse and try to drag again, it resets back to the original offset.   You can only drag to -125mV.   You have to zoom out to get it back on the screen, take small adjustments and then you can set the offset to keep it on the screen all the way to 10mV/div.   

[SJL-Instruments]

Interesting.  The idea of using the previously set value to determine how to interpret the entry isn't user intuitive IMO.  I can't believe someone would want it work this way. 

I'm sure as sales grow, you will receive lots of opinions and I wouldn't be surprised if some of those are not how things typically work.   If I get 20 people to suggest you should scan right to left with the earliest time always on the right side, will you do it?   Just remember it's your product.   

We're currently rethinking this. Really, the complaints were from situations where a unit with no prefix doesn't make sense. (For example, setting the timebase position to "50" can only mean 50 ns, not 50 s.)
On the other hand, the vertical offset is debatable - requesting "200" probably means "200 mV", but if a high-voltage probe is used, it could mean "200 V".

Perhaps the best thing to do is implement things as you suggested, requiring an explicit prefix (so "200" would always mean "200 V"). The only exception would be for things like the timebase, where a 50s position is outside the capability of the hardware. This would make things as consistent as possible, and the software would only "correct" the user entry if it's completely unambiguous.

[joeqsmith]

I've received comments about people trying to use my VNA software where they enter for example 140m for frequency and can't understand that isn't 140MHz.  Failure of our education system isn't something I can address with my software.  I assume the user knows what they want.  I fully understand our friends reasoning  in the attached clip.

10MHz, voltage set just above where the scope will trigger.  Lots of back and forth to center the waveform at 10mV/div.  Now set it to 5mV/div.  Now change it back to 10mV/div.  What is the cause of it going unstable?   It's channel 2, so nothing to do with the trigger.   Easy to repeat.   

[nctnico]

Really?  Personally, I'm not a fan of software that tries to outguess me.  If it units are volts and I enter 50, it should give me 50, not m,u,n...  It should always do the same thing.  But that's just MO.   

We had it implemented as you stated, and changed it after receiving complaints that e.g. typing 50 into the offset box would set it to 50V instead of 50mV.

I agree with Joe here. Don't try to guess at typing errors. All test equipment I have uses values as they are typed in. If they are outside the range, you'll get an error. Otherwise the punched in value is used.

[SJL-Instruments]

Thanks nct and joe for the pointers. We'll change all input methods to the standard behavior in the next release (this weekend).

10MHz, voltage set just above where the scope will trigger.  Lots of back and forth to center the waveform at 10mV/div.  Now set it to 5mV/div.  Now change it back to 10mV/div.  What is the cause of it going unstable?   It's channel 2, so nothing to do with the trigger.   Easy to repeat.

We've tried to replicate this setup, but can't reproduce the behavior you're seeing (attached). It would be helpful to capture the raw CDF data when this occurs.
Just to be clear, you're putting a 10 MHz sine wave into CH1 & CH2? Or all channels?
As to why the vertical division has any effect at all: the displayed vertical region changes the CDF search bounds. This in principle shouldn't affect anything (just gives higher resolution), but gives a starting point if you want to investigate it over serial.

[joeqsmith]

If there truly is a problem with customers entering out of range values, you may want to consider coercing the entry to the boundary conditions.

The low cost VNAs keep evolving and I don't want to waste time changing the limits when a new model is released, so I don't coerce the settings.   I had a person trying to set their VNA outside of it's upper frequency limit.  Somehow they seemed to feel the software could magically turn a 4GHz VNA into a 10GHz VNA.  For something I give away for free, I refuse to work to the least common denominator.   You may not have a choice but to add some checks.   

***
Looking at the PicoTech software, they appear to set boundary conditions.

[joeqsmith]

Looks like the EEVBLOG site is having problems again.  I'll try and get back with you later on in the day.

***
I am using an RF generator to a DC splitter to ch1&2.  3&4 are turned off.  10MHz signal, 0V trigger, 100ps/div, 64pts/div, 500ns holdoff.  Start with around 200mVp-p level.   Center the waveforms at 10mV/div.  Set ch2 to 5mV/div.  Decrease signal level.   See attached.

[joeqsmith]

As to why the vertical division has any effect at all: the displayed vertical region changes the CDF search bounds. This in principle shouldn't affect anything (just gives higher resolution), but gives a starting point if you want to investigate it over serial.

Learned something new about the product.  Reading the manual:

The parameters s0…s7 represent the lower bound (“start voltage”) of the region to sample
for each channel, on a scale from –1.5 V (0) to +1.5 V (65535). This will be the lowest voltage
returned in the corresponding CDF data. The number of parameters required depends on
the model of the oscilloscope, and is equal to the number of channels (regardless of the
bitmask).
• Likewise, the parameters e0…e7 represent the upper bound (“end voltage”) of the region
to sample on each channel, and will be the highest voltage returned in the corresponding
CDF data.
• The parameters s0…s7 and e0…e7 are optional and will retain previously set values if omitted.
Modifying them can be useful for obtaining higher vertical resolution when the samples
per CDF K is low.
The search region (e0 - s0, e1 - s1, etc.) for any channel should not be smaller than 200 units
(∼9 mV). Undefined behavior will occur if this range is too small.

There is no mention at all of the boundaries having any effect on the trigger.  But it seems they do.  Adjusting these to a smaller value for channel 1 allows the scope to trigger on some very small signals.   

Showing channel 1&2 attached to the spillter.  -26dBm 2.4GHz signal applied and having no problem with the trigger. 

[SJL-Instruments]

Thinking about your UI and idea of dragging waveforms.  Set up a waveform to say 400mV.  Now set the scale to 10mV/div.  Now try and drag the waveform into view.  If you release the mouse and try to drag again, it resets back to the original offset.   You can only drag to -125mV.   You have to zoom out to get it back on the screen, take small adjustments and then you can set the offset to keep it on the screen all the way to 10mV/div.

Easy enough to allow the marker to be dragged down indefinitely once it hits the bottom of the screen. Will be implemented in next version.

If there truly is a problem with customers entering out of range values, you may want to consider coercing the entry to the boundary conditions.

Looking at the PicoTech software, they appear to set boundary conditions.

Thanks for the suggestion - this is already implemented in some places (e.g. the trigger holdoff), and we'll systematically go through each input and check when this makes sense.

I am using an RF generator to a DC splitter to ch1&2.  3&4 are turned off.  10MHz signal, 0V trigger, 100ps/div, 64pts/div, 500ns holdoff.  Start with around 200mVp-p level.   Center the waveforms at 10mV/div.  Set ch2 to 5mV/div.  Decrease signal level.   See attached.

Based on the CDFs you've sent, this might be metastability in the trigger circuit. It looks like the CDFs are a mixture between the correctly triggered samples, and samples taken at uncorrelated times throughout the waveform. This can occur if you're working on the very edge of the trigger sensitivity (below the recommended 200 mVpp). We'll look into a way to detect or mitigate this. (For now, we can mention this effect in the manual.)

There is no mention at all of the boundaries having any effect on the trigger.  But it seems they do.  Adjusting these to a smaller value for channel 1 allows the scope to trigger on some very small signals.   

Showing channel 1&2 attached to the spillter.  -26dBm 2.4GHz signal applied and having no problem with the trigger.

The exact way in which these interact, and the precise minimum signal level required for a trigger, is subject to process variation. The recommended 200 mVpp is a "safe" guideline. We can briefly mention some of these effects in the documentation (e.g. smaller range leading to increased trigger sensitivity), but can't give exact numbers applicable to every unit.

[joeqsmith]

Dang, -42dBm and it will trigger well enough to detect the 2.4GHz just above the noise floor.  I was thinking it would be a problem to trigger some basic logic levels.  Apparently this is not the case, at least with this particular scope.

You've been holding out on us!      

***
Now that I have had a small taste,  I want these settings exposed in your software!  Time to add a power user mode and let us push the hardware!   
***

The recommended 200 mVpp is a "safe" guideline.

  I don't want to play it safe!   

[SJL-Instruments]

Dang, -42dBm and it will trigger well enough to detect the 2.4GHz just above the noise floor.  I was thinking it would be a problem to trigger some basic logic levels.  Apparently this is not the case, at least with this particular scope.

You've been holding out on us!      

We generally try to keep all the specs conservative  . Since it's early in the lifecycle, with relatively low volume and low statistics, it's better to play it on the safe side, in case a 3 sigma event occurs (violating a min/max spec) and we get an angry customer.

Perhaps this is a bad idea from a marketing perspective. But much better to underpromise than overpromise.

Now that I have had a small taste,  I want these settings exposed in your software!  Time to add a power user mode and let us push the hardware!   
***

The recommended 200 mVpp is a "safe" guideline.

  I don't want to play it safe!   

Got it - we will add this mode. With all the necessary disclaimers, etc.
UI might be less polished than the "standard" mode at first. Always open to feedback on which options should be extended, preferred layout, etc.

[joeqsmith]

We generally try to keep all the specs conservative  . ...
Perhaps this is a bad idea from a marketing perspective. But much better to underpromise than overpromise.

The rise time on this particular scope puts it closer to 10 than 6G.  Trigger sensitivity below 10mV (assuming you provided access).  I would say your use of the the word "conservative" is an understatement!

[joeqsmith]

... this might be metastability in the trigger circuit.

Is it possible this could have been the cause of my locking up the sweeps?  If so, is there actually a way the restarting the software can somehow shake it loose?   I could believe when it hung both times, I was working with very low trigger levels.

[SJL-Instruments]

... this might be metastability in the trigger circuit.

Is it possible this could have been the cause of my locking up the sweeps?  If so, is there actually a way the restarting the software can somehow shake it loose?   I could believe when it hung both times, I was working with very low trigger levels.

Interesting possibility - we'll do some tests. If the scope is hung or unresponsive, there is a 10 second timeout after which the query is retried. Do you remember if the software hung for more than 10 seconds?

Now that I have had a small taste,  I want these settings exposed in your software!  Time to add a power user mode and let us push the hardware!   
***

The recommended 200 mVpp is a "safe" guideline.

  I don't want to play it safe!   

Along these lines, you can push the timebase down to 8 or 9 ns if you need it. There will be more distortion on Channel 1, but the other channels should be ok.

[joeqsmith]

Do you remember if the software hung for more than 10 seconds?

Sorry, I can't say with certainty.  If it ever locks like this again, I will take a screen shot and collect some other metrics for you.  It's rare and I have no idea how to replicate it.  I am certain that the last time I was bringing up the signals amplitude slowly at the time it hung.  I was waiting for it to change to Run and noticed nothing was being shown like I normally see with Wait.  I zoomed way out vertically and still did not see a trace.  Restarted the software and everything started working normally.   

Along these lines, you can push the timebase down to 8 or 9 ns if you need it. There will be more distortion on Channel 1, but the other channels should be ok.

I read this and I thought, surely he isn't suggesting that the start of collection can be set lower than 11, potentially leading to shorter length, lower loss....  A quick test and sure enough, channel 1 about 7.5ns!  If using the scope this way, I really don't care about channel 1 distortion anyway.  I just need the trigger to be stable.   

Add all the disclaimers you want to the manual.  IMO, specifying the minimums and  typical numbers is good enough.  But it's a shame to have the hardware crippled by software.    If you add support, the first thing I'm going to do is shave off 3ns of cable....     Still plenty of margin. 

[joeqsmith]

Shown with channel1 boundary set to +/-50mV,  7.5ns start of collection, 1ns sweep range, 1ps resolution.  Test signal at 7GHz. THD is around -22dB, down in the muck. 

I am curious on the cause of the DC shift?  The test signal is CW, so I expect something in your front end is doing some rectification that is somehow tied to the trigger.   Granted, I know I am pushing this thing to look at VERY small signals at much higher frequencies than you spec it to and pushing that start of collection way early.   

To be clear, by no means am I suggesting this is a problem.  I just want to understand what is going on internally.   

[SJL-Instruments]

Shown with channel1 boundary set to +/-50mV,  7.5ns start of collection, 1ns sweep range, 1ps resolution.  Test signal at 7GHz. THD is around -22dB, down in the muck. 

I am curious on the cause of the DC shift?  The test signal is CW, so I expect something in your front end is doing some rectification that is somehow tied to the trigger.   Granted, I know I am pushing this thing to look at VERY small signals at much higher frequencies than you spec it to and pushing that start of collection way early.   

To be clear, by no means am I suggesting this is a problem.  I just want to understand what is going on internally.   

Yep, this is why we spec the start time at 11 ns. 

The DC shift is not due to rectification and should be independent of the signal. We're actually reasonably sure it can be compensated for. The only reason we haven't is that we're not 100% sure it won't change with temperature, aging, etc.
Internally, the threshold voltage for the Channel 1 comparator must be rapidly switched from the trigger voltage to the CDF query voltage. The compensation network for this isn't perfect, and you're seeing the residual transient. You could avoid this problem this with two comparators and a resistive splitter, but that draws more power, increases the noise floor, and opens up matching issues.
This is also why decreasing the CDF search range improves the trigger sensitivity.
***
Perhaps a good middle ground for the software is to show data down to 8 ns by default, for all channels except CH1.

[joeqsmith]

Thanks for the added information on the DC.   

I wouldn't limit it in software, or if you do, set it to your absolute minimum (76486).  I would rather have it be documented that 11 is the recommended start of acquisition and that it may be possible to use lower values with reduced performance.  Let the user decide if it is useful to them or not but don't lock them out.

For a default power up, it doesn't matter to me as I will save the setup for my personal use.   It would be nice if it supported an initialization file where, if present, the software would automatically load these settings without the need to do it manually.   It would be no different than your other setup files, except for a unique name that your software looks for.

Shown with 7GHz 70mVp-p signal applied to Ch1.  Other channels have ground caps inserted.  Manual doesn't mention isolation.  Is this coupling from Ch1 to Ch2 normal? 

[SJL-Instruments]

I wouldn't limit it in software, or if you do, set it to your absolute minimum (76486).  I would rather have it be documented that 11 is the recommended start of acquisition and that it may be possible to use lower values with reduced performance.  Let the user decide if it is useful to them or not but don't lock them out.

We are not planning to set any limits if extended timebase settings and/or power-user mode are enabled. We trust the user to understand the limitations and consult the manual.
But in the default mode, we will still keep a limit at 11 ns (at least on CH1), to prevent confusion if CH1 appears distorted.
The exact minimum delay is unit-dependent and subject to process variation. 8 ns is at the 2 sigma level (~95% of units), and 8.5 ns is ~3 sigma.

For a default power up, it doesn't matter to me as I will save the setup for my personal use.   It would be nice if it supported an initialization file where, if present, the software would automatically load these settings without the need to do it manually.   It would be no different than your other setup files, except for a unique name that your software looks for.

Easy enough to implement (except on macOS, for reasons...). We'll add this to the Windows + Linux versions.

Shown with 7GHz 70mVp-p signal applied to Ch1.  Other channels have ground caps inserted.  Manual doesn't mention isolation.  Is this coupling from Ch1 to Ch2 normal? 

This coupling is normal and increases at higher frequencies. Later units also have a revised top case which improves the crosstalk.
Do note that the CH2 waveform you're seeing is below the "nominal" RMS noise floor. 

[joeqsmith]

When looking at the start of collection, what determines the minimum value before it reports an underflow? The manual states:

Error Response: WARNING: Delay underflow -inf  This error occurs when the requested value is outside the range of the delay generator and cannot be achieved.  If you are certain the requested delay falls within acceptable bounds, contact us for
a diagnosis.

Above it states:

Undefined behavior may occur if the requested delay is lower than 11 ns (D110000) or higher than the holdoff minus 25 ns. It is the user’s responsibility to stay within these bounds.

The term bounds must be referring to different boundary conditions as it does not appear to be constant for a fixed holdoff time.  Can you provide the equations?   7.7ns seems to work in all of my test cases so far. 

The document does mention the delay generator in 2.3 but doesn't mention how it ties into the underflow warning. 

Later units also have a revised top case which improves the crosstalk. Do note that the CH2 waveform you're seeing is below the "nominal" RMS noise floor. 

I dare say pretty much everything I have looked at over the last two days was outside of nominal.      

Showing 8.5GHz signal applied with varying amplitudes.  Start of collection was set to 7.7ns and a 1ps resolution.  Indeed channel 2 doesn't exhibit the same tailing as channel 1.   Based on this, I plan to remove 3ns worth of coax. 

***
I suggest as you make changes to the hardware, you consider sending a set of replacement parts for this unit anyone working on a review so they remain current.   For a while, I was thinking to have you ship a production unit that you bless as a gold standard to have as a reference.  I no longer feel that will be useful.   After all of my testing and our conversation, I'm now fairly confident that the electronics on this particular unit represent production. 

[joeqsmith]

Let it run overnight and saw no problems using the 7.7ns start of collection.  Showing both the time domain and distortion.   

Drift is dominated by open loop YIG, not the scope.

[SJL-Instruments]

When looking at the start of collection, what determines the minimum value before it reports an underflow? The manual states:

Error Response: WARNING: Delay underflow -inf  This error occurs when the requested value is outside the range of the delay generator and cannot be achieved.  If you are certain the requested delay falls within acceptable bounds, contact us for
a diagnosis.

Above it states:

Undefined behavior may occur if the requested delay is lower than 11 ns (D110000) or higher than the holdoff minus 25 ns. It is the user’s responsibility to stay within these bounds.

The term bounds must be referring to different boundary conditions as it does not appear to be constant for a fixed holdoff time.  Can you provide the equations?   7.7ns seems to work in all of my test cases so far. 

The document does mention the delay generator in 2.3 but doesn't mention how it ties into the underflow warning. 

The minimum delay is determined by the combined gate delays of all chips between the CH1 input and the sampling circuit. This is unit-dependent, and there isn't a useful way to calculate it. The easiest method is to simply try smaller delays until you receive an underflow warning (as you've done).

The maximum delay is determined by the 25 ns reset time of the sampling circuit. If less than 25 ns is allocated between the sampling time and the end of the trigger holdoff, the sampling circuit will be in an indeterminate state at the next trigger and yield incorrect results.

I suggest as you make changes to the hardware, you consider sending a set of replacement parts for this unit anyone working on a review so they remain current.   For a while, I was thinking to have you ship a production unit that you bless as a gold standard to have as a reference.  I no longer feel that will be useful.   After all of my testing and our conversation, I'm now fairly confident that the electronics on this particular unit represent production. 

We are also confident, given the last several posts, that your unit is within production spec.
We can certainly send you an updated case, if you'd like. (We did recently send a revised version to Shahriar.)

[joeqsmith]

The minimum delay is determined by the combined gate delays of all chips between the CH1 input and the sampling circuit. This is unit-dependent, and there isn't a useful way to calculate it. The easiest method is to simply try smaller delays until you receive an underflow warning (as you've done).

Could you explain the actual hardware/firmware mechanism in further details which sets this warning?  Block diagram of that area of the hardware design? 

For keeping the unit up to date, I would suggest anything that effects the performance of the scope, automatically send it.   I'm not concerned with the cosmetics.  If you do decide to start including probes, I suggest sending these out to reviewers as well.   


Besides decreasing the sampling resolution, is there a way to speed up the sweeps while reducing performance?  What limits the sweep rates? 

I have not yet measured it but it seems pulling all four channels vs one makes little difference.  Same with reducing the number of CDFs.  Would adding a mode where you tell the firmware/hardware to sweep a range and just have it stream the data back rather than requesting each delay, speed up the process?   I'm not thinking small changes in sweep times but 10X, 100X faster.   

If do decide to go after some sort of auto setup mode, it would be nice if it not only set the vertical and horizontal but also the trigger level.  I have not attempted to automate this myself.

***
I checked the Signal Path channel yesterday to see if he had his review up yet.   I keep postponing mine as you are making so many improvements in such a short time,  by the time I release a review, it would be obsolete.   I would have a different view if you were not using the feedback I am providing and working at such a rapid pace. 

[SJL-Instruments]

The minimum delay is determined by the combined gate delays of all chips between the CH1 input and the sampling circuit. This is unit-dependent, and there isn't a useful way to calculate it. The easiest method is to simply try smaller delays until you receive an underflow warning (as you've done).

Could you explain the actual hardware/firmware mechanism in further details which sets this warning?  Block diagram of that area of the hardware design?

 
Essentially, the entire delay generator is looped back on itself to form a ring oscillator, and we measure the period to verify the delay. If the calibration is still valid, this should be correct to within 1 ps. If it differs from the target by more than 2 ps, the warning is issued.
If the requested delay is too small, the delay generator will clamp to its minimum delay. This will be caught by the above check, but where this occurs is subject to process variation.

For keeping the unit up to date, I would suggest anything that effects the performance of the scope, automatically send it.   I'm not concerned with the cosmetics.  If you do decide to start including probes, I suggest sending these out to reviewers as well.   

We'll ship you an updated case by EOD tomorrow. Probes are quite far from production, but we'll keep you updated.

Besides decreasing the sampling resolution, is there a way to speed up the sweeps while reducing performance?  What limits the sweep rates? 

I have not yet measured it but it seems pulling all four channels vs one makes little difference.  Same with reducing the number of CDFs.  Would adding a mode where you tell the firmware/hardware to sweep a range and just have it stream the data back rather than requesting each delay, speed up the process?   I'm not thinking small changes in sweep times but 10X, 100X faster.   

If do decide to go after some sort of auto setup mode, it would be nice if it not only set the vertical and horizontal but also the trigger level.  I have not attempted to automate this myself.

First, there is the theoretical minimum time needed to take the CDF samples themselves. At 40 ns holdoff, with 20 samples/CDF and 100 triggers/sample (which would give degraded but still "acceptable" performance), this is 80 us per point, corresponding to 12 kCDF/s.

There is a fixed minimum overhead per sample due to FPGA/DAC communication, analog settling time, and MCU processing time. With some optimization, this can be brought down to probably ~10 us per sample, so ~200 us per point.

Then there is the time required to set a delay. Right now this takes ~8 ms, and gives a precision of ~0.1 ps @ 20 ns delay.
We can cut this down to ~50 us by skipping the verification step. This will substantially degrade the ENOB.

Combining the above, this limits the speed to ~3 kCDF/s.

Each CDF requires 60 bytes. Given the 921600 baud rate, this limits the speed to 1920 kCDF/s. Many of the CDF entries are strictly-speaking, redundant, and with pruning we can probably achieve 3 kCDF/s.
The current speed with default settings is ~50 CDF/s. This will take some time to develop, but a factor of ~100x is possible, with degraded noise and jitter performance.

I checked the Signal Path channel yesterday to see if he had his review up yet.   I keep postponing mine as you are making so many improvements in such a short time,  by the time I release a review, it would be obsolete.   I would have a different view if you were not using the feedback I am providing and working at such a rapid pace. 

We appreciate the amount of feedback you've provided, and the time you've put into testing the scope. Keep in mind that we won't stop improving the product for the foreseeable future - be careful not to postpone the review indefinitely. 

[joeqsmith]

Essentially, the entire delay generator is looped back on itself to form a ring oscillator, and we measure the period to verify the delay. If the calibration is still valid, this should be correct to within 1 ps. If it differs from the target by more than 2 ps, the warning is issued.  If the requested delay is too small, the delay generator will clamp to its minimum delay. This will be caught by the above check, but where this occurs is subject to process variation.

Thanks.   Makes sense why you need to constantly align it and why it changes a few counts.     

I'll check the isolation again once the new parts arrive and post any improvements.   Obviously I had the PCB out of the case to perform the rework.  The thermal pads appear to still be fine if you did not want to include them. 

We appreciate the amount of feedback you've provided, and the time you've put into testing the scope. Keep in mind that we won't stop improving the product for the foreseeable future - be careful not to postpone the review indefinitely. 

   Are you getting any feedback from Signal Path? 

[SJL-Instruments]

I'll check the isolation again once the new parts arrive and post any improvements.   Obviously I had the PCB out of the case to perform the rework.  The thermal pads appear to still be fine if you did not want to include them.

We have included new pads with the revised case. They are ~1 mm thick, and will compress significantly upon first assembly to obtain best thermal contact. Will be shipped out tomorrow.

   Are you getting any feedback from Signal Path? 

We can't comment on that, sorry. (Not sure whether Shahriar wants his schedule publicized.)

[joeqsmith]

   Are you getting any feedback from Signal Path? 

We can't comment on that, sorry. (Not sure whether Shahriar wants his schedule publicized.)

I wasn't referring to his schedule.   I want to know if he is finding other problems or offering suggestions outside of what had been mentioned here.... 

[SJL-Instruments]

I wasn't referring to his schedule.   I want to know if he is finding other problems or offering suggestions outside of what had been mentioned here.... 

Not yet - although if he does have suggestions or finds any problems, we will be similarly responsive in addressing them (and have mentioned this to him).

[joeqsmith]

Too bad.  It may prove helpful to hear from others who are trying it out. 

Using the GigaWave to look at the output from my frequency extender.   LiteVNA set to 10GHz.   250ps sweep time with 500fs resolution.   I have to say, the more I play around with it, the more surprised I am with just how well it works.   

[joeqsmith]

LiteVNA set to 11GHz, 100ps sample time with the start of collection at 7.7ns, ran overnight.  What is interesting about this plot is while the signal is all negative, the trigger is set to a positive value.   

Is there a sign problem or is it possible that voltage values calculated are not the same as what the trigger circuit sees?   

4.5.2 L (Set Trigger Level)
Command Format: Lx
Expected Response: OK Lx.
Available in all firmware revisions.
Sets the trigger level on a scale from –1.5 V (L0) to +1.5 V (L65535).

I limit it to +1 (54612) to -1 (11909).   Trigger level with this test was set to +3mV or 32833. 

[SJL-Instruments]

LiteVNA set to 11GHz, 100ps sample time with the start of collection at 7.7ns, ran overnight.  What is interesting about this plot is while the signal is all negative, the trigger is set to a positive value.   

Is there a sign problem or is it possible that voltage values calculated are not the same as what the trigger circuit sees?   

This is essentially the reverse of the DC transient on CH1 prior to the spec'd start time. When the trigger circuit is reset, there can be a residual offset of a few mV when switching from the CDF query voltage to the trigger voltage. (Anecdotally, this offset is always negative, but we again haven't characterized this thoroughly).
This is mainly important if you are pushing the frequency beyond spec, as the trigger sensitivity tends to drop with frequency.

[joeqsmith]

Thanks. This makes sense. 

You may want to consider creating a forum for your products that you could direct customers to from your website.  The groups.io reflector seems to be popular.   As sales grow, you may also want to start thinking about putting a FAQ together.

[joeqsmith]

The software I put together to test your scope is pretty barbaric.  Send a command, wait for a response.  Because your protocol is not consistent for all messages, I have unique handlers for the types.  It was just a brute force to try some things out and not meant as a solid platform to build on. 

If I were to write something for it, I wonder how your firmware handles say back to back commands?  How deep is your message queue? 
If you are in the middle of sending CDF data and I send you a command that could potentially change the collection, how do you handle it?  Do you wait for the current data to be sent to act on the new command? ignore the command until it is sent?   Just thinking how I would structure the software. 

I wonder if you came up with a better protocol, would you be able to change it this late in the game?   For example, if you always handled your send messages the same rather than append "SJLI" rather than a CRLF?  Adding a CRC or other error checking/correction....    For now, I don't think it's too big of a deal but down the road, it may be more difficult to change it.  Maybe you feel it is good enough to build on?

[SJL-Instruments]

You may want to consider creating a forum for your products that you could direct customers to from your website.  The groups.io reflector seems to be popular.   As sales grow, you may also want to start thinking about putting a FAQ together.

Thanks, these are both good ideas. We do plan on doing this once as our userbase expands. For the time being, we are following up with users individually (mostly via email), and they generally appreciate the one-on-one communication.
Our focus for now is user support and software development. We think our current communication model works well in these early stages, but the tradeoffs will change as sales increase. (A forum enables users to help each other and share knowledge, but this is most useful above some critical number of participants.)

The software I put together to test your scope is pretty barbaric.  Send a command, wait for a response.  Because your protocol is not consistent for all messages, I have unique handlers for the types.  It was just a brute force to try some things out and not meant as a solid platform to build on. 

If I were to write something for it, I wonder how your firmware handles say back to back commands?  How deep is your message queue? 
If you are in the middle of sending CDF data and I send you a command that could potentially change the collection, how do you handle it?  Do you wait for the current data to be sent to act on the new command? ignore the command until it is sent?   Just thinking how I would structure the software. 

I wonder if you came up with a better protocol, would you be able to change it this late in the game?   For example, if you always handled your send messages the same rather than append "SJLI" rather than a CRLF?  Adding a CRC or other error checking/correction....    For now, I don't think it's too big of a deal but down the road, it may be more difficult to change it.  Maybe you feel it is good enough to build on?

The current serial interface is designed to be simple to use as possible. We think the current specifications do give us enough leeway in the future. If we were to add CRCs, for example, we would have a command to enable them. We also have a command schema (anything starting with #) reserved for future use. We will never break backwards compatibility - that's just asking for trouble.

For terminators, we use CRLF everywhere we can, for ease of use from an interactive terminal. For binary responses, a CRLF is too likely to appear in the data. The SJLI "terminator" is less likely to appear. Of course, it may still happen (1 in 4 billion chance), so in our software we read based on the expected length of the message.
(As to why it's there at all: for some users, it might be acceptable to look for the SJLI and discard responses with the wrong length, which is much easier to implement.)

There is currently not a message queue, to minimize bugs and edge cases (e.g. changing the parameters during collection, as you've mentioned). If it becomes necessary, we can add one without breaking any existing user programs. Currently, the firmware ignores any command sent before the previous response is read. A message queue would process each command in order (so, still no issues with parameter changes during collection).

[joeqsmith]

Simple is fine as long as it is robust. 

I have completely restructured my test code which has turned up an odd behavior that I would like to understand.   

I send a CAL command and wait for the scope to respond with the OK CAL.  I then immediately send the Delay command.  What I am seeing is the scope will respond with a Delay underflow -inf.    I would assume that as soon as the scope sends the OK CAL, it is ready to take the next command but it doesn't appear that is always the case.  It never gives me this warning except when performed right after a CAL.  If I get this underflow and immediately resend the D command, it never fails that I have seen, on the second attempt.   

***
If after receiving the OK CAL, I wait an additional 50ms for the scope to do what ever it is doing, then send the D command, it never seems to throw the underflow warning.   It seems that OK doesn't really mean it's OK when it comes to the calibration.   

[joeqsmith]

In anticipation of the new power user mode,  I trimmed my delay line to center around the 8ns start of collection.  Time to remeasure it on the VNA.

[SJL-Instruments]

I send a CAL command and wait for the scope to respond with the OK CAL.  I then immediately send the Delay command.  What I am seeing is the scope will respond with a Delay underflow -inf.    I would assume that as soon as the scope sends the OK CAL, it is ready to take the next command but it doesn't appear that is always the case.  It never gives me this warning except when performed right after a CAL.  If I get this underflow and immediately resend the D command, it never fails that I have seen, on the second attempt.   

***
If after receiving the OK CAL, I wait an additional 50ms for the scope to do what ever it is doing, then send the D command, it never seems to throw the underflow warning.   It seems that OK doesn't really mean it's OK when it comes to the calibration.   

We can reproduce this, but only when operating outside of the specified timebase range.
The calibration is valid immediately after OK CAL is returned, and sending (for example) D110000 immediately afterwards should not result in a warning.
If the delay command you're sending is near the hardware limit, what you're seeing is likely a momentary increase in chip temperature which pushes the minimum possible delay above 7.7 ns.

[joeqsmith]

We can reproduce this, but only when operating outside of the specified timebase range.
The calibration is valid immediately after OK CAL is returned, and sending (for example) D110000 immediately afterwards should not result in a warning.
If the delay command you're sending is near the hardware limit, what you're seeing is likely a momentary increase in chip temperature which pushes the minimum possible delay above 7.7 ns.

Attached showing the returned warning and the target delay. 

The previous delay was 120000.  The software runs the cal, waits for the OK CAL, then sets it to 110000.  Adding a delay after the OK CAL seems to correct it. 

My old software was much slower.  As I said, just something quick and dirty to test the product.  I restructured the code to allow me to more easily expand it.  Part of that was speeding up the communications.  This is when the problem showed up.  I can throttle my software or resend the D command but everything else seems solid and I would like to understand if this is an underlying problem with the calibration.   

***
Maybe a clue but if I add 30ms delay after the calibration returns the OK CAL, the D110000 never seems to fail.  Using 20ms will cause an occasional fault.   Without any delay, it will frequently fault.   It only appears to be a problem when running the calibration.   

I let it run about 10 minutes with a 30ms delay and no warnings were sent from the scope. 

***
Looking at delayunderflow3.jpg, the last number is the number of ms from the time the D110000 command was sent and the scope returned the warning.   This time varies a lot and can be as low as 2ms.  Again, dealing with Windows but it at least doesn't appear that anything was wrong, like the scope was hung or something odd like that. 

[SJL-Instruments]

The previous delay was 120000.  The software runs the cal, waits for the OK CAL, then sets it to 110000.  Adding a delay after the OK CAL seems to correct it. 

My old software was much slower.  As I said, just something quick and dirty to test the product.  I restructured the code to allow me to more easily build from it.  Part of that is speeding up the communications.   This is when the problem showed up.    I can throttle my software or resend the D command but everything else seems solid and I would like to understand if this is an underlying problem with the calibration.   

***
Maybe a clue but if I add 30ms delay after the calibration returns the OK CAL, the D110000 never seems to fail.  Using 20ms will cause an occasional fault.   Without any delay, it will frequently fault.   It only appears to be a problem when running the calibration.   

This is quite odd, and so far we cannot reproduce this on any of our units. We can send D120000, CAL, D110000 in a loop with no extra wait time.

Checking the firmware, the "Delay underflow -inf" message is sent before the delay verification is performed. It occurs when the calibration result implies that the requested delay cannot be achieved even in theory. (i.e. it depends only on stored values from the CAL command) But, the calibration results are finalized before OK CAL is sent, and do not change afterwards, so the wait time between receiving OK CAL and sending the next D command should be irrelevant.

In short, the only explanation we can think of is a serial issue. The 30 ms wait time may have something to do with flushing a serial buffer. Just to verify, are you terminating all commands with \r only, and waiting to receive the full response (including CRLF) before sending the next message?

[joeqsmith]

My code uses state machine.  Send command, wait for a valid response.  I would like to send more than one command but you can't handle that so I don't. 

Yes, all commands are sent with a CR.  Actually, when I resend the D command, its just executing that same state a second time.  I only need this delay for the calibration, nothing else.

I wonder if your software just doesn't send the commands fast enough to replicate what I am seeing.   Certainly possible it is on my end as well.  No idea. 

[SJL-Instruments]

My code uses state machine.  Send command, wait for a valid response.  I would like to send more than one command but you can't handle that so I don't. 

Yes, all commands are sent with a CR.  Actually, when I resend the D command, its just executing that same state a second time.  I only need this delay for the calibration, nothing else.

I wonder if your software just doesn't send the commands fast enough to replicate what I am seeing.   Certainly possible it is on my end as well.  No idea. 

For this test, we wrote a short script using the Python serial library, sending and receiving commands as fast as possible. Here are some measured timings, if you'd like to compare:
1. Send CAL -> Received OK CAL: 61.5 ms
2. Send CAL, Received OK CAL, Send D110000, Received OK D: 65.9 ms

It's certainly possible that LabView handles serial in a subtly different way. But the "Delay underflow -inf" message leads us to believe that the scope is somehow receiving the wrong command. For example, D11000 (1.1 ns) will always trigger this warning.

***

Another possibility: The D command will return OK D even if the warning is issued. (i.e. two CRLF will be included in the response.) The state machine may be looking at a response from a previous command, depending on how it is implemented.

[joeqsmith]

The state machine looks for the unique response for each command.  It can't get out of sync, unless the scope starts sending the wrong acknowledges.   The software isn't yet self aware and can't modify its commands.  That's what I like about computers, they do exactly what you program them to, day in and out...

I do like protocols where every frame is processed the same.  Not where you have different end of frame markers and double CRLF in some cases.   Simple to me is making things consistent (and robust).   A goal of talking to the scope using a dumb terminal program seems of little value,  especially if it is making the system less robust, IMO. 

I saved the most recent responses and dumped them when this error happens.  Note the back to back calibrations prior to the D110000 fault.   It appears every time the scope receives two CAL commands, even though the state machine is waiting for them to send the OK CAL,  it seems to cause the fault.  Note that the first time I mention it, you can see the two CAL commands.   

I forced it to a single CAL command with no delays and it has not yet faulted out.   Are you only sending one CAL command or multiple?

***
It's been running for about 40 minutes now using a single CAL command and still no faults.   It is certainly a big clue into what is going on. 

[SJL-Instruments]

I do like protocols where every frame is processed the same.  Not where you have different end of frame markers and double CRLF in some cases.   Simple to me is making things consistent (and robust).   A goal of talking to the scope using a dumb terminal program seems of little value,  especially if it is making the system less robust, IMO. 

This does make sense. The intention was to have a simple single-CRLF response whenever possible. This doesn't work for binary data, and so is the one exception. The double CRLF was unintentional, since the delay underflow warning is intended to never happen in normal operation.

I saved the most recent responses and dumped them when this error happens.  Note the back to back calibrations prior to the D110000 fault.   It appears every time the scope receives two CAL commands, even though the state machine is waiting for them to send the OK CAL,  it seems to cause the fault.  Note that the first time I mention it, you can see the two CAL commands.   

I forced it to a single CAL command with no delays and it has not yet faulted out.   Are you only sending one CAL command or multiple?

***
It's been running for about 40 minutes now using a single CAL command and still no faults.   It is certainly a big clue into what is going on. 

This is very interesting, and puzzling. We still can't reproduce this behavior - issuing an arbitrary number of CAL commands, then a D command, works every time on our test units. It also doesn't explain why adding a 30 ms delay seems to avoid the problem.
That said, the way the official software is set up, it happens to issue at least one other command in between every two CAL commands.

***

We're running stress-tests where we send a random sequence of CAL and D commands (with random parameters) with no extra delays. So far, everything is working as intended..

***

After carefully checking the relevant code path in the firmware, the only way a "Delay underflow -inf" message can occur is if the parameter passed to the D command is below 20000 (2 ns). This is regardless of what the CAL command does, even if the calibration result is completely wrong.
Of course, we're sure this isn't what you intended to do - the problem could lie on either the scope side or the LabView side, but it's definitely a serial issue.

If you'd like, we can send you a firmware patch which returns more information when this warning is issued. It could help clarify what is happening.

[joeqsmith]

Serial communications have been in use long before I started my career.  I wouldn't have thought there was much of a point in reinventing the wheel.  I don't see using your company name as an end of frame marker as being professional.   Again, just MO.  I don't like having to deal with these special fringe cases that fall outside of what is considered normal.   Its not a productive conversation to be having as it sounds like there is no chance in changing it.  I will drop it and work around what you have. 

My setup has been running for about two hours without a warning after removing back-to-back calibrations.   It appears to solve what ever the problem is.  So does adding a small delay after the second CAL.   It's odd you are unable to replicate it.   My code performs error checking and re-transmission already and I will also change it to make sure your scope never sees back to back calibration commands.  Basically my plan forward is to bury the problem as I am not sure what else I can offer you to help in this matter.   Just be aware something odd is happening with calibrations and setting the delay, and not understanding it may come back to haunt you in the future.    

This scope has been in pretty much non-stop use since I had reworked the board and while there could still be something abnormal with this unit, I have not seen any other strange behaviors outside of what I have mentioned here.  It now appears to be very solid.   But maybe there is something else going on with part variances (FPGA) that effects the design.   Time will tell as you build more units. 

[SJL-Instruments]

Serial communications have been in use long before I started my career.  I wouldn't have thought there was much of a point in reinventing the wheel.  I don't see using your company name as an end of frame marker as being professional.   Again, just MO.  I don't like having to deal with these special fringe cases that fall outside of what is considered normal.   Its not a productive conversation to be having as it sounds like there is no chance in changing it.  I will drop it and work around what you have. 

Given the interface we have already defined, there is still enough leeway to implement an SCPI interface without breaking backwards compatibility. This will not come out before your review is published. You should review the product as it exists now. But this is just to say that we understand your point, and want to do better.
We will later release an SCPI-compatible firmware update, and any future product we launch will have an SCPI interface by default.

This scope has been in pretty much non-stop use since I had reworked the board and while there could still be something abnormal with this unit, I have not seen any other strange behaviors outside of what I have mentioned here.  It now appears to be very solid.   But maybe there is something else going on with part variances (FPGA) that effects the design.   Time will tell as you build more units. 

Thanks again for the careful testing you've done. We haven't received any other reports of hardware issues outside of the the ones you've mentioned. For now, we are confident that the "growing pains" have been resolved, and the hardware is stable.

My setup has been running for about two hours without a warning after removing back-to-back calibrations.   It appears to solve what ever the problem is.  So does adding a small delay after the second CAL.   It's odd you are unable to replicate it.   My code performs error checking and re-transmission already and I will also change it to make sure your scope never sees back to back calibration commands.  Basically my plan forward is to bury the problem as I am not sure what else I can offer you to help in this matter.   Just be aware something odd is happening with calibrations and setting the delay, and not understanding it may come back to haunt you in the future.    

As a precaution, we have added a note about repeated CAL commands in the next manual revision. The official software happens to be set up in a way that never sends back-to-back calibrations, and so avoids the issue. Thanks for bringing it to our attention.

[joeqsmith]

I let it continue to run without the back-to-back CAL and saw no problems.   I have gone ahead and made these changes to my software.   To be clear,  I have no plans to write an interface for your scope, but at least now I have what I consider a good platform to build on if I need it.   
 

This will not come out before your review is published. You should review the product as it exists now. But this is just to say that we understand your point, and want to do better.

For the review, I had planned to only show your software.  So these details about your choice for the serial interface are not relative.  I have thought about doing a segment on my LabView source code.  With it being pretty much a dead end tool now with their extortion tactics and subscription model  there may not be any value in including it.  Someone wrote me the other day who had attempting to reinstall their older version of LabView and claimed they could not get their license to authenticate.  That's twice now I have heard that.  One was from a university.   

Some parts of my review that I had already recorded will need to be updated.   For example I had done a tear down at the time I reprogrammed the unit.  Because I had not removed the PCB from the case, you only got to see the top side.   When I reworked the board, I did not record anything.  The focus wasn't about making a video but rather attempting to solve the random problems I was seeing.  Working with these tiny parts gets more difficult as I age and the risk of damaging the unit because of not being focused on the task at hand was too great.   Now, with the new case coming, I will redo this section of the review.  Pretty sure I can swap out the case on video and not damage the scope.     Other parts of the video where I was limited by your software may also change.   

Honestly, had I just reviewed the scope the way it stood when it arrived, it wouldn't have presented itself well.  Over the last month, things have really started to shape up.  I would like that power user mode but can certainly proceed without it.   

Making reviews isn't really something I am good at to start with.  Compound that with the moving target you have provided, it adds an extra layer of difficulty.  If it were a simple unbox, look at the parts supplied, five stars... Maybe include some music and talk about what an expert I am, then sure, I can have it done today.   I suggest you be patient.     

Thanks again for the careful testing you've done. We haven't received any other reports of hardware issues outside of the the ones you've mentioned. For now, we are confident that the "growing pains" have been resolved, and the hardware is stable.

I too am confident in the the hardware design.  Your build quality is still a question as I have not seen what your production process looks like.  The firmware/software seems a bit lacking but as you have said, you plan to continue to develop it.  Potential customers just need to be aware that any limitations I may show during the review could possibly be addressed in the the future.  Of course, no guarantees. 
 

As a precaution, we have added a note about repeated CAL commands in the next manual revision. The official software happens to be set up in a way that never sends back-to-back calibrations, and so avoids the issue. Thanks for bringing it to our attention.

If you can't replicate it, and nothing in your design appears to match up with the symptoms I have described, I really don't know what else you can do at this point. 

***
grammar 

[joeqsmith]

The main menus size should be saved with the default settings.  It is nice that it saves the power-user mode.  Problem is the default screen is too small and some of your selectors overlap. 

The min/max and current all being one color make it difficult to determine what going on.   If for example, you have a digital signal.   It is high, then it is low.  Now I have a line at the high state and one at the low.  Where is that signal....  Better to allow multiple colors.     I do like how the min/max works now compared with the previous version.   I don't like that when I move the graph horizontally, the min/max data still doesn't clear properly and requires a manual reset. 

When FFT is selected, the main graph flickers badly.   Not a functional problem but just doesn't look professional.

When selecting finer horizontal resolutions, the main graph flickers badly (even without running an FFT).     

I like the new scale settings.   Both horizontal and vertical.   So much faster now setting it.   

Big thanks for including all the features we talked about for the power-user.   

Overall, this version is a big improvement IMO.  So much easier to drive.   

[SJL-Instruments]

The main menus size should be saved with the default settings.  It is nice that it saves the power-user mode.  Problem is the default screen is too small and some of your selectors overlap. 

The min/max and current all being one color make it difficult to determine what going on.   If for example, you have a digital signal.   It is high, then it is low.  Now I have a line at the high state and one at the low.  Where is that signal....  Better to allow multiple colors.     I do like how the min/max works now compared with the previous version.   I don't like that when I move the graph horizontally, the min/max data still doesn't clear properly and requires a manual reset. 

When FFT is selected, the main graph flickers badly.   Not a functional problem but just doesn't look professional.

When selecting finer horizontal resolutions, the main graph flickers badly (even without running an FFT).     

Thanks for the feedback. We have just released v2.5.8 on our website, including fixes for all of these issues.

The flickering issue is hardware-dependent, and we were only able to reproduce it on one machine. There is a chance that our patch may not fix it on your machine. Let us know if the problem is resolved for you.

[joeqsmith]

Default settings and the overlap of menu items appear fixed. I like the new colors for the min/max.  Min/Max now seems to reset correctly. 

Flicker is still very poor.   Even when using the internal trigger with no signals applied, it flickers.  Let me put it this way, it isn't something I would have ever released.  It's that bad.  It reminds me of that original NanoVNA software they had when I first looked at it.   

NVIDIA Quadro M4000,  Xeon E5-1650 v4,  32G RAM, Win 10 Pro 1903. 

[SJL-Instruments]

Default settings and the overlap of menu items appear fixed. I like the new colors for the min/max.  Min/Max now seems to reset correctly. 

Flicker is still very poor.   Even when using the internal trigger with no signals applied, it flickers.  Let me put it this way, it isn't something I would have ever released.  It's that bad.  It reminds me of that original NanoVNA software they had when I first looked at it.   

NVIDIA Quadro M4000,  Xeon E5-1650 v4,  32G RAM, Win 10 Pro 1903.

Which portion of the screen flickers? The entire graph, or only the traces? Do the axis labels flicker as well? What about the intensity grading in CDF mode?
We can't currently reproduce this on our machines, so this will help us to narrow down the problem.
***
We can cause the whole graph to flicker if we modify the timings of some graphics calls. There is a narrow window which can cause a race condition. We'll send you a v2.5.9 prerelease version tomorrow morning which will hopefully fix the issue.

[joeqsmith]

I would call it the entire graph area, including the axis labels, cursors and traces.  Everything in the darker colored area flickers.   Without the FFT running, if I hold the mouse button over the white bar at the top, it will increase the flicker frequency.

You should review the product as it exists now.

Careful what you ask for.  Imagine making a review and this is what potential customer see:

[SJL-Instruments]

Thanks for the additional information and screen capture. We've just sent you a prerelease of v2.5.9, which we think fixes the root cause of the flickering.

[joeqsmith]

The flickering issue is hardware-dependent, and we were only able to reproduce it on one machine.

I also ran it on a newer PC with the following:

NVIDIA RTX A4500, CUDA cores 7168, Compute Compatibility 8.6
Intel(R) Core(TM) i9-10980XE CPU, 3.00GHz   
64.0 GB
Windows 10 Pro, 22H2, 19045.3930

Same flicker problem.  I obviously can't explain why you are not able to replicate it or why you felt the need to release it when it was clear there was a major problem with the prerelease.   IMO, your goal should be to release high quality software.  Seeing a problem like this flicker in the wild just isn't something that should ever happen.   

Running the prerelease 2.5.9 on the above hardware does not appear to exhibit the flicker.   I will test it tonight on the old PC and get back with you. 

[joeqsmith]

I have tried the 2.5.9 prerelease on my old PC and it no longer exhibits the flicker.   

The updated case arrived today as well. 

[joeqsmith]

2.5.9 prerelease, error when saving settings.   Not repeatable. 

***
Strike that.  It repeats.   

Also,  I suspect there is something still different between your software and mine when it comes to the power user mode.   I can set your software to what I believe are the same settings as my software and will get different results.   Does your software for example no allow trigger values in the mV range?  Maybe the boundary settings are limited?   For what ever reason, with my software I am able to work with much smaller signals than with yours.  Something in your software appears to be limiting me.   Really strange.

[SJL-Instruments]

2.5.9 prerelease, error when saving settings.   Not repeatable. 
***
Strike that.  It repeats.   

We're looking into this, and will send you an updated prerelease version when we find the root cause (hopefully today).
We can reproduce the error if the scope is disconnected prior to saving settings. Is this what happened in your case? (To be clear, we consider this a bug, and will fix it.)

Also,  I suspect there is something still different between your software and mine when it comes to the power user mode.   I can set your software to what I believe are the same settings as my software and will get different results.   Does your software for example no allow trigger values in the mV range?  Maybe the boundary settings are limited?   For what ever reason, with my software I am able to work with much smaller signals than with yours.  Something in your software appears to be limiting me.   Really strange.

There are two possible reasons:
1. On startup, the software performs the DC offset trim automatically (Section 3.7.2) if nothing is connected. This will shift all voltages on the ~mV scale. This isn't relevant if signals are connected on startup.
2. For backwards compatibility reasons, the trigger level command sent to the scope is 22 DAC units (~1 mV) higher than entered in the software.
Otherwise, there are no limits set in power-user mode. Any boundary limits are explicitly shown (the displayed value will be clamped).

Same flicker problem.  I obviously can't explain why you are not able to replicate it or why you felt the need to release it when it was clear there was a major problem with the prerelease.   IMO, your goal should be to release high quality software.  Seeing a problem like this flicker in the wild just isn't something that should ever happen.

Going forward, we will cut back our release schedule to once per two weeks. This will give us more time for QA, and still gives a reasonable turnaround time for user requests. In hindsight, weekly releases were on the edge of what we could handle.

[joeqsmith]

2.5.9 prerelease, error when saving settings.   Not repeatable. 
***
Strike that.  It repeats.   

We're looking into this, and will send you an updated prerelease version when we find the root cause (hopefully today).
We can reproduce the error if the scope is disconnected prior to saving settings. Is this what happened in your case? (To be clear, we consider this a bug, and will fix it.)

It's possible but I am not certain.  I really like having this feature and appreciate you adding it.   

Also,  I suspect there is something still different between your software and mine when it comes to the power user mode.   I can set your software to what I believe are the same settings as my software and will get different results.   Does your software for example no allow trigger values in the mV range?  Maybe the boundary settings are limited?   For what ever reason, with my software I am able to work with much smaller signals than with yours.  Something in your software appears to be limiting me.   Really strange.

There are two possible reasons:
1. On startup, the software performs the DC offset trim automatically (Section 3.7.2) if nothing is connected. This will shift all voltages on the ~mV scale. This isn't relevant if signals are connected on startup.
2. For backwards compatibility reasons, the trigger level command sent to the scope is 22 DAC units (~1 mV) higher than entered in the software.
Otherwise, there are no limits set in power-user mode. Any boundary limits are explicitly shown (the displayed value will be clamped).

This is where I would like to see an auto setup.  I am working with sub 10mV signals and can believe it is a DC offset problem and the trigger will need to change.  I adjusted it a fair amount trying to locate a level but may not have gone far enough.  I'll try again later.   Think about it, one button, auto set.  Just getting the vertical and trigger set would be very helpful compared with my trial an error technique.  The computer would be much faster. 

Same flicker problem.  I obviously can't explain why you are not able to replicate it or why you felt the need to release it when it was clear there was a major problem with the prerelease.   IMO, your goal should be to release high quality software.  Seeing a problem like this flicker in the wild just isn't something that should ever happen.

Going forward, we will cut back our release schedule to once per two weeks. This will give us more time for QA, and still gives a reasonable turnaround time for user requests. In hindsight, weekly releases were on the edge of what we could handle.

I want to be clear about this.  Feel free to send me prereleases while I continue to evaluate the product.  I don't mind testing them along with running my other tests.  I think giving yourself more time to test your software is a big step in the right direction.   

[joeqsmith]

If I do disconnect the scope from the PC, how do I get your software to reconnect to it without having to exit and restart? 

[SJL-Instruments]

If I do disconnect the scope from the PC, how do I get your software to reconnect to it without having to exit and restart? 

Currently the software does not support this. We will add this to the next version.

This is where I would like to see an auto setup.  I am working with sub 10mV signals and can believe it is a DC offset problem and the trigger will need to change.  I adjusted it a fair amount trying to locate a level but may not have gone far enough.  I'll try again later.   Think about it, one button, auto set.  Just getting the vertical and trigger set would be very helpful compared with my trial an error technique.  The computer would be much faster. 

This is being worked on - we aren't happy enough with the reliability yet, but with any luck it should be ready for next release.

We're looking into this, and will send you an updated prerelease version when we find the root cause (hopefully today).
We can reproduce the error if the scope is disconnected prior to saving settings. Is this what happened in your case? (To be clear, we consider this a bug, and will fix it.)

It's possible but I am not certain.  I really like having this feature and appreciate you adding it.   

We've found the root cause of this issue, and will send you a patched version tomorrow to test.

[joeqsmith]

For the power-user, consider making the End the total collection time rather than the end time.  If I want 1.6ns of data, I have add it to the Start in my head.  Then if I change the start, I have to manually calculate and enter a new end.   Maybe others would not run it that way but that would be my preference.  If you allow both a start/stop times and start/duration, and cover both would be great.   

DC offset was the problem.  Adjusting the trigger to a different level corrected it. 

Not finding any other major problems with the software.

***
When you start the program, it starts out with the menu that allows selection of the simulation.  You have to select the scope, then select OK.  I have been trained so well by Microsoft,  could you allow the double click selection so I don't have to move the mouse a second time and select another button?   

When you start the program, it flashes a few boxes on the screen before it loads.  This is something new.  Could you clean this up?

While I really like the new vertical scale with the drop down + custom, after selecting custom the only way to get back to drop down mode is to right click, select Select All,  right mouse click, select Delete, click outside the box or select the spin icon.   That's a lot going on for what should be a one click operation. 

FFT could use some cursor measurements.  Peak readouts... 

I was watching some of Picotech's reviews of their 9400.  I can't say I am a fan of their UI but they do have some good ideas that make it easier to drive their scopes. 

***
FFT settings are not included in the Save Settings. 

***
Closing the FFT window and reopening it will cause it to reset to some defaults rather than using the last settings causing me to have to reset it up every time.   

[SJL-Instruments]

For the power-user, consider making the End the total collection time rather than the end time.  If I want 1.6ns of data, I have add it to the Start in my head.  Then if I change the start, I have to manually calculate and enter a new end.   Maybe others would not run it that way but that would be my preference.  If you allow both a start/stop times and start/duration, and cover both would be great.

Got it - we will make this change in the next version.

Not finding any other major problems with the software.

We have sent you an updated prerelease of v2.5.9. If the last issue is resolved, we will release this publicly as a bugfix update.

[joeqsmith]

It corrects the save settings problem I saw. 

When you create multiple prereleases, you may want to consider having a unique version number in the header.   As I share screen shots, I don't want you asking me what version of software I was running.  It is up to you to track your code.  Internally, I don't care, but anything that leaves your office should have a unique identifier, IMO.

About the lockup.  I was running some longer sweeps and I think what may be happening is I do something that tells the software to do something besides sweeping.  The scope continues to dump data and the software can't abort it.  This is a total guess on my part.  It had looked like it hung as I have seen.  Nothing displayed in the graph as before.  This time I just let it sit for a long while and sure enough, it recovered.   It is very possible I was running high resolution wide time ranges when I have seen it hang before. 

[SJL-Instruments]

It corrects the save settings problem I saw.

Thanks for confirming. We've released this version as v2.5.9 (primarily to resolve the flicker problem).

When you create multiple prereleases, you may want to consider having a unique version number in the header.   As I share screen shots, I don't want you asking me what version of software I was running.  It is up to you to track your code.  Internally, I don't care, but anything that leaves your office should have a unique identifier, IMO.

We will do this going forward - thanks.

About the lockup.  I was running some longer sweeps and I think what may be happening is I do something that tells the software to do something besides sweeping.

To clarify, this means the hangup happened as you were changing some settings? Do you remember which ones?
This narrows it down quite a bit - likely a inter-process communication issue. Hopefully we can resolve this by next release.

When you start the program, it starts out with the menu that allows selection of the simulation.  You have to select the scope, then select OK.  I have been trained so well by Microsoft,  could you allow the double click selection so I don't have to move the mouse a second time and select another button?   

When you start the program, it flashes a few boxes on the screen before it loads.  This is something new.  Could you clean this up?

While I really like the new vertical scale with the drop down + custom, after selecting custom the only way to get back to drop down mode is to right click, select Select All,  right mouse click, select Delete, click outside the box or select the spin icon.   That's a lot going on for what should be a one click operation. 

FFT could use some cursor measurements.  Peak readouts... 

I was watching some of Picotech's reviews of their 9400.  I can't say I am a fan of their UI but they do have some good ideas that make it easier to drive their scopes. 

***
FFT settings are not included in the Save Settings. 

***
Closing the FFT window and reopening it will cause it to reset to some defaults rather than using the last settings causing me to have to reset it up every time.   

We will work on these bugfixes/features for the next release. As we get through this list, we'll send you occasional prereleases for feedback.

[joeqsmith]

About the lockup.  I was running some longer sweeps and I think what may be happening is I do something that tells the software to do something besides sweeping.

To clarify, this means the hangup happened as you were changing some settings? Do you remember which ones?
This narrows it down quite a bit - likely a inter-process communication issue. Hopefully we can resolve this by next release.

Sadly I do not but I can believe that my sweep times were in the order of several minutes.   When I was playing around writing my own code for it, I never flush Windows buffers.  It was easy to get my software in a mode where the scope had I expect, already dumped it's data but my software would be looking for other responses.   This is what made me wonder if you don't have a similar condition.   I think I have seen it happen three times.  Rare.

[joeqsmith]

For those of you interested in this product, if there is something specific you would like to see included in my review, consider this my open invitation to put in your requests.   Even if it isn't something I can demonstrate, maybe the Signal Path channel will consider it.   

[joeqsmith]

While attempting to make some very long, high resolution sweeps, I managed to get the scope to lockup to the point where exiting the software and reloading, it does not find the unit.     My guess is a power cycle is going to recover it.   I think I have had it hang in such a way that required a power cycle twice now.   

[joeqsmith]

Power cycle did shake it loose.  If an automotive companies firmware required you to pull the battery terminal every now and then, would you find that acceptable?  What about an aircraft?     

I started to write some simple test scripts to stress test your product and it seems easy enough to reproduce the lockups.  I could provide you with a sequence of commands that will cause it to hang.  I suspect you could just go through your firmware and clean that up.    I've also now seen where the scope will spam the data bus, sending  "FAIL 752440 0"  non stop for example.   The manual makes no mention of it.   Maybe it means something to you. 

Not having your firmware source I can't really guide you.  I guess we can rug sweep it like the double cal and hope no one runs into it.     

[SJL-Instruments]

I started to write some simple test scripts to stress test your product and it seems easy enough to reproduce the lockups.  I could provide you with a sequence of commands that will cause it to hang.  I suspect you could just go through your firmware and clean that up.    I've also now seen where the scope will spam the data bus, sending  "FAIL 752440 0"  non stop for example.   The manual makes no mention of it.   Maybe it means something to you. 

Could you provide the command sequence? We will try to reproduce the hang.

Are you able to reliably reproduce the "fail" message? What was happening just before it occurred?

[joeqsmith]

I started to write some simple test scripts to stress test your product and it seems easy enough to reproduce the lockups.  I could provide you with a sequence of commands that will cause it to hang.  I suspect you could just go through your firmware and clean that up.    I've also now seen where the scope will spam the data bus, sending  "FAIL 752440 0"  non stop for example.   The manual makes no mention of it.   Maybe it means something to you. 

Could you provide the command sequence? We will try to reproduce the hang.

Are you able to reliably reproduce the "fail" message? What was happening just before it occurred?

The firmware will need improvements before I could hunt down your problem with the spam messages.    Send the following two commands.  Scope will respond with "CH1 BAD: 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0".   Close the test software and try to connect with your software.

5332 DA62 2D43 A11C 1456 0D
74F5 71ED 8586 AEF6 3B79 0D

[SJL-Instruments]

The firmware will need improvements before I could hunt down your problem with the spam messages.    Send the following two commands.  Scope will respond with "CH1 BAD: 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0".   Close the test software and try to connect with your software.

5332 DA62 2D43 A11C 1456 0D
74F5 71ED 8586 AEF6 3B79 0D

The first command is interpreted as "S2", since the third byte (0xDA) is non-printable and the rest of the command is ignored.
This will cause subsequent commands to fail, as a minimum of 3 triggers per sample (S3) is required. The default value is 4096.
We will document this in the next manual revision.

[joeqsmith]

Try this script, should get the same response.  Scope should not reconnect after sending them.   Both scripts fail 100% of the time. 
6A22 912D 41A5 DCC3 8EA6 0D
7832 9A43 72E4 011D 2F2A 0D
2491 424C 10D3 D3E3 A99C 0D
7467 A795 2B74 ADB8 15F1 0D

IMO, the firmware should NEVER require a hard reset like this.   Normally, I would subject it to random packets, varying lengths, different terminators, patterns, speeds, attempt overflows....  Just your basic 101 stuff.  That's all am doing now.   That's how I made it spam the bus.  The CH1 BAD:  fault is the most prevalent.  I suspect the firmware is just not well written to make sure it handles packet faults.  You may be better off just going over it than trying to hunt down why a a specific set of commands takes it out. 

[joeqsmith]

The first command is interpreted as "S2", since the third byte (0xDA) is non-printable and the rest of the command is ignored.
This will cause subsequent commands to fail, as a minimum of 3 triggers per sample (S3) is required. The default value is 4096.
We will document this in the next manual revision.

I think you are missing the point.  I don't think pointing out that your firmware is not robust and to treat it like a princess or it will require a power cycle is time well spent.  Far better to harden the firmware so it handles all unforeseen conditions gracefully.  Again just MO. 

[joeqsmith]

Of course, if you had a simple checksum and other checks builtin to the protocol like most,  I would still write scripts to create valid checksums with an invalid payload.   I like things that are solid.   If it were a $50 nanovna, I would say who cares.

[SJL-Instruments]

The first command is interpreted as "S2", since the third byte (0xDA) is non-printable and the rest of the command is ignored.
This will cause subsequent commands to fail, as a minimum of 3 triggers per sample (S3) is required. The default value is 4096.
We will document this in the next manual revision.

I think you are missing the point.  I don't think pointing out that your firmware is not robust and to treat it like a princess or it will require a power cycle is time well spent.  Far better to harden the firmware so it handles all unforeseen conditions gracefully.  Again just MO. 

We understand your point, and intend to harden the firmware, likely in the same release where we add SCPI support.
Until then, we want to document where all the edge cases occur. Our comment was to point out that your fuzzing uncovered one of the bounds we forgot to document - we wanted to be public about this change to the documentation.

[joeqsmith]

I'll try to work around the firmware and see if I can replicate the spamming issue. 

With that first script, sending only the first command should not hang the scope.  It should still respond to other commands.  It seems to need both to cause the scope to only send the CH1 BAD response. 

Attached 1st column is sent command in ASCII, 2nd is command in HEX, 3rd is the response.   T is not a documented command in the manual.   A lot of these where it responds, it has an invalid payload that does not match with the manual.  The firmware decides to use it anyway.      My guess is some random miss without any error checking/recovery and then interpreting bad payloads as somehow good it the reason I have seen the scope hang when using it normally.   Personally, adding SCPI doesn't really bring much.  Hardening what you have would be far more beneficial.   

[SJL-Instruments]

I'll try to work around the firmware and see if I can replicate the spamming issue. 

With that first script, sending only the first command should not hang the scope.  It should still respond to other commands.  It seems to need both to cause the scope to only send the CH1 BAD response. 

Attached 1st column is sent command in ASCII, 2nd is command in HEX, 3rd is the response.   T is not a documented command in the manual.   A lot of these where it responds, it has an invalid payload that does not match with the manual.  The firmware decides to use it anyway.      My guess is some random miss without any error checking/recovery and then interpreting bad payloads as somehow good it the reason I have seen the scope hang when using it normally.   Personally, adding SCPI doesn't really bring much.  Hardening what you have would be far more beneficial.   

We're working on hardening the firmware. The command parser itself is solid. As a first pass, we just need to add range checks for the parameters in each command.
The T command is aliased to the *TST? command. We will document this in the next manual revision.
For clarity, the sequence S2, then T will reproduce your result.

[joeqsmith]

What about a these?  None are valid commands at the time it crashes.   

3&4, I changed my test to run up till five failures so you can see how the scope only returns CH1 BAD responses. 

I suspect you are going to spend a lot of time documenting  outlier cases.  IMO, it would be better to address the root problem.  Once the communications are robust, you can start to build off that solid foundation.

[SJL-Instruments]

What about a these?  None are valid commands at the time it crashes.   

3&4, I changed my test to run up till five failures so you can see how the scope only returns CH1 BAD responses. 

I suspect you are going to spend a lot of time documenting  outlier cases.  IMO, it would be better to address the root problem.  Once the communications are robust, you can start to build off that solid foundation.

The current manual (Section 4.5.1) states that issuing an H command with parameter below 40 will cause undefined behavior.
This will be caught and rejected when we add the bounds checking.

***

We are also restructuring the serial parser to be inherently more robust. We will perform our own fuzzing tests after the rewrite. When we are happy with the results of these tests, we can send you a prerelease firmware update if you'd like.

[joeqsmith]

As I add more and more case statements to avoid having your scope lock up, it is running longer but I have yet to reproduce the spam problem. 

At the time it did this, I was sending a 10-Byte payload + CR.  I have change my test to now send variable payloads.   Hopefully I can get it to repeat and trap it. 

[joeqsmith]

The first command is interpreted as "S2", since the third byte (0xDA) is non-printable and the rest of the command is ignored.

The current manual (Section 4.5.1) states that issuing an H command with parameter below 40 will cause undefined behavior.
...
When we are happy with the results of these tests, we can send you a prerelease firmware update if you'd like.

s,S,h,H are not being sent, along with seven other codes that have cause the scope to hang.   As you can see, it still hangs.  Because your firmware seems to in some cases ignore the first byte of the command (7F,54 for example will interpret as a T), I now also prevent all of these cases on the second byte.  Basically I will continue to increase the test cases until you provide improved firmware, or I find a combination that allows the scope to run long enough that the spam error repeats.     

I have no problem running any prerelease firmware,  now that I am setup to reprogram the device.  FP stands for Field Programmable.  As the product evolves, you may want to consider how to update the FPGA as well as the microcontroller across the USB interface.   Guessing it would require a hardware change.   

[joeqsmith]

We used the 1708 serial interface for automotive.  Something like a RS485/422.  One of my motorcycles uses something similar.   We were using J1587  protocol.  We adopted a similar protocol for other industrial projects I have been involved with.   The following link provides a simple overview of it:

https://www.kvaser.com/about-can/can-standards/j1587/

Note this is a very old standard but may still be in use today.  It has certainly stood the test of time.  Maybe have a quick read and see if there is something you can leverage from an existing standard like this.   


 

[joeqsmith]

Assuming that "Unknown command!"s are ignored  and not causing the scope to hang,  I have added a filter for them.  Even with my 12 test cases in the two first fields, it will still hang..    Changing to the first three fields. 

[joeqsmith]

Adding a check for the first three fields wasn't enough so it now checks every field.   Even with all of this, the scope will lock up. 

About 4 hours into this hunt and about the only thing I have to show for it is worn out USB connectors.   

[joeqsmith]

Maybe you can tell the cause of the FAIL 752440 0 from the attached dump.   When I exited the script and attempted to run your software, it threw the attached exception. 

[joeqsmith]

So, another new one.  The scope stops responding all together.   Exiting the test script and attempting to run your software, it does not find the scope. 

Lots of problems.  I will hold off doing anything more until you have time to go over your firmware.   Hopefully I have provided you with enough clues. 

[SJL-Instruments]

So, another new one.  The scope stops responding all together.   Exiting the test script and attempting to run your software, it does not find the scope. 

Lots of problems.  I will hold off doing anything more until you have time to go over your firmware.   Hopefully I have provided you with enough clues. 

We have just sent you a revised firmware version with a hardened parser and strict bounds checking. All the test cases you have shown no longer cause an issue. Our fuzzing tests are ongoing and have not revealed any issues so far.

Because your firmware seems to in some cases ignore the first byte of the command (7F,54 for example will interpret as a T), I now also prevent all of these cases on the second byte.

The byte 0x7F is a backspace character. This behavior is intentional, and simplifies use of the serial interface from an interactive terminal.

[joeqsmith]

First, thank you for taking the time to dig into the root cause.   I know it wasn't your intention to go after it so early but I am glad you did.   

It's installed and I am currently testing with all of my case statements removed.   My plan is to let it run overnight but it is over 150,000 cycles now.  Consider I was lucky if it made it past 10,000 with the old firmware.   So what ever changes you have made greatly improved it's robustness.   

***
Job well done! It ran all night without any further problems.  I also ran some other basic checks using your software as well as mine and it all seems to work. 

With the software and firmware shaping up, the only thing missing now is those 5X probes.        We can always revisit that.   Looks like no one had anything specific they wanted to see during the review.  My plan is to finish up this weekend and let you get back to your normal routine.      Again, good job.  You have made a lot of progress over this last month.   

[SJL-Instruments]

Job well done! It ran all night without any further problems.  I also ran some other basic checks using your software as well as mine and it all seems to work. 

With the software and firmware shaping up, the only thing missing now is those 5X probes.        We can always revisit that.   Looks like no one had anything specific they wanted to see during the review.  My plan is to finish up this weekend and let you get back to your normal routine.      Again, good job.  You have made a lot of progress over this last month.   

Thanks for the update, and glad the patch has resolved the problems.  We are continuing to test the firmware on several units. If all goes well, we will release it sometime next week.

[joeqsmith]

As promised,  I provided a preview of my review to SJL,  but we ran into small setback when looking at eye diagrams.  I had previously posted some data and it was suggested I increase the intensity to get a better view of what the eye looks like:

https://www.eevblog.com/forum/testgear/pocket-sized-6-ghz-1-tss-et-scope/msg5301991/#msg5301991

Even back then, then you can see that the eye diagram isn't all that easy to see what is happening.    The attached image is showing  a similar setup using the latest software.  With the advanced user settings I can attempt to increase the number if data points to add more detail to the eye, but the software errors out.  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?

I can certainly change that part of the review but the software really needs some improvements to better show the eye, before going ahead with it.  Once we have this sorted out, we can go ahead and release the review.   

[nctnico]

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.

[joeqsmith]

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.   

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.

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

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

[joeqsmith]

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.   

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

[SJL-Instruments]

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

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

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

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

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

[SJL-Instruments]

Hi SJL-Instruments !

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

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

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

My questions are:

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

Thanks for your interest! And quite a noble cause. 

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

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

[joeqsmith]

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

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

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

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

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

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

[joeqsmith]

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

[Lukas]

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

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

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

[SJL-Instruments]

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

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

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

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

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

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

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

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

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

[SJL-Instruments]

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

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

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

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

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

[joeqsmith]

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

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

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

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

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

[joeqsmith]

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

[KE5FX]

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

[SJL-Instruments]

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

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

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

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

[joeqsmith]

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

[SJL-Instruments]

We found a simple, bias-free way to remove 90% of the speckle. Essentially, we just enforce monotonicity on each CDF. In detail, any neighboring pair of points that are in the wrong order are set to their average. This might need to be repeated a few times until the entire CDF is monotonic.

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

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

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

[SJL-Instruments]

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

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

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

[joeqsmith]

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

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

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

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

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

[SJL-Instruments]

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

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

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

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

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

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

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

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

If we introduce a dual-comparator version of the GigaWave, it would be similar enough to integrate into the existing software. The sweep speed would be the same (or faster).

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

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

[KE5FX]

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

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

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

[joeqsmith]

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

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

So yes, better. 

[joeqsmith]

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

[SJL-Instruments]

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

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

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

[PHOStronics]

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

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

[SJL-Instruments]

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

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

[PHOStronics]

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

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

[SJL-Instruments]

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

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

[joeqsmith]

We found a simple, bias-free way to remove 90% of the speckle. Essentially, we just enforce monotonicity on each CDF. In detail, any neighboring pair of points that are in the wrong order are set to their average. This might need to be repeated a few times until the entire CDF is monotonic.

From what I can tell, the latest manual makes no mention of this.   

So, if CDF(0) > CDF(1), both CDF(0 &1) are set to the average of CDF (0&1).   We then check the new value of CDF(1) with CDF(2).  Once all are checked, we repeat this entire process until they are in order.   Then we calculate the new PDF.

For example, CDF  0, 0.1, 0.05, 0.2    Final CDF is 0, 0.075, 0.075, 0.2,     PDF is then calculated from final CDF. 

[SJL-Instruments]

From what I can tell, the latest manual makes no mention of this.   

So, if CDF(0) > CDF(1), both CDF(0 &1) are set to the average of CDF (0&1).   We then check the new value of CDF(1) with CDF(2).  Once all are checked, we repeat this entire process until they are in order.   Then we calculate the new PDF.

Yes, that's correct. We'll document this in the next manual revision. If you want it to converge faster, you can overcompensate slightly: set CDF(0) to (average - delta) and CDF(1) to (average + delta) where delta is some fraction of CDF(0) - CDF(1).
Essentially you're just removing all of the negative probability densities in the PDF in the minimally invasive way.

[joeqsmith]

Shown using the same setup as previous plot with your software.   For those wanting to try their own thing,  attached Zip contains CSV file for the voltage and CDF pairs.   

...where delta is some fraction of CDF(0) - CDF(1).

Interesting is how much of a difference using 50% vs 40% vs 30% makes in how well it de-speckles.

[PHOStronics]

Is the reason the monotonicity constraint is not directly part of the gausian process regression just implementation complexity, or is there a reason not to do it?
You mentioned you enforce it only in post processing but that seems like something that would aid in reducing the space of possible functions, and thereby alter the actual amount of information potentially gained from a trial voltage chosen

[SJL-Instruments]

Is the reason the monotonicity constraint is not directly part of the gausian process regression just implementation complexity, or is there a reason not to do it?
You mentioned you enforce it only in post processing but that seems like something that would aid in reducing the space of possible functions, and thereby alter the actual amount of information potentially gained from a trial voltage chosen

The monotonicity violations are just a result of the inherent statistical noise during sampling and are unrelated to the choice of query voltages. The monotonicity condition applies only to the "true" CDF values and not to the sampled CDF values, so you cannot assume this during acquisition.

[joeqsmith]

Sorry about the long delay but finally rebuilt the FPGA to further even out the distribution so we can see all of the level state changes.  Showing with 40k trigger min/max PAM4 with brightness set to max and something reasonable.   Zoomed into the transition area.  This was after a few hours of warmup.  At 128 pts/div, it took several minutes to collect this data  and initially the drift was really messing with the measurements.  Big improvement in the noise but is it ever slow.   

I tried several approaches to further reduce the speckles.  I mentioned looking at the histograms and doing a window.  One used a weighted filter.  Then there was a modified conways life sort of technique.  They all of course strip out good data.   Looking forward to the new firmware.   

[joeqsmith]

With the brightness set to the min, all of the transitions are still buried in the noise.  Guessing that the increase in samples per CDF will greatly improve this. 

[SJL-Instruments]

Sorry about the long delay but finally rebuilt the FPGA to further even out the distribution so we can see all of the level state changes.  Showing with 40k trigger min/max PAM4 with brightness set to max and something reasonable.   Zoomed into the transition area.  This was after a few hours of warmup.  At 128 pts/div, it took several minutes to collect this data  and initially the drift was really messing with the measurements.  Big improvement in the noise but is it ever slow.   

To clarify, is this with 40k Triggers/Sample min/max with 100 samples/CDF?

With the brightness set to the min, all of the transitions are still buried in the noise.  Guessing that the increase in samples per CDF will greatly improve this. 

With 40k triggers/sample, the speckles are likely dominated by CDF quantization noise (will be fixed in v14). Increasing samples per CDF (if below 100) will also help, but 100 should be sufficient for PAM4.

Some updates on v14 firmware: USB DFU is working. We are in the process of offloading more work onto the FPGA for faster acquisition. This is quite a large rewrite, so we will likely spend 2 or more weeks performing stability and regression tests. If all goes well, it should still be on schedule for end of month.

[joeqsmith]

To clarify, is this with 40k Triggers/Sample min/max with 100 samples/CDF?

That is correct. 

Some updates on v14 firmware: USB DFU is working. We are in the process of offloading more work onto the FPGA for faster acquisition. This is quite a large rewrite, so we will likely spend 2 or more weeks performing stability and regression tests. If all goes well, it should still be on schedule for end of month.

I am not sure how you define firmware.   Can you program both the microcontroller as well as the FPGA over USB with this new version? 

I'm up for fastest acquisition.   I wouldn't be surprised if those previous plots didn't require an hour  to collect one sweep.   I suspect some of the smearing (4 men enter, five exit) isn't from the scopes trigger drifting with temperature, shifting time.     

[SJL-Instruments]

I am not sure how you define firmware.   Can you program both the microcontroller as well as the FPGA over USB with this new version? 

Yes, both the FPGA and MCU can be reprogrammed via USB. We will add an "Update Firmware" menu option to the software that will just require selecting a single .bin file. Ideally, should never need to open the case after v14.

I'm up for fastest acquisition.   I wouldn't be surprised if those previous plots didn't require an hour  to collect one sweep.   I suspect some of the smearing (4 men enter, five exit) isn't from the scopes trigger drifting with temperature, shifting time.     

The ideal sweep time can be calculated from Section 2.2.2. Our goal is for v14 firmware to be within 20% of the theoretical minimum across all parameter ranges.

[joeqsmith]

Same signals applied to my 20 year old LeCroy waveblunder 64Xi.   Gigawave 6GHz, 1TS,12-bit vs the LeCroy's  600MHz, 5GS, 8-bit.  Of course, the LeCroy has a faster sweep rate (<sec vs several minutes), but the transitions are also much more discernible.  Of course, the 64xi can't show 35ps transitions like the 6400 can.   

***
Right tool for the job.  If you need to measure fast edge, 2-state signals,  6400 really shines. 

***
Qualify that with MHz trigger rates....

[SJL-Instruments]

As promised, we have released v2.6.0 of the software which adds jitter analysis. Measurement markers have been added, and more measurements are now available in point mode. The manual has been updated to revision H13. Image attached.

If we introduce a dual-comparator version of the GigaWave, it would be similar enough to integrate into the existing software. The sweep speed would be the same (or faster).

We've recently come up with a better algorithm for the dual-comparator version that offers a quadratic speedup. In theory this should reduce the Nmin requirement for eye diagrams by a factor of 300. This would allow capturing a PAM4 eye in 10 seconds, and a two-level eye in <1 second, without any increase in trigger rate. This also lets us avoid the pretrigger requirement. Now to put this into practice...

[joeqsmith]

Tried out the latest software and the first thing I noticed was when I change to color grading, the plots background now turns solid white.   Turning off the readouts, changing the scaling and CDF options has no effect.   With vectors enabled, it appears normal.

[SJL-Instruments]

This is due to graphics-card-specific OpenGL implementation details. This prerelease should fix the problem:
https://gigawave-releases.s3.us-east-2.amazonaws.com/GigaWave_v2.6.1_PREVIEW-2024-03-10_Windows.zip

NVIDIA Quadro M4000,  Xeon E5-1650 v4,  32G RAM, Win 10 Pro 1903.

Is this the machine you're testing on? We'll build one with the same specs for future QA checks.

[joeqsmith]

NVIDIA Quadro M4000,  Xeon E5-1650 v4,  32G RAM, Win 10 Pro 1903.

Is this the machine you're testing on? We'll build one with the same specs for future QA checks.

Yes.  I suspect the other machine I listed would have the same problem if you would like me to try it.   Updated software does solve it. 

Looking at task manager, does seem to require a bit of processing on this old PC.   

[SJL-Instruments]

Yes.  I suspect the other machine I listed would have the same problem if you would like me to try it.   Updated software does solve it. 

If you have the time, this would be helpful information to know. Good that the fix addresses the problem.

Looking at task manager, does seem to require a bit of processing on this old PC.

We'll improve the caching structure and CPU usage in the next update. We've put just enough time into optimizing the software for it to run smoothly on Windows tablets - but there's always more that can be done.

[joeqsmith]

1GHz oscillator attached to the 6400 using a 6dB attenuator:

https://www.minicircuits.com/WebStore/dashboard.html?model=BW-S6-2W263A%2B

Both systems are using 80/20.   6400 was allowed to warmup about an hour.   Rj is more than triple with the 6400. 

[joeqsmith]

Zooming in and increasing the resolution and samples per CDF has no effect (resetting cursors after adjustments). 

***
Updated plot to include P-P@ 1e-3&1e-2 BER.   

[SJL-Instruments]

The 6400 reports total RMS jitter, and cannot automatically currently isolate the Rj contribution.

The histogram at the bottom looks double-peaked (before the image was updated). The 1 sigma deviation for one of the features looks like ~6 ps RMS. This should be closer to Rj.

At 13 ns, your specific unit has ~4.7 ps RMS intrinsic trigger jitter that adds in quadrature (calculated from Section 2.3 and the calibration sheet). Subtracting this contribution gives 3-4 ps RMS as an estimate for Rj.

***

We can extract the Rj(δδ) and Dj(δδ) contributions assuming the dual-Dirac model. This will be implemented in the next update. There is no way to further decompose Dj(δδ) with this architecture.

[joeqsmith]

Using your 85ps @ BER 1e-3,  @ BER 1e-12  is about 185 ps p-p vs 48ps measured.   

https://www.analog.com/media/en/technical-documentation/app-notes/hfan0402-converting-between-rms-and-peaktopeak-jitter-at-a-specified-ber.pdf   

[SJL-Instruments]

Using your 85ps @ BER 1e-3,  @ BER 1e-12  is about 185 ps p-p vs 48ps measured.   

https://www.analog.com/media/en/technical-documentation/app-notes/hfan0402-converting-between-rms-and-peaktopeak-jitter-at-a-specified-ber.pdf   

Both the 85 ps and 48 ps measurements are correct - they're just measuring different things.

The conversion you quoted is valid only in the absence of Dj(δδ). It assumes a Gaussian jitter distribution. Since in your case there is visible double-edging, the Dj(δδ) contribution is a significant factor.

Since you're looking at the 12th transition after the trigger, likely the Dj(δδ) of the transition you're looking at is roughly 12x larger than the Dj(δδ) inherent to the clock (which is what was reported by your clock analyzer). (This assumes the Dj correlation timescale is ~10 ns or longer - in general the true Dj spectrum can be complicated.)

The appropriate alpha (equal to 2*Q_BER in below reference) for 1e-2 BER is 4.652.
https://people.engr.tamu.edu/spalermo/ecen689/jitter_dual_dirac_agilent.pdf
Eyeballing your plot, it looks like Dj(δδ) ~ 20 ps. Taking Rj(δδ) ~ 6 ps (effective, due to trigger jitter), this gives ballpark estimates:
TJ(BER = 1e-2) = 20 + 4.652*6 = 48 ps
TJ(BER = 1e-3) = 20 + 6.180*6 = 57 ps.
The reported measurements are larger than this since the selected analysis window has a significant vertical extent compared to the slope of the signal.

The PP jitter measurements reported in our software are the "true" PP jitter and do not assume the dual-Dirac model. When we implement Rj(δδ) and Dj(δδ) decomposition, we will also add TJ(δδ) measurements at BER down to 1e-12.

[joeqsmith]

Moving the start to 7.7ns does significantly lower the p-p values.

[joeqsmith]

When importing, is there a reason that the software will no allow disabling vectors?   

[SJL-Instruments]

When importing, is there a reason that the software will no allow disabling vectors?   

Imported traces (.CSV) only contain voltage as a function of time. There is no information about the distribution of the noise, so disabling vector mode would show no extra information.

[joeqsmith]

Why not store the raw CDF, voltage and settings?   This would have allowed me to upload the files directly from your software for those wanting to post process it and in this case, you could display the data any way you like. 

Shown using the delayline.   I wouldn't have expected a such a reduction as the sample delay is still the same but it is channel 2 rather than 1 and we have added a lot of coax plus all the other errors that go along with it.   

[SJL-Instruments]

Why not store the raw CDF, voltage and settings?   This would have allowed me to upload the files directly from your software for those wanting to post process it and in this case, you could display the data any way you like. 

Certainly doable - just a matter of priority. The graphics pipeline would need to be restructured to allow an arbitrary number of CDFs to be rendered responsively. Currently the raw CDF data can be exported as an NPZ - we'll add a CDF CSV export option to the next update.

Shown using the delayline.   I wouldn't have expected a such a reduction as the sample delay is still the same but it is channel 2 rather than 1 and we have added a lot of coax plus all the other errors that go along with it.   

The transient response on CH1 may introduce additional jitter - another reason why we only spec it down to 11 ns.
For a periodic clock signal, coax delay will distort the shape of the waveform but will not substantially affect the random jitter. The CH2 measurement should be accurate for this purpose (keeping in mind the various contributions mentioned before).

[joeqsmith]

Personally, I don't see the need for one more way to save data.  Rather just save all the data so it can be recalled and displayed in any format that you support with normal processing.   CSV or other delimited ASCII is nice in that pretty much anything can parse it.   

It will be interesting to learn how you plan to compensate for the channel to channel and trigger delays when making these measurements.   Even more interested in following this:

We've recently come up with a better algorithm for the dual-comparator version that offers a quadratic speedup. In theory this should reduce the Nmin requirement for eye diagrams by a factor of 300. This would allow capturing a PAM4 eye in 10 seconds, and a two-level eye in <1 second, without any increase in trigger rate. This also lets us avoid the pretrigger requirement. Now to put this into practice...

[SJL-Instruments]

Personally, I don't see the need for one more way to save data.  Rather just save all the data so it can be recalled and displayed in any format that you support with normal processing.   CSV or other delimited ASCII is nice in that pretty much anything can parse it.

Sure, we can add import of the NPZ CDF data. Likely two updates down the line, given the current feature backlog and v14 firmware work.

It will be interesting to learn how you plan to compensate for the channel to channel and trigger delays when making these measurements.

Could you clarify what you mean by "channel-to-channel delay"? For the trigger delay, we will store the relevant jitter calibration constants in v14 firmware, and add an option to automatically compensate for them in the RMS and Rj jitter measurements.

Even more interested in following this:

We've recently come up with a better algorithm for the dual-comparator version that offers a quadratic speedup. In theory this should reduce the Nmin requirement for eye diagrams by a factor of 300. This would allow capturing a PAM4 eye in 10 seconds, and a two-level eye in <1 second, without any increase in trigger rate. This also lets us avoid the pretrigger requirement. Now to put this into practice...

We don't want to say too much about this yet, other than it works very well in theory. If you'd like, we can send you a functional prototype for beta-testing, once it gets that far.

[hpw]

As promised, we have released v2.6.0 of the software which adds jitter analysis. Measurement markers have been added, and more measurements are now available in point mode. The manual has been updated to revision H13. Image attached.

If we introduce a dual-comparator version of the GigaWave, it would be similar enough to integrate into the existing software. The sweep speed would be the same (or faster).

We've recently come up with a better algorithm for the dual-comparator version that offers a quadratic speedup. In theory this should reduce the Nmin requirement for eye diagrams by a factor of 300. This would allow capturing a PAM4 eye in 10 seconds, and a two-level eye in <1 second, without any increase in trigger rate. This also lets us avoid the pretrigger requirement. Now to put this into practice...

Mira, mira

This would be that yellow on the egg, as supporting digital signals and any better OXCO as getting than fs jitter & jitter spectrum & 10..90% graphs.

In other words the yellow egg product. 

[joeqsmith]

It will be interesting to learn how you plan to compensate for the channel to channel and trigger delays when making these measurements.

Could you clarify what you mean by "channel-to-channel delay"? For the trigger delay, we will store the relevant jitter calibration constants in v14 firmware, and add an option to automatically compensate for them in the RMS and Rj jitter measurements.

Not channel to channel delay (not quoted correctly) but as far as jitter errors caused by differences between channels,  I refer to your previous post:   

The transient response on CH1 may introduce additional jitter ...

We don't want to say too much about this yet, other than it works very well in theory. If you'd like, we can send you a functional prototype for beta-testing, once it gets that far.

Yes, I would like to see it.   We can take it off line when/if you get to that stage.

[SJL-Instruments]

Mira, mira

This would be that yellow on the egg, as supporting digital signals and any better OXCO as getting than fs jitter & jitter spectrum & 10..90% graphs.

In other words the yellow egg product. 

Do you have a sense of the magnitude of jitter you'd like to look at? It may be difficult to get below 400 fs RMS jitter floor with discrete components.

Not channel to channel delay (not quoted correctly) but as far as jitter errors caused by differences between channels,  I refer to your previous post:   

The transient response on CH1 may introduce additional jitter ...

Got it - this is mainly an issue before 11 ns. The jitter calibration is done for CH1 and may be better on the other channels - we'll just have to characterize this carefully.
This difference should also go away completely with a dual-comparator architecture.

[hpw]

Mira, mira

This would be that yellow on the egg, as supporting digital signals and any better OXCO as getting than fs jitter & jitter spectrum & 10..90% graphs.

In other words the yellow egg product. 

Do you have a sense of the magnitude of jitter you'd like to look at? It may be difficult to get below 400 fs RMS jitter floor with discrete components.

by PM...

[SJL-Instruments]

We have just released v2.6.2 of the software and v14 of the firmware. The main additions are USB firmware update support, and significantly (3-10x) faster sweep rate. The firmware has been significantly rewritten, and now natively supports Nmin up to 250 and K up to 500k, with optional 16-bit CDF return format and built-in monotonicity correction.

For TDR/TDT applications in particular, sub-2-second sweep rates are now possible with good time resolution and accuracy. We have also added the ability to display time in distance units for this purpose.

For single-valued signals at the fastest sweep rates, there is still a remaining factor of ~3 in theoretical speedup. This requires a new mode of operation (send timebase start/stop/step and return an array of voltages), which we plan to implement in v15.

[joeqsmith]

I downloaded the latest firmware (second file you provided) along with the latest software.  Running the software without the new firmware appears to act normal.  After programming the new firmware and power cycling the scope, the software lists the scope and appears to connect.  It would not start sweeping like expected (no signals applied).  I then used your software to check the device info.  SN and firmware display 0 (see attached).

Using my software, I am able to connect to the device.   Reading out the status I get the following:

Info:  14 9 0.0000 0.0000 0.0000 0.0000 1.0000 1.0000 1.0000 1.0000
ID: GigaWave 6400 Digital Sampling Oscilloscope

So it appears to have the rev 14 firmware and knows it is SN#9.   I then attempt to sweep and it appears to crash the scope. I can no longer get it to respond to any commands.  Power cycling the scope,  I am again able to connect.  Attempting to sweep once again hangs it. 

Let me know how you would like to proceed. 

[SJL-Instruments]

We have just flashed the firmware file we provided to you onto a test unit, and were able to use the software without problems.

To confirm, did you update both the MCU and FPGA firmware? The v14 FPGA bitstream can be downloaded from our firmware upgrade guide (software page on the website).
***
Directly linked below for convenience:
https://gigawave-releases.s3.us-east-2.amazonaws.com/GigaWave_6400_FPGAbitstream_v14.bin

[joeqsmith]

I was not aware the FPGA had been updated as well. 

[SJL-Instruments]

Sorry for not making that clear. Flashing the FPGA should resolve the issue.

Future updates can be done over USB in the software, and will only require selecting one .dfu file.

[joeqsmith]

No problem.  The latest manual does talk about the FPGA rev 14,  but having programmed it a few times I didn't read it.  Anyway, it is now programmed and working fine.   I'll give it a trial run tomorrow after I get some sleep and provide you with an update. 

Thanks

[joeqsmith]

What is the key sequence you select to reset the Maximum Triggers/Sample to infinite?   

Have you considered adding tool tips (help) when hovering the mouse over a control?   

Power user mode, why when I select a start of 11n, the actual start is 10.997n?    12 is 11.998.  End at 18 gives 18.003.   

When selecting the auto setup, often the CDF range will be set such that the signal isn't smooth.   It provides a good starting point (see attached ch1,  Setting to even 50m will clean this up)

To oversimplify, I use a scope to see how the amplitude of a signal varies with time.  Any scope I have used, allows me to set a time base and input gain to get what I want.  With your scope, the user is now introduced to statistics.  Something users may have no interest in.   I mention this after having a conversation with a friend after they had spent some time reading this thread.  The jist of the conversation was, what is all this math stuff...   Because of the focus being more on the statistics and not actual use, I think they perceive it to be more an interesting science project than a lab tool.    It would be interesting to hear from others. 

[SJL-Instruments]

What is the key sequence you select to reset the Maximum Triggers/Sample to infinite?   

You can enter "inf" or "infinity" to reset the setting to infinity.

Have you considered adding tool tips (help) when hovering the mouse over a control?

We have not considered this yet, but certainly can add them. We have added this to our to-do list.

Power user mode, why when I select a start of 11n, the actual start is 10.997n?    12 is 11.998.  End at 18 gives 18.003.   

This is so that the timebase lines up correctly in intensity/color-grading mode. This is more clear with few points in the timebase.

As an extreme example, consider having only two points in the timebase at 10ns and 11ns. Then the intensity-grading at 10 ns would fill the region from 9.5 to 10.5 ns, and the intensity grading at 11 ns would fill the region from 10.5 to 11.5 ns. If the endpoints were labeled as 10 ns and 11 ns, the timebase and cursors would not line up correctly.

When selecting the auto setup, often the CDF range will be set such that the signal isn't smooth.   It provides a good starting point (see attached ch1,  Setting to even 50m will clean this up)

Thanks for catching this - will be fixed in next update.

To oversimplify, I use a scope to see how the amplitude of a signal varies with time.  Any scope I have used, allows me to set a time base and input gain to get what I want.  With your scope, the user is now introduced to statistics.  Something users may have no interest in.   I mention this after having a conversation with a friend after they had spent some time reading this thread.  The jist of the conversation was, what is all this math stuff...   Because of the focus being more on the statistics and not actual use, I think they perceive it to be more an interesting science project than a lab tool.    It would be interesting to hear from others. 

This goes back to the origins of the scope. At first, we did not intend to target eye diagrams or SI applications.

If looking only at single-valued signals, there is no need to mess with any of the CDF settings. For applications such as measuring the risetime of clocks, or the relative timing of pulses, the scope "just works" and is a quite useful practical tool. Our first few customers fell under this use case, and found the scope very easy to get started with.

Later we realized that the scope is technically capable of intensity-grading and eye diagrams, but this requires understanding of the statistical theory of operation. We implemented these features so that the hardware was not limited by the software, but we do recognize there is a learning curve. Again, had we known this during development, we would have made different choices.

The products we currently have under development will "just work" for their intended application. Certainly we have lost many potential customers for SI applications due to the perception you mentioned. From our perspective, the best thing we can do is to learn from this experience, and apply it to our future products.

[joeqsmith]

Thinking about the FPGA, have you considered adding a revision register that would be exposed to both the firmware and  software?  Rather than the crash and burn when there is an incompatibility problem, you could report the issue.   With the new method of programming, are you suggesting users will never run into the possibility that the firmware and FPGA are not compatible?

Power user mode, why when I select a start of 11n, the actual start is 10.997n?    12 is 11.998.  End at 18 gives 18.003.   

This is so that the timebase lines up correctly in intensity/color-grading mode. This is more clear with few points in the timebase.

As an extreme example, consider having only two points in the timebase at 10ns and 11ns. Then the intensity-grading at 10 ns would fill the region from 9.5 to 10.5 ns, and the intensity grading at 11 ns would fill the region from 10.5 to 11.5 ns. If the endpoints were labeled as 10 ns and 11 ns, the timebase and cursors would not line up correctly.

Sorry but I don't understand.  Using your example, I would sample at 10n & 11n.  I would end up with a set of PDF data at each time.  I would just plot the intensity of these two data sets.  At least that is how my software currently works. 

I repeated my random data test, allowing it to run several hours.  I noticed that it appeared the scope had stopped responding to all messages.   So I shutdown my software and started yours.  It does not find the scope.   Windows sees the communications port.  Using my software, I am able to establish a connection to the port but the scope does not respond to any commands.   

I had asked about how to program the device with custom software and wonder if these new commands could have locked up the unit.  Still, if that was possible, I would have expected your software would be able to clear it.  Power cycling the scope did return it to normal operation.   

I also tried to collect data using the new firmware/FPGA with my software.  It appears that something has been changed that broke my code.  So, I tried the original software that you provided (v2.5.3) and it also no longer is able to run the scope.  Guessing you are aware of this and the new manual documents these changes.   

***
v2.5.12 also does not work with the latest firmware/FPGA.   This version is new enough, I would expect it to notify the user with some sort of error about the firmware being too new.  Instead, it just doesn't collect any data.

***
Looking at the new manual, there isn't a section about what was changed to the protocol.   I was expecting something big enough to break the software would have been in a "whats new" in the Programming Guide.   I guess I need to diff the two versions of manual to find out what was changed.   

***
Comparing the two PDF manuals Programming Guide section, I see the following changes:

Note: Revision 14 of the firmware will perform this monotonicity correction automatically.

Internally, the delay will be measured and fine-tuned to achieve an accuracy of 0.2 ps or better.
This process takes ∼8 ms. If the optional argument y is set to 1, the verification will be skipped,
saving time in exchange for a typical accuracy of ∼2 ps.
Note: The parameter y is ignored in firmware revisions v13 and earlier.

• [Firmware v14 and later] The optional parameter y determines the CDF return format. If y
is set to 2, then the returned CDF values have 16-bit precision. Otherwise, 8-bit precision
is used.   

Note there is no mention of the Y parameter in the latest manual's example code.  This may be the problem, but I would expect it to default to what ever the old firmware did as to not break your own software.   Odd also is the manual makes no further mention of the 8-bit precision in this section and assumes everything is integer based.   Seems like a last second feature (fast mode?) and wasn't well thought out?

[SJL-Instruments]

Thinking about the FPGA, have you considered adding a revision register that would be exposed to both the firmware and  software?  Rather than the crash and burn when there is an incompatibility problem, you could report the issue.   With the new method of programming, are you suggesting users will never run into the possibility that the firmware and FPGA are not compatible?

We can do this in the next revision of the firmware. Ideally, with the USB DFU method, this compatibility issue should never occur, as all future .dfu update files will contain matching MCU and FPGA firmware files. Nevertheless, it would be a good failsafe.

Sorry but I don't understand.  Using your example, I would sample at 10n & 11n.  I would end up with a set of PDF data at each time.  I would just plot the intensity of these two data sets.  At least that is how my software currently works. 

We have attached an explicit example. The timebase contains three points at 10.5, 10.75, and 11.0 ns. If the horizontal timebase was labeled to start at 10.5 and end at 11.0, the intermediate tick marks would not line up correctly. If there is a better scheme we haven't thought about, we are open to changing this behavior.

I repeated my random data test, allowing it to run several hours.  I noticed that it appeared the scope had stopped responding to all messages.   So I shutdown my software and started yours.  It does not find the scope.   Windows sees the communications port.  Using my software, I am able to establish a connection to the port but the scope does not respond to any commands.

I had asked about how to program the device with custom software and wonder if these new commands could have locked up the unit.  Still, if that was possible, I would have expected your software would be able to clear it.  Power cycling the scope did return it to normal operation.

 
We had run similar tests to validate the firmware before releasing it, and did not find this problem. These tests may not have been long enough. We'll run some much longer tests and see if we can reproduce this behavior.

I also tried to collect data using the new firmware/FPGA with my software.  It appears that something has been changed that broke my code.  So, I tried the original software that you provided (v2.5.3) and it also no longer is able to run the scope.  Guessing you are aware of this and the new manual documents these changes.   

***
v2.5.12 also does not work with the latest firmware/FPGA.   This version is new enough, I would expect it to notify the user with some sort of error about the firmware being too new.  Instead, it just doesn't collect any data.

***
Looking at the new manual, there isn't a section about what was changed to the protocol.   I was expecting something big enough to break the software would have been in a "whats new" in the Programming Guide.   I guess I need to diff the two versions of manual to find out what was changed.   

The serial protocol is fully backwards-compatible. All previous software versions do work with the new firmware.
The difference is in the new bootloader, which now inserts a 2 second delay upon startup to listen for a firmware update command. If the scope is plugged in for at least 2 seconds prior to starting the software, it should work correctly. This goes for your custom software as well.

We will document this change in the next manual revision. The bootloader delay is necessary as a failsafe to allow recovery from a bricked MCU update, or an incompatible firmware file being flashed (especially if users later wish to develop open-source or custom firmware).

Note there is no mention of the Y parameter in the latest manual's example code.  This may be the problem, but I would expect it to default to what ever the old firmware did as to not break your own software.   Odd also is the manual makes no further mention of the 8-bit precision in this section and assumes everything is integer based.   Seems like a last second feature (fast mode?) and wasn't well thought out?

The Y parameter is optional and does default to the old behavior if omitted. The serial interface is fully backwards-compatible.
The 8-bit precision is the old operating mode, which uses 1 byte for the CDF return format. If the optional parameter is omitted, the behavior is exactly the same as previous revisions. We're not sure what you mean by "assumes everything is integer based" - could you clarify?

[joeqsmith]

The serial protocol is fully backwards-compatible. All previous software versions do work with the new firmware.
The difference is in the new bootloader, which now inserts a 2 second delay upon startup to listen for a firmware update command. If the scope is plugged in for at least 2 seconds prior to starting the software, it should work correctly. This goes for your custom software as well.

That is not what I am seeing.  The scope has been running a half hour.  Older software does not appear to work with it. The latest appears to  still work fine. 
Using v2.5.12, there appears to be nothing I can change in the settings that will cause it to start a collection.  I only see the flashing Wait.   I see this same behavior with all of the older versions of your software that I tried.   

Really odd is that you're not seeing this and it works for you.  With mine, I can't get any of them to work except the latest. 

***
Odd too, looking at the main graph of v2.5.12 for example, the horizontal axis begins at -102 ns and ends at 138 ns.  Guessing this is because it never sees a trigger.  Odd is the internal trigger doesn't even kick.   Yet it all works on your end?   Crazy.    Must be a user problem. 

[joeqsmith]

Found how to reproduce the problem easy enough.  Run your new software, collect some data.  Exit your software.  Now run v2.5.12.  Should be dead.   Exit the software and run the new software again, should return to normal.     Exit and run the old software, again should be dead.  Now power cycle the scope.  Should work. 

In case it has something to do with my setup, I have attached the defaults.

[SJL-Instruments]

To be clear, we are claiming that the following should work:
1. Plug in the scope.
2. Run v2.5.12.

We can reproduce the issue you are describing. It occurs because the new software sets the scope to the new 16-bit CDF return format, which the old software cannot understand. This is only an issue if the user has both the old and new version of the software installed, and runs the new software, then the old software, without the scope being unplugged in between.

In general, we will guarantee backwards compatibility, but not forwards compatibility. A workspace settings file created in v2.5.12 will load correctly in v2.6.2, but not the other way around. It is possible to maintain forwards compatibility, but this would add a very large overhead to our software development. We could do it if it's important to our users, but this does not appear to be the case at the moment.

[joeqsmith]

...  This is only an issue if the user has both the old and new version of the software installed, and runs the new software, then the old software, without the scope being unplugged in between ...

To be clear, you are considering the software I wrote as being old software.  I could care less about your old software having problems outside of it demonstrating the problem you have caused with my custom software.    Why wouldn't you return the scope to what ever the older software requires on exit? 

I suggest at minimum, adding at least a comment to the start of the programming manual that describes this.  As you now require I modify my software to force it back to the original mode. 

***
I am not a fan of having to power cycle test equipment to work around firmware, FPGA and software problems.   

[SJL-Instruments]

...  This is only an issue if the user has both the old and new version of the software installed, and runs the new software, then the old software, without the scope being unplugged in between ...

To be clear, you are considering the software I wrote as being old software.  I could care less about your old software having problems outside of it demonstrating the problem you have caused with my custom software.    Why wouldn't you return the scope to what ever the older software requires on exit? 

I suggest at minimum, adding at least a comment to the start of the programming manual that describes this.  As you now require I modify my software to force it back to the original mode. 

***
I am not a fan of having to power cycle test equipment to work around firmware, FPGA and software problems.   

Point taken - in the next software revision, we will return all parameters to default upon exiting the software.
We have linked a prerelease below that incorporates this change. It should no longer cause a problem with your custom software, or with any older version of our software.
https://gigawave-releases.s3.us-east-2.amazonaws.com/GigaWave_v2.6.3_PREVIEW20240323_Windows.zip

[joeqsmith]

Repeating the random test, attached showing the commands sent just prior to the DSO going unresponsive.    Once it enters this mode, it will no longer respond to any commands. 

***
I should mention, this is the same test I had ran a few weeks back.  The older firmware survived this test for several hours. 
https://www.eevblog.com/forum/testgear/pocket-sized-6-ghz-1-tss-et-scope/msg5337386/#msg5337386

[joeqsmith]

Power user mode, why when I select a start of 11n, the actual start is 10.997n?    12 is 11.998.  End at 18 gives 18.003.   

This is so that the timebase lines up correctly in intensity/color-grading mode. This is more clear with few points in the timebase.

As an extreme example, consider having only two points in the timebase at 10ns and 11ns. Then the intensity-grading at 10 ns would fill the region from 9.5 to 10.5 ns, and the intensity grading at 11 ns would fill the region from 10.5 to 11.5 ns. If the endpoints were labeled as 10 ns and 11 ns, the timebase and cursors would not line up correctly.

Sorry but I don't understand.  Using your example, I would sample at 10n & 11n.  I would end up with a set of PDF data at each time.  I would just plot the intensity of these two data sets.  At least that is how my software currently works. 

We have attached an explicit example. The timebase contains three points at 10.5, 10.75, and 11.0 ns. If the horizontal timebase was labeled to start at 10.5 and end at 11.0, the intermediate tick marks would not line up correctly. If there is a better scheme we haven't thought about, we are open to changing this behavior.

Sorry but I am still not understanding why the mismatch.  In this last example, you start at 10.5.  The software shows data 125 ps prior.   If I send the D command with a 10ns delay,  I assume the data the scope sends is at the delay I specify, not 125ps prior.  Your plot shows switch points between the sample times.  Again, not what I would expect.   In my software, I am just setting the delay and reading back the data for each discrete point in time.    If I program 10.0 as a start, it starts at 10.0.  If the scope is sending me data at some other time, I am not aware of it.   

[SJL-Instruments]

Sorry but I am still not understanding why the mismatch.  In this last example, you start at 10.5.  The software shows data 125 ps prior.   If I send the D command with a 10ns delay,  I assume the data the scope sends is at the delay I specify, not 125ps prior.  Your plot shows switch points between the sample times.  Again, not what I would expect.   In my software, I am just setting the delay and reading back the data for each discrete point in time.    If I program 10.0 as a start, it starts at 10.0.  If the scope is sending me data at some other time, I am not aware of it.   

The data returned always corresponds to the time requested. What we are talking about pertains only to the display of the data.

Suppose we take data from 10 ns to 11 ns in 0.1 ns steps. Conceptually, the data is plotted as shown in the attached image. To make the data visible in intensity-graded mode, we shade a finite width of the screen centered around each point in time.

This means that the start and end point of the time axis does not correspond to the first and last time in the data.

Repeating the random test, attached showing the commands sent just prior to the DSO going unresponsive.    Once it enters this mode, it will no longer respond to any commands.

We cannot reproduce a lockup by sending this exact sequence of commands. We have been performing similar fuzzing tests on several units in parallel (integrated 200 hours) with no lockup.
There may be some difference between the way we are performing these tests. We are sending between 1 and 100 commands, each containing between 1 and 10000 random bytes, and then reading the responses. If possible, it would be helpful to have a sequence of commands that reproduces the problem. We are looking for codepaths that could cause what you're seeing, but not being able to cause the problem makes debugging difficult.

[joeqsmith]

Sorry but I am still not understanding why the mismatch.  In this last example, you start at 10.5.  The software shows data 125 ps prior.   If I send the D command with a 10ns delay,  I assume the data the scope sends is at the delay I specify, not 125ps prior.  Your plot shows switch points between the sample times.  Again, not what I would expect.   In my software, I am just setting the delay and reading back the data for each discrete point in time.    If I program 10.0 as a start, it starts at 10.0.  If the scope is sending me data at some other time, I am not aware of it.   

The data returned always corresponds to the time requested. What we are talking about pertains only to the display of the data.

Suppose we take data from 10 ns to 11 ns in 0.1 ns steps. Conceptually, the data is plotted as shown in the attached image. To make the data visible in intensity-graded mode, we shade a finite width of the screen centered around each point in time.

This means that the start and end point of the time axis does not correspond to the first and last time in the data.

In your previous example where you show the plot using 10.5, 10.75, and 11.0 ns, you actually plot 4 data points, even though the software is showing only 3. 

If I use my software to collect data starting from 10.5n with a range of 0.5n and a 250ps resolution, I get a start of 10.5 and a stop of 11 with three data points.   This is what I would expect to see.   

***
 
So ... I looked at LabView's intensity graph and sure enough, it has the same problem as what you show.  I had not noticed it until I looked at the three sample example.   When I scaled the graph originally, I just used the two end points.  Looking at a lot of data, I did not see the error.   

[joeqsmith]

Repeating the random test, attached showing the commands sent just prior to the DSO going unresponsive.    Once it enters this mode, it will no longer respond to any commands.

We cannot reproduce a lockup by sending this exact sequence of commands. We have been performing similar fuzzing tests on several units in parallel (integrated 200 hours) with no lockup.
There may be some difference between the way we are performing these tests. We are sending between 1 and 100 commands, each containing between 1 and 10000 random bytes, and then reading the responses. If possible, it would be helpful to have a sequence of commands that reproduces the problem. We are looking for codepaths that could cause what you're seeing, but not being able to cause the problem makes debugging difficult.

If we are calling a command one packet of data,  I send them until I decide to stop it.   The packet size is between 1 and 12 bytes.  All packets are CR terminated (adding one additional byte).    There are no filters as to what the payload contains.   It's just random data of a random length. 

Sure, I can create a test file of commands for you like last time.  It seems easy enough to reproduce. 

[joeqsmith]

Power cycle the scope and send these commands.   Next run your software.  You should find that the software will connect to the scope.   The scope should not trigger no matter what settings you make.

Next, power cycle the scope.  Run your latest software then exit.  Send these command to the scope.  Run your software.  The scope should not be detected.

***
Note this is a CSV file.  The file type isn't supported for uploading.  Packets are CR terminated.

[joeqsmith]

Not that is will help your situation but with LabView, I just clip off the first and last half time and then process the X axis normally.   Nice thing about this approach besides aligning the screen to the requested start and stop locations, it's also simple (at least with LabView) to add. 

[SJL-Instruments]

Not that is will help your situation but with LabView, I just clip off the first and last half time and then process the X axis normally.   Nice thing about this approach besides aligning the screen to the requested start and stop locations, it's also simple (at least with LabView) to add. 

Thanks for the suggestion. We will implement this behavior in the next revision (half-width shaded region on first and last points). You're not the first to ask about the axis labeling - hopefully this will prevent future confusion.

Power cycle the scope and send these commands.   Next run your software.  You should find that the software will connect to the scope.   The scope should not trigger no matter what settings you make.

Next, power cycle the scope.  Run your latest software then exit.  Send these command to the scope.  Run your software.  The scope should not be detected.

We have tried sending these commands in several configurations (in one large binary blob, or with commands separated by 0.1, 1, 10, 100, ms, both with or without reading the responses) but cannot induce a lockup.
We have attached a log from one of these tests if you'd like to verify that we are interpreting your file correctly, and splitting the commands as you'd expect. In this log, some commands take longer than the 10 ms timeout, and so the corresponding response appears after a later command (with the intermediate commands queued).
Based on your response #472, does the scope always lockup at the command "72 2D 72 0D"? If so, this may be enough information for us to track down the root cause in firmware (even if it is unit-dependent).

[joeqsmith]

I am not sure if it actually locks up.  It ends up in one of two modes, depending on if I had ran the new software or not.  One mode, it will not trigger after connecting to the scope with your latest software.  The other, it seems to go unresponsive and your software can not detect it on startup.  Windows still sees the connection.  In this state, I am able to use my software to connect to the scope but it will not respond to any commands.

Both cases, the scope will recover only after a power cycle. 

I just tried it again with the script I provided and was able to repeat the same results.   

Looking at your txt file, it appears correct.   

It appears that it is related to the new R command as symptom is tied to if I run your new software or not.   Currently I give the scope a ms to respond.  If it doesn't respond, I send the next packet.   This is the same way I tested the previous firmware.   I wonder if I am overflowing some internal buffer in your firmware.   I slowed down my transmission and it's up to 50k packets.   I'll let it continue to run but it is starting to look like an overflow problem.     

You mentioned you had looked at my VNA software.   If so, did you get the 32-bit application to run? 

Not that it helps, but on the graphing, LabView allows you to have multiple markers per axis on a graph.  The horizontal would normally be 0 - 10 for example, but I can have a second scale of say 10n - 10.5n on that same axis.   I can also manually scale the graphs.  So, I send the data to the graph and set the min and max horizontal to a half sample from the actual min/max.  I then set the second scale to what the actual time is.  There's no math or anything to track.  It's very clean to do it this way and I don't have a dead spot on the graph which is sounds like you will have based on your description.  If I tell the scope to sweep from 10-11, I am not expecting the graph to be from 9-12 with data only showing up between 10 and 11.  I expect it to start at 10 and stop at 11. 

***
Appears to be some type of overflow.  I suspect when I run your software and allow the scope to start to sweep, it places it into a mode where it is more susceptible to the overflow.   If you have LabView, I can give you the source code.  Or, if you have the runtime engine installed for 2011 (would have been required to run the original software I provided for the NanoVNA) I can supply you with an EXE.  My guess is there is nothing really unique about the data I am sending the scope, it's just how fast I am able to send it.  But you tried it with a 100us throttle, which should be faster than what I am doing.   

[SJL-Instruments]

So, we found the root cause of the issue.

First, we misread your reply #477, and thought that the commands themselves would cause a lockup. We can confirm that running the commands, in conjunction with our software, reproduces the behavior you're seeing. Sorry about that.

The main problem is that one of your commands sets the CDF tolerance (% command) to 0.000007, and our software does not reset it to the default (0.01) on startup. We will implement this in the next revision. This solves the "first lockup mode" you're describing, where the software connects but does not trigger.

The reason this causes a lockup is that the timeout for the R command is scaled based on the CDF tolerance (the expected amount of time needed to reach the specified tolerance), and we did not put a cap on this. In v15 firmware we will get rid of this, and allow the user to specify a max timeout manually, in seconds.

This change will solve the "second lockup mode" to some degree, but not completely. As an example, at very low trigger rates (100 Hz), each R command may need 5 seconds to gather enough data. It's possible to queue up hundreds of these read commands in the serial buffer, effectively "locking up" the scope for several minutes.

This behavior is technically "as designed," but the end result is not desirable. We could of course put a hard cap on the timeout, or decrease the buffer size, but this artificially limits the capability of the scope, and does not completely get rid of the issue. Another idea is to limit the total "queued time" of buffered commands, but the time taken is data-dependent and not predictable. If you have a preferred way to solve this issue, let us know.

On another note, this behavior is unchanged from v13. We did not find it, since our tests did not try fuzzing in conjunction with running the software. We will make this mode part of our testing in the future. The necessary conditions are for the CDF tolerance to be very low (<10 ppm), and the max samples to be very high (>3 million), which is difficult to find with random bytes.

We did check the firmware for any buffer overflow issues, and did not find any. Any commands that would overflow the buffer will be dropped, but should not cause a lockup.

Not that it helps, but on the graphing, LabView allows you to have multiple markers per axis on a graph.  The horizontal would normally be 0 - 10 for example, but I can have a second scale of say 10n - 10.5n on that same axis.   I can also manually scale the graphs.  So, I send the data to the graph and set the min and max horizontal to a half sample from the actual min/max.  I then set the second scale to what the actual time is.  There's no math or anything to track.  It's very clean to do it this way and I don't have a dead spot on the graph which is sounds like you will have based on your description.  If I tell the scope to sweep from 10-11, I am not expecting the graph to be from 9-12 with data only showing up between 10 and 11.  I expect it to start at 10 and stop at 11.   

We've attached a screenshot of the updated scheme - this should be identical to your proposal in #478.

[joeqsmith]

One possible solution would be to add a watchdog.  The software would send down a refresh command at some minimum rate.  The firmware would require this command, or any other communications at this minimum rate or it would return to the default power up state.  The firmware can't really count on the calibration command as the user may not want to send it.  The refresh command may not even have an acknowledge returned to the PC.

You may want some sort of fault status that the software could read to determine if a reset occurred.   

It's possible to queue up hundreds of these read commands in the serial buffer, effectively "locking up" the scope for several minutes.

That's fine as long as the PC would continue to send the refresh during this time.  If something went wrong and no data was being sent from the PC, the firmware would reset to the default state.   The timeout could be in the several seconds.  We are not trying to waste a lot of time with this sanity check.  We just want a way to recover if there is a major fault. 

I'm sure there are many ways to skin this one.   Give it some thought.

[SJL-Instruments]

After asking the good folks on the MCU forum, seems like the consensus, and industry-standard implementation, is to scrap the FIFO entirely (or reduce its length to 1). In our specific case, there is no extra throughput gain to be had by having a FIFO length of 2 or higher, and a FIFO length of 1 is sufficient if the end-user program can be mapped to a state machine. This avoids the lockup problem entirely.

There is a question of whether to actually remove the FIFO, or just remove it as part of the documented interface. Both options would behave identically as long as the user implementation follows the documentation (wait for response to start before sending next command). Removing it may break backwards compatibility - we are leaning towards keeping it for this reason. If it is kept, we would add a note in the documentation in case anybody does run into the lockup.

[joeqsmith]

I had changed to a full handshake some time ago and don't see a problem with it working as described.  As long as everything is documented, should be good to go.  I have added the tol command to my software as well and adding the Y to the R command. 

***

The reason this causes a lockup is that the timeout for the R command is scaled based on the CDF tolerance (the expected amount of time needed to reach the specified tolerance), and we did not put a cap on this. In v15 firmware we will get rid of this, and allow the user to specify a max timeout manually, in seconds.

Consider that what ever you come up with, there needs to be a way to abort a command (without pulling the USB cable).   As I mentioned, I use a full handshake today.  However, if the scope doesn't respond in N time, I do some sort of recovery.  Normally, resending the last command.  There isn't any mention in the manual how you want to handle such cases. 

[Kean]

There is a question of whether to actually remove the FIFO, or just remove it as part of the documented interface.

Are you able to detect software disconnection of the communication port to flush the FIFO.  e.g. via the CP2102 hardware handshaking signals or maybe the SUSPEND pins.
Not sure if SUSPEND is useful, as that probably cannot be triggered under app software control, and only by host power management.

[SJL-Instruments]

Consider that what ever you come up with, there needs to be a way to abort a command (without pulling the USB cable).   As I mentioned, I use a full handshake today.  However, if the scope doesn't respond in N time, I do some sort of recovery.  Normally, resending the last command.  There isn't any mention in the manual how you want to handle such cases. 

We could immediately cancel the current command, and flush the FIFO, when the Control-C (or Command+C) byte is received. This has the benefit of being natural for interactive terminal use. (We do not anticipate needing to send binary data in a command, other than during USB firmware update, where throughput is not a major concern.)

Are you able to detect software disconnection of the communication port to flush the FIFO.  e.g. via the CP2102 hardware handshaking signals or maybe the SUSPEND pins.
Not sure if SUSPEND is useful, as that probably cannot be triggered under app software control, and only by host power management.

For the reasons you mentioned, we don't think this would be a reliable mechanism for this use case. If a serial connection is closed by one program and opened by another, the SUSPEND pin will not necessarily go high in between, so the FIFO responses will continue to be processed and sent to the second program.
Our current plan is to nominally (in the documentation) require waiting for one response to start before sending the next command. We will keep the FIFO for backwards compatibility, but will mention the potential lockup issue if this guideline is not followed, as well as how to request immediate cancellation/flushing if needed.

[joeqsmith]

We could immediately cancel the current command, and flush the FIFO, when the Control-C (or Command+C) byte is received. This has the benefit of being natural for interactive terminal use. (We do not anticipate needing to send binary data in a command, other than during USB firmware update, where throughput is not a major concern.)

As I previously wrote, I have never understood your desire to use a terminal to control the scope.  You can't get any meaningful data without some sort of custom software.  As I also mentioned, I would rather have all communications processed the same way. 

https://www.eevblog.com/forum/testgear/pocket-sized-6-ghz-1-tss-et-scope/msg5327255/#msg5327255

If you do decide to implement some sort of abort command, make sure you think through it.  You already have no error checking in the protocol and two different terminators.  Using your company name as a terminator to work around binary data being sent....   Make sure that as you expand the protocol, you don't piecemeal it.

This is the reason I had mentioned the automotive standards.

[SJL-Instruments]

As I previously wrote, I have never understood your desire to use a terminal to control the scope.

We have one user who has requested a bulk voltage read mode (specify start/end/step and receive a voltage array), and would prefer using this from an interactive terminal. We do agree that for now, a custom program is needed to interpret the CDF data.

Although, on second thought, anybody using an interactive terminal would never build up a FIFO backlog anyway, so this concern is a moot point for the current discussion.

As I also mentioned, I would rather have all communications processed the same way. ...
Make sure that as you expand the protocol, you don't piecemeal it.

This is the reason I had mentioned the automotive standards.

We are working on implementing the SCPI standard for test equipment. Given that most of our planned changes for v15 concern the serial interface, we'll bite the bullet and commit to implementing this standard for v15 (rather than make piecemeal adjustments in between), even if it delays the update somewhat.

[joeqsmith]

As I previously wrote, I have never understood your desire to use a terminal to control the scope.

We have one user who has requested a bulk voltage read mode (specify start/end/step and receive a voltage array), and would prefer using this from an interactive terminal. We do agree that for now, a custom program is needed to interpret the CDF data.

Although, on second thought, anybody using an interactive terminal would never build up a FIFO backlog anyway, so this concern is a moot point for the current discussion.

That seems odd as the newer software allows ways to export the data.   Then there are other shortcomings, for example, they have something beyond a single state signal.  I could see having only the voltage could confuse them when taking measurements.   Guessing they understand the limitations of the scope and how it works.   IMO, the way it is today, if someone needed a feature beyond what the software support, I would suggest just asking you to add it.  Other's may be able to leverage these features.   If you really need something custom, there's no reason not to roll it from scratch.  It's not that complicated especially now with the improved documentation.     
 
If you continue to make changes to a protocol that you do not intend to support long term, you're just making work for yourself and anyone else who writes an interface for it.   This is why I wanted you do make sure you had a clear path moving forward early on. 

[SJL-Instruments]

We have just released v2.6.3 of the software and revision H16 of the manual. This fixes the bugs discussed here since the last update, adds tooltips (built-in help) for all controls, and FFT cursors. The manual now has a changelog, and we have added documentation on the MCU update protocol (per request).

We tried implementing Rj/Dj decomposition for Tj(BER) as well as mask testing for this update, but after several iterations we were not satisfied with the results. This is largely due to the single-comparator hardware limiting the BER fidelity to ~1e-4 in a reasonable acquisition timeframe. We did mention this in the manual, and made this clear to anyone asking about SI applications; but just in case, we've contacted all customers who mentioned SI, and extended their return period in case they were expecting this capability in the future.

A bit disappointing on our end, as we do want to push the hardware as far as it can go for the end-user. But best to be transparent about the limits of the hardware, once we reach them. More advanced jitter decomposition/BER analysis will require a future hardware model. Seems like the most successful applications for this scope as of now are high-speed timing analysis (setup/hold, rise/fall times, phase-matching) , TDR/TDT, qualitative eye diagram evaluation, and pulsed laser measurements.

[joeqsmith]

Tooltips is nice.  Consider providing a means to disable it and include that setting when saving the setup.   Bug wise, of course if you run that script I provided, and run your software without a power cycle, you still can't detect the scope is present.   I'm guessing you are aware of this and it will require a firmware change to solve it. 

It it much faster compared with when I first looked at it.  The whole user experience is much improved.  You've come a long way. 

I imagine if you turn the crank again (new products) it will get easier based on what you have learned.

[SJL-Instruments]

Tooltips is nice.  Consider providing a means to disable it and include that setting when saving the setup.   

Thanks - we will include this in the next update.

Bug wise, of course if you run that script I provided, and run your software without a power cycle, you still can't detect the scope is present.   I'm guessing you are aware of this and it will require a firmware change to solve it.

Yes, this will be fixed in the v15 firmware update. Currently we're estimating this to be released in mid-May. The planned changes for v15 are also listed in the software changelog on our website.

I imagine if you turn the crank again (new products) it will get easier based on what you have learned.

Yep, the current user experience for the GigaWave sets the minimum bar for what we want to release in the future.

[joeqsmith]

- Implement SCPI standard. [Backwards-compatible with existing protocol.]

Are you planning to remove the older protocol once the new one has been adopted?   Will new products use the new protocol only?  Something different?   

The real advantage IMO to implementing SCPI is to use the current product as test case.   I doubt many people will write custom software for it and those that do will have already locked down their interface.     Down side is it adds complexity and increases the risk of there being problems. 

- Store jitter calibration in firmware, perform automatic jitter correction in software.

I though the current firmware stored the calibrations and that is why you have a unique release for each individual scope.   I can't imagine having to support something like this in production.

[SJL-Instruments]

New products will use SCPI only. As you said, the main benefits of SCPI for the GigaWave are (1) ease of use for new users, and (2) to be sure we have a bug-free implementation for future products. Whatever we implement, backwards compatibility is the #1 consideration and we will keep the current interface available.

Perhaps the current interface is already easy enough to get started with. We are the worst possible judge of whether this is true for new users, given how long we’ve spent thinking about the protocol. You did mention inconsistencies with the return terminators being a possible sticking point. SCPI would define all the low-level considerations like this in a standard way.

***
The current firmware does store the calibrations. There is no additional complexity needed to also store the jitter calibration. It’s not currently stored because it’s not necessary for the current functionality of the scope. From our perspective, this is a small change and straightforward to implement.

[joeqsmith]

Perhaps the current interface is already easy enough to get started with. We are the worst possible judge of whether this is true for new users, given how long we’ve spent thinking about the protocol. You did mention inconsistencies with the return terminators being a possible sticking point. SCPI would define all the low-level considerations like this in a standard way.

It will be interesting to see how you solve problems like stacking commands.  I had asked about it early on, then you took the stance of requiring a single command and waiting for an ack.

Concatenating commands
Multiple commands can be issued to an instrument in a single string. They are made of simple commands separated by a semicolon character (. For example, the command to "Measure a DC voltage then measure an AC current" would be issued as MEASure:VOLTage:DC?;:MEASure:CURRent:AC?.

Doing a quick search for the standard, came up with this one which is very old.
https://www.ivifoundation.org/downloads/SCPI/scpi-99.pdf