Pocket-Sized 6 GHz 1 TS/s ET Scope

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