Products > Test Equipment

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

<< < (25/71) > >>

Fungus:

--- Quote from: rf-loop on November 20, 2020, 07:32:07 am ---This "trigger engine" need include also as perfect fine interpolation as possible between ADC raw samples as possible in real time.

--- End quote ---

Not true. All you need to know is that one sample is below the trigger level and the next sample is above it (for simple rising edge trigger).

You can do all the fine interpolation much later when you go to display the trace on screen.

Which approach is better? That's harder to say.

 

tom66:

--- Quote from: Someone on November 20, 2020, 06:31:41 am ---
--- Quote from: rhb on November 20, 2020, 04:05:39 am ---Certain operations must be done at acquisition sample rate.  Display is rather leisurely at 30-120 fps.
--- End quote ---
Now you're just linking concepts which have almost nothing to do with each other. Offline (CPU or otherwise) processing can be done at any rate, very few things in a digital oscilloscope have to be done at the full throughput of the ADCs, but triggering is one of them and you're both constantly talking away from that point.

--- End quote ---

The trigger is running at the full sample rate (1GSa/s) on this prototype.   Every sample is capable of generating a trigger.

Realignment is not done for every trigger because as stated that can be done once the waveform is captured - based on the difference between the sample and the ideal trigger point.  For instance, if you want to trigger at 8'h7f but you actually got a trigger at 8'h84 then you know it is 5 counts off, so look up in your table for that given timebase for the pixel offset.

This operation only needs to be done at the waveform rate of the scope - e.g. 20k/100k times a second - and is part of the render engine, not the capture engine.

gf:

--- Quote from: Fungus on November 20, 2020, 08:06:13 am ---All you need to know is that one sample is below the trigger level and the next sample is above it (for simple rising edge trigger).

--- End quote ---

Not generally granted, e.g. for signals close to Nyqust. If two adjacent samples are e.g. 0.0 and 0.1 then the analog ADC input signal can still raise up to 1.0 and go down again between the samples, while still not violating the sampling theorem. In this case your algorithm would miss an edge trigger at level 0.5 completely although the original signal does cross this level.

Someone:

--- Quote from: tom66 on November 20, 2020, 08:10:21 am ---
--- Quote from: Someone on November 20, 2020, 06:31:41 am ---
--- Quote from: rhb on November 20, 2020, 04:05:39 am ---Certain operations must be done at acquisition sample rate.  Display is rather leisurely at 30-120 fps.
--- End quote ---
Now you're just linking concepts which have almost nothing to do with each other. Offline (CPU or otherwise) processing can be done at any rate, very few things in a digital oscilloscope have to be done at the full throughput of the ADCs, but triggering is one of them and you're both constantly talking away from that point.

--- End quote ---

The trigger is running at the full sample rate (1GSa/s) on this prototype.   Every sample is capable of generating a trigger.

Realignment is not done for every trigger because as stated that can be done once the waveform is captured - based on the difference between the sample and the ideal trigger point.  For instance, if you want to trigger at 8'h7f but you actually got a trigger at 8'h84 then you know it is 5 counts off, so look up in your table for that given timebase for the pixel offset.

This operation only needs to be done at the waveform rate of the scope - e.g. 20k/100k times a second - and is part of the render engine, not the capture engine.

--- End quote ---
You keep talking about offset in counts, but trigger interpolation is in time. There isn't a lookup because the slope of the signal isn't known a-priori, interpolating the trigger point on the time axis needs at least 2 points (more is preferable) which is already an impractical size for a LUT. Yes it can be done offline (as mentioned by Fungus above), but it still needs access to the raw ADC samples that created the trigger, which are not always what is stored in the acquisition buffer.

And yes, the shift can be applied at render time, which complicates that processing (and how the acquisition filtering further changes alignment) while needing the offset value forwarded with the matching acquisition. Closely related to channel skew adjustment/trimming (which can destroy many of the naive assumptions of memory access patterns in a multichannel scope).

tom66:

--- Quote from: Someone on November 20, 2020, 08:52:15 am ---You keep talking about offset in counts, but trigger interpolation is in time. There isn't a lookup because the slope of the signal isn't known a-priori, interpolating the trigger point on the time axis needs at least 2 points (more is preferable) which is already an impractical size for a LUT. Yes it can be done offline (as mentioned by Fungus above), but it still needs access to the raw ADC samples that created the trigger, which are not always what is stored in the acquisition buffer.
--- End quote ---

Yes, and every raw sample is piped into RAM and stored; nothing about the trigger data is thrown away.  1GSa/s sampling rate and 1GSa/s memory write rate.  The samples that generate the trigger are stored as well as pre- and post- trigger data.  No filtering, no downsampling at this point.

The principle is, if the input filter has the correct response (it needs to roll off before Nyquist so that you avoid the described Nyquist headaches) you can calculate slope from the delta from the presumed trigger point (which is at t=0 - centre of the waveform) and the actual trigger point at t=? ... the actual trigger point will be offset from the point that the oscilloscope triggered at by a fraction of the sample rate (0-1ns).  It will never be more than that fraction because then the next comparator would have generated the trigger instead.    When you are at the described mode where 1ns < 1pixel,  you can ignore this data because the waveform points aren't going to be plotted fractionally on the screen.  This is only needed for sinx/x modes.   You'd need LUTs for different timebases or channel configurations (1-4ch), but this is something that could be generated at 'production time' as part of the calibration process.
   
A more complex trigger engine could use several samples to inform a slope calculation.  Since the Zynq ARM has full visibility of the samples, it's possible to do a calculation like this before each waveform is sent to the interpolator or the rendering engine.  I don't think that would be terribly difficult to do either,  although it would be more complex than what I've suggested it might be less sensitive to noise on the trigger point.

I would say that once you are operating at an input frequency >> than the rating of the scope, you can't rely on the trigger being reliable, just as you can't rely on the amplitude being reliable.  My DS1000Z falls over on Fin > 130MHz, even though the amplitude is stable.

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