Bode plot for scope owners that don't have the option

[mawyatt]

Where are CH1 and CH2 connected? CH1 to the inverting input and CH2 to the output of the opamp?

One thing puzzles me: if CH1 is the input and CH2 is the output of the DUT (as defined here), then - given the waveforms and spectra of CH1 and CH2 - I don't understand why the Vout(f)/Vin(f) or CH2(f)/CH1(f) bode plot shows a low pass response? What am I missing? It rather seems to plot CH1(f)/CH2(f) which is Vin(f)/Vout(f) or 1/gain?

Here's a clip from our notebook (requested earlier) that may help. VBP is the floating Bode Plot Voltage Source, which is usually an Injection Transformer Secondary to realize a floating source. DSO Inputs for a Bode Plot are taken across the floating source, which if taken differentially is just VBP.

Note that VBP (Injected Signal) is considered an Error Signal within the Negative Feedback System, and thus experiences the Negative Feedback System's attempt to correct such. GH is the System Loop Gain and if the Feedback "H" is Unity (1) then the Voltage Ratio across the floating VBP Source is the Open Loop Gain "G", which is Op-Amp Open Loop Gain in this case being discussed.

Anyway, hope this helps.

Best

[TheoB]

Where are CH1 and CH2 connected? CH1 to the inverting input and CH2 to the output of the opamp?

One thing puzzles me: if CH1 is the input and CH2 is the output of the DUT (as defined here), then - given the waveforms and spectra of CH1 and CH2 - I don't understand why the Vout(f)/Vin(f) or CH2(f)/CH1(f) bode plot shows a low pass response? What am I missing? It rather seems to plot CH1(f)/CH2(f) which is Vin(f)/Vout(f) or 1/gain?

Anthing lower is distorted by the CH2 DFT of the first bins. The DC signal seems to spill over to the next bin of interest (the first non-zero bin I want to see).

Sure, the main lobe width of the frequency response of a Kaiser(beta=14) window is about 9.2 bins, so only the bins from #5 onwards have the full stopband attenuation for DC and negative frequencies (which is >= 106dB for a Kaiser(14) window).

Good observation. CH1 is output, CH2 is the feedback input.
I've added a command line switch '-loopgain'. In that case I plot CH1/CH2 and calculate the phase margin. CH1 is used to determine the available frequencies. In the loopgain application only the output of the amplifier contains that information. The feedback error signal (the - input) should be extremely small due to the high loopgain at low frequencies.

I've now removed the DC component after applying the window function. That makes sense as DC is not of interest and it just leaks in the other bins when a window function is applied.

[gf]

I've now removed the DC component after applying the window function. That makes sense as DC is not of interest and it just leaks in the other bins when a window function is applied.

The (scalar) DC offset is supposed to be subtracted from the original signal, not from the windowed signal. If you want to subtract it from the windowed signal, you must apply the window function to DC as well, according to the equivalence (CH1 - DC) * window = CH1 * window - DC * window (where CH1 and window are vectors/arrays and DC is a scalar value).

The subtraction is trivial, but you can only subtract an estimate, and the estimation of the DC value also suffers from leakage. Leakage is not unidirectional, but AC frequencies also leak into the estimated DC value. Only in certain special cases, can you get an accurate estimate, but not in general. The best you can get is a signal whose DC estimate is zero after subtraction, but this does not mean that you have eliminated the actual DC component of the signal. You may even introduce a DC offset which was not present originally. Of course, for a tiny AC signal riding on a huge DC offset, DC subtraction is a big win, even if there remains a residual offset.

In addition to leakage from DC, the first few of bins also suffer from leakage from negative frequencies. If low frequency components are present in the signal, it is inevitable that their negative frequency counterparts are be present in the Fourier spectrum as well, leaking into the first few positive frequency bins.

EDIT:

I have no idea how to compensate for the error of the first few bins in general, so my conclusion is to consider them unusable. If you need to measure these low frequencies, you can of course increase the measurement window duration by a factor of 5 and discard the first 5 bins. That's the price you pay for getting a spectrum analysis filter with high selectivity, high stopband rejection and low far-distance leakage.

Another question: When you measure with a single edge in the measurement window, what assumptions do you make about the settling time of the DUT? Do you expect/require the DUT to settle completely in the interval between the edge and the end of the measurement window?

[TheoB]

My goal was to make the DC bin zero. First idea was to subtract the average from the CH2-CH1 signal. Indeed there is no longer a DC signal if I don't use a window function. But once I use any window function, DC comes back. And I can see how that happens. The center samples get a much higher weight compared to the edge samples. I do FFT(WINDOW(CH2-CH1)). As long as MEAN(WINDOW(CH2-CH1))=0 there is no DC. And that works indeed. The input for FFT should not have any DC.
The part about negative frequencies I  don't understand. The FFT (actually RFFT) is taken from real valued time samples so negative and positive frequencies show the same values.

When the DFT is computed for purely real input, the output is Hermitian-symmetric, i.e. the negative frequency terms are just the complex conjugates of the corresponding positive-frequency terms, and the negative-frequency terms are therefore redundant.

I couldn't say it like that, but I can copy: https://numpy.org/doc/stable/reference/generated/numpy.fft.rfft.html

Another question: When you measure with a single edge in the measurement window, what assumptions do you make about the settling time of the DUT? Do you expect/require the DUT to settle completely in the interval between the edge and the end of the measurement window?

Yes when I capture a 1Ms/625Ms/s=1.6ms trace, the DUT must have a stable output in that time (or indeed in half of that time). The lowest bin is 1/1.6ms=625Hz. When the input frequency is lower only one edge is captured.
The same limitation is seen when a you capture 1.6ms of a 10kHz signal. 16 periods will be shown. Still you will not see any output below 10kHz in a linear network. Simply because there is no input signal present below 10KHz.

[TheoB]

I updated dho-remote to v1.3

• Loopgain analysis added (argument --loopgain)
  
• FFT window selection menu added
  
• Hann window added
  
• Selection algorithm for Bode points optimized
  

A demo video showing the loop gain feature https://youtu.be/Dlk0V3aPnzg

Program can be downloaded form Github: https://github.com/tband/dho-remote

[gf]

The part about negative frequencies I  don't understand. The FFT (actually RFFT) is taken from real valued time samples so negative and positive frequencies show the same values.

Look at the attached FFT plots of 4 sine waves: a=cos(1Hz), b=sin(1Hz), c=cos(10Hz), d=sin(10Hz). All have 1V RMS and no DC offset. 40Sa/s, and FFT size = 40, Kaiser window.

Ideally, the correct amplitude in the frequency domain should be 0.707V RMS at all four frequencies -1Hz, +1H, -10Hz and +10Hz, and DC should be zero.

The -10Hz and +10Hz peaks are indeed correct, for both cos(10Hz) and sin(10Hz).

But look at the -1Hz, +1Hz and DC bins, and notice the difference between a and b. The amplitude of "a" at -1Hz and +1Hz is too high, and the amplitude of "b" at -1Hz and 1Hz is too low. And "a" also leaks into the DC bin, although no DC is present in the time domain signal.

What happens is that a fraction of +1 Hz leaks into DC and into -1Hz, and a fraction of -1Hz leaks into DC and +1Hz, and depending on the phase, the phasors add up differently. Sometimes they add up, sometimes they even cancel each other (the latter happens with the leakage of signal "b" into the DC bin - it is not zero because there is no leakage, but because the leakage from -1Hz and from +1Hz happens to cancel each other).

I think you can see the resulting non-determinism in the first few bins? Both, "a" and "b" are 1Hz and have the same amplitude. Nevertheless you get different amplitudes in the FFT plot and also a different DC value, although the true DC offset of both is zero. Signal "b" even happens to show DC=0, so DC removal would not change anything for signal "b". And if you would subtract mean(a*w) from signal "a", such that the FFT shows DC=0 after the subtraction, then you would get only an amplitude of 0.16 in the -1Hz and +1Hz bins, which is much too low. So for signal "a", DC removal does not help either.

Code: [Select]


% 40 Sa/s
% FFT size = 40

% two 1Hz sine waves with 1V RMS, but different phase
a = sqrt(2)*cos(2*pi*[0:39]/40); % 1Hz
b = sqrt(2)*sin(2*pi*[0:39]/40); % 1Hz

% two 10Hz sine waves with 1V RMS, but different phase
c = sqrt(2)*cos(2*pi*[0:39]/40*10); % 10Hz
d = sqrt(2)*sin(2*pi*[0:39]/40*10); % 10Hz

% periodic variant of the window function
w = kaiser(41,14)(1:40)'; w /= mean(w);

clf
hold on
plot([-20:1:19],fftshift(abs(fft(w.*a)/length(x))),";a;")
plot([-20:1:19],fftshift(abs(fft(w.*b)/length(x))),";b;")
plot([-20:1:19],fftshift(abs(fft(w.*c)/length(x))),";c;")
plot([-20:1:19],fftshift(abs(fft(w.*d)/length(x))),";d;")
grid on


[TheoB]

Yes a window function can introduce a DC term when the input data is not symmetrical around the x=0 axis (the peak of the window). That is exactly the reason why I apply a window and then remove the DC term.  That order works. I still see bleeding between the first bins. So I tend to get more consistent results when capturing a few periods and ignore the first bins instead of capturing a single edge. I've also implemented a filter to only use a single point per harmonic. This prevents the staircase we saw before. I only do that for the first 50 harmonics due to limited accuracy in determining the exact frequency (I interpolate between three bins)

[gf]

I still see bleeding between the first bins. So I tend to get more consistent results when capturing a few periods and ignore the first bins instead of capturing a single edge.

This is exactly my point. Don't try to fix the first few bins. You can't. Rather ignore them and capture at least a few periods (>= 3 periods with Blackman, >= 4 periods with Blackman-Harris or Blackman-Nuttall, >= 5 periods with Kaiser(beta=14)). As a side effect, the DC bin will then be correct as well (although you won't be interested in the DC bin for the Bode plot).

[gf]

Yes a window function can introduce a DC term when the input data is not symmetrical around the x=0 axis (the peak of the window). That is exactly the reason why I apply a window and then remove the DC term.  That order works.

Code: [Select]

...
cpg = sum(win) / len(win)  # coherent power gain
y_windowed=data["y"] * win / cpg
y_windowed=y_windowed - np.mean(y_windowed)
ywf = rfft(y_windowed)
...

What your code is doing is equivalent to setting the DC bin to zero after the FFT (which has no effect for the Bode plot as you don't care about DC). But it does not remove leakage from DC to other bins.

Let me demonstrate with a comparison between 1) no DC removal, 2) proper subtraction of estimated DC and 3) your method. The signal are two 1mV RMS sine waves sitting on a 1V DC offset. I used a low beta to exaggregate the effect. W/o DC subtraction, the peaks from the 2 frequencies drown in leakage from DC. Your method does not fix that, it just sets the DC bin to zero. However, proper DC subtraction nicely uncovers the peaks.

EDIT:

Btw, in this context it may be noteworthy that the periodic variants of cosine-based window functions (Hann, Blackman, Blackman-Harris, Blackman-Nuttall, Flattop, etc.) have per se zero leakage from DC to other bins (except for the few low frequency bins near DC), due to the location of the zeros in their frequency response. With these window functions, the benefit of DC subtraction vanishes. [ I tried, of course, to show a prominent example where subtraction of the DC estimate really helps. ]

EDIT:

Due to this property (most of the zeros in the frequency response are located at bin frequencies), I generally recommend using the periodic variant of the cosine sum window functions for this application (argument sym=False when you use the SciPy functions). For Kaiser, symmetric versus periodic does not make a big difference -- the zeros are not located at bin frequencies anyway.

Code: [Select]


% 40 Sa/s
% FFT size = 40

% Two small sine waves sitting on a large DC offset
% 6.5Hz 1mVrms + 12Hz 1mVrms + 1V DC
a = 0.001*sqrt(2)*cos(2*pi*[0:39]/40*6.5) + ...
    0.001*sqrt(2)*cos(2*pi*[0:39]/40*12) + 1;

% window function (using periodic variant)
% normalized to mean(w) == 1
w = kaiser(41,7)(1:40)';
w /= mean(w);

% windowed signal
aw = a .* w;

% windowed signal with DC removed
aw_DC_removed = aw - mean(aw) .* w;

% what you are doing
aw_yours = aw - mean(aw);

clf
subplot(3,1,1)
plot([-20:1:19],fftshift(20*log10(abs(fft(aw)/length(a)))))
title("Without DC removal")
ylim([-100 0])
grid on

subplot(3,1,2)
plot([-20:1:19],fftshift(20*log10(abs(fft(aw_DC_removed)/length(a)))))
title("With subtraction of estimated DC")
ylim([-100 0])
grid on

subplot(3,1,3)
plot([-20:1:19],fftshift(20*log10(abs(fft(aw_yours)/length(a)))))
title("Yours")
ylim([-100 0])
grid on


[iMo]

Let me ask here in the hardcore FFT thread :

1. my DDS siggen is at  10.000000Hz, plus minus 10Hz let say..
2. doing FFT in the o'scope (804/824 here), 1.25GSa/s and 1Mpts, Blackman or Hanning, scope counter shows 10.0001MHz:
3. when I set time base such it shows "1us" I can see 10.0749MHz in the peak search
4. when I set time base such it shows "2us" I can see 9.99999MHz in the peak search
5. when I set time base such it shows "5us" I can see 10.0012MHz in the peak search
6. when I set time base such it shows "10us" I can see 10.0097MHz in the peak search
etc.
So the closest is at "2us". Now, what is the formula giving all that params together, telling me "the 10MHz peak is at the right frequency in the FFT"? 
PS: the "peak search" is the table o'scope shows on the display..

[TheoB]

With those timebase settings, what you capture is exactly 1M/1.25G=800us. 10 divisions of the timebase values you gave is always less than this 800us. All timebase settings 50us/div or faster should give the exact same result (that is what I use in my program). The bins are 1/800us=1.25kHz wide.
The scope however uses the screen, not the memory to calculate FFT. Simply watch the full scan from 0-625MHz with setting 5ns/div. I think you only get 32 points or so. Then set your timebase to 50us/div to have the full-span at 1.25kHz resolution. Even in stop mode you can increase the timebase and see the resolution increase. No idea why Rigol choose to do that as the scope is fully capable to do FFT fast with 1M points that are captured anyhow. No need to use less samples at faster timebase settings. Anyhow, this lower resolution affect the frequency resolution. The best resolution you get at 50us/div, not 2us/div.
Try also to change your DDS with 1kHz steps at 2us/div setting. I see 39kHz steps (bin size). 1.25Gs/39kHz=32kSamples.

[iMo]

With the (all w/ 1Mpts, averaging 64)
1.25GS I get in the table 9.99999MHz at 2us
1.25GS 9.99999MHz at 20us
625MS 9.99999MHz at 100us
156MS 10.0001MHz at 500us
62.5MS 10.0000MHz at 1ms
31.25MS 10.0000MHz at 2ms..
PS: the same with none averaging..

[TheoB]

The FFT will not show any difference unless a neighbor bin becomes larger. The frequency quantitation is thus equal to the bin size. The bin size is 1.25kHz @ 50us/s.
At 2ms/s the sample rate is 31.25Ms/s. I would expect a bin size of 31.25M/1M=31.25Hz. That's indeed what the scope does, but it displays the 10MHz with limited resolution (100Hz). At 1MHz 10Hz resolution etc, limited to 6 digits.

[gf]

In this context I wonder what the Rigol DHO actually displays on the screen when a narrow span of only (say) 10...15 FFT bins is selected.
[ E.g. ~10MHz input signal, 1250MSa/s, 1Mpts, center=10MHz, span=15kHz, Blackman window ]

Does it just connect the few frequency domain samples (FFT bins) that fall within the span with straight lines (linear interpolation), or does it "properly" interpolate between FFT bins with some sort of Zoom FFT or CZT?

EDIT: what I mean is, does it display something like the blue trace, or more like the orange trace in the attached figure?

[TheoB]

When you interpolate between two bins I consider that not 'proper'. Lines between the points makes it easier to watch. I do interpolate between multiple bins but under the assumption that this is a single frequency tone spread over multiple bins. In this way I try to calculate the fundamental of the signal with higher resolution than the bins. If you just calculate a DFT from random data there is no way to predict sub-bin points. The window function does smooth the bins though.
You have the scope, so see for yourself how Rigol does it. Best visible when at 5ns/div due to the low amount of FFT points (stop the scope to investigate in detail).

[TheoB]

I updated dho-remote to v1.4

• Harmonic filtering improved. Now only local maxima in the spectrum on CH1 are used.
• Auto setup now tries to set the timebase such that multiple periods are captured
• Demo mode added. No scope needed: python dho-remote.py -d examples/LRC.bplt
• Installation instruction added here.

After a regular system update it stopped working. Turned out that python updated from 3.12 to 3.13.1. And pyvisa was no longer present
Re-installing the package installed it for the newer version.
Once you know, it's not a big deal but it shows that relying on the correct python libraries can be tricky.
Seems to be a common thing with Python and virtual environments have been invented to work around it. I added instructions and a package dependency list.

[gf]

I updated dho-remote to v1.3

V1.3 shows commit dates of "2 months ago". Isn't the new one v1.4?
But the v1.4 commit does not belong to any branch in the repository.

[iMo]

..there are the v1.4 zip and gz files for the dwld
https://github.com/tband/dho-remote/tags

[TheoB]

Ah yes, it should be v1.4 and I forgot to 'push'. Should now be correct :-)