EEVblog® Electronics Community Forum
Products => Test Equipment => Topic started by: TimFox on October 05, 2023, 10:13:54 pm
-
I just received my DHO914S, printed out the full user manual, and am just starting to learn about thumb-drive saving and other functions.
To try a simple Bode plot, I made a passive R-C filter between two BNC-binding post adapters on Ch 1 and Ch 2, driving Ch 1 through a BNC Tee from the back-panel generator output.
The resistor from 1 to 2 is 9100\$\Omega\$/ 1% metal film and the capacitor from 2 to ground is 1640 pF/2% polystyrene, which calculates to -3 dB and -45 deg at 10.66 kHz.
I am surprised at the ripple on the resulting measurement, on both ratio and phase (see attachment).
The Bode plot was set for 100 points from 1 kHz to 100 kHz, log frequency span, other parameters per default setting.
The 11,610 Hz frequency on the graph is 9% high, which seems like too much error for the 1% resistor and 2% capacitor, especially since parasitic capacitance on Ch 2 binding post and any effect of the source resistance in series with the 9100\$\Omega\$ resistor should lower the frequency.
A 1 megohm input impedance at Ch 2 would only reduce the 9100\$\Omega\$ by about 1%.
The graph was done on my favorite graphing program (Grapher from Golden Software), directly from the .csv file I transferred through a thumb drive, with my own formatting and notes.
Even near 11 kHz, I eyeball about 5 deg pk-pk ripple on the phase angle.
Is this reasonable for the measurement, and is there any improvement I can make with the settings for the Bode plot acquisition?
-
And oscilloscope screen displayed Bode Plot result is?
-
Very similar, but harder to read on the small screen.
There is no discrepancy between the screen and my graph of the data.
I first tried several different capacitors, but always saw the "ripple" in magnitude in phase.
To see the non-monotonic behavior better, I saved the data to the thumbdrive.
-
Can you add photo of setup? Generator has 50 Ohm impedance, but this cannot explain ripple. Is result repeatable? I got spikes in bide plot dut to microphoning - just hitting table, not very hard. Different scope however.
-
A firmware-based artefact is conceivable: They must do some kind of curve fitting to determine the incoming amplitude and phase, and if that is implemented in a sloppy way, the result might vary with the number of full and partial periods sampled.
Does the scope offer any parameters for the Bode plot which you can change -- sweep rate for example, which one could decrease to work from a larger number of sampled periods?
EDIT: I checked the manual and could not find any options beyond setting the number of frequency points per decade, which is not promising. But the "FIR Filter" option looks ominous. It is probably meant to reduce edge effects at the start and end of the captured wave trains? Does switching it ON or OFF affect the ripple on the Bode plot?
-
Thanks for the suggestions.
I'll load a photo of the setup later today: everything is right on the front panel, with a coax cable from the generator output on the back, but no 50 ohm terminator. No connection to the ground terminal on the rear, with the supplied power module (three-prong plug) connected to an outlet strip on my computer desk.
The appearance of ripple is very repeatable: I was trying different components and frequency ranges (all below 100 kHz). The only parameter I could find (not an exhaustive search yet) is the number of points and log sweep: I should try a linear frequency sweep to see if that differs and try testing the FIR on/off suggestion.
I'll also check the .csv file to see if there is some odd/even effect in the recorded data.
Edit: I checked for odd/even effects in gain and phase curves, but there is nothing obvious.
However, there may be a periodic effect, with a period of 6 or 7 data points (eyeball analysis).
There are 200 data points, in a log sweep, at 100 per decade.
-
The million dollar question: how long does it take to do a plot?
-
The time to do the plot varies with the frequency range: when starting at 100 Hz, the plot is quite slow due to the long time required to measure the low frequency sinusoids.
Otherwise, it seemed reasonable for the discrete measurements being made.
I first noticed the wiggles while watching the Bode plot advance during the measurement.
-
Here is a photo of the setup on the front panel of the DHO914S (no tripod, so depth of field suffers).
The resistor runs out of the photo plane from the left binding post adapter on Ch1 to the right binding post adapter on Ch2, and the capacitor is on the right adapter.
The 36" RG-213/U cable runs from the back panel around to the BNC Tee on Ch1, under the adapter, without terminator.
-
Your setup looks fine, let's hope the horrible looking Bode Plot is due to something simple.
If this is due to the DSO and firmware, not good!!
Sure hope the 814 we've ordered doesn't exhibit this kind of behavior!!
Best,
-
Very similar, but harder to read on the small screen.
Coud you share a screenshot from it ?
-
I'll save one after I try the suggestion about FIR sometime in the next couple of days.
However, I'm sure there is no substantial difference, only that my graph of the data makes the wiggles easier to see.
-
There are many things you can do to find the problem
Replace cap with resistor (or no filter present test)
Also just do it the slow way and measure it manually (not with the automated bode plot) and compare a few freq.
Then you know what it should be (not theoretical)
also check is ripple error the same for the same freq every time or random.
Also check if it changes with different frequency steps.
my 914S only arrives in 3 weeks but will also compare.
-
There are many things you can do to find the problem
Replace cap with resistor (or no filter present test)
Also just do it the slow way and measure it manually (not with the automated bode plot) and compare a few freq.
Then you know what it should be (not theoretical)
also check is ripple error the same for the same freq every time or random.
Also check if it changes with different frequency steps.
my 914S only arrives in 3 weeks but will also compare.
Slow way: I haven't found any way to calculate the phase difference between Ch1 and Ch2 in the scope firmware (at a fixed frequency).
I have tried different capacitor values, which shifts the corner frequency, but see essentially the same thing.
Also: my first setup had an external wire between the ground terminals of the two binding post adapters, with the same apparent results.
-
I assume the phase measurement is in there
edit: page 142 in the English DHO900 user guide
-
Thanks: I looked for and found that "other" menu under "measure" that has the four phase measurements.
(My problem with menu-driven systems is knowing which menu to look for.)
I will get back to this probably next week.
-
It's a low frequency experiment but the equipment is wideband-capable. There are a circuits running at a GHz clock speeds inside the plastic housing. While the DUT is represented by a through-hole components with long leads and it is located very close to the front panel of the oscilloscope. What if there is some kind of EMC issue because of that? It would be interesting to make sure the results are the same when the DUT is located at some reasonable distance from the scope
-
If nothing else works, I can make up a shielded enclosure with BNC connectors to house the discrete components.
-
At what level you made this test? Was test signal 10 mVpp or 1 Vpp? Low signals are more noisy, which may lead to errors... Not sure what can be configured in DHO914S.
EDIT: amplitude and point/decade is adjustable. Page 199 of manual, paragraph 15.3
-
Manual tells you can choose between fixed and variable amplitude - but no values are mentioned.
(Edit: but the datasheet tells..)
Apart from that, I don't find the representation of the Bode mode all that great.
-
Manual tells you can choose between fixed and variable amplitude - but no values are mentioned.
(Edit: but the datasheet tells..)
Apart from that, I don't find the representation of the Bode mode all that great.
Only one channel used ?
What if you need Bode plot a multistage filter ?
-
The Bode plot function allows one to select the input and output ports from the four front connectors (on the 914S), but only one pair at a time.
-
Manual tells you can choose between fixed and variable amplitude - but no values are mentioned.
(Edit: but the datasheet tells..)
Apart from that, I don't find the representation of the Bode mode all that great.
Yeah, I've had problems with the documentation.
For example, that excerpt shows "points per octave", but the 100 points I entered were "points per decade": I ended up with 200 frequencies between 1000 and 100,000 Hz.
I used the default amplitude values--more experiments next week when I have time.
-
The Bode plot function allows one to select the input and output ports from the four front connectors (on the 914S), but only one pair at a time.
Shame.
Here's a pic from an old post where 2 traces are shown from a 2 stage passive filter:
(https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/?action=dlattach;attach=399022)
Starts here and that pic ^ is a few posts later.
https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg1435854/#msg1435854 (https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg1435854/#msg1435854)
-
That could be useful.
Note that the Siglent unit in the picture requires an external AWG, so the total costs more than the Rigol.
-
Yepp,
Appx 18€ more. ;)
SDS1104X-E + SDG1032X are around 850€ together (incl.VAT), DHO914S cost 832€ (incl VAT), prices from batronix.
But this is only interesting when you need a good bode plot function(and a good 2-ch awg), you don't have 12 bit for it then.
-
My DHO914S, direct from Rigol North America, cost $699 plus shipping.
I'm not anyone's sales representative, just trying to understand how to improve this measurement.
-
Understand, back to your topic:
If your time allows you, can you make a short video from the bode menu ?
As written before the manual is a little bit meager.
-
Understand, back to your topic:
If your time allows you, can you make a short video from the bode menu ?
As written before the manual is a little bit meager.
"Meager" is a polite word here; unfortunately the series hasn't been out long enough for someone to write a relevant "dummies" book.
My next experiment is to build the simple network in a properly shielded box, but I'm busy elsewhere until next week.
I also need to figure out how to increase the drive voltage: I believe the default I used here is only 200 mV pk-pk, but the generator can do 5 V pk-pk max.
-
You shouldn't need a shielded box for this type of simple Bode measurements, now if you are measuring the Open-Loop response of a op-amp in Closed-Loop form (injecting a small signal in the loop), then maybe shielding might be required.
Wonder if the Bode implementation utilizes any sort of frequency selectivity like other implementations?
Best,
-
Really quick and dirty with the 1104X-E and SDG2122X, 8K2 and 2n2 cap...
-
That's what I was expecting to see.
If I can't get my Rigol better, is there a contact at the company that is worth contacting?
-
I've done a bit more experimenting, using exactly the same R-C setup while waiting for my shield box to be delivered.
I played with the bandwidth limit (125 or 20 MHz) and the amplitude (0.2 or 2 V) and the FIR filter (On/Off), increasing the points/decade from 100 to 200, keeping the log scan from 1 to 100 kHz.
No noticeable changes resulted.
I then did the "slow way" manual scan, using the voltage measurement function (pk-pk) and phase measurement function, at essentially the same frequency points (truncating to nearest Hz), manually entered, between 75 and 100 kHz.
The attached graph shows the dB and phase results from that subset of the Bode Plot results, and another graph for the slow manual result.
Both were taken at 20 MHz bandwidth limit and 2 V.
I added symbols to show the actual sample frequencies, and switched to a linear frequency axis for the limited frequency range.
It really looks like bad firmware on the Bode Plot, since the graphs with discrete frequency measurements look reasonable and are certainly monotonic.
[attachimg=1]
Thanks to ebastier, KedasProbe, CosteC, and Martin72 for the suggestions I followed here.
-
The postman just brought me one of these "toys" as well and, unfortunately, I've got to chime in with the same findings: The Bode Plot function is pretty much useless as it is right now!
I found the same "wigglyness" of the traces while at least a monotony should be shown in case of a simple low pass. Maybe they designed too many "wiggles" in the traces on the instrument's PCB... ;D
Whatsoever, there are several points that are possibly worse (but easier to get right):
- The Bode Plot function won't start (and it also won't display any message) if the signal exceeds the range of the "Output" channel (didn't test this for the "input" channel). So it may be necessary to manually adjust the sensitivity of the channels correctly before starting the Bode Plot.
- The preset number of points relates to a decade, not to the whole measurement interval (this may be a convention and I'm not aware of it).
- The setting for the measurement frequency spacing ("Line"/"Log") only relates to a decade, within the next decade, the intervals may change even if the spacing is chosen "Line".
- The on-screen display of the plot is abysmal: Even though the markings suggest a Logarithmic frequency scale, the values are placed linearly within each decade which results in kinks in the diagrams, regardless of Lin/Log setting, see RigolDS7(log) and RigolDS8 (lin) :palm:! I'm not sure if the situation is the same for Amplitude values since the scale of the Y-axis apparently cannot be adjusted to a range that allows a better resolution. Same for the frequency axis, only automatic scaling is available.
So right now, for displaying the bode plots, you've got to take the route via the CSV output. If you think, in its current configuration, the DHO900 is a good tool for high resolution Bode Plots, think again... I'm actually considering to return the instrument since this function was the one that I'ld needed the most for a project I'm currently working on. I'm pretty sure Rigol will get it right eventually, but how long that may take is written between the stars... I guess for the time being, I'm better off with my ADALM2000 and the "Scopy / NWA" tool.
-
That looks like the same problem I reported, and I am also disappointed.
Every time I obtained a scan, I noticed the non-monotonic behavior as it was displayed ("wiggles"): clearly visible even with the narrow display range.
The reason I graphed the results (.csv file) on a graphing program was that I could not adjust the scale on the screen: I assumed that I needed to study the manual more.
In my graphs, the x-axis is the frequency values listed in the first column of the .csv file.
Rigol only advertises the Bode Plot function to be used with an isolation transformer to evaluate feedback stability, and it does announce the voltage and phase margins for that measurement.
The first scan I did (not posted here), I had an attenuator on Ch1 so it would look more like a feedback Bode Plot (gain above unity at low frequency), and those margins were calculated.
Is there a useful address at Rigol to report bugs?
-
I assume the phase measurement is in there
edit: page 142 in the English DHO900 user guide
That is something else, a phase measurement in Measurements. It is not a plot but single point phase measurement.
Bode Plot is something completely different.
-
Understand, back to your topic:
If your time allows you, can you make a short video from the bode menu ?
As written before the manual is a little bit meager.
"Meager" is a polite word here; unfortunately the series hasn't been out long enough for someone to write a relevant "dummies" book.
My next experiment is to build the simple network in a properly shielded box, but I'm busy elsewhere until next week.
I also need to figure out how to increase the drive voltage: I believe the default I used here is only 200 mV pk-pk, but the generator can do 5 V pk-pk max.
The more I read real user feedback now that specimens are starting to trickle in (and it has been few months already since it was "released") I see that it is even worse than I expected (I thought they would cleanup things a bit by now)..
These scopes are still in alpha stage of development as of today... I actually expected much better from Rigol. Hope soon this gets much better, otherwise users will not be happy...
-
You shouldn't need a shielded box for this type of simple Bode measurements, now if you are measuring the Open-Loop response of a op-amp in Closed-Loop form (injecting a small signal in the loop), then maybe shielding might be required.
Wonder if the Bode implementation utilizes any sort of frequency selectivity like other implementations?
Best,
Mike,
I actually did tests (on my Siglent and Keysight scopes) where I injected both signals and wideband noise from additional AWG into circuit while doing Bode and got perfect results as long as S/N ratio was something reasonable. In normal lab normal levels of injected noise from environment are simply not visible in measurements.
If Bode is done right it should not matter.
Best.
Siniša
-
The more I read real user feedback now that specimens are starting to trickle in (and it has been few months already since it was "released") I see that it is even worse than I expected (I thought they would cleanup things a bit by now)..
These scopes are in alpha stage of development as of today... I actually expected much better from Rigol. Hope soon this gets much better, otherwise users will not be happy...
I am, frankly, not too surprised that functionality which is new vs. the DHO 1000 and 4000 series is immature. Those scopes don't have the function generator option and hence the Bode plot functionality. They don't have the 16 digital inputs either -- seems that nobody has tested the logic analyzer on the DHO 900 yet, but I am sure it holds its own surprises...
The fact that basic storage scope functions -- like zooming in and out on captured traces, or storing trace data on a USB stick -- also seem to have glitches is more disconcerting to me. The HDO/DHO 1000 and 4000 have been out for a year and they share that functionality. Do they share the bugs too?
-
I assume the phase measurement is in there
edit: page 142 in the English DHO900 user guide
That is something else, a phase measurement in Measurements. It is not a plot but single point phase measurement.
Bode Plot is something completely different.
Since doing it the slow way (point per point and making your own graph) it is measuring stable/correctly (luckily), most likely they changed something so the timing for the measurements changed and screwed the automated measurement script that was probably working before.
So I'm sure it's an easy fix, just get the measure timings right. (it may end up slower though)
-
That looks like the same problem I reported, and I am also disappointed.
Every time I obtained a scan, I noticed the non-monotonic behavior as it was displayed ("wiggles"): clearly visible even with the narrow display range.
The reason I graphed the results (.csv file) on a graphing program was that I could not adjust the scale on the screen: I assumed that I needed to study the manual more.
In my graphs, the x-axis is the frequency values listed in the first column of the .csv file.
Rigol only advertises the Bode Plot function to be used with an isolation transformer to evaluate feedback stability, and it does announce the voltage and phase margins for that measurement.
The first scan I did (not posted here), I had an attenuator on Ch1 so it would look more like a feedback Bode Plot (gain above unity at low frequency), and those margins were calculated.
Is there a useful address at Rigol to report bugs?
The isolation transformer may be required if the DUT is a powerful amplifier (or a PSU) in order to eliminate ground loops or ground reference offset problems. In case of a low power passive network as a DUT, this is completely irrelevant since the Scope's source and measurement channels are rather had-linked to the same ground and only minuscule currents are flowing.
To verify this, I ran another test with a really high impedance network: A low pass of 100kOhm and 330pF -- same result.
I also tested the effect of enabling the FIR filter -- virtually none, but maybe it helps if there's noise on the signal or if there's heavy distortion (harmonics) that shouldn't be evaluated. But as long as the Bode Plot algorithm isn't refined substantially, all this is a moot point.
Btw, running the plot (1kHz~100kHz -- 2 decades; 50pts each) takes 52s (FIR disabled - RigoDS9) vs. 90s (FIR enabled - RigolDS10).
-
I assume the phase measurement is in there
edit: page 142 in the English DHO900 user guide
That is something else, a phase measurement in Measurements. It is not a plot but single point phase measurement.
Bode Plot is something completely different.
Since doing it the slow way (point per point and making your own graph) it is measuring stable/correctly (luckily), most likely they changed something so the timing for the measurements changed and screwed the automated measurement script that was probably working before.
So I'm sure it's an easy fix, just get the measure timings right. (it may end up slower though)
I said it is not done that way. Bode plot function does not simply automate manual procedure.. It uses different principle.
If they used that Measurement function for BODE, that could be explanation for weird results.
As for what is easy, I disagree.. We have no data of internals and have no clue if this is something simple or whole bode architecture is wrong... It might look easy, but look at the numerous bugs reported... I guess it is not that easy...
-
I believe the transformer is required in order to inject the input signal into the "guts" of a feedback amplifier, without disconnecting the feedback, to get a Bode Plot of the loop gain/phase for stability analysis.
The measurement itself, however, should be a frequency scan measuring the relative gain and phase of two channels.
The measurement menu has enough functions to measure relative gain and phase at a single frequency.
-
I own the 924S and had some similair things. Keep in mind that the default voltage of the generator is peak to peak which is rather low. Besides using the delivered power supply I was using a Lenovo power supply which is quite noisy compared with the one supplied. In addition, I had very rough plots that were absent with the supplied power supply. Furthermore, the earth was important for reducing the noise. I also discovered many bugs such as the fixed vertical scales that make reading more difficult and the automatic gain does not work well at low frequencies. Hereby a plot of an audio transformer.
-
Thanks TimFox for the info, I got my DHO914s a few days ago and was about to try some Bode plots, I'll see how it goes.
-
I found the same "wigglyness" of the traces while at least a monotony should be shown in case of a simple low pass. Maybe they designed too many "wiggles" in the traces on the instrument's PCB... ;D
;D
-
I found the same "wigglyness" of the traces while at least a monotony should be shown in case of a simple low pass. Maybe they designed too many "wiggles" in the traces on the instrument's PCB... ;D
;D
As foul-minded 8th-graders back in 1963, referring to our young female typing teacher, we declared "all that wiggles is not Jell-O".
-
Just pondering how they do the phase/amplitude calculation, the way that comes to mind is an FFT of CH1 and CH2 and extract the amplitude and phase from that. But they would be shortish sample sizes for speed and not synchronised to the input sine. This would lead to both phase and amplitude errors perhaps even the ripple seen. Not sure if that is how they do it or it is even the best way.
P.S. If the sampling rate is a 2^n multiple of the test frequency then the error would tend to zero if such a method is used. You want to sample complete cycles.
-
Just pondering how they do the phase/amplitude calculation, the way that comes to mind is an FFT of CH1 and CH2 and extract the amplitude and phase from that. But they would be shortish sample sizes for speed and not synchronised to the input sine. This would lead to both phase and amplitude errors perhaps even the ripple seen. Not sure if that is how they do it or it is even the best way.
No mention in the manual of the method, nor can I find any algorithmic information on Google.
As someone else mentioned on one of these threads, an actual "Bode Plot" is an approximation, using straight lines on semi-log graph paper (log freq on the x-axis, and dB or degrees of phase on the y-axis) as a quick drawing method for paper graphs of loop gain in a feedback circuit: I learned this from H Bode's book Network Analysis and Feedback Amplifier Design Van Nostrand 1945, and used it manually before we had PCs on our desks to estimate loop gain/phase from the sums of individual piecewise linear curves for each time constant.
The "Bode Plot" function in this unit should be an accurate plot of gain and phase over a desired frequency range, with a measure of the gain and phase margins for the loop gain.
My next step is to carefully measure my network's R and C values, including connectors and 'scope input impedance, to see if the -3 dB / -45o point is at the correct frequency.
In my first graph, a few posts above, I found that even with the wiggles, -3 dB and -45o coincided, but at a noticeably higher frequency than expected: 11,610 Hz instead of calculated 10,660 Hz, a 9% discrepancy with nominal 1% resistor and 2% capacitor tolerance .
-
I believe the transformer is required in order to inject the input signal into the "guts" of a feedback amplifier, without disconnecting the feedback, to get a Bode Plot of the loop gain/phase for stability analysis.
The measurement itself, however, should be a frequency scan measuring the relative gain and phase of two channels.
The measurement menu has enough functions to measure relative gain and phase at a single frequency.
Yes a transformer is usually utilized. The negative feedback loop is broken in a location where the transformer secondary impedance doesn't effect the loop, and the DC bias is unaffected and can pass thru. When a signal is applied to the primary this introduces an "outside disturbance signal" in the loop via the secondary. If the loop remains stable and "pseudo linear" then the loop produces a countering signal in an attempt to neutralize the injected disturbance signal, the ratio of the loop generated correcting signal to the injected signal is the total loop gain and phase around the loop regardless of the injection point. Of course certain injection points are better than others, and some experimentation is often required.
There are a number of posts related to Bode Plots, techniques and injection transformers. As many, we used some Common Mode Filters rewound as injection transformers, recall they worked well over 3~4 decades.
This is extremely disappointing wrt the Rigol Bode Plot implementation in these new 12bit DSOs, we were hoping for much better reports now, that knowledgable folks are getting their hands on such.
We have an 814 due Thursday, for evaluation for a client that doesn't require these features, but all this doesn't "bode" well (pun intended) for these new Rigol 12 bit DSOs!!
Best,
-
Personally, I'm not too worried about the issue yet as the basics are very good, noise floor, sampling seems good, display is excellent. I think and hope the other issues can be resolved by firmware updates.
-
The Bode Plot function appears broken. When I tried a simple low pass RC with 100Hz to 10kHz at 50 pts/decade, 1V amplitude, it worked with the ripple TimFox mentions. When I increased the sample points to 100 pts/decade it changed CH2 resolution to 20mV/div and the top waveform display showed CH2 clipped and it hung until I turned off the Bode Plot window. I think at present a script and PC control might be a more effective way of Bode Plotting until a fix is provided. The on screen display for the Bode Plot function is awfull.
-
Moffy - you are 100% correct. But considering that the whole point of having a DHO900S is more or less the advertized Bode Plot function, what sense does it make to purchase this scope while you've still got to do the "heavy lifting" in a PC. Moreover, my findings with the instability of the inegrated AWG (bugs thread) won't make me feel any better regarding a PC-operated DHO900S. In this case, "any old scope" with phase difference and amplitude measurement and a digital AWG will do the trick. Or, as I mentioned somewhere before, one of these "analog workbench" gadgets will do a pretty good job at Bode Plotting / Network Analysis as well.
-
Thanks for the heads up TurboTom about the AWG I will check out your posts. In spite of the issues I am still reasonably happy with the 's' version as long as I can have sine/square/triangle. :)
-
The Bode Plot function appears broken. When I tried a simple low pass RC with 100Hz to 10kHz at 50 pts/decade, 1V amplitude, it worked with the ripple TimFox mentions. When I increased the sample points to 100 pts/decade it changed CH2 resolution to 20mV/div and the top waveform display showed CH2 clipped and it hung until I turned off the Bode Plot window. I think at present a script and PC control might be a more effective way of Bode Plotting until a fix is provided. The on screen display for the Bode Plot function is awfull.
There is a solution that I do use now too but is it actually an error caused in the automatic gain setting. Before starting the measurement you can still manually set the gain of each channel. I then set the sensivity for each channel to 10 volts per devision. When the plot is started the algorithm will have to amplify the gain first. The result is that the plot continues. If the gain is too sensitive at the start then the signal will clip in advance and the plot will not continue to the next frequency. The software should attenuate the gain until the signal falls below the clipping point. So based on the digital value coming out of the ADC you could decide to adjust the value downward so that the waveform fits in the window.
-
Herewith a comparison of two measurement signals, the AWG of the 924S with a signal from a professional 24 bit audio analyzer. I suspect that the 14 bit AWG is fundamentally much better but that the AWG picks up a lot of interference in the device itself. The red curve is the 24 bit analyzer and green concerns the 924S. What is also noticeable is the huge jitter the 924S gives. In itself this is not such a problem for the Bode plot as long as the input channels use sharp bandpass filters.
-
The Bode Plot function appears broken. When I tried a simple low pass RC with 100Hz to 10kHz at 50 pts/decade, 1V amplitude, it worked with the ripple TimFox mentions. When I increased the sample points to 100 pts/decade it changed CH2 resolution to 20mV/div and the top waveform display showed CH2 clipped and it hung until I turned off the Bode Plot window. I think at present a script and PC control might be a more effective way of Bode Plotting until a fix is provided. The on screen display for the Bode Plot function is awfull.
There is a solution that I do use now too but is it actually an error caused in the automatic gain setting. Before starting the measurement you can still manually set the gain of each channel. I then set the sensivity for each channel to 10 volts per devision. When the plot is started the algorithm will have to amplify the gain first. The result is that the plot continues. If the gain is too sensitive at the start then the signal will clip in advance and the plot will not continue to the next frequency. The software should attenuate the gain until the signal falls below the clipping point. So based on the digital value coming out of the ADC you could decide to adjust the value downward so that the waveform fits in the window.
I tried it out and it worked. :-+
-
The Bode Plot function appears broken. When I tried a simple low pass RC with 100Hz to 10kHz at 50 pts/decade, 1V amplitude, it worked with the ripple TimFox mentions. When I increased the sample points to 100 pts/decade it changed CH2 resolution to 20mV/div and the top waveform display showed CH2 clipped and it hung until I turned off the Bode Plot window. I think at present a script and PC control might be a more effective way of Bode Plotting until a fix is provided. The on screen display for the Bode Plot function is awfull.
There is a solution that I do use now too but is it actually an error caused in the automatic gain setting. Before starting the measurement you can still manually set the gain of each channel. I then set the sensivity for each channel to 10 volts per devision. When the plot is started the algorithm will have to amplify the gain first. The result is that the plot continues. If the gain is too sensitive at the start then the signal will clip in advance and the plot will not continue to the next frequency. The software should attenuate the gain until the signal falls below the clipping point. So based on the digital value coming out of the ADC you could decide to adjust the value downward so that the waveform fits in the window.
I tried it out and it worked. :-+
Great!!
-
Can someone with a DHO900S please try to verify this finding: https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5106039/#msg5106039 (https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5106039/#msg5106039)
I doubt that this problem is unique to the specimen that I've got here, but it may be possible. Thanks a lot!
-
Can someone with a DHO900S please try to verify this finding: https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5106039/#msg5106039 (https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5106039/#msg5106039)
I doubt that this problem is unique to the specimen that I've got here, but it may be possible. Thanks a lot!
Yep, got exactly the same behavior going from 2.147kHz to 2.148kHz brought up 'open the app again'.
-
Bode plot problem is solved. New firmware available.
https://supportcn.rigol.com/Public/Uploads/uploadfile/files/ftp/Firmware/DHO800_DHO900(Software)UpdateV00.01.01.zip
-
Bode plot problem is solved. New firmware available.
So you already checked out the Bode plot? That was quick! :-+
And a pleasant surprise from Rigol -- not only is there a first firmware update very soon, but it seems to fix more than what they announce in the release notes. There's hope... 8)
-
Bode plot problem is solved. New firmware available.
So you already checked out the Bode plot? That was quick! :-+
And a pleasant surprise from Rigol -- not only is there a first firmware update very soon, but it seems to fix more than what they announce in the release notes. There's hope... 8)
The only thing left is the fixed vertical scales, amplitude and phase. Should be nice to have vertical auto ranging as well
-
I have installed the upgrade: now waiting for thorough warm-up before new self-calibration.
-
Date from firmware 1.1 August 10, only 17 days after first firmware release.
I assume those firmware 1.0 DHOs were build in the first 17 days of production.
So what happened in the next 60 days for firmware updates? (3.5 times the same period)
edit: let assume they are working on new features....
-
They solved the Scope App crashing bug if frequency of the AWG is adjusted with encoder 1 :-+.
Yet, regarding the Bode Plot, I couldn't find much of an improvement. But I've got to admit, I used the scope screen as the "window to the data" and not an external CSV visualization. Wiggles were still recognizable, anyway.
-
So I installed the update, checked "about" to verify the new firmware rev level, re-did the self-calibration (with everything disconnected), re-connected the exact connections I had before, and there might be a very slight improvement.
Graphing the .csv file using the same settings on the graphing software, but adding points to the phase curve (heavier line) at the actual data points, I found a very similar result posted below.
One important clue might be that the "ripple" seems to have a period of roughly 6 or 7 points.
The manually-added cursor at -3 dB and -45 deg remained the same.
[attachimg=1]
-
Oh, sigh... I must have misunderstood Cees' post #60 then.
Here's hoping that Rigol do address this next time round. Getting one of the two selling points of the DHO 900 series wrong should be kind of important to them...
-
Oh, sigh... I must have misunderstood Cees' post #60 then.
Here's hoping that Rigol do address this next time round. Getting one of the two selling points of the DHO 900 series wrong should be kind of important to them...
At least we know why it wasn't mentioned in the release notes.
Mystery solved!
-
Anyone connected a second oscilloscope to ch1 when doing a bode plot to see what the input signal looks like?
They could (for speed reasons) like do 5 sin waves at the same time and sort them out with a FFT on both channels. (Amplitude and Phase are provided by an FFT)
but this will introduce errors that they may not take into account so maybe that is what we see.
Delivery of mine is delayed until next week (for now)
-
Not necessary - in the little upper window, the input signals of the corresponding two channels are displayed vs. time. They are proper sinewaves!
-
Graphing the .csv file using the same settings on the graphing software
What software are you using for graphing?
-
I'm using "Grapher" from Golden Software.
It's a package I used at work before retiring, and it is a bit expensive since the package includes lots of stuff.
However, I purchased it for home since I really like to make professional-looking graphs.
-
I just got off the phone with a useful guy at Rigol's North American office.
He's sending me an e-mail, to which I shall respond with my graphs and data for them to evaluate.
-
I'm using "Grapher" from Golden Software.
Yikes. That is a little pricey, especially as a subscription model. I guess I'll stick with Excel. The graphs definitely look nice though. Excel also makes nice graphs, but I was hoping for something with fewer steps.
-
Hi,
Here on the EEV forum today I made a topic about a simple Filter to learn how to test a scope with Bode Plot capability.
I provide a modified schematic of a bandpass filter that is somewhat less sensitive to load variations.
So that Bode plot characteristics of different types and brands of scoops can be better compared.
I tested it with two types of Siglent scoops, the SDS Plus and the SDS HD, a Rigol scope with Bode Plot capability I do not have.
My tests were done with an external Siglent Function Generator, but of course it can also be done with the Function Generator present in the scope itself, if you have the license for that.
Have fun with the Bode Plot function!
Link to the topic:
https://www.eevblog.com/forum/projects/bode-plot-test-filter/ (https://www.eevblog.com/forum/projects/bode-plot-test-filter/)
Kind regards,
Bram
-
But considering that the whole point of having a DHO900S is more or less the advertized Bode Plot function, what sense does it make to purchase this scope while you've still got to do the "heavy lifting" in a PC.
As with bode plotting on all scopes at this point, they make so many assumptions and fixed decisions that they are unlikely to be the best solution to any given problem. There is a very large parameter/configuration/tradeoff space between different requirements that needs at least several more options (as spectrum analysers do). Using an external programmable something, be that PC or raspberry Pi, is still motivated for anything beyond toy examples.
-
Oh, sigh... I must have misunderstood Cees' post #60 then.
Here's hoping that Rigol do address this next time round. Getting one of the two selling points of the DHO 900 series wrong should be kind of important to them...
Based on the complaints I had regarding the auto ranging, this appears to have been resolved. Elsewhere I have indicated how much interference there is around the AWG and have seen the wrinkels as well. However, it appears that this also depends on the amplitude of the generator and the default value of 200 mV peak to peak is far too low. I myself run at least with 2 volts or higher. Next what I have mentioned was the fixed vertical scales which is still not solved.
-
Using an external programmable something, be that PC or raspberry Pi, is still motivated for anything beyond toy examples.
So what software do you (and others) use to acquire Bode plots? Are there good (and affordable) solutions which can control instruments from various manufacturers via SCPI, and have pre-programmed Bode plot acquisition and display with a good balance of flexibility and ease-of-use?
-
Using an external programmable something, be that PC or raspberry Pi, is still motivated for anything beyond toy examples.
So what software do you (and others) use to acquire Bode plots? Are there good (and affordable) solutions which can control instruments from various manufacturers via SCPI, and have pre-programmed Bode plot acquisition and display with a good balance of flexibility and ease-of-use?
Personally I have started experimenting with Visual Studio C++, and have written a small test program that sets the AWG frequency and amplitude, scales ch1 and takes a sample of the memory and downloads it to a file. It is pretty straight forward, and much easier than I anticipated. One can then analyse the data on the PC. Opens up a world of possibilities.
-
I captured the AWG output at 1kHz/5Vp-p on CH1/1V/div, 200us/div with 62.5Msps and 1Mpts (downloaded 100kpts) and the output is quite noisy of the order of +/- 1.25% or +/-15 counts for a peak of 1200 counts. It also has a noticeable DC bias around +150mV. Can't tell what is the ADC or the AWG yet with regards to noise.
-
Can't tell what is the ADC or the AWG yet with regards to noise.
Take a capture with the same scope settings but a grounded input for comparison?
-
Can't tell what is the ADC or the AWG yet with regards to noise.
Take a capture with the same scope settings but a grounded input for comparison?
Thanks, I'll get there but diner first. :)
-
Did the same test, AWG not running, with a 51R resistor connected across the BNC input and got a similar result. The noise looks repetitive, possibly PSU related, when I get my USB C male breakout connector I'll try again with a battery as the supply.
-
Using an external programmable something, be that PC or raspberry Pi, is still motivated for anything beyond toy examples.
So what software do you (and others) use to acquire Bode plots? Are there good (and affordable) solutions which can control instruments from various manufacturers via SCPI, and have pre-programmed Bode plot acquisition and display with a good balance of flexibility and ease-of-use?
Is free affordable? ;)
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/)
Easy enough to mix and match vendors/instruments with that sort of setup. Bugs are left for the reader to fix! Same package can also produce the pretty plots if desired.
(https://www.eevblog.com/forum/testgear/faster-fra-from-scope-by-external-control-over-visa/?action=dlattach;attach=682136;image)
-
Just pondering how they do the phase/amplitude calculation, the way that comes to mind is an FFT of CH1 and CH2 and extract the amplitude and phase from that. But they would be shortish sample sizes for speed and not synchronised to the input sine. This would lead to both phase and amplitude errors perhaps even the ripple seen. Not sure if that is how they do it or it is even the best way.
No mention in the manual of the method, nor can I find any algorithmic information on Google.
I'm not sure any of the scope manufacturers have detailed what measurement and processing techniques are being used to produce their results, so people have been trying to reverse engineer implementations for curiosity/understanding. A problem is the different possible methods all have their own plusses/minuses but it doesn't appear any of the scopes are offering different modes. Long captures and big FFTs vs hardware averaging, single tone vs chirp vs noise.
Some people think chirps are magical:
https://www.ap.com/blog/how-many-ways-can-we-measure-frequency-response/ (https://www.ap.com/blog/how-many-ways-can-we-measure-frequency-response/)
But from actually building out systems measuring frequency response by optimised chirps, impulse/step response, and stepped sine, I keep coming back to stepped sine due to its dynamic range advantages (which is generally more pressing/extreme in electronics than in acoustics or mechanical/vibration).
-
But considering that the whole point of having a DHO900S is more or less the advertized Bode Plot function, what sense does it make to purchase this scope while you've still got to do the "heavy lifting" in a PC.
As with bode plotting on all scopes at this point, they make so many assumptions and fixed decisions that they are unlikely to be the best solution to any given problem. There is a very large parameter/configuration/tradeoff space between different requirements that needs at least several more options (as spectrum analysers do). Using an external programmable something, be that PC or raspberry Pi, is still motivated for anything beyond toy examples.
What implementation do you refer to (as being too monolitic and not flexible enough) and what do you miss ?
-
But considering that the whole point of having a DHO900S is more or less the advertized Bode Plot function, what sense does it make to purchase this scope while you've still got to do the "heavy lifting" in a PC.
As with bode plotting on all scopes at this point, they make so many assumptions and fixed decisions that they are unlikely to be the best solution to any given problem. There is a very large parameter/configuration/tradeoff space between different requirements that needs at least several more options (as spectrum analysers do). Using an external programmable something, be that PC or raspberry Pi, is still motivated for anything beyond toy examples.
What implementation do you refer to (as being too monolitic and not flexible enough) and what do you miss ?
The obvious first step would be to offer some form of speed vs noise suppression tradeoff for the user to choose. Trying to pull noise out of a switching regulator control loop is a wildly different environment to checking the bandwidth of a filter out of circuit/use. The supplied tools are very rudimentary and this is a space with plenty of scope to build productivity improving solutions, question is there a market big enough for development effort to go into it? So far not so much.
-
But considering that the whole point of having a DHO900S is more or less the advertized Bode Plot function, what sense does it make to purchase this scope while you've still got to do the "heavy lifting" in a PC.
As with bode plotting on all scopes at this point, they make so many assumptions and fixed decisions that they are unlikely to be the best solution to any given problem. There is a very large parameter/configuration/tradeoff space between different requirements that needs at least several more options (as spectrum analysers do). Using an external programmable something, be that PC or raspberry Pi, is still motivated for anything beyond toy examples.
What implementation do you refer to (as being too monolitic and not flexible enough) and what do you miss ?
The obvious first step would be to offer some form of speed vs noise suppression tradeoff for the user to choose. Trying to pull noise out of a switching regulator control loop is a wildly different environment to checking the bandwidth of a filter out of circuit/use. The supplied tools are very rudimentary and this is a space with plenty of scope to build productivity improving solutions, question is there a market big enough for development effort to go into it? So far not so much.
OK, speed argument is not a feature, but we already agreed that is valid point in a separate topic...
Apart from that?
What is so rudimentary it left you wanting..?
I look at my Siglent and see, just of top of my head:
- automatic adaptive /manual level stimulus
- Vary level stimulus (where you draw level/frequency graph to have stimulus vary with frequency). Up to 4 stored profiles.
- offset (for DC biased measurements)
- Amplitude unit and system impedance.
- 3 channels of analysis
- linear and log sweep
- number of points
- Cursor measurements
- Automated measurements of -3dB LP point, HP point and BW
- Automated measurement of GM and PM (gain and phase margin)
- Full control of graphing (auto/manual) mode, axis types, units etc..
- Table data always visible with graph.
- Many more details
- Save CSV data for PC analysis. And with built in networking, you can save directly on PC/server (shared folder) without sticks cards etc.
That is why I asked: what specifically? If it's a good suggestion, I will pass it on to Siglent. They are always listening to ways how to make their products more useful for customers...
-
...
That is why I asked: what specifically? If it's a good suggestion, I will pass it on to Siglent. They are always listening to ways how to make their products more useful for customers...
Really? I got the impression when reviewing and analyzing the SDG6000X that very little of my (IMO reasonable) suggestions have been considered by them. Possibly their Oscilloscope department is more responsive to user / customer wishes.
-
...
That is why I asked: what specifically? If it's a good suggestion, I will pass it on to Siglent. They are always listening to ways how to make their products more useful for customers...
Really? I got the impression when reviewing and analyzing the SDG6000X that very little of my (IMO reasonable) suggestions have been considered by them. Possibly their Oscilloscope department is more responsive to user / customer wishes.
I don't work for Siglent and cannot comment on that. I still have same SDG6000X as you, paid with my own money.
They did fix many original complaints but not all of the suggestions.
I guess there is hardware/software distinction as to what can or cannot be done sometimes to consider.
Anyways, it is for Siglent to answer.
OTOH as you can see from SDS2000X HD topic, there are literally dozens and dozens things implemented as enhancements as per user requests. Fixed memory/sampling mode, more Math channels etc. etc.. In Bode plot alone more than dozen things were added as per user request.. Where it is possible. Higher screen resolution is not gonna happen on existing scope...
-
Yes, this is basically what makes me assume that there are completely differend divisions of the engineering department working on the gear: The Scope and RF (SA/VNA) groups are pretty decent and maintain good "customer relations" while the AWG section -- let's put it like this -- leaves room to improve ;). But that's off topic here, so I'll shut up on this now.
-
I did an FFT plot up to 1MHz for the DHO914s CH1 input with 51R resistor and there are some peaks in the region of 10-100kHz. The vertical scale is db, horizontal Hz, the bins are about 963Hz apart so the high level below 1kHz is just DC.
-
The guy at Rigol has sent my data to the relevant group.
He asked me for data from a "direct" connection, so I disconnected the LP filter network and its BNC to binding post adapters, driving Ch2 through a 12 inch coax from the TEE on Ch1.
Obviously, the resulting gain and phase curves have much less variation over the 1 to 100 kHz, 100 pts/decade scan than had the LPF curves.
Note the dots on the phase curve, showing the actual frequencies for each data point.
The gain curve was reasonably flat (+/- 0.25 dB), but the phase curve shows a similar ripple, with a somewhat longer period.
See attached curves (vertical scales adjusted for new range), which I sent him along with the .csv file.
[attachimg=1]
-
I would try to connect the AWG to the CH1 and do an AWG sweep from 1kHz to 100kHz (w/ proper 50ohm termination).
Look at the CH1 signal envelope - are there the (AM) wiggles as well?
Not sure it will be clearly visible when your wiggle amplitude (aka "AM modulation index") is 6% only..
PS: when none wiggles visible the issue could be a math bug in Bode, otherwise the AWG could be the issue..
-
The guy at Rigol has sent my data to the relevant group.
He asked me for data from a "direct" connection, [...]
Good to read that you reached someone who seemed to care and came back with a relevant follow-up question. Who did you contact? Is there an email address you could share?
-
I would try to connect the AWG to the CH1 and do an AWG sweep from 1kHz to 100kHz (w/ proper 50ohm termination).
Look at the CH1 signal envelope - are there the (AM) wiggles as well?
Not sure it will be clearly visible when your wiggle amplitude (aka "AM modulation index") is 6% only..
PS: when none wiggles visible the issue could be a math bug in Bode, otherwise the AWG could be the issue..
I'll try this later; I'm not sure how to set up a useful frequency sweep. In all the results I have posted here, there was no 50 ohm termination, for frequency < 100 kHz.
Earlier, I used a 50 ohm termination to make sure of the output impedance and drive capability: 5 V pk-pk (maximum AWG setting) gives 5 V pk-pk without, and 2.5 V pk-pk with, the 50 ohm termination.
I don't think the Bode Plot sweep retains Ch1 ("input") data separately, only the ratio Ch2/Ch1 (in dB) and phase difference.
On the narrow-band manual data (70 to 100 kHz) I posted above, https://www.eevblog.com/forum/testgear/rigol-dho914s-bode-plot/msg5102484/#msg5102484 (https://www.eevblog.com/forum/testgear/rigol-dho914s-bode-plot/msg5102484/#msg5102484) , again without 50 ohm termination, the measured pk-pk voltage on Ch1 was quite constant at 2 V pk-pk (probably < 1% pk-pk), and the equivalent graph of voltage ratio and phase shift was acceptably monotonic, using the same frequency points (in that narrow range) as the Bode Plot function used over the wider range. (Those data were obtained before the recent firmware update, but I haven't seen any important difference to the Bode Plot results from that update.)
-
I would try to connect the AWG to the CH1 and do an AWG sweep from 1kHz to 100kHz (w/ proper 50ohm termination).
Look at the CH1 signal envelope - are there the (AM) wiggles as well?
Not sure it will be clearly visible when your wiggle amplitude (aka "AM modulation index") is 6% only..
PS: when none wiggles visible the issue could be a math bug in Bode, otherwise the AWG could be the issue..
I'll try this later; I'm not sure how to set up a useful frequency sweep. In the results I have posted here, there was no 50 ohm termination, for frequency < 100 kHz.
Earlier, I used a 50 ohm termination to make sure of the output impedance and drive capability: 5 V pk-pk (maximum AWG setting) gives 5 V pk-pk without, and 2.5 V pk-pk with, the 50 ohm termination.
I don't think the Bode Plot sweep retains Ch1 ("input") data separately, only the ratio Ch2/Ch1 (in dB) and phase difference.
On the narrow-band manual data (70 to 100 kHz) I posted above, again without 50 ohm termination, the measured pk-pk voltage on Ch1 was quite constant at 2 V pk-pk (probably < 1% pk-pk), and the equivalent graph of voltage ratio and phase shift was acceptably monotonic, using the same frequency points (in that narrow range) as the Bode Plot function used over the wider range.
My test above is not made with the "Bode" o'scope functionality.
It shows you the "envelope" of the AWG sweep.
Thus the setup is simply AWG->Ch1 (50ohm terminated), do the sweep, watch the "envelope" of the signal in CH1.
Your Bode wiggles mean the CH1 signal envelope shall be 6% amplitude modulated, provided the Bode wiggle issue comes from the AWG.
When the envelope of the sweep signal is clean (none AM modulation), your wiggles in Bode come from math bug in Bode.
-
I would try to connect the AWG to the CH1 and do an AWG sweep from 1kHz to 100kHz (w/ proper 50ohm termination).
Look at the CH1 signal envelope - are there the (AM) wiggles as well?
Not sure it will be clearly visible when your wiggle amplitude (aka "AM modulation index") is 6% only..
PS: when none wiggles visible the issue could be a math bug in Bode, otherwise the AWG could be the issue..
I'll try this later; I'm not sure how to set up a useful frequency sweep. In the results I have posted here, there was no 50 ohm termination, for frequency < 100 kHz.
Earlier, I used a 50 ohm termination to make sure of the output impedance and drive capability: 5 V pk-pk (maximum AWG setting) gives 5 V pk-pk without, and 2.5 V pk-pk with, the 50 ohm termination.
I don't think the Bode Plot sweep retains Ch1 ("input") data separately, only the ratio Ch2/Ch1 (in dB) and phase difference.
On the narrow-band manual data (70 to 100 kHz) I posted above, again without 50 ohm termination, the measured pk-pk voltage on Ch1 was quite constant at 2 V pk-pk (probably < 1% pk-pk), and the equivalent graph of voltage ratio and phase shift was acceptably monotonic, using the same frequency points (in that narrow range) as the Bode Plot function used over the wider range.
My test above is not related to the "Bode" o'scope functionality.
It shows you the "envelope" of the AWG sweep.
Thus the setup is simply AWG->Ch1 (50ohm terminated), do the sweep, watch the "envelope" of the signal in CH1.
Your Bode wiggles mean the envelope shall be 6% amplitude modulated, provided the Bode wiggle issue comes from the AWG.
When the envelope of the sweep signal is clean (none AM modulation), your wiggles in Bode come from math bug in Bode.
Bode plot is RELATIVE measurement. You can have AWG amplitude vary (and in fact that is being used by Bode plot implementation if it is done right) all over the place, it shouldn't make a difference.
-
Bode plot is RELATIVE measurement. You can have AWG amplitude vary (and in fact that is being used by Bode plot implementation if it is done right) all over the place, it shouldn't make a difference.
Yep, but he has got wiggles with straight AWG->CH1-Ch2 connection (see the above graph).
There is always 1:1 ratio.
Thus with my test you get whether the wiggles come from Bode math bug, or the AWG wobbles in the amplitude with 6% (0.5dB) modulation index..
PS: the 3rd issue could be there is a phase shift (or jitter or something like that) between CH1 and CH2 when doing Bode..
-
The guy at Rigol has sent my data to the relevant group.
He asked me for data from a "direct" connection, [...]
Good to read that you reached someone who seemed to care and came back with a relevant follow-up question. Who did you contact? Is there an email address you could share?
Can you persuade them to follow the bugs thread?
-
Bode plot is RELATIVE measurement. You can have AWG amplitude vary (and in fact that is being used by Bode plot implementation if it is done right) all over the place, it shouldn't make a difference.
Yep, but he has got wiggles with straight AWG->CH1-Ch2 connection (see the above graph).
There is always 1:1 ratio.
Thus with my test you get whether the wiggles come from Bode math bug, or the AWG wobbles with 6% (0.5dB) modulation index..
I am new to DSOs with built-in AWG, so I'm not sure how to set up a frequency sweep on this unit.
When I scanned the same circuit manually, relying on the Vpp measurement tool on Ch1 and Ch2, there was very little amplitude change on Ch1 (no 50 ohm termination, just 9100 ohms in the LPF), although Ch2 (after the filter) followed the expected variation.
On manual point, by mistake, used a different AWG output setting, but the result in the voltage ratio was negligible.
-
...
Bode plot is RELATIVE measurement. You can have AWG amplitude vary (and in fact that is being used by Bode plot implementation if it is done right) all over the place, it shouldn't make a difference.
And this exactly isn't the case here, see these two 1kHz~100kHz sweeps, 50pts/dec with equal signals to both inputs AWG -> 30cm Coax -> (BNC-Through-Terminator) -> T-Piece central leg -> 2 * 30cm Coax to each input.
In RigolCSV11, the terminator is installed, so the effective input voltage to the scope was 2.5Vpp (5Vpp AWG output), while in RigolCSV12, the terminator was left out and the coax from the AWG was directly coupled to the T-Piece central leg, so both scope inputs were seeing 5Vpp.
I verified before that the signals were identical and even adjusted the "Channel Skew" at 25MHz so there wasn't any delay between the channels (had to adjust channel 2 by ~700ps) which weren't caused by the cables (reversal of the inputs didn't make any change). After that, I ran the Bode Plots and found what's shown below. The funny thing about this all is that the channel-to-channel phase measurement, if used separately, only shows a difference between the channels of <0.1°, basically "dithering" in the noise. I hope Rigol can make sense of this... :-//
-
What would happen if you do the above measurement with say 5V and 2.5V AWG amplitude and terminated 50ohm in both cases?
Thinking loud - whether 50ohm termination on CH1 and CH2 is required in this rig when doing Bode with the AWG's 50ohm output..
Even though 1-100kHz are pretty low freqs to mess up the matching.. Or perhaps the 50ohm matching plays a role in the math inside the box?
-
Tom,
Could you check the AWG amplitude stability over the frequency sweep with a good SA using peak hold? Not much help with phase but could show if the source of this "ripple" is the AWG and not the DSO.
Anyway, just a thought.
Edit: Think you found a correlation between scope trace position selection/movement and offset from AWG that may be related to unstable internal scope bias/rail voltages. Could this "ripple'" effect be related to such??
Best,
-
Interesting that the amplitude and phase error curves are so similar, and I think 2N3055 is correct that it's probably not the AWG since it is a relative measurement. It's not noise because it is too repeatable that leaves math i.e. their algorithm.
-
There was a suggestion early-on that I should use a shielded network for this test to eliminate possible high-frequency pickup from the "naked" wires and components.
Therefore, I made a simple box (after I discovered I was out of BNC connectors and had to wait for an order).
Also, I carefully measured the actual R and C values to get the theoretical corner frequency fc (-3 dB and -45 deg).
The C was measured with the BNC included, and 15 pF added for the input capacitance of CH2 on the 'scope.
The R value was measured between BNCs, and (slightly) corrected for the 50 \$\Omega\$ (series) output resistance of the AWG and the 1 megohm (parallel) input resistance of CH1.
C = 1,987 pF. R = 8,859\$\Omega\$, Therefore, fc = 9,041 Hz.
Summary: the curves still wiggle, perhaps a bit less than before.
However, the eyeball value of fc remains closer to the older eyeball value of 11.6 kHz (which should have been 10.66 kHz with the older component values) than the new calculated value of 9.04 kHz.
(See fiducials at older value of 11.6 kHz and new calculated value of 9.04 kHz.)
[attachimg=1]
-
Maybe a Rigol MSO5000 owner can present a bode plot of a RC element with similar values here.
The bodeplot function was implemented there after my MSO5000 time, i.e. it was not part of the actual development of the scope.
-
Another investigation of my DHO914S with the shielded low-pass filter between CH1 and CH2.
I had carefully measured the actual R and C values for the box (including the effects of the AWG output resistance and CH2 input resistance and capacitance) for my previous post, giving a calculated corner frequency of 9040 Hz.
In the data set below, I manually stepped the frequency from 8,000 to 12,600 Hz in 200 Hz increments (plus one at 9,040 Hz), noting the CH2 V(pk-pk) and phase (CH1 - CH2) from the "Avg" results posted by the 'scope.
The solid lines are the measurements (with dots on the measured gain curve to show data points), while the dashed lines are calculated directly from the 9,040 Hz corner frequency.
While the solid lines do not have the "wiggles" found on the automated Bode Plots I did before, there are noticeable systematic discrepancies between the measured and calculated curves.
Fiducials were added at 9,040 Hz (expected) and 10,000 Hz (eyeball fit), as before.
To verify the connections, I reduced the frequency to 100 Hz and measured 0 dB and about 0.5 deg, as expected.
I have sent these results to Rigol for their consideration.
I am also open to suggestions about how to do these tests; I already found that I needed to reduce the "counts" setting for the measurement results from default of 1000 to 50, to speed up the average's settling after changing frequency.
[attachimg=1]
-
The plots look reasonably good to me. I previously mentioned that I did some noise and AWG SIN wave measurements, by downloading the memory data to my PC. The noise on my scope was around +/-15 counts out of 4096 counts or +/- 0.4% of fullscale. If the waveform isn't fullscale on the scope then the noise will be relative to the signal larger. When searching for zero crossings and peaks a degree of filtering was necessary and uncertainty remained. It's not terrible but good filtering is necessary for good results. You might want to increase the waveform averages, but that will slow down results, as well as the memory depth, this will increase the sample rate and might give a little more resolution.
-
The plots look reasonably good to me.
I would like to see a screenshot of this.
-
The plots look reasonably good to me. I previously mentioned that I did some noise and AWG SIN wave measurements, by downloading the memory data to my PC. The noise on my scope was around +/-15 counts out of 4096 counts or +/- 0.4% of fullscale. If the waveform isn't fullscale on the scope then the noise will be relative to the signal larger. When searching for zero crossings and peaks a degree of filtering was necessary and uncertainty remained. It's not terrible but good filtering is necessary for good results. You might want to increase the waveform averages, but that will slow down results, as well as the memory depth, this will increase the sample rate and might give a little more resolution.
I'll look at memory depth. I didn't see any appreciable effect from measurement averages (in the manual scans) except to slow the measurement settling time.
With 2 V pk-pk out of the AWG and 0.5 V/div, the voltages are a reasonable fraction of full-scale.
I think there must be some firmware bugs in the measurement display, as well: after changing the frequency, and waiting for the averaging to settle, the Max and Min values did not change and are much farther apart than the "Dev" would indicate.
The manual does not give any useful details about these variables.
(There are no screenshots for this latest graph of mine: data were entered manually from the "Result" listing into Excel, thence to Grapher.)
-
The plots look reasonably good to me. I previously mentioned that I did some noise and AWG SIN wave measurements, by downloading the memory data to my PC. The noise on my scope was around +/-15 counts out of 4096 counts or +/- 0.4% of fullscale. If the waveform isn't fullscale on the scope then the noise will be relative to the signal larger. When searching for zero crossings and peaks a degree of filtering was necessary and uncertainty remained. It's not terrible but good filtering is necessary for good results. You might want to increase the waveform averages, but that will slow down results, as well as the memory depth, this will increase the sample rate and might give a little more resolution.
I'll look at memory depth. I didn't see any appreciable effect from measurement averages (in the manual scans) except to slow the measurement settling time.
With 2 V pk-pk out of the AWG and 0.5 V/div, the voltages are a reasonable fraction of full-scale.
I think there must be some firmware bugs in the measurement display, as well: after changing the frequency, and waiting for the averaging to settle, the Max and Min values did not change and are much farther apart than the "Dev" would indicate.
The manual does not give any useful details about these variables.
(There are no screenshots for this latest graph of mine: data were entered manually from the "Result" listing into Excel, thence to Grapher.)
That is a shame, I thought averages would improve the resolution, they certainly should. It looks like you are doing everything well, not that you need my approval. The only thing left is to download the raw samples to a PC and do all the calculations yourself, but that kind of defeats the whole purpose! I don't expect sample depth/rate to make much if any difference but it's worth a try. :)
-
After having decided to return the scope and prepared the shipment, I'm looking at the whole situation somewhat more relaxed ;). Of course, I very well understand the urge to understand what's going on here -- I've been in the same boat just a few days ago and contributed with quite some observations.
But viewed from the "other side" of having made a decision, I actually can only recommend not to spend your time on a product that's not ripe for the market yet and let Rigol do their job, don't do it for them!
If the distributor where you purchased your scope offers a return policy, return it ASAP. This will make Rigol feel that there's something wrong with their approach to supply unfinished products to paying customers, and maybe finally change their attitude (though it's likely they won't...).
IMO, it's not worth spending valuable time on a product that shouldn't have been supplied as faulty as this one without any warranty that it will get fixed eventually :-//.
-
After having decided to return the scope and prepared the shipment, I'm looking at the whole situation somewhat more relaxed ;). Of course, I very well understand the urge to understand what's going on here -- I've been in the same boat just a few days ago and contributed with quite some observations.
But viewed from the "other side" of having made a decision, I actually can only recommend not to spend your time on a product that's not ripe for the market yet and let Rigol do their job, don't do it for them!
If the distributor where you purchased your scope offers a return policy, return it ASAP. This will make Rigol feel that there's something wrong with their approach to supply unfinished products to paying customers, and maybe finally change their attitude (though it's likely they won't...).
IMO, it's not worth spending valuable time on a product that shouldn't have been supplied as faulty as this one without any warranty that it will get fixed eventually :-//.
Personally I am quite happy with my purchase in spite of its foibles. I do expect Rigol to remedy many of the issues, but I also agree it looks rushed for sale. Being an engineer as we are, we like to investigate and we are all benefiting from TimFox's investigations even Rigol indirectly or directly. :)
-
Update on my communications with Rigol: (Rigol NA had escalated my case back to the R&D department).
Today, I received a request from the FAE department in China for information on my tests, so I wrote a 9-page organized memo with my relevant results, and sent it to them this afternoon, with attached data files.
-
Update on my communications with Rigol: (Rigol NA had escalated my case back to the R&D department).
Today, I received a request from the FAE department in China for information on my tests, so I wrote a 9-page organized memo with my relevant results, and sent it to them this afternoon, with attached data files.
Did you report anything other than Bode plot?
-
Personally I am quite happy with my purchase in spite of its foibles. I do expect Rigol to remedy many of the issues,
Me too.
but I also agree it looks rushed for sale.
The holiday season is here, they need to get them on shelves. :)
AFAIK NO manufacturer can get oscilloscopes right on initial release.
So... if supposedly knowledgeable people buy a cheap-as-chips oscilloscope that's so new that there's still a waiting list to get one, from a manufacturer that isn't famous for speedy/regular firmware updates...
...forgive me for finding it amusing when thay act all indignant about having a few bugs then post several times about how they're sending theirs back because they have some important work that needs doing.
If you have work to do and need a specific function then buy something you know will do it. Anything else reflects more on you than on Rigol.
-
Personally I am quite happy with my purchase in spite of its foibles. I do expect Rigol to remedy many of the issues,
Me too.
Good for you.
but I also agree it looks rushed for sale.
The holiday season is here, they need to get them on shelves. :)
AFAIK NO manufacturer can get oscilloscopes right on initial release.
So... if supposedly knowledgeable people buy a cheap-as-chips oscilloscope that's so new that there's still a waiting list to get one, from a manufacturer that isn't famous for speedy/regular firmware updates...
...forgive me for finding it amusing when thay act all indignant about having a few bugs then post several times about how they're sending theirs back because they have some important work that needs doing.
If you have work to do and need a specific function then buy something you know will do it. Anything else reflects more on you than on Rigol.
If you're referring to Thomas, he certainly is very knowledgeable about electronics.
Again ad hominem attack from you.
Are you suggesting if you are smart you should have known that: Rigol will release buggy and half functional product and Rigol does not care to fix bugs because people who buy Rigol products don't do any important work and Rigol products are not meant to work properly anyways.
Is that what you are saying? I certainly would not say that about Rigol, despite their shortcomings.
Also, you used word "indignant" as derogative, something that you project as a character flaw.
While, in fact, it means "feeling or showing anger or annoyance at what is perceived as unfair treatment."
Which is how everybody should feel if you are cheated. And to make it clear, Thomas wasn't "indignant" because scope did not have "some special function".
He bought it for functions that are in the datasheet and are stated as being there. DHO900 claimed it had specific functions he needed, it just was so badly made it was unusable. He paid for it with his own money. And he found it wanting, felt cheated and sent it back.
Your statements certainly reflect more on you than having anything to do with Rigol products.
I like that one..
-
...
So... if supposedly knowledgeable people buy a cheap-as-chips oscilloscope that's so new that there's still a waiting list to get one, from a manufacturer that isn't famous for speedy/regular firmware updates...
...forgive me for finding it amusing when thay act all indignant about having a few bugs then post several times about how they're sending theirs back because they have some important work that needs doing.
If you have work to do and need a specific function then buy something you know will do it. Anything else reflects more on you than on Rigol.
I assume you are pointing fingers at me here, Fungus, and you may be partially right. I purposely ordered the scope at a distributor who offers the no-questions-asked return policy for this situation.
But we may argue about your terminus "few bugs". I'ld rather consider the findings major shortcomings than just bugs. Please keep in mind that I would have spent round about 1000€ on the DHO914S including the digital porobe set.
I considered buying only the scope and making the probe set myself as per the instructions found here and elsewhere but finally decided against that since Rigol's digital probe set comes with proper connector housings, fast adjustable threshold comparators, a wide input voltage range (so I can even use it on ancient p-mos circuitry -- sometimes I'm a sucker for ancient calculators, right now I've got a broken Compucorp 326 calculator with a faulty ROM chip on my hobby table) and comes with resistive interconnects and 32 quality microclips which adds up to combined representing some value for the money, considering the time required for a DIY solution and the limited performance (but that's OT).
I several times told that I still consider the DHO800 a good choice, especially after Rigol will eventually have addressed the problems found so far. Btw, IMO the sampling / aliasing findings are not a real issue (for the DSO only modes -- the additional cut by half when the digital channels are enabled is a no-go). Maybe they would be for someone new to DSOs, but once familiar with with the matter, you just have to observe the sampling frequency and know what kind of signals you can measure accurately and what not, and if unsure, start with a single channel and enable additional channels as possible/required. It's just a question of common sense and some discipline.
But if I intend buy a new product for a sum that's not too far from other, proven working products, I at least expect it to provide the promised features in a way that they are useable / useful. I gave Rigol a chance despite knowing of their history of slow problem solving, assuming / hoping they have learned from the past, only to find that basically all the added functionality that I intended to buy the DHO900 for, are unfinished construction sites or hardware-limited to a degree that wasn't forseeable from analyzing the teardowns and early reports of the product. So I decided to pull the safety-line, that's it.
I've got enough equipment that covers the basic oscilloscope functions, but if I've got (or just want) to replace one of these in future, the DHO800 is probably still high on the list, provided its performance matches the requirements.
If this approach amuses you, well, I'm glad you found some "joy" in my contributions ;)
All the best,
Thomas
-
IMHO, the Rigol will not start to fix faster and will not start to produce better sw/fw quality products unless the buyers will simply start to return their products back. It could easily be their leaders consider their products perfect as they do not see such a tangible buyer's feedback in their $$ numbers.. ;D
-
I considered buying only the scope and making the probe set myself as per the instructions found here and elsewhere but finally decided against that since Rigol's digital probe set comes with proper connector housings, fast adjustable threshold comparators, a wide input voltage range (so I can even use it on ancient p-mos circuitry -- sometimes I'm a sucker for ancient calculators, right now I've got a broken Compucorp 326 calculator with a faulty ROM chip on my hobby table -- and comes with resistive interconnects and 32 quality microclips which adds up to combined representing some value for the money, considering the time required for a DIY solution and the limited performance (but that's OT).
Nice to see someone with a similar obscure interest here! :) The large input voltage range was what got me interested in the Rigol logic probe (and potentially the DHO900) as well. The LGP-30 I am occasionally working on has logic levels of -20V and 0V... And it's a train trip away from me, so a portable scope would be nice.
Even with the compromised sampling rates, the DHO900 logic analyzer (with or without use of the analog channels) still has better specs than the Saleae Logic Pro 16, which costs 1.5x the price and does not support the large input voltage range. So I am still on the edge: I am very disappointed with Rigol that they did not publish an honest spec sheet, but even the compromised specs are quite competitive.
I will definitely wait and see whether Rigol gets the Bode wiggles fixed (and quickly!). Back when the DS1054Z was released, I bought mine right after Rigol had fixed the "jitter bug" it had originally been released with, which took them about three months. Let's see whether they repeat that story with the Bode plot on the DHOs. And let's see whether Siglent make up their mind on a price for the SDS1000X HD in the meantime, which might make the decision easier -- or more difficult...
EDIT: It only took 6 weeks from publishing the "5µs jitter bug" in an EEVblog video (#683, 14 Nov 2014) to having a firmware fix from Rigol. They actually published a Beta fix on the forum even earlier, but the first attempt did not work properly. The fix released around New Year did the trick then.
Maybe we should ask Dave to make a video about the "Bode wiggle bug" too, to speed things up? ::)
-
IMHO, the Rigol will not start to fix faster and will not start to produce better sw/fw quality products unless the buyers will simply start to return their products back. It could easily be their leaders consider their products perfect as they do not see such a tangible buyer's feedback in their $$ numbers.. ;D
An EEVblog video about the "Bode wiggle bug" would probably be a more effective way to get Rigol's attention. As mentioned above, it got them to fix the "5µs jitter bug" in the DSO1054Z within 6 weeks after video #683 was published. (That bug was even nastier than the Bode problem, since it affected the core scope functionality.)
I think the percentage of returned scopes will always be small, since most users will not do a detailed evaluation right after purchasing. And those who do return it may do so for various reasons -- including "harmless" ones like finding the screen too small for their hands or eyes etc. I would not expect the resellers and Rigol to even collect information about the reasons for returns, hence specific bugs might not get direct attention that way. To put the spotlight on a really obnoxious bug, nothing beats public visibility...
EDIT: Fixed the mangled video reference, it's #683.
-
Has Rigol been providing timely fixes for bugs reported on their other DHO platform scopes? I would have expected the second model series released to have less bugs and the DHO800 and 900 series to have even less. If not less, then I would expect the bugs to be limited to UI layout and other series specific differences.
I hope Rigol's software team is using a common code base and stabilizing the whole platform rather than working on each one in isolation. I also hope that Rigol has developed a quality automated software unit test suite to help them do this. Are these things too much to hope for?
-
Update on my communications with Rigol: (Rigol NA had escalated my case back to the R&D department).
Today, I received a request from the FAE department in China for information on my tests, so I wrote a 9-page organized memo with my relevant results, and sent it to them this afternoon, with attached data files.
Did you report anything other than Bode plot?
I also reported the measurements I made manually, using the magnitude and phase measure functions, stepping the frequency through narrow ranges.
For the second set, I had shielded the filter components and carefully measured the actual resistance and capacitance (including connectors) to calculate the -3 dB point.
The measured frequency for -3 dB and -45o was about 10% higher than the calculated frequency; otherwise, the curves were smooth.
-
Has Rigol been providing timely fixes for bugs reported on their other DHO platform scopes? I would have expected the second model series released to have less bugs and the DHO800 and 900 series to have even less. If not less, then I would expect the bugs to be limited to UI layout and other series specific differences.
The DHO900-specific features (AWG, Bode plot, logic analyzer) are not available in the earlier DHO models, hence could not benefit from prior testing in the DHO1000 and 4000.
A few bugs were found in the basic scope functionality of the DHO800, mostly by Serg65536 (e.g. curves disappearing upon scrolling or zooming while in STOP mode). No idea whether these have crept in during the transition to a smaller FPGA, or have already been present in the larger DHO models -- I don't think the DHO1000 and 4000 have received the same attention and scrutiny here.
-
Has Rigol been providing timely fixes for bugs reported on their other DHO platform scopes? I would have expected the second model series released to have less bugs and the DHO800 and 900 series to have even less. If not less, then I would expect the bugs to be limited to UI layout and other series specific differences.
The DHO900-specific features (AWG, Bode plot, logic analyzer) are not available in the earlier DHO models, hence could not benefit from prior testing in the DHO1000 and 4000.
And that's where most of the bugs are.
A few bugs were found in the basic scope functionality of the DHO800, mostly by Serg65536 (e.g. curves disappearing upon scrolling or zooming while in STOP mode). No idea whether these have crept in during the transition to a smaller FPGA, or have already been present in the larger DHO models -- I don't think the DHO1000 and 4000 have received the same attention and scrutiny here.
The only other one I know of is the serial decoder threshold voltage. The voltage level doesn't take into account the probe attenuation settings so it's only correct when probes are set to 1x. If you set the probes to (eg.) 10x then you have to set the threshold voltage voltage 10x higher for it to work.
Edit: One other bug I found - it doesn't save the setting for zoom/fine control when you push the horizontal timebase knob.
-
https://www.youtube.com/watch?v=3TAeSheBUl4 (https://www.youtube.com/watch?v=3TAeSheBUl4)
-
That's TurboTom's video, and he reported this on the forum earlier:
https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5112108/#msg5112108 (https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5112108/#msg5112108)
-
Hi guys, can you confirm please that the Bode Plot function still doesn't work with the accuracy one would expect, neither with the latest firmware?
Cheers.
-
I am still in communication with Rigol, but was unaware of any firmware updates since the first one in early October.
I noticed on another thread that there is an early November update that I haven't used--no one informed me, despite my having registered the product.
The release notes did not mention the Bode Plot function.
Over the next week, I intend to send them more data, after my original organized data report sent to them in late October, most of which I posted in this thread.
-
i tried on prototype board on DHO804 also get same wobbly effect...
https://www.eevblog.com/forum/testgear/rigol-dho804-bode-plot (https://www.eevblog.com/forum/testgear/rigol-dho804-bode-plot)
(https://www.eevblog.com/forum/testgear/rigol-dho804-bode-plot/?action=dlattach;attach=1953054;image)
-
i tried on prototype board on DHO804 also get same wobbly effect...
First, congratulations on getting a signal from your replica AWG board! :-+
In your Bode plot, I can't see the characteristic periodic wiggles others have reported. The distortions seem more irregular, both on the phase and amplitude curve. Could you try to re-run the plot with more data points per decade? -- Also, what did you use for your device under test?
-
i tried on prototype board on DHO804 also get same wobbly effect...
In your Bode plot, I can't see the characteristic periodic wiggles others have reported. The distortions seem more irregular, both on the phase and amplitude curve. Could you try to re-run the plot with more data points per decade? -- Also, what did you use for your device under test?
if 50 points per decade, there are 5 decades there, ie 250 points, its going to be too long time to finish and a lot of front end relay clicking, the algorithm is too inefficient imho. maybe later if i need more serious DUT to specify, but i can already see the problem doing the short test, i suspect DHO800/900 use Vpp measured on screen to make bode plot, hence this will include noises and invalidate bode plot, so i guess no point to do more test with more data points.
i suggest using FFT method, i've done this long time ago with DS1052E and Hantek DDS3x25 iirc succesfully. i stated few suggestions to rigol on the linked thread (if they happen to get to the message). and the DUT i used in the test can be seen in the video linked in the thread linked above.
tbh, bode plot is not my cup of tea, i'm only exploring the full potential of the DHO800 fw and hw hack. attached is the bode plotter pc app i made like 10 years ago, and then never use it :palm: cheers.
-
I think I have a guess as to why the Bode Plot feature has weird bends or corners in it (the "wiggles" issue is separate). They are simply drawing the points at the wrong horizontal position in the graph. The measurements themselves are fine; it's just displayed wrong.
For some reason, at each decade boundary, the 1st sample to the right of the boundary has an unusually large horizontal jump that is inconsistent with the ones that follow it. In contrast, the 1st sample to the left has a small jump that is consistent with the ones that precede it.
In the 3 photos, 300 points per decade was used. This made the delta Hz between samples small. The 1st photo shows the cursor at 9.92 kHz, the 2nd at 10.00 kHz, and the 3rd at 10.08 kHz. Notice the cursor make a small horizontal jump from 9.92 to 10.00 kHz while it is large for 10.0 to 10.08 kHz. The 2nd jump should instead be slightly smaller than the first due to the logarithmic scale.
The Excel file and chart were taken directly from the Rigol's measurements generated by the same Bode plot.
I'll report this to Rigol's support.
Apologies if someone else already covered all this.
-
I think I have a guess as to why the Bode Plot feature has weird bends or corners in it (the "wiggles" issue is separate). They are simply drawing the points at the wrong horizontal position in the graph. The measurements themselves are fine; it's just displayed wrong.
how can you say measurements are fine when you get wiggles as well in excel plot?
-
I'll report this to Rigol's support.
On the Rigol EU and the Rigol NA page the last firmware update is from december 2023.
It doesn't look like anyone at rigol was interested in that.
-
I think I have a guess as to why the Bode Plot feature has weird bends or corners in it (the "wiggles" issue is separate). They are simply drawing the points at the wrong horizontal position in the graph. The measurements themselves are fine; it's just displayed wrong.
how can you say measurements are fine when you get wiggles as well in excel plot?
The graphs I showed at the beginning of this thread were all done by taking the .CSV file of raw data ("Result") and graphing them through a separate graphing program (GrapherTM from Golden Software), not using the Rigol display graph. Besides the "wiggles", I found quantitative errors on the frequency of the -3dB points.
see https://www.eevblog.com/forum/testgear/rigol-dho914s-bode-plot/msg5109597/#msg5109597 (https://www.eevblog.com/forum/testgear/rigol-dho914s-bode-plot/msg5109597/#msg5109597)
-
I think I have a guess as to why the Bode Plot feature has weird bends or corners in it (the "wiggles" issue is separate). They are simply drawing the points at the wrong horizontal position in the graph. The measurements themselves are fine; it's just displayed wrong.
how can you say measurements are fine when you get wiggles as well in excel plot?
I expect some imprecision in the measurements for this device so the wiggles are expected. However, the accuracy of the Excel graphs are night and day better because the macro-level graph mangling the scope displays with all the weird bends / corners are absent in the Excel graph.
-
I'll report this to Rigol's support.
On the Rigol EU and the Rigol NA page the last firmware update is from december 2023.
It doesn't look like anyone at rigol was interested in that.
I reported several bugs back in February and March that were well received by Rigol. I've been told that one of them has been fixed for an upcoming firmware release (no release date). This is more communication than I expected.
However... it's been 7 months since a firmware release. I worry that Rigol is already abandoning their newest scope.
-
That's the drama of the actually not bad Scope series, it's so quiet from Rigol's side.
They had updated the firmware so that it no longer crashed and that was it.
At least something is still happening with the 1000/4000s.
-
That's the drama of the actually not bad Scope series, it's so quiet from Rigol's side.
Yep. It's getting a bit long now...
The list of bugs isn't long or complex, just silly errors like not multiplying the serial decoder threshold by the probe scale factor - one line of code to fix!
A couple of days work could probably fix most of them.
It's hard to understand what they're playing at after all the effort that must have gone into bringing this to market with a totally new OS, etc. Is the software team immediately disbanded on launch day...? :-//
-
In October of 2023, I sent a long carefully-written memo, with graphs and attached .xlsx files, to the home engineering department (contact from US office), who acknowledged receipt.
The Bode function results were all for 1 to 100 kHz, log scan, with a simple well-shielded R-C filter (9 kHz nominal -3 dB point).
No answer since then.
When was the last firmware update posted for the DHO914S?
Anyway, when (very slowly) manually stepping through a narrow frequency range, the curves were monotonic (with a very small ripple), but the actual frequencies for -3 dB and -45o were off by about 10%.
-
@Fungus:
The problem with the bodeplot also needs to be fixed, as well as the incorrect (at least one) window coefficients in the FFT. A constant RBW unit designation would also be nice in this context, as well as possibly a display of the current memory points.
More complex features such as a peak or average function for the FFT will probably not come, as these two functions are not even available on the DS70000.
In my MSO5000 days, I had almost weekly contact with rigol support, with a lively exchange about bugs and feature suggestions, including the Bodeplot, which later became available.
Later, however, there were also answers like “we have to launch the MSO8000 first, then we'll probably continue”.
That was between 2018 and 2020, when I had my DHO800 and wrote to support twice, I never received a reply.
In the meantime, I think the chances of rigol taking “proper” care of the DHO800/900 series again are 30:70.
I rather fear that improvements will only come with a new series.
That would be very unwise of them, because it would destroy trust.
-
Did you ever tried to ask a big vendor, say TI, to improve a thing which is already sold? Not to fix the silicon, but to update the errata sheet or something like that. Rigol also went public. Perhaps the top guys there were indoctrinated in the same MBA school.
-
Did you ever tried to ask a big vendor, say TI, to improve a thing which is already sold? Not to fix the silicon, but to update the errata sheet or something like that. Rigol also went public. Perhaps the top guys there were indoctrinated in the same MBA school.
Instrument vendors do actually fix things after release. Not maybe taking every customer wish, but if they find that instrument is not performing properly they fix it. Keysight does it. R&S does it (they sometimes take time but they fix). Siglent fixes things too, actually better than them sometimes.
Rigol is actually worst by a mile in that regard. I think that Fungus might not ne far with question if development is disbanded quickly after release. It certainly seems so...
-
The list of bugs isn't long or complex, just silly errors like not multiplying the serial decoder threshold by the probe scale factor - one line of code to fix!
There is a recent DHO1000/4000 firmware update which has apparently fixed the serial decode probe scale. It wasn't an exciting update but maybe something is on the way for DHO800/900.
https://www.eevblog.com/forum/testgear/rigol-hdo1000-and-hdo4000-12bit-oscilloscopes-launched-in-china/msg5547705/#msg5547705 (https://www.eevblog.com/forum/testgear/rigol-hdo1000-and-hdo4000-12bit-oscilloscopes-launched-in-china/msg5547705/#msg5547705)
-
The list of bugs isn't long or complex, just silly errors like not multiplying the serial decoder threshold by the probe scale factor - one line of code to fix!
There is a recent DHO1000/4000 firmware update which has apparently fixed the serial decode probe scale. It wasn't an exciting update but maybe something is on the way for DHO800/900.
https://www.eevblog.com/forum/testgear/rigol-hdo1000-and-hdo4000-12bit-oscilloscopes-launched-in-china/msg5547705/#msg5547705 (https://www.eevblog.com/forum/testgear/rigol-hdo1000-and-hdo4000-12bit-oscilloscopes-launched-in-china/msg5547705/#msg5547705)
Problem is that it has been 2 years since 1000/4000 were released, in 2022....
Not what I would call maximum effort......
-
Instrument vendors do actually fix things after release. Not maybe taking every customer wish, but if they find that instrument is not performing properly they fix it. Keysight does it. R&S does it (they sometimes take time but they fix). Siglent fixes things too, actually better than them sometimes.
The monetary relationships between KS, R&S and their customers are of a very different scale. Similar to the service life of the equipment. The fact that Rigol, Siglent, etc. are also providing the fixes is actually a matter of good will. Perhaps it's more profitable to keep releasing new cheap toys frequently making many users happy to play with them. But I think it'll be not fair to assume that the vendors are intentionally evil. Although they may have a more important, actually not commercial customer, the capabilities can also be a factor. The software consumes the majority of man-hours, not the hardware. If you check the Rigol internet site, you can read that in 2024 a new SW development center is set up somewhere in center China, at the former silk road. That probably means that currently the SW development capability of Rigol is not great, while it's now too expensive to continue to order the development from outside than do that work in-house. Let's wait...
-
There is a recent DHO1000/4000 firmware update which has apparently fixed the serial decode probe scale. It wasn't an exciting update but maybe something is on the way for DHO800/900.
They definitely know about the bugs.
-
Instrument vendors do actually fix things after release. Not maybe taking every customer wish, but if they find that instrument is not performing properly they fix it. Keysight does it. R&S does it (they sometimes take time but they fix). Siglent fixes things too, actually better than them sometimes.
The monetary relationships between KS, R&S and their customers are of a very different scale. Similar to the service life of the equipment. The fact that Rigol, Siglent, etc. are also providing the fixes is actually a matter of good will. Perhaps it's more profitable to keep releasing new cheap toys frequently making many users happy to play with them. But I think it'll be not fair to assume that the vendors are intentionally evil. Although they may have a more important, actually not commercial customer, the capabilities can also be a factor. The software consumes the majority of man-hours, not the hardware. If you check the Rigol internet site, you can read that in 2024 a new SW development center is set up somewhere in center China, at the former silk road. That probably means that currently the SW development capability of Rigol is not great, while it's now too expensive to continue to order the development from outside than do that work in-house. Let's wait...
I would prefer if you would exclude Siglent in rationalizing why Rigol thinks it is OK to release alpha level products and never fix them. Because Siglent definitelly tries to not do that, and invests significant effort in that.
And talking about cheap toys, Rigol DHO4000 is definitely "Big Boys" price and not an entry level instrument either.
And that on also receives no update form many bugs reported on whole platform, after being released 2 years ago.
I also know that Rigol is investing serious money into developing new products and chipsets etc.
It is their DECISION to deliberately skimp on FW development....
It is their strategy.
As long as users keep buying "half cooked" products and keep "defending" "poor Rigol" for it, they will happily do nothing to increase quality of FW development. That is what "capitalist West" thought them ooh so well..
-
I don't get how a company can invest tens/hundreds of millions in bringing a device to market (surely what it costs in making ASICs, software development, etc.) but can't afford a couple of weeks of bug fixes after users start to find them.
Makes no sense.
Rigol is still fiddling with the DHO800 licensing and doing other things in their firmware.
Most of the bugs are minor things so what gives?
Maybe they have stats on how many 'scopes will come back under warranty as "bricked" with every release.
-
As long as users keep buying "half cooked" products and keep "defending" "poor Rigol" for it, they will happily do nothing to increase quality of FW development. That is what "capitalist West" thought them ooh so well..
I don't know if rigol still sells many DHOs to people who don't care if and how their device works.
They came onto the market with the 800/900 as very entry 12 bit scopes a while before siglent, so the models sold well at first.
Now the owners can only hope that rigol will change its mind.
-
I would prefer if you would exclude Siglent in rationalizing why Rigol thinks it is OK to release alpha level products and never fix them. Because Siglent definitelly tries to not do that, and invests significant effort in that.
And talking about cheap toys, Rigol DHO4000 is definitely "Big Boys" price and not an entry level instrument either.
And that on also receives no update form many bugs reported on whole platform, after being released 2 years ago.
I also know that Rigol is investing serious money into developing new products and chipsets etc.
It is their DECISION to deliberately skimp on FW development....
It is their strategy.
As long as users keep buying "half cooked" products and keep "defending" "poor Rigol" for it, they will happily do nothing to increase quality of FW development. That is what "capitalist West" thought them ooh so well..
If you think that everything is fine with Siglent, I've no objections because of no experience. But the facts are:
- they're of the same origin (a communist country, BTW),
- their products are of the same price category,
- they're competing on the same market.
Because of that, I'm not sure their similar products can be as different as day and night. Although Siglent operates a more dealer-friendly policy and that naturally results in more talks about their products on the internet.
Concerning Rigol, the latest crop of products (DHO800/900, DG800/900 Pro, DM858) belongs to the entry-level category (hence cheap toys). Looks like they'd patented a new type of plastic enclosure and the main goal of the release is to get a feedback about that innovation from the market. For that goal, the SW quality does not make a big difference. Some products, e.g. the DGs seems even more undercooked than that of the pervious generation, and Rigol is not in rush to update the SW.
On the other hand, the latest public firmwares for the upscale series (DS7000/8000) are dated 2024 (or late 2023), which is a quite recent date. Notice that there are many series but few hardware ("chipset") generations. Latest upscale models are based on the Ultravision 2 hardware. I don't think there is a significant SW difference between the series that uses the same HW. It's basically a platform code. The fact that there are no upscale series based on the low-noise Ultravison 3 HW suggests that the code is not yet mature enough. So they're releasing an entry-level scopes with the SW as is, making money to fund the development efforts (it definitely can take a time because of complexity of the matter). Note that at the same time, they also have to continue providing maintenance to the Ultravision 2 code.
BTW I was wrong saying that they'd established a new SW development center. Looks like it's just another Rigol facility, not dedicated to SW. Anyway, I'm not defending or blaming them for more and more half-baked products. But sometimes, commenting on what Rigol is doing is like to comment the erratic movements of a drunk man.
-
- they're of the same origin (a communist country, BTW),
:scared:
Oh, that must be new, otherwise countless brand manufacturers wouldn't be producing there.
And I thought the McCarthy era had been over for decades.
-
- they're of the same origin (a communist country, BTW),
Oh, that must be new, otherwise countless brand manufacturers wouldn't be producing there.
And I thought the McCarthy era had been over for decades.
When you work for a brand, you're not free to do whatever you want. But when you're unleashed...
Yes, McCarthy era. Looks like we still have a huge crowds of funboys.
-
I'm pretty sure politics aren't supposed to be discussed here. 🤷
-
If you think that everything is fine with Siglent, I've no objections because of no experience. But the facts are:
Contradiction in terms....
If you have no relevant informations, all you have is irrelevant facts and misguided generalizations based on "they all come from same XYZ country so they will all be the same..". I find that to be orders of magnitude too simplistic to be relevant.
I don't say everything is perfect with Siglent. Nothing is perfect. But, and pay attention here, they have proven by it's work that they take it much more seriously and professionally. In some occasions Siglent is better than some very famous brands in that regard.... While Rigol is demonstrably worse.
-
I couldn't pass up the black Friday deal for the DHO804, I am waiting on a delivery right now. Been browsing the forum regarding hacks, fw updates and etc.
I am interested in using FFT extensively and sometimes bode plots.
I see this thread hasn't been updated in a while, does anyone have info on these features at the current moment? This is my first scope, so I am not aware of all the minor details and gotchas yet. Anyways, even if half broken, are there any caveats to working with these modes on the DHO804?
EDIT: https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5543385/#msg5543385 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5543385/#msg5543385) I see here this user's saying you actually need a signal generator and this video running bode plots on 804 https://www.youtube.com/watch?v=vKeOM21Gt7A (https://www.youtube.com/watch?v=vKeOM21Gt7A) however it seems you need to modify hardware?
-
I couldn't pass up the black Friday deal for the DHO804, I am waiting on a delivery right now. Been browsing the forum regarding hacks, fw updates and etc.
I am interested in using FFT extensively and sometimes bode plots.
I see this thread hasn't been updated in a while, does anyone have info on these features at the current moment? This is my first scope, so I am not aware of all the minor details and gotchas yet. Anyways, even if half broken, are there any caveats to working with these modes on the DHO804?
The current firmware brings no changes to FFT functionality. Also, there are no automated Bode plots at all in the DHO804. (Note that the present thread discusses the DHO914S, i.e. a model variant with a built-in signal generator which does support Bode plots.)
-
Thanks for the reply :). Regarding FFT and bode plotting outside your device, are there any solutions I can find on Github or some de facto software that's used? Ideally something over the network to not have to dump .csvs to usb etc etc. I saw mentions of Samba and FTP possibility? Or even just using adb? What would you guys suggest?
-
The FTP port is open, just use it. I use WinSCP to access it.
Samba is new in 1.04, I didn't get it working yet (not that I tried very hard).
-
If you want a bode plot, you need extra hardware. I have a LiteVNA for that (or NanoVNA). This little device is a bargain and outperforms the Rigol in any way for frequencies above 10kHz. For FFT up to 100MHz the Rigol is fine. But above that a TinySA (Ultra) is better. Lower noise floor and much higher frequency. Do note that these devices are 50 Ohm based. This means very high impedances can be measured but become inaccurate. For LF/audio cases I use a simple LF generator and manual measure the response.
-
Regarding native FFT, are there any things to keep in mind or settings I should use to get the most out of this machine while using FFT? I keep reading a bunch of different "recipes" on youtube and on EEVblog on how to get the most out of it, which is self-contradicting often and confusing.
-
Thanks for the reply :). Regarding FFT and bode plotting outside your device, are there any solutions I can find on Github or some de facto software that's used? Ideally something over the network to not have to dump .csvs to usb etc etc. I saw mentions of Samba and FTP possibility? Or even just using adb? What would you guys suggest?
A solution would be to have an app running in the 804, sending a request to a waveform generator on the network (like "do set XX KHz, YYY mVpp sine), then the 804 will measure the actual amplitude, save the data into a .csv, making nice graphs, and so on.. Perhaps the hw syncing would be needed in order to get the phase properly. But doable, imho..
PS: or to have a DIY generator hanging on the 804's USB port (like a DDS sine chip like the notorious 9850/51 module, or any of its friends, interfaced via an arduino/rpi/whatever, as the simplest Sunday afternoon hw solution.. not talking sw, of course, such an app should be created by the talented android people here :) )..
PPS: in order to see the "amplitude vs frequency graph only" no special syncing would be required.. Just a plain freq sweep..
Also for "audio only" you may generate the sine via the arduino and a cheapo DAC..
And, you may add an RF mixer->filter and create a Spectrum Analyzer till XX GHz :) ..
What is the priority is to get the 804 talk with the arduino/rpi/whatever via the USB on its front panel first, and then..
-
A solution would be to have an app running in the 804...
...
Perhaps the hw syncing would be needed in order to get the phase properly.
Not if you measure two channels simultaneously (input and output voltage of the DUT) and calculate the (complex) quotient Vout(f) / Vin(f), for each frequency f.
I just wonder, is there a fast way for an app to access the samples of the captured traces (w/o saving to a file and re-loading from the file)?
-
I just wonder, is there a fast way for an app to access the samples of the captured traces (w/o saving to a file and re-loading from the file)?
Sure, just download the data directly via SCPI.
I assume an APP running on the 'scope can do that, too.
A Bode plot app running on a DHO804 and controlling an external Signal Generator would be a neat hack, and seems perfectly doable. There's already an improved FFT app out there.
-
A comment from the originator of this thread:
My current belief is that the problem with the DHO914S Bode plot function is that it does not allow anywhere near enough time for the magnitude and phase measurements to settle after changing frequency (in steps).
As can be seen in my posts from October 2023 and later, when I stepped the frequency manually I had to wait for the measured data to settle and it was a very slow process.
Even with that, there were some quantitative errors in the result, measuring a simple and calibrated R-C filter in the vicinity of 10 kHz.
See my "Reply 32" way back then.
-
A solution would be to have an app running in the 804...
...
Perhaps the hw syncing would be needed in order to get the phase properly.
Not if you measure two channels simultaneously (input and output voltage of the DUT) and calculate the (complex) quotient Vout(f) / Vin(f), for each frequency f.
I just wonder, is there a fast way for an app to access the samples of the captured traces (w/o saving to a file and re-loading from the file)?
What would help immediately a bit is to create a ramdisk (in the android) and force/redirect (how??) the system to write the .csv files there. To process say 20-40 files (the "20-40 freq points") for a typical bode made over 3-4 freq decades cannot be such a problem then, imho..
PS: we should leave this thread with this as it is not directly related to the 914S issue..
-
What would help immediately a bit is to create a ramdisk (in the android) and force/redirect (how??) the system to write the .csv files there
Why would you want to convert to ASCII and parse it back again if "speed" is an issue?
Just read binary data with ":WAV::DATA?"
-
Because we want to process everything in android. No scipi transfers.
Just a click on an icon, entering in "from-to" and after a while you will see the bode graph and get bode.csv.
Basically the same mrisco does with his "new FFT" in his UI.
-
PS: we should leave this thread with this as it is not directly related to the 914S issue..
It is if it uses the DHO914S internal signal generator and ends up better than the official Bode plot.
-
Because we want to process everything in android. No scipi transfers.
You're going to have to use SCPI to tell it to write CSV files.
And to control the built-in signal generator.
-
That will be all done by the userspace apps inside android. The only communication outside 804 will be via the front panel USB to/from a small black box - the black box could be anything you would setup during the Sunday's afternoon :)
There is none built-in generator in 804, therefore the black box with myGenerator.
PS: we cannot help with 9xxS as we do not have access to the stuff (to the internal generator, or do you have the driver sources?). Therefore we should leave this thread with the "myBode" idea and let us start a new thread like "DHO800 myBode"..
-
PS: we cannot help with 9xxS as we do not have access to the stuff (to the internal generator, or do you have the driver sources?)
Hint: Use SCPI.
See section 3.25 of this: https://www.batterfly.com/PDF/RIGOL/dho800/DHO800-Series_programmingguide_EN.pdf (https://www.batterfly.com/PDF/RIGOL/dho800/DHO800-Series_programmingguide_EN.pdf)
-
This is the myGenerator hardware (an example only)..
0-60MHz 2Vpp sine (9851 DDS), couple of milliHerz step, controlled via USB..
Almost everybody here has something like that in his junkbox handy. No need to have AWG for bode..
-
Almost everybody here has something like that in his junkbox handy. No need to have AWG for bode..
True, but it would be a nice feature and not much extra work.
-
If you can control the INTERNAL AWG via SCPI, then simply create a BODE_APP (android one) which will call AWG via scpi, do set sine, a freq and ampl, and then it will make a measurement in CH1 and CH2 simultaneously (with some param), do repeat for all freqs, you get N .csv files (best placed in the ramdisk as I wrote above) and the BODE_APP will then crunch out a nice picture from all those files :) Easy..
For DHO800 and none-S owners we may easily use an external generator (of any kind). We will not call internal AWG via scpi, but the external myGenerator via simple commands via the USB connector in the front panel (all under our control). We may add some relay clicking for an attenuator/amplifier in myBode black box.. Setting a DDS/PLL/etc.,etc. chip via SPI/I2C and banging with relays cannot be a big problem off the android via any MCU, imho..
The process and result in both cases shall be the same, btw..
-
and then it will make a measurement in CH1 and CH2 simultaneously
How will you "make a measurement" without SCPI?
-
If you can control the INTERNAL AWG via SCPI, then simply create a BODE_APP (android one) which will call AWG via scpi, do set sine, a freq and ampl, and then it will make a measurement in CH1 and CH2 simultaneously (with some param), do repeat for all freqs, you get N .csv files (best placed in the ramdisk as I wrote above) and the BODE_APP will then crunch out a nice picture from all those files :) Easy..
For DHO800 and none-S owners we may easily use an external generator (of any kind). We will not call internal AWG via scpi, but the external myGenerator via simple commands via the USB connector in the front panel (all under our control). We may add some relay clicking for an attenuator/amplifier in myBode black box.. Setting a DDS/PLL/etc.,etc. chip via SPI/I2C and banging with relays cannot be a big problem off the android via any MCU, imho..
The process and result in both cases shall be the same, btw..
As I mentioned above, be sure to allow enough time after each AWG frequency step to allow the measurements of magnitude and phase in the DSO to settle out.
Apparently, the coders who wrote the Rigol-supplied firmware were not aware of that problem.
-
..As I mentioned above, be sure to allow enough time after each AWG frequency step to allow the measurements of magnitude and phase in the DSO to settle out.
Apparently, the coders who wrote the Rigol-supplied firmware were not aware of that problem.
To write the BODE_APP in android is not an easy exercise, sure. There is a lot of stuff to be solved in order to get it running. Knowledgeable people here who would perhaps try to write the BODE_APP will certainly spend a lot of time with getting it right.
The fastest (and most reliable) way to tackle the issue is Rigol itself, of course. Adding like XXms delay for settling out the AWG signal is something they could do anytime. But it could be somethimg else as well.
The major problem here to be solved is to get in contact with somebody involved at Rigol..
-
The major problem here to be solved is to get in contact with somebody involved at Rigol..
I'm sure Rigol are aware of it.
We've had two firmware updates in the last few months. Let's hope the streak continues...
-
The major problem here to be solved is to get in contact with somebody involved at Rigol..
I'm sure Rigol are aware of it.
We've had two firmware updates in the last few months. Let's hope the streak continues...
I sent them a detailed memo and data a year ago to the main company (after short discussion with US office).
I got a polite acknowledgment of receipt, but nothing since then.
-
Could you try following - a bode of a parallel resonant circuit, like 100-300mH in parallel with 10-50nF (foil), driven by the AWG via a 50-300k resistor and sensed via A) the 10x probe(s) setting, and then B) with 1x probes(s) setting ??
I want to see the bode plot with higher dynamic range where some adaptive approach with AWG level would be needed..
Example below..
Could you measure the AWG output level during the process somehow?
PS: when I google the issue I get only this discussion..
Edit for clarity..
-
Out of curiosity I've simulated one of your measurements and the results match pretty well (considering the parasitics and tolerances) - see below.
The only annoyance there I see are the "wiggles".
But those wiggles are there because you have to smooth out the points as they are inherently noisy (and not to let interpolate the points with a sinc or a similar fit). Mind the scope is 12bit only, with a much lower ENOB, there are many sources of noise (internal and external). Most bode graphs are made upon 3-5 points per decade/octave and then a nice smooth fit is made.
PS: would be interesting to compare Rigol's and Siglent's raw Bode data on their noisiness.
That would require to have both o'scopes hanging on the same DUT, and of course, you have to be confident you are really getting the "raw" data, and not the smoothed data instead.
-
Those "wiggles" are actually rather large: about 2 dB and 7 deg pk-pk.
Also, the "corner" frequency (-3 dB and -45 deg) is off by about 10%.
With a straight coax connection (no passive filter), the Bode function gave 0.4 dB and 3 deg peak-peak about 0 dB and 0 deg.
The interesting bit is that the "wiggles" appear to be periodic (with respect to samples) over the frequency range.
I used 100 points/decade for the scan.
With 12 bit "resolution" at 1/10 of full scale (-20 dB), 1/409 voltage ratio is -50 dB or so.
I analyzed this problem quite thoroughly into a memo that I sent to Rigol, which included my results with a slow manual scan through a limited frequency range.
If you are interested, please DM me with an e-mail address and I will send a .pdf to you.
-
I've had a look at the thread again (after a year) and yes, you've made a lot of work with that issue, indeed.
Still thinking whether the use of the transformer can have some impact (the notorious AWG transformer decoupling from the Rigol's example).
Imagine the RC filter above. The AWG is noisy as "moffy" reported (he indicated some periodic noise) and you have the CH1 at the input of the RC filter and CH2 at the output of the RC filter.
Now when the AWG noise event appears, it takes some time the event propagates from the point CH1 (the AWG output) via RC to the point CH2 (because there is a propagation delay via the RC filter). Thus you get an error in the CH1/CH2 ratio as well as in phase, imho (correct me if I am wrong).
Now imagine there is the CH1 and CH2 wired to the secondary wires of the transformer as in the example. The AWG noise event comes to the both channels in the same time, imho. So it is a "differential wiring" where the "common mode noise error from the AWG" will not apply and the CH1/CH2 errors should not appear then.
Just a thought..
-
As I understand the Bode plot function, it measures the amplitude and phase difference between Ch1 (input) and Ch2 (output) of the device under test.
The delay between input and output of the filter is included in its phase shift.
The two channels should be sampled simultaneously (or very close in time).
If the sampling is premature compared with the stepping in frequency of the AWG, then the measurement would be corrupted.
In my manual scanning (excruciatingly slow, done over a narrow frequency range), I had to wait for the individual measurements to settle to get a reasonable result.
-
The Bode measures the "ratio" of the amplitudes and "difference" in phases.
So when there is an AWG noise disturbance (superimposed on the set sine wave) the propagation of such a disturbance via the DUT (from CH1 via DUT to CH2 as described above) can have different phase/amplitude parameters compared to the pure sine wave you set.. And you may get errors in the moment of sampling (the same as when you had to wait till the stuff settles).
As the result you may get the wiggles (because the AWG noise has got some periodic characteristic)..
When the AWG noise disturbance (superimposed on the set sine wave) appears at the both channels at the same time (when using the transformer as in the Rigol's example), the error coming from the disturbance will not apply.
PS: still a thought experiment :)
-
That's why I suggested that Rigol or anyone writing their own firmware needs to pay attention to the settling time of the measurement.
-
There's SCPI commands to measure phase and amplitude - all the "crunching" has been done for you, no need to download any data. :)
(https://www.eevblog.com/forum/testgear/rigol-dho914s-bode-plot/?action=dlattach;attach=2454289;image)
-
Don't know how Rigol does the Bode Function. Others utilize a Synchronous Sampling or Detection method where a Frequency Selective Filter is placed around the measurement frequency to mitigate external influences. This is extremely important when attempting Bode Functions on a SMPS for example to evaluate Open and Closed Loop Stability. We utilized this for other uses such as Open Loop Oscillator Gain and Phase measurements as well as investigating Oscillator Injection Locking effects.
Best
-
It could easily be Rigol runs SCPI scripts for Bode with some math in between. Perhaps there are the SCPI strings to be found on the filesystem hidden somewhere :)
-
There's SCPI commands to measure phase and amplitude - all the "crunching" has been done for you, no need to download any data. :)
(https://www.eevblog.com/forum/testgear/rigol-dho914s-bode-plot/?action=dlattach;attach=2454289;image)
In my detailed reports, I used the built-in magnitude (peak-peak) and phase functions to create the manual-scan plots (from the .csv files).
-
So, you would do (a simplification)
:MEASure:ITEM VPP, CH1, CH2
:MEASure:ITEM FRPHase, CH1, CH2
and it returns Vpp for CH1 and Vpp for CH2, and phase difference between rising edges CH1 vs. CH2, all done in memory??
-
So, you would do (a simplification)
:MEASure:ITEM VPP, CH1, CH2
:MEASure:ITEM FRPHase, CH1, CH2
and it returns Vpp for CH1 and Vpp for CH2, and phase difference between rising edges CH1 vs. CH2, all done in memory??
That could be done, but it would return sub-par results as explained by mawyatt above. You want to apply narrow-band filtering in both channels (e.g. via synchronous detection), to ensure that you only pick up the DUT's reponse to the test frequency and block any interfering signals.
Maybe Rigol has implemented that properly in their built-in Bode plot on the DHO900S, maybe not. But I think it will be impossible to make a DHO800 do it properly via its onboard measurement and filtering options. The bandpass filters available in the Math menu are far too wide. -- Hmm, maybe one can cobble a Math function together which correlates and averages the CH1 and CH2 signals in a suitable way? But off the cuff I don't see how.
-
As the first step we need the data fast (it means no messing with .csv files). Therefore my Q on whether it runs off the memory. The next step is to play with the math and processes..
-
So, you would do (a simplification)
:MEASure:ITEM VPP, CH1, CH2
:MEASure:ITEM FRPHase, CH1, CH2
and it returns Vpp for CH1 and Vpp for CH2, and phase difference between rising edges CH1 vs. CH2, all done in memory??
I've never done it, but... that's what the functions are for, yes.
That could be done, but it would return sub-par results as explained by mawyatt above.
He's talking about extreme cases.
TimFox has said they're OK and the real problem is in settling time. :-//
Either way, they're a easy way to kickstart the coding and to experiment with.
-
That could be done, but it would return sub-par results as explained by mawyatt above.
He's talking about extreme cases.
TimFox has said they're OK and the real problem is in settling time. :-//
Either way, they're a easy way to kickstart the coding and to experiment with.
You can't say that "these functions are ok" -- whether they are adequate will depend totally on the measurement conditions.
In a perfect world without background noise they will work; in many real-world scenarios they won't. Note that the output from the DUT can become a rather low-level signal outside of its passband, while any mains hum, switching-power-supply interference etc. will stay at a constant level during the scan. You don't want your amplitude and phase measurements to respond to these.
But I agree that it should be straightforward to experiment with these -- just write a Python script which talks to your signal generator and your scope, drives the frequency sweep and captures measurements from the scope.
-
I've done it today manually with my ds1062ca (it shows perhaps 2 valid digits for voltage and time diff, can do scpi too, interesting) and hp3010b w/ 33k/47n LP off the junkbox (50/500/5kHz, 6Vpp) and got results within 10% (against sim) first shot without much messing with it..
E: hp3310b
-
He's talking about extreme cases.
Nope!!
To the best of our knowledge all "Quality" Frequency Response Analyzers (Bode Plot Functions) employ some form of correlated sampling and/or stimulus frequency filtering to mitigate unwanted outside influences which include simple noise. Even the Analog Discovery AD2 does this :-+
Since the FRA or Bode Function has the driving stimulus source available, why not use this for some form of correlation & filtering which pays huge dividends in signal processing and measurement fidelity.
Guess if your interest is limited to single pole RC filters and such maybe this isn't important, but some folks are looking into popular SMPS use which we wouldn't consider "Extreme" ;)
Best
-
Creating the Quality Bode is a long way to go. In order to start people have to master basic prerequisites (a lot of them).
After the primitive version with capturing Vpp and phase will work (off the 800/900 with an external generator), the next step is to implement more demanding process.
It has none sense to start with a complicated stuff at this stage, as there is nothing done yet except posting ideas..
-
That could be done, but it would return sub-par results as explained by mawyatt above.
He's talking about extreme cases.
TimFox has said they're OK and the real problem is in settling time. :-//
Either way, they're a easy way to kickstart the coding and to experiment with.
You can't say that "these functions are ok" -- whether they are adequate will depend totally on the measurement conditions.
In a perfect world without background noise they will work; in many real-world scenarios they won't. Note that the output from the DUT can become a rather low-level signal outside of its passband, while any mains hum, switching-power-supply interference etc. will stay at a constant level during the scan. You don't want your amplitude and phase measurements to respond to these.
But I agree that it should be straightforward to experiment with these -- just write a Python script which talks to your signal generator and your scope, drives the frequency sweep and captures measurements from the scope.
I said that the magnitude and phase measurements seem to work, if one allows sufficient settling time.
The Bode plot function as supplied "compiles, didn't it?" and gives a graph, but it is very inaccurate even for a simple one-pole low-pass filter in the audio range.
-
SCPI command to request data:
MEASure:STATistic:ITEM? AVER,RRPHase,CHAN1,CHAN2
-
FYI - the DS1062CA HP3310b experiment..
Mag +0.7db off and the phase is spot on..
Interestingly the scpi (here the jupyter notebook in win7) returns more digits than on the display..
-
I said that the magnitude and phase measurements seem to work, if one allows sufficient settling time.
In any case, sufficient dwell time must be allowed for each frequency point. While the settling time of the generator and detector may be predictable, the settling time of the DUT is unknown. So the dwell may need to be configurable (or it must be estimated, which adds to the complexity the procedure).
-
Maybe Rigol has implemented that properly in their built-in Bode plot on the DHO900S, maybe not. But I think it will be impossible to make a DHO800 do it properly via its onboard measurement and filtering options. The bandpass filters available in the Math menu are far too wide. -- Hmm, maybe one can cobble a Math function together which correlates and averages the CH1 and CH2 signals in a suitable way? But off the cuff I don't see how.
I also don't see that built-in measurements are suitable.
If you have the samples of the two traces, then a frequency-selective detector is not very difficult, e.g. like this (https://godbolt.org/z/ehe6ea9hK) (just drafted from the scratch, not tested, so please forgive any errors). The provided window function and number of samples determine the shape and RBW of the bandpass filter. I'd use a window function with low side lobes / high stop band attenuation, say 100dB, maybe even more.
[ EDIT: For example, a Kaiser window with beta=16 gives you more than 120dB stop band attenuation, and a RBW-3dB of about 2.18*fs/num_samples, where fs is the sample rate. ]
The sin/cos (cexp) evaluation for each sample is of course computationally expensive. Since exp(x*k) = exp(x*(k-1))*exp(x), a less expensive, recursive calculation is possible, but you must take care of numerical error accumulation when you apply it to a large number of samples.
-
In the meantime I've quickly assembled a python stuff such I can get data off my vintage DS1062CA and perform a "primitive" version of myBode..
The script does "Auto", waits couple of secs and performs say 100 measurements and uses the averages for Mag and Phase then.
What I've learned so far - with the Magnitude with averaging I get stable 3 digits, but there is an issue with Phase - after "Auto" the scope often returns the "delay between CH1 and CH2 rising edges" shifted by a period, thus you get a 360deg shift. Also with smaller phase differences it returns strings like "<20us" (based on the time scale).
But the CH1 and CH2 waveforms are downloaded as well and ready for some math..
-
I also don't see that built-in measurements are suitable.
If you have the samples of the two traces, then a frequency-selective detector is not very difficult, e.g. like this (https://godbolt.org/z/ehe6ea9hK) (just drafted from the scratch, not tested, so please forgive any errors). The provided window function and number of samples determine the shape and RBW of the bandpass filter. I'd use a window function with low side lobes / high stop band attenuation, say 100dB, maybe even more.
[ EDIT: For example, a Kaiser window with beta=16 gives you more than 120dB stop band attenuation, and a RBW-3dB of about 2.18*fs/num_samples, where fs is the sample rate. ]
The sin/cos (cexp) evaluation for each sample is of course computationally expensive. Since exp(x*k) = exp(x*(k-1))*exp(x), a less expensive, recursive calculation is possible, but you must take care of numerical error accumulation when you apply it to a large number of samples.
Perhaps this will work?:
vin = complex(0)
vout = complex(0)
ts = 1.0 / SAMPRATE
k = len(data1)
wink = signal.windows.kaiser(k, beta=5, sym=True)
for i in range(0, k-1):
vin = vin + data1.astype(complex)[i] * wink[i] * np.exp(-2.0*np.pi*freq*ts*i*1j)
vout = vout + data2.astype(complex)[i] * wink[i] * np.exp(-2.0*np.pi*freq*ts*i*1j)
print("%d %1.5e %1.5e %1.5e %1.5e" %(i, vin.real, vin.imag, vout.real, vout.imag) )
xgain = vout / vin;
xmagnitude = np.abs(xgain)
xmagnitude_DB = 20.0 * np.log10(xmagnitude)
xphase = np.angle(xgain)
print("xgain is %1.5e %1.5e" %(xgain.real, xgain.imag) )
print("xmagnitude is %1.5e" %xmagnitude )
print("xMag dB is %1.5e" %xmagnitude_DB)
print("xPhase is %1.5e" %xphase)
-
Perhaps this will work
[...]
* I miss the the imaginary unit inside exp(...)
* xphase = np.abs(xgain) ==> I think this should be np.angle(...)
* In numpy, you would not loop over the elements (slow), but operate directly on the vectors
Try this one:
import numpy as np
k = 65536 # number of samples
freq = 12345
SAMPRATE = 1e6
# simulate captured data
data1 = np.sin(2.0*np.pi*freq*np.arange(0,k)/SAMPRATE)
# -40dB, phase=pi/8
data2 = 0.01*np.sin(2.0*np.pi*freq*np.arange(0,k)/SAMPRATE + np.pi/8)
k = len(data1)
ts = 1.0 / SAMPRATE
xwin = np.kaiser(k, 14)
data1 = data1 - np.mean(data1)
data2 = data2 - np.mean(data2)
vin = np.sum(data1 * xwin * np.exp(-2.0j*np.pi*freq*ts*np.arange(0,k)))
vout = np.sum(data2 * xwin * np.exp(-2.0j*np.pi*freq*ts*np.arange(0,k)))
xgain = vout / vin;
xmagnitude = np.abs(xgain)
xmagnitude_DB = 20.0 * np.log10(xmagnitude)
xphase = np.angle(xgain)
print("xMag dB is %1.5g" %xmagnitude_DB)
print("xPhase is %1.5g" %xphase)
Edit: Added mean subtraction
-
Yep, forgot the *1j in the complex exp..
I get now (my code above):
Sample rate Hz is 1000000.0
Timescale is 1.0e-04 sec / div
From scope readings 50 averg:
freq Hz is 4.375e+03
period secs is 2.195e-04
ref_ampl V is 4.985e+00
dut_ampl V is 7.115e-01
delay secs is 3.528e-05
Mag dB is -1.691e+01
Phase deg is -5.786e+01
From scope waves (single sweep within above meas)
xgain is 1.19831e-01 -1.68624e-02
xmagnitude is 1.21012e-01
xMag dB is -1.83434e+01
xPhase is -1.39799e-01
xPhase deg is -5.03278e+01
freq Hz is 1.010e+04
period secs is 9.506e-05
ref_ampl V is 4.975e+00
dut_ampl V is 6.478e-02
delay secs is 2.436e-05
Mag dB is -3.771e+01
Phase deg is 9.225e+01
vs
xgain is 1.47492e-02 4.11434e-03
xmagnitude is 1.53123e-02
xMag dB is -3.62992e+01
xPhase is 2.72038e-01
xPhase deg is 9.79338e+01
-
Btw, note that I did not care to scale vin and vout properly, since the scaling cancels out when the ratio vout/vin is calculated.
-
From scope waves (single sweep within above meas)
What was the record length? How many samples?
Which "freq" value are you using? The nominal frequency, to which the generator was tuned, or the measured one (from scope measurements)?
-
Data record length is 598 samples in each channel.
Sampling rate above was 1MegHz.
Freq is from the oscilloscope reading (all scope readings except the waveforms are 50x and average). My current HP3310B generator is vintage analog..
Another one (Rigol DS1062CA and HP3310B, DUT is an RLC circuit):
Sample rate Hz is 2000000.0
freq Hz is 1.010e+04
period secs is 9.506e-05
ref_ampl V is 4.975e+00
dut_ampl V is 6.478e-02
delay secs is 2.436e-05
Mag dB is -3.771e+01
Phase deg is 9.225e+01
vs
xgain is 1.47492e-02 4.11434e-03
xmagnitude is 1.53123e-02
xMag dB is -3.62992e+01
xPhase is 2.72038e-01
xPhase deg is 9.79338e+01
-
Data record length is 598 samples in each channel.
598 samples at 1MSa/s are not enough for 4.4kHz. With the given window function, the detector needs about >= 5 full periods of data. It does not need to be an integer multiple of a period, though.
But why 598? A width of 10div at 100µs/div and 1MSa/s should be 1000 samples :-//
Freq is from the oscilloscope reading (50 averages).
Use the nominal (expected) frequeny for the detector calculation.
-
That is what the scope returns after Auto. Number of periods aprox 4.
This vintage scope has got 10kB for both channels.
I will do the manual scope setting, we will see.. :D
-
That is what the scope returns after Auto. Number of periods aprox 4.
After a closer look at the frequency response, a detector with a Kaiser(14) window needs at least 4.55 periods to keep DC out of the filter's passband. So my conservative gut feeling of >= 5 was not too far off.
To deal with very small signals sitting on a large DC offset, an additional mean value subtraction is certainly useful before calculating vin and vout
data1 = data1 - np.mean(data1)
data2 = data2 - np.mean(data2)
This vintage scope has got 10kB for both channels.
Oh :scared: I was assuming a DHO8xx/9xx. But that should still allow 5k points per channel.
598 points is still strange. Could these be screen data (perhaps re-sampled to get one sample per screen pixel)?
Have you tried plotting data1 and data2?
-
I've been indicating the experiments are with the DS1062CA. It is Rigol's scope from around 2005 (2ch 60Mhz, 2GSps, the highest 1302 model is 300MHz, hackable??), it has got a single scpi waveform download command.
I've been using pyvisa (win10) which downloads 600 points (something like 7.4bits signed) always. Those data are the display data.
The scope's memory depth per channel is 5120 of bytes I assume. No idea how to download them.
Anyhow, I've refreshed python a little bit during this Sunday afternoon, waiting on the DHO804 :)
-
I've been indicating the experiments are with the DS1062CA
Sorry, I missed that.
I've been using pyvisa (win10) which downloads 600 points (something like 7.4bits signed) always. Those data are the display data.
Is the sample rate correct then?
If the full width of 1ms is covered by only 600 points, then it's no longer 1MSa/s, but rather resampled to 600kSa/s?
When you plot the downloaded data, do you see the same waveform as on the screen?
Or is the trace truncated, so that you only see 60% of the full width?
-
I've been printing all data related..
Here is with Keiser_Bessel_derived window.
Added the offset removal.
Anyhow, there is an subtle issue with the Phase in your math, getting usually fully off results after all tweakings.
Of course the Phase interpretation - below the DUT phase is leading by 70deg. Now, it is a game with the 360 shift..
But still, I get hairy Phases off your math.
Tried beta 5 and 14 (note it is beta, not alpha)..
The basic Simple version returns always the same Mag and Phase with 3 digits precision (but the Phase shifts by a cycle based on scope settings, when set it is constant).
:PS those 598 data points - it was the standard bug in the for loop, it is 0..599=600
-
I've been printing all data related..
Here is with Keiser_Bessel_derived window.
Added the offset removal.
Anyhow, there is an subtle issue with the Phase in your math, getting usually fully off results after all tweakings. Tried beta 5 and 14 (note it is beta, not alpha)..
The basic Simple version returns always the same Mag and Phase with 3 digits precision.
:PS those 598 data points - it was the standard bug in the for loop, it is 0..599=600
It works with simulated data, so I think something must be still wrong with the inputs.
If SAMPRATE or freq are wrong, the filter is centered at a wrong frequency, and what you get is just noise divided by noise.
The acquisition sample rate may be 500000, but what matters is the the sample rate of the downloaded vectors data1 and data2 (display data), which is obviously only 600Sa/0.0024s=250000Sa/s.
==> Use SAMPRATE=250000 for the calculation
Which frequency do you set on the signal generator?
==> set the variable freq to the same value (not to the measured value)
-
Ok, the SAMPRATE - I will try with 250000..
The generator itself is set to a fixed frequency and amplitude (quite stable).
The "freq" is used in both Simple and GF versions, it is coming from the internal scope measurement on CH1 (all inputs come from the scope). All input data except the 2 waveforms are captured 50x and averaged.
What I need is to get stable results (even when a bit off but stable) from your version after each measurement (still not the case).
The Simple version is quite stable here with optimal signal settings, but not suitable for Quality Bode under any settings, sure..
-
Below plz find the .csv file with a series of measurements..
PS: added a Bode of manually swept LC circuit and clicking python, Keiser with beta=14, none averaging, otherwise as above..
-
Below plz find the .csv file with a series of measurements..
What is the difference between colums F,G,H and K,L,M which have the same name?
Can you also post the contents of the data1 and data2 arrays? (for one measurement, or maybe for two)?
What was the frequency set on the generator? (please give a number, not "fixed" ;) )
Does this scope also have a built-in frequency counter (not the frequency measurement)? If yes, what does it read?
-
1. What is the difference between colums F,G,H and K,L,M which have the same name?
2. Can you also post the contents of the data1 and data2 arrays? (for one measurement, or maybe for two)?
3. What was the frequency set on the generator? (please give a number, not "fixed" ;) )
4.Does this scope also have a built-in frequency counter (not the frequency measurement)? If yes, what does it read?
1. FGH should be without "x" - it is the Simple Bode method..
2. later perhaps this evening
3. the freq set on generator is the freq in column A - measured by scope, none counter used, look at the HP3310B spec, you will get how the freq is set :)
4. nope, there is none special counter built in, it just returns a coarse freq in column A
freq = float(scope.query(':MEASure:FREQ? CHAN1'))
The Keiser GF method works, see above Bode of an LC I did within 2 minutes manually (Keiser beta=14, none averaging, just turning a knob on the HP3310 and click into jupyter-lab cell).
A couple of times I changed time base and channel 2 (DUT out) vertical such I got those "optimal minimal" 5-12 periods with maxed CH2 amplitude inside the screen (this must be automated in the future App!!).
The CH2 measurement above 20-30kHz was already noisy as the LC was built on flying leads and crocodiles and bananas.. ;D
With a modern scope and generator it is the way to go, indeed.. :-+
PS: added above the DUT sim - you may compare the SIM and myBode results.. 8)
-
There is a "counter" in the scope (when enabled I get it on the screen) but I do not know how to read it.. 6 digits and shows 5 stable digits with my generator.
There are many open issues with my vintage DS1062CA 2GSa/s scope - how to see the ETS actually works (I can set it in menu, up to 50GSa/sec, 10GSa/sec in my model), how to read the 5120 long buffer, how to read the counter, how to hack it to 300MHz 1302, etc..
-
A divider 1.5Meg/33ohm in a shielded box, scope averaging 8, REF amplitude aprox 11Vpp, DUT ampl aprox 200uVpp on the screen (1mV/div).
xFreq measured with scope's "counter" and used in the math, stability during the measurement within 0.2Hz.
9.5 periods on the screen, AC coupling, 1Meg input, 1x probe, BW limit ON, sinx/x ON, DS1062CA and HP3310B.
For betas 1..30.
-
A divider 1.5Meg/33ohm in a shielded box, scope averaging NONE, REF amplitude aprox 11Vpp, DUT ampl aprox 200uVpp on the screen (1mV/div), noise aprox 200uVpp.
xFreq measured with scope's "counter" and used in the math, stability during the measurement within 0.1Hz.
9.5 periods on the screen, AC coupling, 1Meg input, 1x probe, BW limit OFF, sinx/x OFF, DS1062CA and HP3310B.
For betas 1..30.
PS: both measurments clicked manually, so the number of measurements for each beta may differ (too lazy with programming python's "for loops" today :) )
I've tried with 1.5Meg/3.9ohm, the DUT voltage buried in the noise on the screen (my scope uses data off the display, 200points resolution), the results were -111 to -115dB, rather hairy. With 12bit less noisy scope and "ADC raw data" the -120dB is easily doable, imho..
-
sinx/x OFF
Just wonder, does the scope really honor this parameter for calculating the dispaly data at the timebase you are using here?
For betas 1..30.
I wonder if such a large beta is really useful. Sure, increasing beta increases the stop band attenuation, but it also increases the RBW and equivalent noise bandwidth of the filter, i.e. more noise can pass through the filter. If you are not dealing with strong interfering signals that must be filtered out, a too large beta is rather counterproductive. A beta of 30 also increases the minimum number of periods in the measurement window to 10.
I've tried with 1.5Meg/3.9ohm, the DUT voltage buried in the noise on the screen (my scope uses data off the display, 200points resolution), the results were -111 to -115dB, rather hairy. With 12bit less noisy scope and "ADC raw data" the -120dB is easily doable, imho..
The aim is of course to use longer records with much more samples, not just 600.
For now, you can try to average the complex gain of (say) 100 measurements at the same frequency, before calculating magnitude and phase.
Or, if the samples you can read from the scope are 8-bit quantized, then maybe even renounce scope averaging and only do compex gain averaging in the app.
-
I asked my notebook :) to help me with the python:
How to measure magnitude ratio in decibels and phase in degrees of two sine waves with help of Keiser window and something like DFT at given frequency, using complex exponential function? Could you show me python code?
import numpy as np
import matplotlib.pyplot as plt
# Parameters
fs = 1000 # Sampling frequency in Hz
T = 1.0 # Signal duration in seconds
f0 = 50.0 # Frequency of the sine waves in Hz
A1, A2 = 1.0, 0.5 # Amplitudes of the sine waves
phase1, phase2 = 0.0, np.pi/4 # Phases of the sine waves in radians
beta = 8.0 # Kaiser window beta parameter
# Time array
t = np.arange(0, T, 1/fs)
# Generate the sine waves
x1 = A1 * np.sin(2 * np.pi * f0 * t + phase1)
x2 = A2 * np.sin(2 * np.pi * f0 * t + phase2)
# Kaiser window
window = np.kaiser(len(t), beta)
# Apply window to the signals
x1_windowed = x1 * window
x2_windowed = x2 * window
# Compute the DFT at the given frequency using a complex exponential
k = int(f0 * len(t) / fs) # Index corresponding to frequency f0
exponential = np.exp(-2j * np.pi * k * np.arange(len(t)) / len(t))
X1 = np.dot(x1_windowed, exponential) # DFT value for x1
X2 = np.dot(x2_windowed, exponential) # DFT value for x2
# Compute magnitude ratio in decibels
magnitude_ratio_db = 20 * np.log10(np.abs(X2) / np.abs(X1))
# Compute phase difference in degrees
phase_diff_deg = np.angle(X2 / X1, deg=True)
# Print results
print(f"Magnitude Ratio (dB): {magnitude_ratio_db:.2f}")
print(f"Phase Difference (degrees): {phase_diff_deg:.2f}")
# Plot signals and window
plt.figure(figsize=(10, 6))
plt.subplot(2, 1, 1)
plt.plot(t, x1, label="Sine Wave 1")
plt.plot(t, x2, label="Sine Wave 2")
plt.legend()
plt.title("Original Sine Waves")
plt.subplot(2, 1, 2)
plt.plot(t, x1_windowed, label="Windowed Sine Wave 1")
plt.plot(t, x2_windowed, label="Windowed Sine Wave 2")
plt.legend()
plt.title("Windowed Sine Waves")
plt.tight_layout()
plt.show()
How to measure magnitude ratio in decibels and phase in degrees of two sine waves with help of Keiser window and something like DFT at given frequency, while not using complex exponential function and not using costly sin and cos and arctan2 functions? Could you show me python code?
import numpy as np
import matplotlib.pyplot as plt
# Parameters
fs = 1000 # Sampling frequency in Hz
T = 1.0 # Signal duration in seconds
f0 = 50.0 # Frequency of the sine waves in Hz
A1, A2 = 1.0, 0.5 # Amplitudes of the sine waves
phase1, phase2 = 0.0, np.pi/4 # Phases of the sine waves in radians
beta = 8.0 # Kaiser window beta parameter
# Time array
t = np.arange(0, T, 1/fs)
# Generate the sine waves
x1 = A1 * np.sin(2 * np.pi * f0 * t + phase1)
x2 = A2 * np.sin(2 * np.pi * f0 * t + phase2)
# Kaiser window
window = np.kaiser(len(t), beta)
# Apply window to the signals
x1_windowed = x1 * window
x2_windowed = x2 * window
# Initialize recurrence variables for sine and cosine
delta_theta = 2 * np.pi * f0 / fs
cos_curr, sin_curr = 1.0, 0.0 # cos(0) = 1, sin(0) = 0
cos_delta, sin_delta = np.cos(delta_theta), np.sin(delta_theta)
# Initialize accumulators for projections
X1_real = 0.0
X1_imag = 0.0
X2_real = 0.0
X2_imag = 0.0
# Compute projections using recurrence relations
for i in range(len(t)):
# Accumulate projections
X1_real += x1_windowed[i] * cos_curr
X1_imag += x1_windowed[i] * sin_curr
X2_real += x2_windowed[i] * cos_curr
X2_imag += x2_windowed[i] * sin_curr
# Update sine and cosine using recurrence
cos_next = cos_curr * cos_delta - sin_curr * sin_delta
sin_next = sin_curr * cos_delta + cos_curr * sin_delta
cos_curr, sin_curr = cos_next, sin_next
# Normalize the projections
X1_real *= 2 / len(t)
X1_imag *= 2 / len(t)
X2_real *= 2 / len(t)
X2_imag *= 2 / len(t)
# Compute magnitudes
X1_mag = np.sqrt(X1_real**2 + X1_imag**2)
X2_mag = np.sqrt(X2_real**2 + X2_imag**2)
# Magnitude ratio in decibels
magnitude_ratio_db = 20 * np.log10(X2_mag / X1_mag)
# Approximate phase angle calculation
def approximate_angle(y, x):
"""Approximate angle using Taylor series expansion."""
if x == 0:
return np.pi/2 if y > 0 else -np.pi/2
elif y == 0:
return 0 if x > 0 else np.pi
ratio = y / x
angle = ratio / (1 + 0.28 * ratio**2) # Fast approximation
if x < 0:
angle += np.pi if y >= 0 else -np.pi
return angle
# Compute phases using the approximation
X1_phase = approximate_angle(X1_imag, X1_real)
X2_phase = approximate_angle(X2_imag, X2_real)
# Phase difference in degrees
phase_diff_deg = np.degrees(X2_phase - X1_phase)
# Print results
print(f"Magnitude Ratio (dB): {magnitude_ratio_db:.2f}")
print(f"Phase Difference (degrees): {phase_diff_deg:.2f}")
# Plot signals and window
plt.figure(figsize=(10, 6))
plt.subplot(2, 1, 1)
plt.plot(t, x1, label="Sine Wave 1")
plt.plot(t, x2, label="Sine Wave 2")
plt.legend()
plt.title("Original Sine Waves")
plt.subplot(2, 1, 2)
plt.plot(t, x1_windowed, label="Windowed Sine Wave 1")
plt.plot(t, x2_windowed, label="Windowed Sine Wave 2")
plt.legend()
plt.title("Windowed Sine Waves")
plt.tight_layout()
plt.show()
-
This is something I do not understand:
# Compute the DFT at the given frequency using a complex exponential
k = int(f0 * len(t) / fs) # Index corresponding to frequency f0
exponential = np.exp(-2j * np.pi * k * np.arange(len(t)) / len(t))
Why quantize to an integer?
For this use case we want a direct down-conversion from f0 to DC, i.e. np.exp(-2j * np.pi * f0 * t).
The above expression is almost equivalent, except for the int(...).
-
Here is the second source with previous settings..
Used as-is, just input data1 and data2 (removed offset).
# remove the offset
data1 = data1 - np.mean(data1)
data2 = data2 - np.mean(data2)
# Parameters
fs = xSAMPRATE # Sampling frequency in Hz
T = 12 * XSCALE # Signal duration in seconds
f0 = 4000 # Frequency of the sine waves in Hz
beta = 8.0 # Kaiser window beta parameter
-
Here is the second source with previous settings..
Used as-is, just input data1 and data2 (removed offset).
Is the python loop over the samples really faster than np.exp() applied to the whole vector?
Unfortunately, python loops are not very fast.
-
You have to try to measure the loop'ss duration inside the DHO804 :)
Do we have python/numpy which fits inside the android there??
Or simply redo it into C and do measure..
Below the Bessel I0=1 in the Kaiser it seems..
How to measure magnitude ratio in decibels and phase in degrees of two sine waves with help of Kaiser window and something like DFT at given frequency, while not using complex exponential function and not using costly sin and cos and atan2 functions? Do use atan2 approximation. Could you show me a C code?
#include <stdio.h>
#include <math.h>
#include <stdlib.h>
// Constants
#define PI 3.14159265358979323846
// Kaiser Window function
void compute_kaiser_window(double* window, int length, double beta) {
for (int n = 0; n < length; n++) {
double term = (2.0 * n / (length - 1)) - 1.0;
window[n] = exp(-beta * (1 - term * term));
}
}
// Apply Kaiser window to a signal
void apply_window(double* signal, const double* window, int length) {
for (int i = 0; i < length; i++) {
signal[i] *= window[i];
}
}
// Recursive trigonometric DFT computation
void compute_dft_at_frequency(const double* signal, int length, double freq, double sampling_rate, double* real_out, double* imag_out) {
double omega = 2 * PI * freq / sampling_rate;
double cos_omega = cos(omega);
double sin_omega = sin(omega);
double real = 0.0;
double imag = 0.0;
// Initialize recursive variables
double cos_prev = 1.0;
double sin_prev = 0.0;
double cos_curr, sin_curr;
for (int n = 0; n < length; n++) {
real += signal[n] * cos_prev;
imag -= signal[n] * sin_prev; // Negative for DFT
// Recursive update of cos and sin
cos_curr = cos_omega * cos_prev - sin_omega * sin_prev;
sin_curr = sin_omega * cos_prev + cos_omega * sin_prev;
cos_prev = cos_curr;
sin_prev = sin_curr;
}
*real_out = real;
*imag_out = imag;
}
// Approximate atan2
double approximate_atan2(double y, double x) {
if (x == 0.0) {
return (y > 0.0 ? PI / 2 : (y < 0.0 ? -PI / 2 : 0.0));
}
double abs_x = fabs(x);
double abs_y = fabs(y);
double ratio = y / (abs_x + sqrt(x * x + y * y));
double angle = (PI / 4) * ratio;
if (x > 0.0) return angle;
if (y >= 0.0) return angle + PI;
return angle - PI;
}
// Calculate magnitude and phase
void calculate_magnitude_and_phase(double real_x, double imag_x, double real_y, double imag_y, double* magnitude_db, double* phase_deg) {
// Magnitudes
double mag_x = sqrt(real_x * real_x + imag_x * imag_x);
double mag_y = sqrt(real_y * real_y + imag_y * imag_y);
// Magnitude ratio in dB
*magnitude_db = 20 * log10(mag_y / mag_x);
// Phase difference using atan2 approximation
double phase_x = approximate_atan2(imag_x, real_x);
double phase_y = approximate_atan2(imag_y, real_y);
*phase_deg = (phase_y - phase_x) * 180.0 / PI;
}
// Main function
int main() {
int length = 1024;
double sampling_rate = 1000.0; // Hz
double target_freq = 50.0; // Hz
double beta = 5.0; // Kaiser beta
// Signals
double x[1024];
double y[1024];
double window[1024];
// Generate test signals
for (int n = 0; n < length; n++) {
x[n] = sin(2 * PI * target_freq * n / sampling_rate);
y[n] = 0.5 * sin(2 * PI * target_freq * n / sampling_rate + PI / 4);
}
// Compute Kaiser window
compute_kaiser_window(window, length, beta);
// Apply window to signals
apply_window(x, window, length);
apply_window(y, window, length);
// Compute DFT at target frequency
double real_x, imag_x, real_y, imag_y;
compute_dft_at_frequency(x, length, target_freq, sampling_rate, &real_x, &imag_x);
compute_dft_at_frequency(y, length, target_freq, sampling_rate, &real_y, &imag_y);
// Calculate magnitude and phase
double magnitude_db = 0.0;
double phase_deg = 0.0;
calculate_magnitude_and_phase(real_x, imag_x, real_y, imag_y, &magnitude_db, &phase_deg);
// Print results
printf("Magnitude Ratio (dB): %f\n", magnitude_db);
printf("Phase Difference (degrees): %f\n", phase_deg);
return 0;
}
Also
#include <stdio.h>
#include <math.h>
// Function to compute the modified Bessel function I0(x)
double bessel_I0(double x) {
double sum = 1.0; // Initialize sum for the series
double term = 1.0; // First term in the series
double k = 1.0; // Iteration counter
double x2 = (x / 2.0) * (x / 2.0); // (x/2)^2 for repeated use
while (term > 1e-10) { // Converge until the term is very small
term *= x2 / (k * k);
sum += term;
k += 1.0;
}
return sum;
}
// Function to compute Kaiser window coefficients
void compute_kaiser_window(double* window, int length, double beta) {
double denom = bessel_I0(beta); // Denominator I0(beta)
for (int n = 0; n < length; n++) {
double ratio = (2.0 * n / (length - 1)) - 1.0; // Calculate (2n/(N-1) - 1)
double term = beta * sqrt(1.0 - ratio * ratio); // beta * sqrt(1 - ratio^2)
window[n] = bessel_I0(term) / denom; // w[n] = I0(term) / I0(beta)
}
}
// Test the Kaiser window computation
int main() {
int length = 16; // Length of the window
double beta = 5.0; // Shape parameter
double window[16];
// Compute the Kaiser window
compute_kaiser_window(window, length, beta);
// Print the coefficients
printf("Kaiser Window Coefficients:\n");
for (int n = 0; n < length; n++) {
printf("w[%d] = %f\n", n, window[n]);
}
return 0;
}
-
I do not own a DHO. In C, an explicit loop is required anyway, and a complex multiplication (-> iterative calculation) is very likely faster than cexp(). Drawback of an iterative calculation is that it accumulates errors, but I don't think this is a problem when double precision numbers are used. With single precision in conjunction with a huge number of samples, I would at least verify the accuracy.
EDIT:
Regarding apply_kaiser_window(): You want to (pre)calculate the window function only once, as long as length does not change.
-
Yep, added above the Kaiser coeff pre-computation with Bessel as well. Should be used in the previous C code (the Kaiser coeff calc function there seems to me buggy).
All sources above need to be verified before inserting into the DHO800/900, of course.. :D
-
Orig GF math Python:
xMag dB is -93.5903211132
xPhaseA deg is 3.1959587217
AI no trigo functions Python:
Magnitude Ratio (dB): -93.5903211132
Phase Difference (degrees): -3.2231039924
AI no trigo functions C:
Magnitude Ratio (dB): -93.5903211132
Phase Difference (degrees): 1.2746656431
All above with:
Samples 600
Sampling rate 250000
Beta 8
Freq 4008.44
T 0.0024 (sig duration = 12div * 200us/div)
and the test .csv data file below - a real measurement, V_ref_inp first column, V_dut_out second column..
-
Orig GF math Python:
xMag dB is -93.5903211132
xPhaseA deg is 3.1959587217
AI no trigo functions Python:
Magnitude Ratio (dB): -93.5903211132
Phase Difference (degrees): -3.2231039924
AI no trigo functions C:
Magnitude Ratio (dB): -93.5903211132
Phase Difference (degrees): 1.2746656431
All above with:
Samples 600
Sampling rate 250000
Beta 8
Freq 4008.44
T 0.0024 (sig duration = 12div * 200us/div)
and the test .csv data file below - a real measurement, V_ref_inp first column, V_dut_out second column..
To get a feeling for the estimation uncertainty, I ran a Monte Carlo analysis with 1000 simulated measurements using the above parameters and a simulated DUT output signal with a SNR of 0dB (this seems to be approximately the SNR in the 2nd column of the CSV file). And I got an estimation uncertainty (standard deviation) of ~0.7dB for the magnitude and ~3.5° for the phase. I would consider anything within +- 2 standard deviations as plausible result.
The samples in the CSV also look strange. Even the reference waveform is not clean (figure1.png) and the wiggles in the reference waveform don't look like random noise. And indeed, if I look at the power spectrum (figure2.png), I see an extra peak at 121kHz. I have no idea what the scope has done to the waveform. This is certainly not the waveform that came from the generator. Due to the frequency-selective detection, it should not matter for this use case, but it's nevertheless strange.
-
Here is the 5120 data lines long csv I got when I saved "csv data" off the scope onto an usb flash..
Time CH1_ref CH2_dut
Timestep in the file is 20ns
Interestingly it saved VOLTS into the csv file (via usb 8bit unsigned binary in a weird format only)
I have no idea how to download those data via usb, however.. :-[
f0 was 301.373kHz from the generator
2us/div was timebase set on the display (aprox 7.2 periods)
50MSa/sec was Scope's sampling rate
So you have to derive the other stuff.. :scared:
Below AI_python with beta=8 and 5120 samples..
While the magnitude looks nice with all three sources, the phase needs some finetuning, imho..
-
The data look much more realistic now. Calculated manually in Octave, I get -88.430° from these data, with kaiser(8 ). The window function makes a small difference, but not that much. E.g. Kaiser(14) -> -88.433°, Blackman -> -88.432°, Blackman-Nuttall -> -88.432°, Hann -> -88.432°. The uncertainty due to the noise is much larger (see below).
The 89.5° you got is IMO not plausible, if it was calculated from the same data as in the CSV file. While measurement noise is of course not deterministic, the calculation itself (when applied to the same data) should be deterministic within numerical precision limits.
With iterative exp, the error of exp does of course accumulate, but after 5120 samples, the difference between direkt and iterative exp calculation is still below 10-13, i.e. still negligible for the use case, and I still get -88.430° with Kaiser(8 ).
The attached image shows the expected variablilty of the estimated phase due to noise for repeated measurements (for 5120 points and a SNR of 40dB for data1, and 25dB for data2 -- i.e. similar level as in the CSV), from a Monte-Carlo simulation. Standard deviation is ~0.06°.
-
I've replaced the phase calc in the AI_python_no_trigo with the more traditional
xout = complex(X2_real, X2_imag)
xinp = complex(X1_real, X1_imag)
xgain = xout/xinp
# Compute phases
phase = -180.0/np.pi * np.angle(xgain)
# Print results
print(f"Magnitude Ratio (dB): {magnitude_ratio_db: .10f}")
print(f"Phase Difference (degrees): {phase: .10f}")
It has to be -phase against GF_python, however.
I get now from the above BodeData3.csv
# Parameters
fs = 50000000 # Sampling frequency in Hz
T = 5120*20e-9 # Signal duration in seconds
f0 = 301373 # Frequency of the sine waves in Hz
beta = 8.0 # Kaiser window beta parameter
Magnitude Ratio (dB): -68.5645216867
Phase Difference (degrees): -88.4299209563
With above AI_C_no_trigo (the Kaiser coeffs calculated with the Bessel I0 code there)
Magnitude Ratio (dB): -68.5643563692
Phase Difference (degrees): -176.0556207288
The phase is off a bit, needs a replacement for the "atan2_aproximation" which seems to me too simple minded to be true.. :)
PS: and this is AI_C code above with standard atan2:
Magnitude Ratio (dB): -68.5643563692
Phase Difference (degrees): -88.4303926343
Btw. - tried with a 3.57MHz crystal, frankly when not having a generator with 1Hz (or less) resolution you may not Bode_it properly ..
Mine is DDS based 1Hz resolution, so it works somehow but all the interesting stuff happens within 10-20Hz.. The contraption below shows +3dB "gain" in the peak, so parasitics must be considered somehow too.. :)
-
Btw. - tried with a 3.57MHz crystal, frankly when not having a generator with 1Hz (or less) resolution you may not Bode_it properly ..
Mine is DDS based 1Hz resolution, so it works somehow but all the interesting stuff happens within 10-20Hz.. The contraption below shows +3dB "gain" in the peak, so parasitics must be considered somehow too.. :)
And with such a narrow-band DUT, you also need to allow enough dwell time after tuning the generator to the new frequency and before taking the measurement. I would guess 100ms or even more.
-
Not only that, the algorithm must be adaptive - it means before taking each Bode point it has to setup the measurement properly, I would not use internal Auto for that but something more specialized..
-
I finally found by chance the latest programming manual (2010, they added couple of commands after the latest fw upgrade) for my scope with additional scpi command for reading full 2x 5120 samples off my vintage DS1062CA.
Also I found a different math for decrypting the actual int8 values coming off the scope :) .
But.. The math with 5k real samples generates rather noisy results (not usable actually, almost random numbers). The 3 math sources above generate the same results with given sample set, so no issue with math itself, it seems. Data look ok as well..
IMHO it is caused by much higher sensitivity to errors of the DFT+Kaiser algo/math with larger N (like fs and f0 frequency alignment or jitter, spectral leakage, math errors, whatever..).
Tried with various betas with less success.. We have to find the way how to utilize that larger N actually.
So far the best results here are with 600 samples. Below an example - a Bode of the above RLC made in a loop while manually setting freq on the HP3310B, making AUTO and waiting couple of secs for stabilization. None averaging. Frequency reading by the scope (not by its "counter" however), so the freq readings are rather coarse.
Even so the 600points capture with beta 8 looks quite rugged, imho.
-
But.. The math with 5k real samples generates rather noisy results (not usable actually). The 3 math sources above generate the same results so no issue with math itself it seems.
IMHO it is caused by much higher sensitivity to errors of the DFT+Kaiser algo/math with larger N (like fs and f0 frequency alignment or jitter, spectral leakage, math errors, whatever..).
Tried with various betas with less success.. We have to find the way how to utilize that larger N actually.
Hmm, IMO the 5120 point data in your BodeData3.csv seem to work pretty well with fs=50MSa/s and f0=301373.
Basically, the more points, the better. But the f0 estimate must be accurate enough so that the actual signal frequency still falls within the passband of the bandpass centered at f0. The more points, the narrower the bandwidth and the more accurate f0 must be. If you are using a digital signal generator, you should know what frequency you set the generator to (without measuring it). This value should already be a pretty good estimate of f0, suffering only from the deviation between the oscillator of the generator and the oscillator of the scope. For a reasonable generator and scope, I would not expect a deviation of more than say ±3 dozens of ppm. EDIT: E.g. the time base accuracy of the DHO800 is specified ±25 ppm. In order that the signal still falls within the filter bandwidht, make sure that the following constraint is fulfilled:
f0_error <= fs / f0 / num_samples or equivalently
num_samples <= fs / f0 / f0_error (if f0_error is given)
Example: With fs=50MSa/s, f0=300kHz and 5120 samples, f0_error must not exceed 50e6/300000/5210 = 0.032403, IOW the f0 estimate must not deviate more than +-3.2403% from the true value. Or, if f0_error is known to be less than 100ppm (0.0001), then records with a length up to 50e6/300000/0.0001 = 1.66M points can be used.
Can you post the data of a 5k in+out record and the corresponding fs and f0, of which you think that they do not work well?
Frequency reading by the scope (not by its "counter" however)
How accurate is the frequency measurement, and what was the sample rate?
With say 50MSa/s, f0=3MHz and 5000 points, the accuracy of the f0 estimate should be better than 0.3%.
-
I will create sets for you tomorrow. I spent the whole day today messing with the 5k issue..
The frequency shown by scope was off by aprox 700Hz at 3.57MHz for example against my DDS.
But I am using the "freq" off the scope reading in the math, so it should not matter so much, imho.. (the freq measurement time base and sample rate comes from the same oscillator inside the scope).
The issue is at kHz freqs too, the mag_dB jumping random within 20% off and phase is all over the place while making measurements at the "constant frequency of the HP generator" which is stable at say 4kHz within 0.2Hz during the measurements..
-
Here are the sets with 5120 and 600 samples measurements, DS1062CA and HP3310B, RLC DUT as above, xfreq=f0= aprox 3334 Hz in all measurements.
First raw in columns:
[SAMPRATE_scope, xSAMPRATE_meas, betaK, T_wide, ts, xfreq_w, xfreq_counter, xmagnitude_DB, xphase_rad, xphase_deg]
xfreq_w - by scope returned freq used in math
xfreq_counter - manually added from the scope's "counter" after the particular measurement
T_wide not used in math
the subsequent rows are:
data1 data2 raw1 raw2
The data1 and data2 were converted:
data1 = v1scale * (199.0-raw1) - 4.0 * v1scale
data2 = v2scale * (199.0-raw2) - 4.0 * v2scale
where
v1scale = 2.0/25
v2scale = 0.1/25
and offsets on the scope were set 0.0
and the offsets were removed in sw as well:
data1 = data1 - np.mean(data1)
data2 = data2 - np.mean(data2)
Time scale on display was 200us/div, aprox 8 periods visible on the scope screen, and ch1 2V/div, ch2 100mV/div, AC coupling, BW OFF, no averaging
Issues:
1. While looking at raw data I see already an issue in 5k raw data - the first 8 and last 9 bytes/samples returned from scope are wrong.. Was not visible in graphs..
2. While counting the number of periods in 5k samples it is aprox 34 (on the screen and in data aprox 8 with 600 samples). So I wonder whether the SAMPRATE and xSAMPRATE and "ts" is ok with 5k (when 5120/600=8.53)..
:scared:
-
2. While counting the number of periods in 5k samples it is aprox 34 (on the screen and in data aprox 8 with 600 samples). So I wonder whether the SAMPRATE and xSAMPRATE and "ts" is ok with 5k (when 5120/600=8.53)..
The raw samples have the original acquisition sample rate (500000) and obviously span a larger time interval than the screen width.
The 600 display samples are obviously downsampled to a lower sample rate and span the time inverval that corresponds to the screen width (implying a sample rate of 600 / screen_width_in_seconds).
Frequency estimate is OK. At 3.3kHz, 500kSa/s and 5000 points, up to 3% deviation are tolerated.
I checked ...5k_TEST{1,2,3}, and they give quite consistent results (using 500kSa/s):
-23.275dB/68.506°
-23.273dB/68.504°
-23.284dB/68.509°
Due to the garbled start and end, I discarded the first and last 60 samples, and used only the 5000 ones in the center of the record (no special reason to use exactly 5000, I just though is was a nice number).
-
The raw samples have the original acquisition sample rate (500000) and obviously span a larger time interval than the screen width.
I just wonder how the 5k records are recorded at a very fast timebase (say 10ns/div), where the scope already interpolates.
Still at the (maximum) acquisition sample rate? Or as interpolated samples at a higher rate than the maximum acquisition sample rate of the scope?
I rather guess the former, but I would not rule out the latter.
[ The 600 display samples are certainly interpolated then. ]
-
Yep it uses sampling rate of the scope in the 5k output..
Below 90 measurements below resonance and in resonance (the RLC DUT above, res around 4030Hz) with 500k sampling rate and 5000samples (the first 60 and last 60 cut off).
-
Not so bad, right? :)
What frequency span did your RLC Bode cover?
Obviously you did sweep the frequency, but the actual frequency steps are not visible in the measured freq.
Your freq measurement obviously gives a quantized result with not very good resolution.
-
None freq span yet, all just at a "fixed generator" frequency (the x axis is the measurement number). The variable frequency is the next step..
Perhaps this weekend, waiting on the Sunday Afternoon.. :P
Below the 3.57MHz crystal, the HP generator set to resonance freq at the beginning, you may see how the generator slowly drifted off the resonance and the mag dropped suddenly. It is not visible on the freq as the xFREQ returned by the scope is coarse (that freq is derived from the waveforms measurement perhaps).
The scope's "counter" is much more precise, but not readable (it is a hw counter inside, it just shows a number on the display when enabled).
PS: as you may see the frequency measured by the scope jumps between two quantum levels, that is because a similar DS1062CA is running on the other side of the Universe and the two are quantum entanglemented.. This project is using AI and QC, btw.. ;D
-
None freq span yet, all just at a "fixed generator" frequency
So the deviation in the 2nd plot from a horizontal noise band (like in the first plot) is drift, not a controlled sweep?
Do you get lower drift with the digital generator? Why do you use the analog one at all?
-
Yep, that is the small drift of the generator around the resonance peak.
I am not using my DDS generator (in the case above) because it starts at around 100kHz and that is too high frequency for elaborating the basics.
The first step is to understand how the math, the code and the scope work, the next step is to start to mess with variable generators on higher frequencies where there are X other parasitics which will mess up with results.
Therefore I wanted to finetune the math and the code at lowest possible frequency without too much care on coaxes, shielding, leakages, etc. Therefore the RLC at 4kHz and none DDS at this stage..
I have several other DDS boards (ie. one pcb still not populated with the ADI's 9912 - 0..500Mhz, 14bit DAC, 48bit tuning word, the chip is waiting for perhaps 15years in the box already) I may reuse, what it needs is a small mcu to pass the tuning word off the python via serial into the DDS. That will be the next step.
-
The scope's "counter" is much more precise, but not readable (it is a hw counter inside, it just shows a number on the display when enabled).
:COUNter:SOURce CHAN1
:COUNter:NDIGits 6
:COUNter:ENABle 1
:COUNter:CURRent?
-
The scope's "counter" is much more precise, but not readable (it is a hw counter inside, it just shows a number on the display when enabled).
My copy of the manual says:
(https://www.eevblog.com/forum/testgear/rigol-dho914s-bode-plot/?action=dlattach;attach=2460577;image)
-
Yep, the COUNTER in DHO804 which shall arrive till end of this year :)
But I've been using its older brother..
BTW., the owners of the DHO800/900 may start with experimenting - ie. writing android app or use pyton - it seems the math above works, just add the external or internal generator in it and that is it..
-
...just add the external or internal generator in it and that is it..
I am missing a good generator, but maybe it can be done with a Fnirsi DSO-TC3?
-
Almost 20y back I got this kit -see attached manual - from our US ham OMs (I mentioned in one of my previous posts). There are tons of similar on ali/ebay to get.
Now thinking which MCU to use, I have got tons of them, it should be 5V so perhaps a pic12 or pic16..
It will receive serial, parse a couple of commands (actually a single one like "F 25123456" would be enough) and SPI the 9851..
...just add the external or internal generator in it and that is it..
I am missing a good generator, but maybe it can be done with a Fnirsi DSO-TC3?
For initial experiments you may use any generator which produces say 1Vpp into some load - for experiments like above with my RLC it is 33kohm load :).
You will set the generator's freq manually and the DHO804 will measure the freq with COUNTER and process a Bode point while measuring CH1 and CH2 (simplified).
I've done it here with an analog HP generator as well as myDDS manually and it is ok for creating the new Quality Bode APP..
The final step will be to call an internal or external generator.. But the first step is to master the 804..
-
Here is a Bode of the 3.579MHz crystal (setup as in the above pictures).
DDS generator aprox 2Vpp output, 1Hz freq step, Bode span 100Hz, ch1/ch2 5000 samples per point, beta=8, none averaging. Scope DS1062CA.
At the maximum 3.579225 (DDS freq) the scope's counter shows 3.58032MHz.
The DDS freq used in the math and in the graph.
MAG_DB blue left scale
PHASE_DEG orange
There are small periodic wiggles on the MAG_DB visible, it may come from some effects caused by the differences in DDS generator's and scope's sampling frequencies. Also the phase differences in coaxes, delay/skew between the channels, impedance matching, etc. might be the cause.
Thus the Quality Bode shall provide calibration too..
-
At the maximum 3.579225 (DDS freq) the scope's counter shows 3.58032MHz.
The DDS freq used in the math and in the graph.
With 5000 point records, 300ppm deviation is OK for the detector if the sample rate is > 5.5MSa/s.
The vout/vin measurement mostly cancels out magnitude and phase errors due to a small frequency offset.
Only SNR suffers, when the filter is not centered at the frequency.
The plot still reflects the given frequency, of course.
Of course you could measure the ratio f_scope_counter/f_DDS once (at a high enough frequency) and use f_DDS*ratio for the detector calculation. Then the residual deviation is mostly a matter of the short term stability (during the sweep) of the DDS and scope oscillators.
There are small periodic wiggles on the MAG_DB visible, it may come from some effects caused by the differences in DDS generator's and scope's sampling frequencies.
Attenuator mismatch can also introduce "steps" where V/div changes (and I guess V/div was not the same for the whole sweep).
What is the frequency resolution of the used DDS (usually it is sample_rate/2^N, where N is an integer, so the resolution is usually not a decimal number). If you set a DDS to a certain frequency, it will round the given number to an integer multiple of the resolution, and the actual generated frequency will in most cases be different from the given number. Unless the resolution is significantly better than 1Hz, it is better to use the actually generated, rounded frequency for calculation and plotting.
For example: If the resolution is e.g. 0.9Hz, and you make 1Hz steps (nominal), then you actually get [0, 0.9, 1.8, 2.7, 3.6, 5.4, 6.3, 7.2,...]+f_start Hz, which is no longer evenly spaced, but every ~9th step has twice the size. Obviously, if you plot these points with even spacing at [0,1,2,3,4,5,6,7...]+f_start, you'll get a discontinuity at every ~9th frequency point.
Since your record length is limited, you can try to average the complex vout/vin quotient of N (say 10...100) measurements at the same frequency point before calculating magnitude and phase -- to reduce noise. Only the first measurement needs to do the setup, while the following N-1 measurements just capture a record and calculate the gain vout/vin. The complex sine wave exp(...) and window function do not need to be recalculated either.
Also the phase differences in coaxes, delay/skew between the channels, impedance matching, etc. might be the cause.
Thus the Quality Bode shall provide calibration too..
Of course, you can perform a response normalization by running a sweep with both probes connected to the reference signal (at the same point). This will cancel out the frequency and phase response differences between the two scope channels, including the probes. However, you are still only measuring the ratio between the voltages at the probe tips, not the full network parameters of the DUT. So the Bode plot cannot predict how the same DUT would behave in a different environment, with different source and load impedances. And it cannot take into account the loading effects of the probes. The Bode plot is not a network analyzer. The measurement setup is still potentially problematic at high frequencies.
-
The above sweep was done at constant V1/2 /div (the amplitude change across those 100Hz was only aprox 6 dB).
The AD9851 DDS I've been using today has 32MHz*6 = 192 MHz clock (a light overclock). It has got an on-chip multiplier (also potential source of errors). Stability of a standard crystal.
The 9851 resolution is 192MHz / (2^32) = 0.0447Hz.
There is uint64 math inside the mcu creating the 1Hz myDDS resolution.
-
The above sweep was done at constant V1/2 /div (the amplitude change across those 100Hz was only aprox 6 dB).
Constant V/div, also for the 2nd channel (DUT output)? In BodeXtal1.jpg I see 80dB amplitude change. Did you really measure ~20µVpp at 1/2 V/div? Even with up to 30dB processing gain of the detector with 5000 samples, such a low voltage still drown in the noise floor.
The 9851 resolution is 192MHz / (2^32) = 0.0447Hz.
:-+
-
The MAG_DB is blue and left hand side Y axis..
MAG_DB blue left scale
PHASE_DEG orange
-
The MAG_DB is blue and left hand side Y axis..
Sorry, my fault. Then the standard error of the log magnitude is within the expected order of magnitude of about 0.1 dB anyway.
-
Tomorrow I will try to look at the ch1 and ch2 alignment at say 10MHz what could be perhaps the highest frequency people may use for Bode these days (assuming for RF work they use vna).
DDS generator set to 10MHz for example and from its T-bnc via two identical coaxes to ch1 and ch2.
-
@ IMo
Been following this on the sidelines, very interesting undertaking :-+
Question wrt to the DUT 3.57MHz crystal as shown in your fixture on post #259. The response shows an amplitude peaking which would indicate a series crystal resonance and would expect the phase to be near zero at resonance unless we missed something?
Best
-
Question wrt to the DUT 3.57MHz crystal as shown in your fixture on post #259. The response shows an amplitude peaking which would indicate a series crystal resonance and would expect the phase to be near zero at resonance unless we missed something?
Yep, the phase shift is there, I have to investigate..
In the meantime I wired both channels into the DDS generator (aprox 1.5Vpp, fixed 10.000000MHz) via coaxes with the same length, not sure about their other params (both seem to be the RG58), DS1062CA scope's counter shows 10.0031MHz.
Below the MAG_DB and PHASE_DEG.
-
..Question wrt to the DUT 3.57MHz crystal as shown in your fixture on post #259. The response shows an amplitude peaking which would indicate a series crystal resonance and would expect the phase to be near zero at resonance unless we missed something?
Here is my attempt to simulate my above fixture and the Bode results..
It fits the PHASE pretty well..
PS: the Xtal params is a rough estimate only..
-
The amplitude should be peaking at series crystal resonance where the phase should be close to zero. With a crystal Rs of 750Ω maybe try and use 10X scope probes to reduce scope capacitive loading, also try and use 50Ω rather than 499Ω termination resistors. The cables capacitance can be significant unless terminated in their characteristic impedance and might be the reason for the phase being away from zero.
Best
-
Those crystal measurements are usually done with matching transformers at both sides (at least I did it that way when building IF xtal filters for my radios)..
The actual crystal measurement exercise was not the goal here, it was just to see the scope data and the math somehow work.
Now waiting for the DHO804.. :)
-
This is a short video which demonstrate that it is possible to run a Python script along with the waveform window and control a device using USB, that procedure could be used to create a Python Bode plot script.
https://www.youtube.com/watch?v=2Ufc24zl8zw (https://www.youtube.com/watch?v=2Ufc24zl8zw)
-
Could you get the ch1/ch2 data into the python?
How fast it goes?
-
A bode plot Python project: https://github.com/ailr16/BodePlot-DS1054Z (https://github.com/ailr16/BodePlot-DS1054Z)
https://www.youtube.com/watch?v=ivJM8q00k0E (https://www.youtube.com/watch?v=ivJM8q00k0E)
-
Could you get the ch1/ch2 data into the python?
How fast it goes?
Yes, about of 5 fps from screen memory.
-
A simple Bode plot can also be made using the harmonics of a step stimuli.
I experimented a bit with my 1kHz probe compensation. I attach two probes to it. CH1 is the reference, CH2 is not so properly compensated. It's either overcompensated or undercompensated.
The plots show the input signals, their FFT and finally the phase and amplitude difference between CH1 and CH2:
[attachimg=1]
It shows that gain varies from -0.69dB to +1.63dB. Resolution is reasonable. Speed is very fast (much less than a second) as one capture is needed for a few hundreds points.
[attachimg=2]
This shows a simple RC filter exited with a 1kHz 4V square wave signal.
Advantage is that it's fast and accurate. Disadvantage harmonics drop by 1/f, so a large dynamic range is needed. Both for the DUT and the scope (I use a DHO804). Passives should not pose any problem, but active circuits need to be able to process the peak to peak square wave signal. But it's very easy to experiment with this setup. As shown in the last picture, I created a small GUI that controls some basic scope settings and does the FFT/Bode post processing with Python numpy.
For this implementation, all you need is a fixed square wave signal and a script to post process the raw captured data.
The accuracy of the generator is not important, as long as it creates harmonics at the frequency of interest. All channels of the scope can be used, so in principle you can measure three circuit points simultaneously.
-
Nice idea and work :-+
If one has an AWG or Pulse Generator, creating a narrow width pulse to simulate an Impulse Function would be interesting to investigate!!
Best
-
A lower duty cycle like 2% seems to help a bit indeed:
[attachimg=1]
But looking at more detail shows the maximum frequency is not the same. That's caused by a filter algorithm I use. I only use FFT points that have an amplitude less than 60dB from the maximum amplitude. Changing the duty cycle also introduces a huge DC term (harmonic 0) which I should ignore.
My setup is limited due to long leads above 1MHz.
To summarize, duty cycle does not have any influence on the performance. It's all about the step in the voltage.
-
[attachimg=1]
This is an LC parallel resonance tank (23.7nF, 68uH) driven by a 1K resistor. It shows the dynamic range can be over 40dB.
The input frequency sets the frequency step size. Here I use 25% duty cycle such that the harmonics are spaced at 1kHz. For one decade from 100kHz to 1MEG there are thus 900 steps . That might still be too low for high Q circuits. In that case the drive frequency needs to be lowered. That works, but it becomes noisier as the amplitude lowers.
-
This is an LC parallel resonance tank (23.7nF, 68uH) driven by a 1K resistor. It shows the dynamic range can be over 40dB.
The input frequency sets the frequency step size. Here I use 25% duty cycle such that the harmonics are spaced at 1kHz. For one decade from 100kHz to 1MEG there are thus 900 steps . That might still be too low for high Q circuits. In that case the drive frequency needs to be lowered. That works, but it becomes noisier as the amplitude lowers.
From how many time domain samples is it calculated?
-
1 Msamples at 156.25 Ms/s
-
[attachimg=1]
[attach=2]
This is 4.9MHz crystal with 300Hz resolution. It's clear that you need more resolution, but it's nice to see :popcorn:
-
With a Dirac's pulse you should get a continuous spectra.. :)
-
Yes, but the power per harmonic drops to zero. I did the experiment a few posts back.
-
[attach=1]
I corrected the setup from banana plugs to coax. Crystal is placed between ch1 and ch2 (50 Ohm). CH1 is driven by 4Vpp 300 Hz signal generator.
[attach=2]
The signal on CH2 now only contains the signal that passes the crystal, nothing else. Before I tried to measure the notch that happens with a R-crystal series connected network. CH2 is lowered to 20mV/div instead of 1V/Div. That helps to improve the signal to noise ratio.
Concept wise it shows that you can use this method on any scope. You don't need the Bode plot option or swept signal generator. I even think this works for loop stability analysis just as well.
For a 3V DCDC converter inject 100mV step into the feedback loop. The supply will follow this as 2.95V and 3.05V and the resulting spectrum can be measured with the scope channels set to full scale. With a loop bandwidth of 10kHz, inject a 100Hz signal and the resolution should be fine.
-
One potential issue with this approach is you cannot set the "ADC range" for each frequency within your Bode. So the dynamic range of the Bode is limited by the actual ADC setting. With the "standard" approach you would adjust the ADC at each frequency such the signal fits it well (at least I would do it).
PS: Dirac - the spectral amplitudes do not go to zero (with the discrete number of points).. With a pulse of an amplitude A and number of spectral lines N the amplitude of each line should be A/N (plus minus windowing coef), afaik.. Sure, with million spectral lines it is not applicable in this case..
-
Yes indeed. There is a fixed ADC dynamic range. Since the harmonics attenuate by 1/N (20dB/decade roll-off) only the first three decades can be used. I have not seen a lot of real DHO915s results (and I don't own one) but from what I've seen the results are much worse from what I show. That is probably due to the way Rigol implemented it.
-
Try to generate random square noise and do N averagings of the spectra, what it does..
-
With a Dirac's pulse you should get a continuous spectra.. :)
One disadvantage of a continuous spectrum stimulus is that the detector cannot benefit from processing gain. IOW, as the detector bandwidth is reduced, the SNR does not increase accordingly, because with decreasing bandwidth, the detector captures less noise, but also less of a useful wide-band signal :( OTOH, if useful signal is concentrated in a single frequency, the detector still captures the full power of the useful signal when the detector's bandwidth is reduced, but it captures less noise, therefore increasing SNR.
And the crest factor of a Dirac delta impulse is, of course, horrible (in fact, it is infinite). For a given peak-to-peak amplitude (which is limited by the ADC), the crest factor determines the power of the signal (high crest factor implies low power), and a low-power signal has a low SNR wrt. to a given noise power.
Try to generate random square noise and do N averagings of the spectra, what it does..
PRBS has at least a low crest factor. But its spectrum is still noisy, i.e. there will exist random frequencies in the spectrum with low stimulus power and therefore low SNR.
If you want to do vector averaging, you can only average the complex gain Vout(f) / Vin(f), which has the same expected value in each acquisition. But if you want to average multiple acquisitions of Vin(f) or Vout(f), you can only do power averaging, i.e. you don't get phase information.
-
So the new "ideal Quality Bode" inside the DHO-XXX should work such it:
a) allows to enter Fstart, Fstop, N points per decade, M averages, window function and beta/alfa off its screen (or something like that)
b) sets the generator's output (if applicable) at the level which is appropriate for the given DUT and the type of measurement (set siggen output attenuation or DUT output amplification if applicable, for example)
c) looks at the DUT's output and sets the scope's CH1 and CH2 ranges and sampling rate such it fits best the scope and math, if it does not fit well the scope and math goto b)
d) makes the measurements in CH1 and CH2, downloads the CH1 and CH2 data into the python, do it M times for averaging if applicable
e) makes the math in the python (or C/C# whatever) residing inside the DHO-XXX and updates the custom graph on its screen accordingly
f) while still in between Fstart and Fstop goto b)
-
With a Dirac's pulse you should get a continuous spectra.. :)
One disadvantage of a continuous spectrum stimulus is that the detector cannot benefit from processing gain. IOW, as the detector bandwidth is reduced, the SNR does not increase accordingly, because with decreasing bandwidth, the detector captures less noise, but also less of a useful wide-band signal :( OTOH, if useful signal is concentrated in a single frequency, the detector still captures the full power of the useful signal when the detector's bandwidth is reduced, but it captures less noise, therefore increasing SNR.
And the crest factor of a Dirac delta impulse is, of course, horrible (in fact, it is infinite). For a given peak-to-peak amplitude (which is limited by the ADC), the crest factor determines the power of the signal (high crest factor implies low power), and a low-power signal has a low SNR wrt. to a given noise power.
Try to generate random square noise and do N averagings of the spectra, what it does..
PRBS has at least a low crest factor. But its spectrum is still noisy, i.e. there will exist random frequencies in the spectrum with low stimulus power and therefore low SNR.
If you want to do vector averaging, you can only average the complex gain Vout(f) / Vin(f), which has the same expected value in each acquisition. But if you want to average multiple acquisitions of Vin(f) or Vout(f), you can only do power averaging, i.e. you don't get phase information.
Good points :-+
Correlated/Synchronized/Freq-Selective sampling/detecting with the signal source is a powerful technique, and allows the signal being processed to be less influenced by thermal noise but other "noise" sources as well, such as Line, SMPS chopping, and Digital for example.
Best
-
With a Dirac's pulse you should get a continuous spectra.. :)
One disadvantage of a continuous spectrum stimulus is that the detector cannot benefit from processing gain. IOW, as the detector bandwidth is reduced, the SNR does not increase accordingly, because with decreasing bandwidth, the detector captures less noise, but also less of a useful wide-band signal :( OTOH, if useful signal is concentrated in a single frequency, the detector still captures the full power of the useful signal when the detector's bandwidth is reduced, but it captures less noise, therefore increasing SNR.
And the crest factor of a Dirac delta impulse is, of course, horrible (in fact, it is infinite). For a given peak-to-peak amplitude (which is limited by the ADC), the crest factor determines the power of the signal (high crest factor implies low power), and a low-power signal has a low SNR wrt. to a given noise power.
Try to generate random square noise and do N averagings of the spectra, what it does..
PRBS has at least a low crest factor. But its spectrum is still noisy, i.e. there will exist random frequencies in the spectrum with low stimulus power and therefore low SNR.
If you want to do vector averaging, you can only average the complex gain Vout(f) / Vin(f), which has the same expected value in each acquisition. But if you want to average multiple acquisitions of Vin(f) or Vout(f), you can only do power averaging, i.e. you don't get phase information.
I determine the (complex) ratio between CH1 and CH2. From that I determine the phase and amplitude. Both phase and amplitude can be averaged over multiple measurements taken into account phase wrapping in the right way.
-
So the new "ideal Quality Bode" inside the DHO-XXX should work such it:
A good starting point would be the Siglent Bode Implementation, adding the ability to do the Bode Function on Math Functions, Selective Bode Plot Averaging, Channel Bode Math (Bode Channel +- ), Normalizing (Calibration References), Selective Sweep types beyond Lin/Log to Range for example.
Selective Sweeps might involve higher resolution frequency steps over a smaller band of the total frequency sweep range, good for examining high "Q" resonate DUTs (Crystals) for example.
Applaud you and TheoB for this undertaking, as we know the effort involved :clap:
Best
-
Hopefully the android programmers here will take the opportunity to program/create an open source Quality Bode for the DHO-xxx. All required components are known, people have shown it is basically doable inside the DHO, so it is up to those skilled and willing members here to start to mess with that android ecosystem..
Of course they should start small.. and slowly make the enhancements..
A nice project for the upcoming year 2025, indeed..
Let us call the 2025 "The year of new Bode" ;D ;D
-
It makes me sad to see all these people talking at length about how to make Bode plot for DHO900..
How about Rigol fixes one you already bought and allegedly is in the scope?
-
Here's some links to using the Bode Function to investigate Oscillator behavior, might be of interest to see how this works with the Pulsed Source being discussed?
https://www.eevblog.com/forum/projects/things-coming-together-bode-plot-diy-isolation-transformer-peltz-oscillator/ (https://www.eevblog.com/forum/projects/things-coming-together-bode-plot-diy-isolation-transformer-peltz-oscillator/)
https://www.eevblog.com/forum/projects/injection-locked-peltz-oscillator-with-bode-analysis/ (https://www.eevblog.com/forum/projects/injection-locked-peltz-oscillator-with-bode-analysis/)
Best,
-
It makes me sad to see all these people talking at length about how to make Bode plot for DHO900..
How about Rigol fixes one you already bought and allegedly is in the scope?
Agree this is sad, as many of the knowledgable folks on here seem to realize that Rigol likely won't be addressing this soon (or ever) and have taken the Bode Task upon themselves.
Best
-
It makes me sad to see all these people talking at length about how to make Bode plot for DHO900..
How about Rigol fixes one you already bought and allegedly is in the scope?
Pay attention, they're actually making it for the DHO800 as well.
Which makes it an excellent hack.
-
Pay attention, they're actually making it for the DHO800 as well.
Which makes it an excellent hack.
Think you've missed the point! Rigol should have already done this, then the "hack" would be expanding the features/function/performance rather than a user created complete baseline creation.
Rigol is in a position with "inside information" to create a Quality Bode Function, but apparently is choosing not to do such probably because of the $ investment, leaving that to their customers at their expense/time.
We must remember Rigol is a mid-level OEM, not lower tier as Owon, Fnirsi, or Hantek and should be held to a higher accountability :-+
Best
-
Pay attention, they're actually making it for the DHO800 as well.
Which makes it an excellent hack.
I find it generally sad that users have to “tinker” with the scope because the manufacturer is not making any effort to improve the device.
The (not error-free) Bodeplot function has not been touched by Rigol since MSO5000 times and simply implemented in the corresponding DHO models.
The sad highlight so far is that a private user has corrected the faulty FFT windows.
Rigol throws the scopes on the market and forgets to mention that they are developer boards.
Now there are new series on the market and I bet that they have the same flaws as the previous 12-bit devices.
This is very disappointing, as Rigol is actually the second “power” in the market for affordable scopes.
Siglent has long since been overtaken, and Owon is already lurking “around the corner” should their new models deliver what they promise on paper.
Rigol should stop launching new models every year and instead focus their development power on optimizing existing models, otherwise they will become redundant in the foreseeable future.
-
I determine the (complex) ratio between CH1 and CH2. From that I determine the phase and amplitude. Both phase and amplitude can be averaged over multiple measurements taken into account phase wrapping in the right way.
Do not average magnitude and phase separately, but average the complex ratios fft(CH1) / fft(CH2) of multiple measurements in complex space (vector averaging), and finally determine magnitude and phase from the (complex) average of the ratios. The vector average is unbiased with regard to the noise of CH1, while separate magnitude and phase averages are significantly biased if the SNR of CH1 is low.
[ The noise of the reference signal CH2 (divisor) unavoidably introduces a bias in any case, but it seems to be virtually negligible as long as the SNR of CH2 is at least 20dB (after utilizing the detector's processing gain). ]
-
For the moment I will not use averaging as there is much better way to increase the SNR of the measured signal.
I start with a square wave signal. The fundamental is set to 0dBfs (fill the entire screen). The fundamental has a SNR of more than 100dB. Harmonics attenuate by 1/N or 20dB/decade. This means an S21 (or 'gain') can be measured over a 4 decades frequency range and you have still 20dB of dynamic range left at the end.
For example when measuring an audio amplifier flatness from 10Hz to 20kHz. At 10Hz the SNR is >100dB and at 20kHz the SNR is lowered to 34dB. Is 34dB at 20kHz enough? That all depends on how much attenuation you want to see at that highest frequency.
With the current hardware I have (happy with the cheap DH0804) I have a 12 bit DAC running up to 1.25Gs. To prevent aliasing and noise folding, it's best to limit the frontend bandwidth to 20MHz and choose a sample rate of at least 40Ms/s. The Rigol has 62.5Ms/s at 1ms/div horizontal timebase (sampling rate cannot be set manually but follows from the horizontal timebase setting and the number of channels enabled).
Memory depth of 25Ms is the max when two channels are enabled (what I need).
25Ms/(62.5Ms/s)=0.4s That means FFT bin size is 2.5Hz (and the lowest bin also starts at 2.5Hz). You can measure the entire amplifier over 4 decades (10k) with at least 34dB SNR.
An extra addition is to capture twice. Once with 10Hz and once with 10kHz. The result will be merged into one plot ranging from 10Hz to 100MHz (or actually 20MHz due to channel bandwidth filtering).
The user should do this:
- Put generator at 10Hz
- Press capture
- Put generator at 10kHz
- Press capture
The FFT bins are exactly the same so this should be doable to extend the useful range.
-
Implemented the dual capture idea idea and indeed it seems to work nicely:
[attach=1]
The plot shows a single capture with 10Hz on the left which becomes limited by noise at high frequencies (and I therefor do not use that data).
On the right an extra run at 10kHz which shows the LRC notch at 110kHz.
It's just proof of concept (and hobby ^-^)
-
The 3rd decade already looks quite noisy. Maybe you should not cover more than 2 decades with one fundamental frequency.
That all depends on how much attenuation you want to see at that highest frequency.
In order to set a challenging aim, let's say 100+ dB.
Maybe user configurable, in order that the algorithm can be adapted according to the user's needs.
At the end it is a trade-off with measurement speed.
-
Well, if you use just one decade for each frequency, the dynamic range is between 110 and 80 dB. Limited by the scope performance. And you get only 10 points per capture. Still 10 times faster than when using a single tone.
Drawback is also that you have to change the frequency more often. Two times feels like ok for manual control.
It's nicer if you can control the signal generator from a PC. In that case you have best of both worlds. Start with a fast frequency transfer using one or more square wave tones to cover a large band quickly. For high Q or high dynamic range use a classic slow stepped sine wave.
In all cases, use FFT on the raw data. It provides very low RBW for noisy environments like switched mode power supplies. And it gives the frequency, amplitude and phase of the external stimulus. I've read the discussion earlier in this thread about using the scope's internal counter for frequency. That does not make sense if you can get that info from the frequency domain directly.
-
In all cases, use FFT on the raw data.
How long does a full 25M point FFT take on the DHO800's CPU?
I guess there is neither an API to the hardware-accelerated FFT engine that could be used by custom apps, nor does it support that many points?
-
I think I have a guess as to why the Bode Plot feature has weird bends or corners in it (the "wiggles" issue is separate). They are simply drawing the points at the wrong horizontal position in the graph. The measurements themselves are fine; it's just displayed wrong.
For some reason, at each decade boundary, the 1st sample to the right of the boundary has an unusually large horizontal jump that is inconsistent with the ones that follow it. In contrast, the 1st sample to the left has a small jump that is consistent with the ones that precede it.
In the 3 photos, 300 points per decade was used. This made the delta Hz between samples small. The 1st photo shows the cursor at 9.92 kHz, the 2nd at 10.00 kHz, and the 3rd at 10.08 kHz. Notice the cursor make a small horizontal jump from 9.92 to 10.00 kHz while it is large for 10.0 to 10.08 kHz. The 2nd jump should instead be slightly smaller than the first due to the logarithmic scale.
The Excel file and chart were taken directly from the Rigol's measurements generated by the same Bode plot.
I'll report this to Rigol's support.
Apologies if someone else already covered all this.
Just to follow up on this bug after almost 2 years, with firmware v1.04, this bug still has not been fixed.
I pinged them again the other day, but it is the holidays...
-
I think I have a guess as to why the Bode Plot feature has weird bends or corners in it (the "wiggles" issue is separate). They are simply drawing the points at the wrong horizontal position in the graph. The measurements themselves are fine; it's just displayed wrong.
For some reason, at each decade boundary, the 1st sample to the right of the boundary has an unusually large horizontal jump that is inconsistent with the ones that follow it. In contrast, the 1st sample to the left has a small jump that is consistent with the ones that precede it.
In the 3 photos, 300 points per decade was used. This made the delta Hz between samples small. The 1st photo shows the cursor at 9.92 kHz, the 2nd at 10.00 kHz, and the 3rd at 10.08 kHz. Notice the cursor make a small horizontal jump from 9.92 to 10.00 kHz while it is large for 10.0 to 10.08 kHz. The 2nd jump should instead be slightly smaller than the first due to the logarithmic scale.
The Excel file and chart were taken directly from the Rigol's measurements generated by the same Bode plot.
I'll report this to Rigol's support.
Apologies if someone else already covered all this.
Just to follow up on this bug after almost 2 years, with firmware v1.04, this bug still has not been fixed.
I pinged them again the other day, but it is the holidays...
In my (much) earlier posts, I showed the discrepancies in the Bode plot by graphing the data directly from .csv files using an external graphing program.
-
Just to follow up on this bug after almost 2 years, with firmware v1.04, this bug still has not been fixed.
This firmware is from 2024.
The next one might work, because the new MHO900 series no longer has the Bode plot problem.
(It works now, but you can't scale it, and the strange display (horizontal lines) remains.)
-
In my (much) earlier posts, I showed the discrepancies in the Bode plot by graphing the data directly from .csv files using an external graphing program.
Cool. I must have missed that post (the thread is long so I had to skim) since I posted the same thing here on Feb 11th, 2024. Glad I'm not the only one who is annoyed by this bug.
-
This firmware is from 2024.
The next one might work, because the new MHO900 series no longer has the Bode plot problem.
(It works now, but you can't scale it, and the strange display (horizontal lines) remains.)
Do we know if Rigol will continue releasing new firmware update for the DHO900 or is v1.04 the end of the line? Given that it has been over 1 years since the last version (none in 2025 for the DHO900), I have some concerns that they might have moved on to the next shiny thing. If they back-port MHO900 fixes into a DHO900 release, that would be great.
-
They should definitely do that, because not only has the Bode plot been repaired, but also the FFT function, plus the additional FFT modes (Average, Peak)...
https://www.eevblog.com/forum/testgear/rigol-mho98-and-mho900-oscilloscope-series/msg6080453/#msg6080453 (https://www.eevblog.com/forum/testgear/rigol-mho98-and-mho900-oscilloscope-series/msg6080453/#msg6080453)
https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/msg6089599/#msg6089599 (https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/msg6089599/#msg6089599)
I can't think of any reason why Rigol shouldn't do that.
It's the same software platform, after all.
-
Just to follow up on this bug after almost 2 years, with firmware v1.04, this bug still has not been fixed.
I pinged them again the other day, but it is the holidays...
Following up again: no reply from Rigol so I created a new email thread with Rigol. Hopefully, they will reply to this one.
-
To follow up on the Bode Plot display bug, I have been able to confirm this bug has been fixed in firmware v00.01.05.00.01.
However, this release has not propagated through all Rigol WWW sites. iMo posted where to get this release on a different thread:
https://www.rigol.com/europe/support/firmware-software.html?lines=E96E379BAA804A0C932AB55923AA5B07&series=0F74EA939496484A8426EB591F02ED29&field=firmware&assetType=firmware (https://www.rigol.com/europe/support/firmware-software.html?lines=E96E379BAA804A0C932AB55923AA5B07&series=0F74EA939496484A8426EB591F02ED29&field=firmware&assetType=firmware)
Firmware Page 2
You have to login to download..
Here's a snippet from the release notes:
[Model Supported] All the DHO800/900 series oscilloscopes
[Latest Revision Date] 2026/01/20
[Updated Contents]
v00.01.05.00.01 2026/01/20
1.Optimized the Bode plot curve.
2.Fixed the issue where cursors cannot be set in FFT mode.
v00.01.05.00.00 2025/11/25
1.Added user-defined probe ratio setting.
2.Optimized AFG frequency display, highlighting the display.
3.Added the Move Scale sub-menu under the Display menu.
4.Added the Peak Detect on/off sub-menu under the Save tab in the Storage menu, allowing users to select whether to enable or disable peak detection while saving the waveforms.
5.Added the Display Area sub-menu under Math menu, allowing you to select whether to display math waveforms in the main window or math operation window.
6.Added the function of switching the screenshot preview.
7.Added the function of exporting LA (Logic Analyzer) waveform memory data.
8.Added saving images in different formats.
9.Fixed an occasional issue where certain horizontal measurement items failed to measure.
10.Fixed an issue where the UI did not synchronize with the probe ratio unit setting command.
11.Fixed the system reboot issue caused by running in the ZOOM mode for a long period.
-
I hope the fix works after all these years after I first started this thread.
I won’t have time to try it until late this month.
-
All I can say is the phrase all software developers dread: it works on my machine. ;)
-
Hi,
I've got a friend who's looking for something to do Bode Plots with. He obviously wants the cheapest thing possible.
Do these things work yet? I saw a few posts up that the Bode plot is much improved by the new firmware.
-
Confirmed as fixed.
-
Hi,
I've got a friend who's looking for something to do Bode Plots with. He obviously wants the cheapest thing possible.
Do these things work yet? I saw a few posts up that the Bode plot is much improved by the new firmware.
Works pretty well.
Still could be faster or some plot scaling could work better, but since dumping data to excel works it is not most important.
-
Bodyplot with the DHO804 and the DGE2070 connected to the DHO via USB: https://t.me/CodeAndCircuits/9/248
[attach=1]
-
Try this: https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg6316164/#msg6316164 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg6316164/#msg6316164)