Products > Test Equipment
A High-Performance Open Source Oscilloscope: development log & future ideas
tom66:
Digital filtering would be post-acquisition using a customisable FIR filter. There would necessarily be a dead zone at the start and end of each trace depending on the number of taps in the filter. So in my example provided before with 200 taps and a 1232 point waveform (presently what is used at 100ns/div) then about half of the waveform is lost to filter tap count. I can't see any feasible way to avoid this - the waveforms are not correlated in time and no data is available outside of their window. The window of data could be increased, but you may as well just go up a timebase if you wanted to do that. But I think it's fair to say that at short timebases you don't generally need long filters, and therefore this will be much less of an issue in the real world.
You are right that averaging may well be considered a subclass of post-acquisition filtering so it doesn't make so much sense to have it as an acquisition mode. Although, it would be possible to do it during acquisition, it would probably complicate the acquisition engine compared to just reading values out into a FIFO and summing them in a filter pipeline (although there would be a lot of reading and writing, so I need to think about how to make this as optimal as possible.)
Also a good point on normal vs ERES, although I think the subtle difference is normal stores 8-bit samples whereas ERES would halve the available sample depth by storing 16-bit samples. The penalty being primarily memory, although there may also be a render speed penalty.
Also, the buffer management supports arbitrary buffer lengths, the only restriction is that they are a multiple of 8 samples for pre and post trigger and the overall buffer must be on a 64 byte boundary (but size is not constrained by this) to fit into cache lines. The records must all be the same size for now, although this is just a programming simplification, there's no strict need for it.
tautech:
Tom, maybe you forget Averaging and ERES are both Math operations and as such are now in the Math menu in SDS5000X.
nctnico:
--- Quote from: tautech on December 18, 2020, 10:11:25 pm ---Tom, maybe you forget Averaging and ERES are both Math operations and as such are now in the Math menu in SDS5000X.
--- End quote ---
Those are Lecroy-isms which are more geared towards signal analysis. On other oscilloscopes averaged / high-res traces replace the channel's trace while retaining the channel's color. There are pros and cons. The pro is that you see the 'original' trace and can have multiple representations of the same signal (in different math channels) the con is that a math trace usually has a different color which does not resemble the original trace and you have a trace on the screen which may not be relevant at all.
tautech:
--- Quote from: nctnico on December 18, 2020, 10:31:24 pm ---
--- Quote from: tautech on December 18, 2020, 10:11:25 pm ---Tom, maybe you forget Averaging and ERES are both Math operations and as such are now in the Math menu in SDS5000X.
--- End quote ---
Those are Lecroy-isms which are more geared towards signal analysis. On other oscilloscopes averaged / high-res traces replace the channel's trace while retaining the channel's color. There are pros and cons. The pro is that you see the 'original' trace and can have multiple representations of the same signal (in different math channels) the con is that a math trace usually has a different color which does not resemble the original trace and you have a trace on the screen which may not be relevant at all.
--- End quote ---
None of which is an issue if you can assign any color to a trace.
tom66:
Averaging and ERES could both be done before or after the fact, but implementing both seems a bit silly and logic-expensive.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version