Products > Test Equipment

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

<< < (41/71) > >>

nctnico:
I never said high trigger rates (waveforms/s) are never necessary. Sometimes they are and in that case I simply select a shorter memory length to speed up the acquisition process. However aiming for insanely high waveforms/s quickly lands you in an area where there are diminishing returns. The oscilloscope manufacturers tend to claim a high waveform update rate makes it more likely to catch glitches but in the end they never get to 100% due to blind time (which can be avoided BTW at the cost of ending up with a weirdly drawn signal). However measuring is about 100% certainty so if you want to capture a glitch with 100% percent certainty during a given interval the only way out is deep memory (+analysis) or triggering (combined with infinite persistence and/or saving a screendump).

tom66:
There's no reason you can't take the Rigol approach (likely the same on other instruments as well) and give the user a choice of 'Auto' vs a memory depth selection.

In 'Auto' the scope always optimises for waveform rate which IMO is the good, default optimisation (I think this is what most people expect unless they are using the scope for a special application.) 

If you select say 120k points but are on a short timebase, then the update rate drops appropriately and the available capture exceeds that of the visible window.  In fact, all the timebase control does in this instance, is inform the oscilloscope what 'auto' mode it should use and how many points it should apply.  In essence, there is no actual difference in a capture at 120k points at say 10us/div and one at 50ns/div,  they both capture the same data.   It is just a matter of how it is displayed to the user and the timebase control is more of a horizontal zoom control.

In all modes, if there is free waveform RAM, use that RAM to store a history buffer.  120k points gets 2000 waveforms for instance. 

Zucca:

--- Quote from: nctnico on December 05, 2020, 04:44:57 pm ---Trust me, nobody cares about waveforms per second!

--- End quote ---

+1
If I want high waveforms per second I do not search a device in the Open Source jungle.

2N3055:
I agree that it is not needed to have 1 MWfrms/sec, but in normal interactive mode it should have enough for fluid display. From what was said previously that is already OK.. 20-25 kWfms per second is more than enough for interactive work..

tom66:
Do note the present performance is dot mode only.  Rigol achieve 50 kwfm/s on dot mode on the DS1000Z series,  the headline 25 kwfm/s figure is given in vector mode (a refreshing change that they don't quote the absolute fastest, unrealistic figure!)

I expect vector mode will be a bit slower, it depends on how many vectors need to be drawn.  I've an optimal algorithm in mind but it's limited to 2 pixels/cycle due to the ARM ALU size.  Maybe with NEON I can do more (64-bit add with 4 or 8 terms if using 16 or 8-bit saturating arithmetic) but it would require carefully hand coded assembly.  That's if I decide to further optimise ArmWave which as I've indicated here I'm not certain is the best route yet. 

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