EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: mawyatt on November 07, 2022, 04:32:59 pm
-
For a given set of Bode parameters, say 100Hz to 100KHz, dec sweep with 20pts/dec, dynamic scaling ON, how do the various DSOs compare time-wise?
Our particular interest is with the various Siglent flavors, like the SDS2000+P, SDS2000HD and SDS6000, but also interested in how other brands perform, including firmware level.
This might be a good means to keep tabs on the various firmware updates also, as the OEMs improve things. Know that different algorithms will play into this, some with very good frequency selectivity will require more computational load, thus longer timeframes, so not exactly an ideal comparison and tabulation.
Also know a few don't feel the DSO Bode Plot capability is useful, very likely because they don't have, nor experience, with a DSO with a good Bode Plot implementation, so please refrain from commenting. Our interest is from those that actually use and value this feature, as we've found it quite useful indeed, albeit slow, so we view relative timescales useful information!!
Best,
Edit: Added for SDS2102X+ and SDS2104X+ Parameters: Simple, Single Sweep, Decade, 100-100KHz, 20 pts/dec, Int AWG
AWG output to CH1 with BNC cable, another BNC to BNC cable from CH1 to CH2.
SDS2102X+ HW 02-08 FPGA 2021-07-16 U-OS 5.0 SW 1.3.9R6 Time 1:10
SDS2104X+ HW 02-04 FPGA 2022-04-06 U-OS 5.0 SW 1.5.2R1 Time 1:45
-
Hi,
For the HD I can do it maybe tomorrow, for the X+ next week at work and for the 6000....I´m out... ;D
Then finding rigol mso5000 and keysight users...
Lecroy didn´t have bode, tek ??
GwInstek, Hantek, Micsig, Owon ???
-
RTM3004: 12 seconds
BTW, I also played around a bit with the SMD test fixture to repeat the test with the capacitors (1pf and 1nf), and on the RTM3004 the results show similar accuracy.
-
What did you use as a DUT ?
-
GwInstek, Hantek, Micsig, Owon ???
No FRA on those, AFAIK.
-
SDS2000X HD, software version 1.2.0.2, FPGA version 2022-07-08
Parameters: Simple, Single Sweep, Decade, 100-100KHz, 20 pts/dec, Ext AWG
1k ohm and 100nF low pass filter (note the circuit type will affect how many times the dynamic scaling will have to adjust the vertical scale)
1 min 53 sec.
-
GwInstek, Hantek, Micsig, Owon ???
No FRA on those, AFAIK.
GW Instek has FRA on the models with an internal generator. But not many have those units as GW Instek released the more elaborate models later on.
-
What did you use as a DUT ?
In our case just a pass thru BNC cable and another BNC cable to the AWG output. I'll add to OP.
Best,
-
SDS2000X HD, software version 1.2.0.2, FPGA version 2022-07-08
Parameters: Simple, Single Sweep, Decade, 100-100KHz, 20 pts/dec, Ext AWG
1k ohm and 100nF low pass filter (note the circuit type will affect how many times the dynamic scaling will have to adjust the vertical scale)
1 min 53 sec.
A quick test with Ext AWG by LAN added ~ 5s from using internal AWG, so seems the X+ and XHD are about the same.
-
RTB2004 with FW version 2.400, BNC cables from Aux Out to Ch1 and Ch1 to Ch2. Bode plot for 100Hz to 100KHz, 20pt/dec takes 9s.
-
What accounts for the 2 orders of magnitude time difference to acquire a Bode plot between Siglent and R&S scopes?
-
SDS2504X HD, 1.2.1.1
Parameters: Simple, Single Sweep, Decade, 100-100KHz, 20 pts/dec, Int AWG
AWG output to CH1 with BNC cable, another BNC to BNC cable from CH1 to CH2.
Done the settings, let it run...
And then checking it three times because:
3:35min.... ;)
-
Pics:
Setting, final measure.
Interesting:
10Hz-100Hz : 2:03min
100Hz- 1Khz : 1:04min
1Khz-100Khz : 28sec.
EDIT:
Didn´t start from 100Hz like mawyatt mentioned.
Here the time from 100Hz- 100Khz, new measured:
1:45min
-
What accounts for the 2 orders of magnitude time difference to acquire a Bode plot between Siglent and R&S scopes?
See this other Bode related thread just started, my have some clues to the large time discrepancy between various Bode Implementations.
https://www.eevblog.com/forum/testgear/bode-plot-torture-test/ (https://www.eevblog.com/forum/testgear/bode-plot-torture-test/)
Best,
-
Hello,
PicoScope 5444A with FRA 4PicoScope 0.7.3b 100Hz-100kHz 20 steps/dec -> ~5sec
with best regards
Andreas
-
First of all I really don´t have a problem with it, but....
It´s remarkable how short others can perform it while the siglents take their time....
In this case minutes against seconds...
On the siglent you got the feeling, they´re switching completely in a different mode, the whole scope becomes a FRA.. - When bode menu is only activated (not starting), you can´t do anything else on the scope until you leave the bode mode.
And leaving the bode mode takes also time....
Won´t believe it´s somekind of performance lack.
-
It´s remarkable how short others can perform it while the siglents take their time....
In this case minutes against seconds...
On the siglent you got the feeling, they´re switching completely in a different mode, the whole scope becomes a FRA.. - When bode menu is only activated (not starting), you can´t do anything else on the scope until you leave the bode mode.
And leaving the bode mode takes also time....
Won´t believe it´s somekind of performance lack.
The widely variable time is somewhat related to performance and the design tradeoffs that the manufacturer has chosen:
https://www.eevblog.com/forum/testgear/faster-fra-from-scope-by-external-control-over-visa/ (https://www.eevblog.com/forum/testgear/faster-fra-from-scope-by-external-control-over-visa/)
As an example for this thread, that Keysight DSOX1102G takes 42 seconds for the above requested 100-100k, 20pts/decade measurement. But 4 seconds of that is the autoscaling of the input attenuators. Swap to a script running on a (slow) computer and you can have a similar quality answer in 14 seconds, but now with the user being able to choose how much averaging to apply at each frequency step.
Want to go faster? A chirp excitation should be able to do this in a few seconds.
-
What accounts for the 2 orders of magnitude time difference to acquire a Bode plot between Siglent and R&S scopes?
Taking 5 averages at every frequency.
Biggest impact is at low frequencies. It takes time to gather enough samples of a signal that has period of 10 ms.
Benefit is that it works with noisy signal (like switchers) and gets few dB better dynamic range..
MSOX3104T did it in 35sec with simple DUT (few resistors and capacitors). It would have been a bit slower if DUT was exercising autoranging.
But it gave up when pushed to small signals.....
Siglent's implementation at this moment doesn't win speed competition. But is very accurate, has best dynamic range, has capability to do multichannel Bode plot (one input and 3 outputs in 4 ch scope) has automatic measurements, best frequency range, works with outside AWG (interesting things can be done there with large signal and channel locking) and has very good accuracy...
-
It´s remarkable how short others can perform it while the siglents take their time....
There is always a trade-off between measurement duration and dynamic range (noise floor).
Comparing the duration is IMO rather meaningless if the achieved dynamic range is not compared as well.
On the other hand, if the dynamic range of the DUT happens to be much lower in the frequency span of interest, then aiming for a too large dynamic range can result in wasted time.
-
It´s remarkable how short others can perform it while the siglents take their time....
There is always a trade-off between measurement duration and dynamic range (noise floor).
Comparing the duration is IMO rather meaningless if the achieved dynamic range is not compared as well.
On the other hand, if the dynamic range of the DUT happens to be much lower in the frequency span of interest, then aiming for a too large dynamic range can result in wasted time.
I agree. I have the feeling the engineers at Siglent geeked out on getting the lowest noise floor while losing sight of what is also important: speed.
-
I agree. I have the feeling the engineers at Siglent geeked out on getting the lowest noise floor while losing sight of what is also important: speed.
Speed? Is it a race or an exercise in getting good results?
-
I agree. I have the feeling the engineers at Siglent geeked out on getting the lowest noise floor while losing sight of what is also important: speed.
Speed? Is it a race or an exercise in getting good results?
Well, if you look in the other thread Mawyatt has created, you'll see that the same results can be obtained in a matter of seconds. There really is no need to go slow. When I'm tweaking a circuit, I don't want to wait for over a minute to see the results of the changes. Heck, you can simulate a circuit faster nowadays. IOW: There is a tradeoff between getting the lowest noise floor and making a feature that is useable. In most cases you'll be working in situations where there is more than enough headroom.
-
I agree. I have the feeling the engineers at Siglent geeked out on getting the lowest noise floor while losing sight of what is also important: speed.
Speed? Is it a race or an exercise in getting good results?
Well, if you look in the other thread Mawyatt has created, you'll see that the same results can be obtained in a matter of seconds. There really is no need to go slow. When I'm tweaking a circuit, I don't want to wait for over a minute to see the results of the changes. Heck, you can simulate a circuit faster nowadays.
Well, referring to random other thread isn't really helping when you put it out of context like that (that thread doesn't mention the elapsed time of the test). Just to ruin it further I'm not sure your LARGE (in size) contributions to that thread were actually comparable to what mawyatt provided as their example:
https://www.eevblog.com/forum/testgear/bode-plot-torture-test/ (https://www.eevblog.com/forum/testgear/bode-plot-torture-test/)
Fast = short time captures and less noise rejection, cant get around that when keeping other conditions the same.
-
I guess you missed the fact that the RTM3004 offers at least the same results in the same noise / disturbance conditions while needing about 10 times less time. It is not my fault mawyatt created two threads to discuss closely related topics.
-
I guess you missed the fact that the RTM3004 offers at least the same results in the same noise / disturbance conditions while needing about 10 times less time. It is not my fault mawyatt created two threads to discuss closely related topics.
Lol, it cant get the same results that much faster. There isn't enough time capture the data that would suppress the interference. I'm guessing your configuration was not comparable to the original post... in that other thread where you could be discussing this rather than trying to blame others for your inability to maintain context. :clap:
-
When at 100Hz, one period is 10ms. You need many of those for calculations.. 60 points in 9 seconds from 100Hz to 100kHz, not very likely..
-
When I'm tweaking a circuit, I don't want to wait for over a minute to see the results of the changes.
Fair enough.
I imagine though that if you're tweaking a circuit you could limit the sweep to around the area of concern. Back in the stone age, that's how we did it, especially since it was usually done with pen and paper.
Still, it would behoove Siglent to let the user select the number of averaging readings. I wonder how difficult that would be?
-
When at 100Hz, one period is 10ms. You need many of those for calculations..
True, but at 10KHz one period is 100us so that last decade goes pretty quick compared to the first one .. 100 times faster .. theoretically.
So, if the first decade took 8s, then the following 2 decades would easily be done in the next 1s.
-
When at 100Hz, one period is 10ms. You need many of those for calculations.. 60 points in 9 seconds from 100Hz to 100kHz, not very likely..
A real network analyser does the same sweep in less than a second.
The same network as used in the 'torture test' thread measured using an Anritsu MS4630B:
(https://www.eevblog.com/forum/testgear/bode-plot-computational-time-for-various-dsos/?action=dlattach;attach=1634464;image)
-
When at 100Hz, one period is 10ms. You need many of those for calculations..
True, but at 10KHz one period is 100us so that last decade goes pretty quick compared to the first one .. 100 times faster .. theoretically.
Nctnico is simultaneously claiming fast capture and good noise rejection (pointing to the other thread) which is inherently impossible. As you say it would be nice to have a richer UI for the user so they can select the trade-offs for their particular application, but this is a minor feature with few real practical uses so it hasn't seen that much investment.
Which is why I keep pointing back to the obvious answer, if you want more control just script/code it to suit your situation. Instrument automation is easy and accessible these days. But I'm sure we'll see yet another endless blah blah blah from people wanting to promote XXX brand and say YYY brand is no good by picking their favourite corner case uses, rather than any real progress in helping people do things better.
-
from people wanting to promote XXX brand and say YYY brand is no good by picking their favourite corner case
Of course!
BTW, the best brand is the one I have.
-
When at 100Hz, one period is 10ms. You need many of those for calculations.. 60 points in 9 seconds from 100Hz to 100kHz, not very likely..
61 points log spaced from 100Hz to 100kHz would need just under 100ms to capture a single cycle of each, of course with zero noise suppression. Compare to a chirp that could squeeze a flat (or shaped) 100-100k Hz spectrum into a single 10ms period, less energy so even more noise sensitive.
This thread is not contributing much as the runtime of the measurement is presented without knowing how much of that time was actually spent capturing data, not comparable at all. Back to the numbers I do know, getting the measurements (not the raw data) to plot this sort of thing under the conditions here:
https://www.eevblog.com/forum/testgear/faster-fra-from-scope-by-external-control-over-visa/ (https://www.eevblog.com/forum/testgear/faster-fra-from-scope-by-external-control-over-visa/)
The actual data captured was less than 1% of the total time spent from pressing start to seeing the result, you can increase the averaging/noise rejection amount and barely affect the total run time. Offloading data captures for FFT or other frequency selective filtering can become more time efficient, entirely dependent on the specific measurement conditions/noise present. But to get those sorts of numbers people need to reverse engineer exactly what these onboard bode/FRA measurement tools are doing.
-
When at 100Hz, one period is 10ms. You need many of those for calculations.. 60 points in 9 seconds from 100Hz to 100kHz, not very likely..
A real network analyser does the same sweep in less than a second.
The same network as used in the 'torture test' thread measured using an Anritsu MS4630B:
Gee, how much more confusion and distraction do you want to add to this thread? That's a sweep with 21 points (not 61 as compared to the other examples) and a RBW of 30Hz, how long was the actual capture? and sweep time? since they arent shown on the plot or mentioned by you. Log sweep? non-constant RBW? plenty of tricks to pull to make your one sided and misleading claims.
-
61 points log spaced from 100Hz to 100kHz would need just under 100ms to capture a single cycle of each, of course with zero noise suppression.
Not with zero noise suppression. At 2GSa/s the processing gain at 100Hz can be up to 70dB, and at 100kHz up to 40dB, if one cycle is captured.
-
61 points log spaced from 100Hz to 100kHz would need just under 100ms to capture a single cycle of each, of course with zero noise suppression.
Not with zero noise suppression. At 2GSa/s the processing gain at 100Hz can be up to 70dB, and at 100kHz up to 40dB, if one cycle is captured.
in-band noise suppression is guaranteed to be zero for a single cycle capture. Yet some scopes are using nothing more than the cursor measurements, so even out of band suppression can be zero for a single capture! GSa/s have nothing to do with it, any frequency selective suppression is relative to the steepness of the filter + settling (and therefore total period of capture).
It is an absolute constraint, more filtering and noise rejection requires more periods captured (one way or another).
-
GSa/s have nothing to do with it, any frequency selective suppression is relative to the steepness of the filter + settling (and therefore total period of capture).
It is an absolute constraint, more filtering and noise rejection requires more periods captured (one way or another).
Signal: 1kHz sine wave with peak amplutide = 1, polluted with Gausian noise with standard deviation = 0.0039763 (SNR = 45dBc)
Measurement interval/window: 10ms
1) signal sampled at 100kSa/s -> 1000 samples, detector ENBW=100Hz
2) signal sampled at 10MSa/s -> 100000 samples, detector ENBW=100Hz
If you look at the attached images, the noise floor of (1) is already lower than 45dBc, and the noise floor of (2) is clearly even lower.
Note that the filter shape and bandwidth is the same for (1) and (2), and the total measurement interval is the same, too.
How do you come to the conclusion that sample rate would not matter for noise floor reduction if the filter and the measurement interval are the same?
[ What really matters is the number of samples, and at a higher sample rate a larger number of samples fit into the same measurement interval. ]
EDIT:
"Settling" is a good point. After presenting a new stimulus frequency to the DUT it is of course necessary to wait until the DUT has settled to s stationary state, before the measurement interval can begin. Hard to predict the required settling time in advance if the DUT is unknown. The implied filter of a DFT-based detector does not need additional settling time, but only a window of N samples need to be captured and processed once the DUT has settled. If an explicit filter (FIR or IIR) in front of the detector were used, it will require some additional settling time.
-
GSa/s have nothing to do with it, any frequency selective suppression is relative to the steepness of the filter + settling (and therefore total period of capture).
It is an absolute constraint, more filtering and noise rejection requires more periods captured (one way or another).
Signal: 1kHz sine wave with peak amplutide = 1, polluted with Gausian noise with standard deviation = 0.0039763 (SNR = 45dBc)
Measurement interval/window: 10ms
1) signal sampled at 100kSa/s -> 1000 samples, detector ENBW=100Hz
2) signal sampled at 10MSa/s -> 100000 samples, detector ENBW=100Hz
If you look at the attached images, the noise floor of (1) is already lower than 45dBc, and the noise floor of (2) is clearly even lower.
Note that the filter shape and bandwidth is the same for (1) and (2), and the total measurement interval is the same, too.
How do you come to the conclusion that sample rate would not matter for noise floor reduction if the filter and the measurement interval are the same?
Now repeat the same with some aggressor signal that is contained in a small bandwidth (extreme case an adjacent sine), adding more sample points does not improve the attenuation of signals the same distance apart, that attenuation is set by the FFT + window function.
You are applying synthetic signals with varying bandwidth. Although the gaussian noise has constant energy, that energy is spread over a wider bandwidth as you increase the number of samples. A purely mathematical/simulation effect that is not matched with real systems as are being discussed here. So it is not the FFT length that is making that difference, but the different noise you added to the signal.
If you could make a steeper filter by interpolating more points in-between you could make an infinitely steep FIR in a finite length (obviously impossible).
-
You are applying synthetic signals with varying bandwidth. Although the gaussian noise has constant energy, that energy is spread over a wider bandwidth as you increase the number of samples. A purely mathematical/simulation effect that is not matched with real systems as are being discussed here. So it is not the FFT length that is making that difference, but the different noise you added to the signal.
Sure, what happens at the end is: When the analog wideband noise is sampled, then all noise frequencies beyond Nyquist are folded into the 0...Nyquist range. And Nyquist is of course higher when the sample rate is higher, therefore a higher sample rate distributes the sampled noise over a larger bandwidth, resulting in a lower power density per Hz. Consequently a bandpass filter with a given ENBW extracts less noise power from the high-sample-rate signal than from the low-sample-rate signal. Still the higher sample rate helps to push down the random noise floor w/o increasing the measurement time.
I don't agree that random noise is of no practical importance. Of course it won't be perfectly white, but It is certainly a nasty issue in practice, too, which needs to be addressed if we don't want that a measured high dynamic range transfer function of a DUT gets buried in the noise floor. OTOH, a small amount of dithering noise is even useful if we want to sqeeze out more than 50dB dynamic range from an 8-bit ADC (improves SFDR, INL,...).
Now repeat the same with some aggressor signal that is contained in a small bandwidth (extreme case an adjacent sine), adding more sample points does not improve the attenuation of signals the same distance apart, that attenuation is set by the FFT + window function.
If you could make a steeper filter by interpolating more points in-between you could make an infinitely steep FIR in a finite length (obviously impossible).
When you initially wrote "with zero noise suppression", I did intpret it it as random (wideband) noise, and not as arbitrary "agressor signal".
I fully agree that a narrower filter bandwidth requires a longer measurement interval. And if a filter with a better selectivity than the (rather lousy) sinc response of a rectangular window is desired, then a longer measurement interval is required as well.
[ However, if only harmonics of the stimulus need to be eliminated, and if a frequency plan can be arranged, such that the window size is an exact integral multiple of the stimulus period, then a rectangular window is still fine (transfer function has zeros at all harmonics), and it has the lowest ENBW among all window functions for a given window size (measurement interval). ]
-
OTOH, a small amount of dithering noise is even useful if we want to sqeeze out more than 50dB dynamic range from an 8-bit ADC (improves SFDR, INL,...).
Yes, often used to get a little more out of the lower bits in many ADCs!!
[ However, if only harmonics of the stimulus need to be eliminated, and if a frequency plan can be arranged, such that the window size is an exact integral multiple of the stimulus period, then a rectangular window is still fine (transfer function has zeros at all harmonics), and it has the lowest ENBW among all window functions for a given window size (measurement interval). ]
Often utilized to reduce/eliminate Mains signal corruption in low speed SD ADCs.
Best,
-
You are applying synthetic signals with varying bandwidth. Although the gaussian noise has constant energy, that energy is spread over a wider bandwidth as you increase the number of samples. A purely mathematical/simulation effect that is not matched with real systems as are being discussed here. So it is not the FFT length that is making that difference, but the different noise you added to the signal.
Sure, what happens at the end is: When the analog wideband noise is sampled, then all noise frequencies beyond Nyquist are folded into the 0...Nyquist range. And Nyquist is of course higher when the sample rate is higher, therefore a higher sample rate distributes the sampled noise over a larger bandwidth, resulting in a lower power density per Hz. Consequently a bandpass filter with a given ENBW extracts less noise power from the high-sample-rate signal than from the low-sample-rate signal. Still the higher sample rate helps to push down the random noise floor w/o increasing the measurement time.
Change the sample rate setting of a scope under these conditions, not in some simulation of perfect signals. The std-deviation of the noise is not a constant. Practical real world scopes include anti-aliasing filters ahead of the sampling, at lower sample rates (bandwidths) the measured broadband noise reduces as the bandwidth has been reduced.
Simplified Simulation /= Real World
The statement is still very true, I can keep rewording it: the only way to increase the attenuation of a noise component is to capture more periods, adding more samples (that have been captured with an antialias filter) does not improve the attenuation of any given signal.
You have only shown that a signal with noise energy spread across more bandwidth has less noise energy within a specific bandwidth. The FFT shows that, but the changed parameters of the FFT did not cause that.
-
Practical real world scopes include anti-aliasing filters ahead of the sampling
Do they? My RTB2004 happily aliases whatever I throw at it while my MSOX3024A appears to do some kind of sample rate dithering unless you turn on FFT in which case it happily aliases whatever I throw at it. Not trying to prove a point, just genuinely curious whether other scopes are anti-aliasing by default.
-
Practical real world scopes include anti-aliasing filters ahead of the sampling
Do they? My RTB2004 happily aliases whatever I throw at it while my MSOX3024A appears to do some kind of sample rate dithering unless you turn on FFT in which case it happily aliases whatever I throw at it. Not trying to prove a point, just genuinely curious whether other scopes are anti-aliasing by default.
They don't. None of the mainstream oscilloscopes I have seen (and I have had a lot of different models through my hands) adjust the anti-aliasing filter depending on the samplerate. The anti-aliasing filter is part of the analog front-end and consists of components soldered to the board. So what gf wrote is right: any signal & noise components beyond fs/s (nyquist) are folded / aliased back to frequencies between 0 and fs/2.
Now some oscilloscopes are sold with the same hardware for different bandwidth models and use an adjustable filter to set the bandwidth according to what it says on the badge but again, the bandwidth is not adjusted when the samplerate is lower. It is entirely up to the user to set the oscilloscope's bandwidth limit to what is appropriate for the measurement at hand.
Besides that, for maximum effect of getting extra bits from an ADC you'll need enough Gaussian noise to make it work. On the Tektronix TDS700 series high-res will actually works worse when the 20MHz bandwidth limit is turned on.
-
Practical real world scopes include anti-aliasing filters ahead of the sampling
Do they? My RTB2004 happily aliases whatever I throw at it while my MSOX3024A appears to do some kind of sample rate dithering unless you turn on FFT in which case it happily aliases whatever I throw at it. Not trying to prove a point, just genuinely curious whether other scopes are anti-aliasing by default.
Apparently our SDS2104X+ doesn't either!! It's easy to get under-sampled aliased artifacts just viewing a single channel without any additional "Signal Processing" taking place, or other channels active!!
Best,
-
Practical real world scopes include anti-aliasing filters ahead of the sampling
Do they? My RTB2004 happily aliases whatever I throw at it while my MSOX3024A appears to do some kind of sample rate dithering unless you turn on FFT in which case it happily aliases whatever I throw at it. Not trying to prove a point, just genuinely curious whether other scopes are anti-aliasing by default.
Sure, you can find ways to cause aliasing, how about the ways to not do that? Do the high-resolution modes suppress that out of band noise?
Taking measurements from the display (as the Keysight does) continues to capture the amplitude of the original signal even when undersampled, that's using random decimation to make the display look nice (no visible aliasing). Upsides and downsides. If you're trying to reduce the number of samples offloaded from the scope for measurement, that's really not the mode to use.
-
Haw fast? Challenge accepted.
A single chirp should be plenty! ;D
This is the first I want to try:
- sample the DUT output
- get a 90* phase shifted DUT signal (here approximated by a delay looking at the 1/4 of the wavelength behind)
- that would be as if it were a quadrature sin and cos of the measured signal
- square each one and sum them together to get instantaneous
- because sin2x + cos2x = 1 at any x, we get a DC voltage representing the frequency response
- square each ADC sample, then square the ADC sample from 1/4 wavelength behind, then add the two results, and that will give the A2 as a DC along the chirp frequency sweep
- can be computed on-the-fly, sample by sample while reading from the ADC :D
These are LTspice simulation of an RC and an RLC implementing my method above:
(https://www.eevblog.com/forum/programming/extract-precise-amplitude-and-phase-from-a-frequency-sweep-(vna-from-dsoawg)/?action=dlattach;attach=1635689;image)
(https://www.eevblog.com/forum/programming/extract-precise-amplitude-and-phase-from-a-frequency-sweep-(vna-from-dsoawg)/?action=dlattach;attach=1635695;image)
Not the final method, only a simulation I happen to post in https://www.eevblog.com/forum/programming/extract-precise-amplitude-and-phase-from-a-frequency-sweep-(vna-from-dsoawg)/ (https://www.eevblog.com/forum/programming/extract-precise-amplitude-and-phase-from-a-frequency-sweep-(vna-from-dsoawg)/)
So far the idea is work in progress, the speed was not addressed yet. It feels like it should be possible to do all in a single chirp of a continuous frequency sweep. In terms of speed, this would mean less than a second for the audio range, and for RF chirps it would be faster than the refresh rate of the display. ;D
-
I´m playing with the thought to do the test which I did before not only with my scope, but also with my Neutrik A1 analyzer and with my PC plus Scarlet audio interface.
Not for checking the time but for the results in general.
Only limitation was that the neutrik won´t go up to 100Khz.
-
Haw fast? Challenge accepted.
A single chirp should be plenty! ;D
This is the first I want to try:
[...]
Note that RG and the DUT's input impedance form a voltage divider, so it is not granted that the voltage at the DUT input is the same as the voltage generated by your VCO.
What do you mean with "get a 90* phase shifted DUT signal (here approximated by a delay looking at the 1/4 of the wavelength behind)"? 1/4 wavelength behind what? And which wavelength? How would you get a 90° phase shifted signal without a proper Hilbert filter?
At each point in time, you need to determine not only instantaneous amplitude, but also instantaneous frequency, in order to draw a Bode Plot. Note that the DUT's group delay can be frequency-dependent. If the chirp at the DUT input is linear, i.e. f(t)=f_start+k*t, then don't expect the same linear relation at the DUT output. You can't determine the instantaneous frequency any more alone from the point in time. The total duration of the response can also be longer than the duration of the chirp stimulus.
Since the transfer function is a function of frequency (not time), why not do it purely in the frequency domain, i.e. capture DUT input and DUT response to the complete chirp simultaneously, FFT both, and divide the two complex spectra to obtain the transfer function?
You can taper the chirp with a tukey window in order to reduce the ringing in the chirp spectrum and make it flatter, as explained in the 1st answer here (https://dsp.stackexchange.com/questions/66541/how-can-i-plot-the-frequency-response-on-a-bode-diagram-with-fast-fourier-transf).
-
What do you mean with "get a 90* phase shifted DUT signal (here approximated by a delay looking at the 1/4 of the wavelength behind)"? 1/4 wavelength behind what? And which wavelength? How would you get a 90° phase shifted signal without a proper Hilbert filter?
- 1/4 wavelength behind the moment of the current ADC sample, in time domain
- the wavelength can be deduced because the start moment of a chirp is known (the oscilloscope is triggered by the generator's "start of a new sweep" signal), and the variation (lin or log) of the chirp is also known, so the expected instantaneous frequency can be deduced
- it's not a proper 90° shifted signal, only an approximation of it
Now I see this topic is about the performance of existing instruments, and not about finding a faster way. Sorry for my offtopic here. I don't want to hijack this thread, but will be glad to talk more about pitfalls or new methods in the other thread, where I was trying to figure out a better way: https://www.eevblog.com/forum/programming/extract-precise-amplitude-and-phase-from-a-frequency-sweep-(vna-from-dsoawg)/msg4514039/#msg4514039 (https://www.eevblog.com/forum/programming/extract-precise-amplitude-and-phase-from-a-frequency-sweep-(vna-from-dsoawg)/msg4514039/#msg4514039)
-
Read this first, it is about doing bode plots with FFT:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-12bit-(published-for-chinese-domestic-market-only)/msg4489057/#msg4489057 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-12bit-(published-for-chinese-domestic-market-only)/msg4489057/#msg4489057)
So I spent some time rewriting this in Rust instead of Python, decreased the sample points (20M -> 2M), and saw the execution time drop from 30 seconds to 1.844 seconds for single data capture and bode plotting. The Rust program uses multithreading and SIMD acceleration.
https://github.com/TopQuark12/siglentRust/tree/bode (https://github.com/TopQuark12/siglentRust/tree/bode)
With this bump in speed, I can now do averages to reduce the bode plot trace noise, with 10 averages + plotting taking 13.558 seconds. I've attached the resulting graphs.
-
Read this first, it is about doing bode plots with FFT:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-12bit-(published-for-chinese-domestic-market-only)/msg4489057/#msg4489057 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-12bit-(published-for-chinese-domestic-market-only)/msg4489057/#msg4489057)
So I spent some time rewriting this in Rust instead of Python, decreased the sample points (20M -> 2M), and saw the execution time drop from 30 seconds to 1.844 seconds for single data capture and bode plotting. The Rust program uses multithreading and SIMD acceleration.
https://github.com/TopQuark12/siglentRust/tree/bode (https://github.com/TopQuark12/siglentRust/tree/bode)
With this bump in speed, I can now do averages to reduce the bode plot trace noise, with 10 averages + plotting taking 13.558 seconds. I've attached the resulting graphs.
What dynamic range you have here? I said many times, there are many ways to do FRA, but they have their own problems. Single frequency sweep is for a reason. It allows variable stimulus and amplification for every single frequency.
What happens to a switcher when you insert broadband noise in it's feedback loop?
Also is this a Bode plot on a scope? How is that connected to the topic? Please don't dilute the thread.
Rogeorge has a topic where they discuss making a software FRA separate from the scope in different variants.
There your post would be very much appreciated and on topic.