Products > Test Equipment
A High-Performance Open Source Oscilloscope: development log & future ideas
<< < (26/71) > >>
Zucca:
You guys are too smart for me, it's hard to follow.

Anyway some inputs from my side

1) Avoid anything which has Broadcom or Qualcomm chips = sporadic pain in the ass guaranteed.
2) As much RAM as possible
3) SATA port for proper SSD?

Great work!
nctnico:

--- Quote from: tom66 on November 20, 2020, 09:08:31 am ---
--- 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.

--- End quote ---
I'm afraid this approach is too simplistic. The trigger comparator needs to have threshold levels to filter out noise which also means you need to use multiple points (at least 4 but more is better) to determine the actual trigger point (=where the signal crossed the trigger point). A problem on many digital trigger oscilloscopes (Siglent is a good example) is that the trigger point becomes a focal point in the centre and smears out the edges of a signal.

I think in the end it may turn out that doing the comparator part digitally and the positioning in software (based on seperately stored samples around the trigger point) is necessary.
Someone:

--- Quote from: tom66 on November 20, 2020, 09:08:31 am ---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).
--- End quote ---
This is getting silly, you still can't provide a mathematical example of your proposed method. How can the slope be known a-priori? With an ideal AFE filter, any frequency (slope) less than the cutoff could be occurring around the trigger point.

Even with the trivial example of a perfect sine wave of constant frequency being sampled perfectly (and below Nyquist) shifting it with DC while keeping the trigger threshold static would present different slopes at the trigger point. Just the phasing of the points when the frequency isn't rational with the sampling frequency causes significant shifts and jitter as the waveform approaches the Nyquist rate.
tom66:
I think there's a misunderstanding here as to how this would work,  there's no need to do any 'a-priori' calculation as *everything is done* after we have the *whole waveform captured and stored in RAM*.  We trigger 'roughly' and then correct the trigger point using the data we have around the trigger point.  That latter stage is software, performed well after the samples are gathered, just before any interpolation or rendering/plotting is performed.   I believe it could be done using one or at most two data points to calculate the slope of the signal at that point.  Let me go away and model it and see how wrong I am ... I've only done the calculations on paper so far so I'm prepared to admit I could be wrong here.

The present application does, in fact, support noise filters on the trigger, but the high and low thresholds are calculated beforehand as centred around the ideal trigger point.  Hysteresis can be set to any value within reason (1..max_sample).   So on a rising edge we trigger on the high trigger level,  and only when the signal goes below the low trigger level do we generate a falling edge.  Therefore, we can work out the level based on the type of edge that we intended to trigger on;  again, we don't need to store anything other than the waveform data (and the trigger edge that we used, in case we have a trigger engine that alternates edge types.)   

There isn't currently any bandwidth filtering on the trigger samples (i.e. LF/HF/AC);  I'm not certain of the best way to implement that yet.  They may have an effect on the jitter of the scope trigger, but the bandwidth of those filters tends to be quite low (~50kHz or so) which means trigger jitter of 1ns (uncorrected) should be insignificant in those cases.  I would like to see a scope that had adjustable filtering for the trigger signal (set the -3dB point for the trigger), I've been discussing this with Reg for some time and we have a few ideas on how to go about it even on realtime data.

Don't let perfect be the enemy of good.   If this gets realistic trigger jitter ~100ps or less for a 1ns ADC clock, then I'm prepared to accept it as a perfectly sufficient way to correct when interpolation is performed; the jitter would then be less than 1 pixel visible to the user.

The waveforms I have captured so far show a "visibly" jitter free capture down to 50ns/div without any trigger jitter correction thus far, on a variety of complex waveforms as well as simple sine waves.    ~100ps or less jitter would require the jitter correction to work down to roughly 10x interpolation (5ns/div).  And, the good news is, this is scalable with the sampling rate.  If the ADC is faster, then you can still do up to 10x interpolation without too many headaches.  I'm not too convinced that there is a great deal of benefit in going beyond 10x interpolation (at which point your scope is *really* lying to you about the signal, rather than just misleading you), but if so, there may need to be more thought as the ADC noise could start influencing the trigger slope detection,  which may require an adjusted algorithm.
nctnico:
A few things to look out for:
- the trigger point may be outside the acquisition data so you can't use the acquired data to calculate the trigger point
- it should be possible to trigger on very slow edges as well. Think tens of micro-Volts per second

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