You see this trace, and I will save it as CSV screen data. What I should get? I get all 4 channels and 1200 points.
When I change only the data source to memory, I get 15 points, ONLY channel 1 (when ch3 is active)
looks like a bug. I shut off other 3 channels and saved memory (now 60pts), and the wave represents.
In general, manual says that Sinc is "optional" and in the menu there is clear option Sinc=OFF. So it is fair assumption that it should be OFF, not replaced by god knows what.Says who?
Maybe it works like that $12,000 keysight 'scope I mentioned earlier:
How is that done, Fungus?
So are you saying that expecting that OFF is OFF is unfair assumption
As for "screen sampling", even Rigol itself has moved on:
looks like a bug. I shut off other 3 channels and saved memory (now 60pts), and the wave represents.
When you shut off 3 channels the 'scope will force sin(x)/x on and it will have more samples/MHz.
For this sort of work you should always try to maximize the sample rate, on a Rigol DS1054Z that might mean using one channel.
How is that done, Fungus?
There are many tools available to download the raw internal memory waveform data from the scope
to your pc.
The one I use is DSRemote. It saves the data in EDF format which can be opened in Octave, Scilab,
Matlab and EDFbrowser for further analysis.
Never use csv format.
There are many tools available to download the raw internal memory waveform data from the scope
to your pc.
The one I use is DSRemote. It saves the data in EDF format which can be opened in Octave, Scilab,
Matlab and EDFbrowser for further analysis.Perhaps we are working in the field or on antenna towers and having PC interface is difficult.
The values in the BYTE format map directly to vertical screen pixels so I believe these numbers are the raw sample data from deep inside the 'scope. These numbers are as accurate as it gets.
Why are these numbers subtly different from the .csv numbers?
Did you check for Sinc=ON|OFF @250MSa/s? Does raw data amplitude stay same or still changes like on screen? Of course you would need feed in 100MHz or so.
Does the trigger circuitry do sin(x)/x.
Does the trigger circuitry do sin(x)/x.
It makes sense to do heavy pre-conditioning of the signal before trigger process, otherwise it would be indeed a complete mess. rig(x)/x => [trigger =>] sin(x)/x. So if there are two passes of heavy conditioning it explains why response becomes so aggressive at low sample counts.
One question that springs to mind while doing this is:
Does the trigger circuitry do sin(x)/x.
If it doesn't do it then there'd be a lot of horizontal jitter at these extremes - the trigger crossing would happen at different times depending on where the ADC happened to sample the wave.
But there isn't. The trigger is perfectly stable no matter what the settings, even with all channels on and close to 2.5 samples per wave.
What's going on there?
Does the trigger circuitry do sin(x)/x.
It makes sense to do heavy pre-conditioning of the signal before trigger process, otherwise it would be indeed a complete mess. rig(x)/x => [trigger =>] sin(x)/x. So if there are two passes of heavy conditioning it explains why response becomes so aggressive at low sample counts.
I have not seen problems in Rigol1kZ digital trigger engine fine interpolation system between true sample points for positioning waveform if also think its own performance and price category in this question.
Frequency response is another key consideration in your selection criteria. Sampling oscilloscopes do not use digital signal processing (DSP) correction, so the frequency response rolls off slowly and looks more Gaussian in shape. Real-time oscilloscopes can implement DSP to correct their frequency response. For instance, Keysight’s S-Series oscilloscope has a very flat frequency response across its bandwidth, which means its gain will not vary by more than 1 dB across the entire band.
Post-correction of A/D Converters
Error correction of ADCs has received increasing attention during the
last two decades. Several methods have been proposed and evaluated
during this time, e.g., [HSP00, LASH02a, IHK91, Mou89, TL97, Hum02,
RI87, Iro86]. These methods have in common that the ADC to be corrected
is treated as a closed entity, i.e., internal signals and states of the
ADC are not available, and the calibration and correction methods must
operate outside of the converter. Moreover, the correction is dependent
on the output signal x(n) of the ADC to be corrected. That is, the
correction is an operation incorporated after the ADC, hence the name
post-correction.
In this chapter we will first review some of the ADC post-correction
methods that have been proposed in the past. This will then lead to the
introduction of a generalized post-correction method.
We are mainly concerned with look-up table correction methods.
These are, as the name suggests, methods that produce a corrected ADC
output value through the use of a look-up table (or possibly several tables
– see Chapter 5 for a scheme incorporating two look-up tables),
where pre-calculated values are stored. A distinction between static and
dynamic correction is made. If the correction for a sample x(n) is a function
only of the value x(n), i.e., not depending on past or future samples,
signal derivatives, signal frequency, etc., then the correction is said to be
static. Else, it is said to be dynamic.
Fungus just reported that sample points downloadable from memory correlate with Sinc=ON|OFF in GUI. So they cannot be true "analog" sample points in principle.
can only conclude that substantial pre-processing by whatever means is taking place before trigger (which is digital AFAIK).
Fungus just reported that sample points downloadable from memory correlate with Sinc=ON|OFF in GUI. So they cannot be true "analog" sample points in principle.
That doesn't mean they aren't "true analog sample points" in ADC memory, only that we haven't found a way to access an unprocessed version of them.can only conclude that substantial pre-processing by whatever means is taking place before trigger (which is digital AFAIK).
Nope, completely wrong
Trigger units work in parallel with the ADC to generate a horizontal timing offset for aligning waveforms on screen. That's it.
It's easy to demonstrate, here's a pulse in dot mode:
Here's another capture of the pulse. Notice that the dots aren't in the same horizontal positions - they've been offset in that axis using timing information from the trigger unit:
Finally, here's a whole bunch of them, overlaid. There's captures at many different times but they all line up and overlay beautifully, no horizontal difference between each wave:
If the signal was being reconstructed for display (as you claim) then there would always be a dot exactly on the horizontal trigger position and the third image (dots at every possible horizontal position) would be impossible.
And now, turn off Sinc and this Gibbs phenomenon disappear (because it is not in real input signal and produced by Sinc interpolation. And in these cases Sinc do not reconstruct true input signal right (even in theory it can not, rules are included in theory) . (Gibbs "ear" is not error, it is Sinc interpolation normal "feature" specially if input signal violate rules))
I think we might finally be getting to the bottom of the Rigol "sinc" mystery (and why there's no truly "raw" data available).