Products > Test Equipment
A High-Performance Open Source Oscilloscope: development log & future ideas
<< < (37/71) > >>
nctnico:

--- Quote from: Marco on December 05, 2020, 04:52:58 pm ---
--- Quote from: nctnico on December 05, 2020, 04:38:52 pm ---No, not at this point in the project.

--- End quote ---
For a minimum functional prototype to get some hype going that makes sense, high capture rate digital phosphor is a high end feature. Budgeting some room/memory for it in the FPGA costs very little time though.

--- End quote ---
But it is just one trick you don't really need and it seriously hampers the rest of the functionality. Look at how limited the Keysight oscilloscopes are; basically one trick ponys. If you use a trigger then the chance of capturing a specific event is 100% and you don't need to stare at the screen without blinking your eyes. At this moment time is better spend on getting the trigger system extended so it can trigger on specific features and sequences of a signal.
Marco:
Digital phosphor is more to get a general idea how the circuit is behaving, using it for detecting if a signal goes beyond bounds by eye seems kinda silly. High capture rates are also valuable for fault detection and also benefit from being implemented in the FPGA. The two features are orthogonal ... but for a minimum prototype FPGA implementation for both could be delayed, even if the latter has higher priority.
nctnico:
The point is that you can do 'digital phospor' just fine in software; doing it in FPGA right now just hampers progress of the project and it doesn't add much in terms of usefulness. Look at high end signal analysis oscilloscopes; none of them have high waveform update rates. It is just that Keysight has been hyping this to be a useful feature on their lower end gear while it isn't. Also realise that the highest waveform update rates happens at a very specific time/div setting only. A high update rate has never helped me to solve a problem. Deep memory and versatile trigger methods are much more useful.
tom66:
Well, there's always the option for both.  The present Python application architecture has support for different rendering engines - ArmWave is just the only one presently implemented but FPGAWave would also be an option.  In that case, the user would have an option to select their preference, and the Zynq SoC would select the required data stream and mode for the CSI transfer engine.

Personally one of the benefits I find from high waveform render rates is that jitter and ringing is more clearly understandable - I know how frequent an event is.

Also - the peak wfm/s rate is one measure of performance but the other is how many intensity-graded levels the display achieves.  To achieve at least 256 then you need a minimum of 256*60 = 15.3kwfms/s but you might want to apply gamma correction and use a 10-bit or 12-bit accumulation buffer for digital phosphor to avoid too much stairstepping implying a necessarily higher capture/render rate. More so potentially at higher zoom levels where there is much more than 1 wave point per displayed X column.
Marco:
When you're initiating the capture of a waveform based on stuff happening hundreds/thousands of samples after a simple/protocol trigger, I'm not sure calling it flexible triggering does that justice.

It's high capture rate pass/fail testing. A feature which can really still wait for a minimum viable prototype, just stick to simple triggers for the moment.
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