Pocket-Sized 6 GHz 1 TS/s ET Scope

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