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

--- Quote from: joeqsmith on March 03, 2024, 04:10:57 pm ---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.

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


--- Quote from: joeqsmith on March 03, 2024, 04:10:57 pm ---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? 

--- End quote ---
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).
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