Pocket-Sized 6 GHz 1 TS/s ET Scope

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