Products > Test Equipment

A High-Performance Open Source Oscilloscope: development log & future ideas

<< < (43/71) > >>

Marco:

--- Quote from: tom66 on December 08, 2020, 08:44:11 pm ---Testing every sample against a reference signal is still fairly expensive.

--- End quote ---
Instead of linearly storing a byte per sample, you need to also retrieve two for the upper and lower bounds and do two comparisons. it's fairly expensive, but not unreasonably expensive like it gets for digital phosphor.

tom66:
What would the upper and lower bounds here be?  Surely the lower bound is always going to be zero?  You could store the peak min/max value for each horizontal pixel in the post-processing stage, but I'm not sure what value this would have?

Marco:
They are part of the mask for a reference signal for pass/fail testing. The mask will be computed based on an area around the current sample, so you can't really determine that on the fly just from the reference signal, so you need the two values per sample to compare against.

rhb:
I have proposed computing statistics so as to be able to trigger on "trace outside x.x sigma bound" and even histograms. This is not a "start of sweep" trigger, but a data event trigger.  I've given careful thought to the resource requirements and it seems quite tractable to me for an Ultrascale implementation.

It's important to distinguish between things which must be done in real time and which simply need to appear to be done in real time.  Most of what a DSO does does not need to be done in hard real time.  A screen refresh delay is of no concern.  Trigger point alignment, AFE correction, anti-alias filtering, downsampling and a few other things must be done in hard real time, but once the data are in the format needed for the selected data view, the time constraints become quite relaxed.

I have the view that a DSO should do everything it is possible to do with the resources available.

My primary concern now is the AFE input filter.  It should be a high order Bessel-Thomson filter to provide accurate waveform shape.  I've got every reference I can find, but unfortunately, the maximally flat phase gets skimpy treatment and I've still not figured out how to analyze and design one from first principles.  I can do a design by hand or with software, but I can't write the derivation on a whiteboard.  More work required.
I'd very much like to see threads discussing how to time synchronize waveforms, implement advanced triggers, do signal processing operations e.g. FFT, etc.

I keep reading a lot of "you can't do this", "you have to do that", but precious little, "this is how you implement that". It would be nice to have more of the latter and less of the former.

Have Fun!
Reg

tom66:
Indeed.  That was the key realisation for this project, that most of the work can be done 'after the fact',  once  you have captured the data.  Provided you have a sufficiently large buffer and data rate between your capture engine and display engine you can do quite a lot with non-realtime processors.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod