Products > Test Equipment
Pocket-Sized 6 GHz 1 TS/s ET Scope
<< < (77/107) > >>
SJL-Instruments:

--- Quote from: joeqsmith on February 27, 2024, 01:34:06 am ---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. 

--- End quote ---
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:

--- Quote ---The factor of 2 discrepancy is likely due to the Nmax setting. Lowering this to match Nmin should give a 46 second sweep.
--- End quote ---

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:

--- Quote from: joeqsmith on February 27, 2024, 02:01:40 am ---
--- Quote ---The factor of 2 discrepancy is likely due to the Nmax setting. Lowering this to match Nmin should give a 46 second sweep.
--- End quote ---

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.   

--- End quote ---
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!   :-DD     

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.   :-DD 
joeqsmith:

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

--- End quote ---

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

--- End quote ---


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. 
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod