New Rigol HDO1000 12-bit DSO - BUGs

[the Chris]

Did you report to Rigol?

No, but it probably doesn't harm trying. Is there an official way to report bugs?

[thm_w]

Did you report to Rigol?

No, but it probably doesn't harm trying. Is there an official way to report bugs?

You can send an email to info-europe@rigol.com in EU or help@rigol.com for NA. They will respond back with a confirmation and add to list of bugs.

edit: I was actually on 2.11 and most of the 0.000V Dev issues seem to be fixed on 2.12, but not all. For Frequency I had it get stuck on a certain Dev value and never change. Which has to be wrong if its calculated based on the last 1,000 points. I assuming its storing those numbers, as the max you can set is 100,000.

[thunderbolt93]

I tried that with FW 2.12 and noticed something
there seems to be some jitter of about 2ns when using the external trigger input.

Both screenshots are taken with infinite persistance

[TurboTom]

It's not a bug, it's a feature  . See pg. 10 of Rigol's HDO1000 Data Sheet document. There you'll find jitter for the external trigger input to be specified at < 1ns rms (which equals <2ns pp or even more, depending on the histogram), exactly what one would expect from an all-digital trigger system that had been "extended" with an additional one-bit ADC (comparator...) for the fifth, external trigger input. Obviously, for this input, an interpolative trigger, based on the waveform isn't possible, hence the jitter of an interval that is defined by the speed the sampling engine's FPGA can process the trigger comparator input signal.

What's much more worrying is the trigger jitter that is present at AC and HF trigger coupling as had been reported by others before. That shouldn't be there and Rigol will have to take care of this.

[gf]

It's not a bug, it's a feature  . See pg. 10 of Rigol's HDO1000 Data Sheet document. There you'll find jitter for the external trigger input to be specified at < 1ns rms (which equals <2.8ns pp), exactly what one would expect from an all-digital trigger system that had been "extended" with an additional one-bit ADC (comparator...) for the fifth, external trigger input. Obviously, for this input, an interpolative trigger, based on the waveform isn't possible, hence the jitter of an interval that is defined by the speed the sampling engine's FPGA can process the trigger comparator input signal.

In principle, it would have been possible to measure the time interval between the trigger point (as determined by the comparator) and the ADC clock edge with a TDC, but it was obviously a cost-saving design decision not to do it.

[pilatomic]

Hello fellow bug collectors,

I took delivery of a DHO1074 last week, and found 2 bugs I didn't see mentionned anywhere. (FW ver 00.02.12).

1. Decoders threshold levels bug.

    If probes are set to a value other than X1, decoders thresholds level do not keep their value each time a new acquisition is done, or a trace is moved.

How to reproduce :

    Set CH1 probe to X10, enable I2C decoder with CH1 as SDA (for example), and set threshold to 1.0V. Press "Single" to . Decoder threshold still shows "1.0V", but when clicked immediately switches to 10.0V. Decoding does __not__ happen until setting back the threshold to 1.0V, which implies the threshold is internally set to 10.0V.

This is a blocking issue in my workflow, as it completely prevents SPI decoding using X10 probes.

2. Cannot change channel of measurement

How to reproduce :

    Enable any measurement, on a specific channel. Press on measurement, press "settings" and change measurement channel. This has no effect.


I wrote to Rigol (info-europe@rigol.com) about that, I'm waiting for their answer.
I hope to see at least the 1st one resolved, as it makes the decoders basically useless with anything else than 1X probes.

[Fungus]

Both have been mentioned before but another person writing to Rigol is good... 

[ebastler]

I have spent some time playing with the FFT on my DHO1074 now. Here's my summary of the good, the bad and the ugly -- repeating various findings others have reported before, but also adding a bit more clarity on some aspects, I hope. Apologies for a long post...

1. Good news first: One does get full control over the FFT record length and sampling rate, and hence the frequency step (resolution) and maximum frequency range. It is just not part of the FFT dialog, but controlled via the regular acquisition settings -- which makes sense to me, since FFT is a math operation based on the normally acquired data:

• The total duration of a sweep (10 * time/div) controls the frequency step in the FFT, df = 1/t_sweep.
  EDIT: While that is "qualitatively true", the exact frequency step (as read from the kinks in the linear-interpolated FFT spectrum) is not exactly as stated. Steps can be smaller than expected, pointing to a larger record length being used. See the posts by gf and myself a bit further down.
• The sampling rate controls the maximum frequency, f_max = f_sampling/2 as expected. Can be set to taste via the time base and the memory depth (acquisition settings).
• Caveat 1: As advertised, the FFT only uses up to 1 MPts of data. If more memory is selected in the acquisition settings, the acquisition will run at a faster sampling rate, but the data will be down-sampled for the FFT, limiting the max. frequency. The sampling rate indicated in the FFT window will be the one actually used for FFT, as one would expect. This is all fine and in spec.
• Caveat 2: At slow time base settings, 50 ms/div and slower, something breaks. The FFT's maximum frequency drops to only 1/10 of what one would expect. E.g. for 1 MPts, 50 ms/div, the sampling frequency is 2 MSa/s as expected, but fmax = 100 kHz instead of the expected 1 MHz. This is a bug, I believe.
  EDIT: Automatic Roll mode was activated and kicked in at 50 ms/div. While it is unfortunate that this throws the FFT off track, it is easily avoided by disabling Roll mode in the acquisition settings.

2. As discussed in earlier posts, the "RBW" displayed in the FFT window title is a mess on multiple levels:

• Terminology is wrong; it is apparently not meant to be a Resolution Bandwidth, but a frequency step. Values don't change when you change window functions, and the numbers are too even to be actual RBWs.
• The displayed RBW value does not have a unit. And the missing unit does not seem to be simply Hz in most cases...
• The displayed RBW is not even reproducibly linked to the FFT settings! Turn the time base up and back down by a step or two, and the RBW does not always return to its prior value?! The actual frequency step and resolution of the FFT behave correctly though. Clearly a bug.

3. Peak search works well for me. Sorting the peak table by frequency or amplitude, setting the minimum peak level and the minimum excursion (valley depth) between peaks all work as expected. However I ran into situations a few times where the FlexKnobs got confused as to what they were controlling. Clearly buggy, although I struggle to find a crisp sequence of steps to reproduce it. Not sure whether this is specific to FFT/Peak Detection, or can also happen with other dialogs which have many numeric input fields to choose from?

• E.g. the yellow "1" and "2" markers were on the peak detection settings, but the markers knobs actually controlled the FFT span and center frequency.
• Related, but not directly correlated with the above: Sometimes the white illuminated arrows next to the FlexKnobs point in the wrong direction, e.g. showing horizontal arrows while the control acts on a vertical (voltage) parameter.

4. As found and fixed by TurboTom, Rigol's Flattop window is broken. With Tom's fixed weights, FlatTop is my go-to window function.

5. As mentioned many times (not only by the friends of Siglent  ), it is a pity that neither Averaging nor Peak Hold modes are implemented for FFT. Not a bug but an important feature wish.

[2N3055]

I have spent some time playing with the FFT on my DHO1074 now. Here's my summary of the good, the bad and the ugly -- repeating various findings others have reported before, but also adding a bit more clarity on some aspects, I hope. Apologies for a long post...

1. Good news first: One does get full control over the FFT record length and sampling rate, and hence the frequency step (resolution) and maximum frequency range. It is just not part of the FFT dialog, but controlled via the regular acquisition settings -- which makes sense to me, since FFT is a math operation based on the normally acquired data:

• The total duration of a sweep (10 * time/div) controls the frequency step in the FFT, df = 1/t_sweep.
• The sampling rate controls the maximum frequency, f_max = f_sampling/2 as expected. Can be set to taste via the time base and the memory depth (acquisition settings).
• Caveat 1: As advertised, the FFT only uses up to 1 MPts of data. If more memory is selected in the acquisition settings, the acquisition will run at a faster sampling rate, but the data will be down-sampled for the FFT, limiting the max. frequency. The sampling rate indicated in the FFT window will be the one actually used for FFT, as one would expect. This is all fine and in spec.
• Caveat 2: At slow time base settings, 50 ms/div and slower, something breaks. The FFT's maximum frequency drops to only 1/10 of what one would expect. E.g. for 1 MPts, 50 ms/div, the sampling frequency is 2 MSa/s as expected, but fmax = 100 kHz instead of the expected 1 MHz. This is a bug, I believe.

2. As discussed in earlier posts, the "RBW" displayed in the FFT window title is a mess on multiple levels:

• Terminology is wrong; it is apparently not meant to be a Resolution Bandwidth, but a frequency step. Values don't change when you change window functions, and the numbers are too even to be actual RBWs.
• The displayed RBW value does not have a unit. And the missing unit does not seem to be simply Hz in most cases...
• The displayed RBW is not even reproducibly linked to the FFT settings! Turn the time base up and back down by a step or two, and the RBW does not always return to its prior value?! The actual frequency step and resolution of the FFT behave correctly though. Clearly a bug.

3. Peak search works well for me. Sorting the peak table by frequency or amplitude, setting the minimum peak level and the minimum excursion (valley depth) between peaks all work as expected. However I ran into situations a few times where the FlexKnobs got confused as to what they were controlling. Clearly buggy, although I struggle to find a crisp sequence of steps to reproduce it. Not sure whether this is specific to FFT/Peak Detection, or can also happen with other dialogs which have many numeric input fields to choose from?

• E.g. the yellow "1" and "2" markers were on the peak detection settings, but the markers actually controlled the FFT span and center frequency.
• Related, but not directly correlated with the above: Sometimes the white illuminated arrows next to the FlexKnobs point in the wrong direction, e.g. showing horizontal arrows while the control acts on a vertical (voltage) parameter.

4. As found and fixed by TurboTom, Rigol's Flattop window is broken. With Tom's fixed weights, FlatTop is my go-to window function.

5. As mentioned many times (not only by the friends of Siglent  ), it is a pity that neither Averaging nor Peak Hold modes are implemented for FFT. Not a bug but an important feature wish.

Excellent work and post!

[Martin72]

4. As found and fixed by TurboTom, Rigol's Flattop window is broken. With Tom's fixed weights, FlatTop is my go-to window function.

Afaik flattop window was not the only one or did you check all of them ?

[ebastler]

4. As found and fixed by TurboTom, Rigol's Flattop window is broken. With Tom's fixed weights, FlatTop is my go-to window function.

Afaik flattop window was not the only one or did you check all of them ?

I did look at the spectra generated with other window functions, and they look much more plausible. There is, however, a slight asymmetry in the main peak when you zoom in a lot, with all the window functions. That's probably not real, so yes, there might be (lesser) deviations in other window functions too.

As a consequence of setting the sampling parameters via the regular time base and memory depth controls, the FFT always works on record lengths which are not a power of two, apparently. I wonder whether the implementation handles that cleanly?

[gf]

Afaik flattop window was not the only one or did you check all of them ?

I did look at the spectra generated with other window functions, and they look much more plausible. There is, however, a slight asymmetry in the main peak when you zoom in a lot, with all the window functions. That's probably not real, so yes, there might be (lesser) deviations in other window functions too.

The left sides of these images definitively do not look correct. Seems to be rather a general problem, not window function specific. Maybe related to the interpolation upon zoom-in?

As a consequence of setting the sampling parameters via the regular time base and memory depth controls, the FFT always works on record lengths which are not a power of two, apparently. I wonder whether the implementation handles that cleanly?

There do exist FFT algorithms for non-power-of-2 sizes. All "1-2-5 sizes" can be decomposed into combinations of radix-2 and radix-5.

[ebastler]

The left sides of these images definitively do not look correct. Seems to be rather a general problem, not window function specific. Maybe related to the interpolation upon zoom-in?

Ah, thanks for the link. I remembered that Martin had done FFT measurements with the DHO800, but could not find them yesterday.

I just repeated with the same settings on the DHO1074, and with an input signal at 1 kHz - 1/2 delta_f. As one would expect things look pretty much the same. I had seen that distortion in yesterday's experiments; it's the "slight asymmetry" of the peak shape I referred to above. Certainly an artefact, but not as problematic as the massive peak broadening and ripple produced by the incorrect flat-top window.

EDIT: I don't think the distorted peak shapes are due to interpolation artefacts. For the FFT, simple linear interpolation between data points is used; while there is no "dot" mode, the individual straight line segments are visible when zoomed in. The asymmetry is on a scale of several delta_f steps.

Maybe, if TurboTom finds himself with too much time on his hands, he could look into those other window functions too? 

There do exist FFT algorithms for non-power-of-2 sizes. All "1-2-5 sizes" can be decomposed into combinations of radix-2 and radix-5.

Sure, I know they exist. My question was whether Rigol got them right.
That might be another reason for FFT artefacts, besides deviations in the window functions.

EDIT 2: Looking at Martins DHO800 screenshots again, they do show more reasonable "RBW" values. The displayed "RBW" is actually the frequency step in Hz in all those screenshots. On the DHO1074, I get displays of "9.999m" or such. And as mentioned, if I switch the time base up and down again, the RBW often does not come back to where it was before, so there is no clear correlation between delta_f and RBW at all. Looks like they at least fixed that in the DHO800, so there is hope for the larger models... If they furthermore added the "Hz" unit and called it "Step" instead of RBW, I'd be happy. 

[gf]

I don't think the distorted peak shapes are due to interpolation artefacts. For the FFT, simple linear interpolation between data points is used; while there is no "dot" mode, the individual straight line segments are visible when zoomed in. The asymmetry is on a scale of several delta_f steps.

The Siglent screenshots I've seen did indeed interpolate linearly between frequency points. But do you also see straight line segments on the DHO?

With linear interpolation between frequency points, you would not see the side lobes of Rectangular, Hann, Blackman, Flattop (and some others) windows, because the frequency points outside the main lobe happen to coincide with zeros of the frequency response of these window functions - and linear interpolation would give zero anywhere in between, too. But in various posted DHO screenshots, I do see side lobes. This leads me to believe that the DHOs do not interpolate linearly.

EDIT: I have to correct: We still can see contributions of side lobes, of course, if the signal frequency is not an integer multiple of delta_f.

[ebastler]

The Siglent screenshots I've seen did indeed interpolate linearly between frequency points. But do you also see straight line segments on the DHO?
[...]
We still can see contributions of side lobes, of course, if the signal frequency is not an integer multiple of delta_f.

Yes, the interpolation clearly shows linear segments -- see the attached screenshot.

In the attached, I set the signal frequency to 1 kHz, a full multiple of delta_f, and there still is an asymmetry. Also, strangely there never seems to be an FFT data point right at 1 kHz; they are always a bit displaced to the left and right, and asymmetrically from the 1 kHz mark. (Assuming that the kinks in the curve denote the data points.) Is that a consequence of the non-power-of-two FFT? EDIT: I don't see how that would be the case though, with an even 10 MHz sampling rate.

[gf]

Also, strangely there never seems to be an FFT data point right at 1 kHz;

The FFT frequency points should be integer multiples of delta_f. So with delta_f=20Hz, yes, there should be a point at 1kHz. Strange if not.

EDIT:

Ist it possible that we do not see a 500,000 point FFT, but rather a 524,288 (power-of-2) point FFT?
Then the actual delta_f would be 19.073 Hz, and frequency points would exist at 991.82 and 1010.9 Hz.

This would at least imply that the reported delta_f (RBW) is wrong/misleading.
(The reported number of FFT points can't be wrong, since it is not reported )

EDIT:

Figure.png shows what to expect from a 10MSa/s, 524288 point FFT with Hamming window and linear interpolation.
It also does not match the shape in your screenshot.

EDIT:

And figure2.png show what to expect with 500000 points.
Since 1kHz is an integral multiple of 20Hz, no side lobes are visible.

[ebastler]

You might be onto something there! Here's the FFT of a 991.82 Hz signal -- looks nice and symmetrical, with a data point right in the center of the peak. (Although the horizontal scale thinks it's peaking at 992.2 Hz, for whatever reason.)

On the other hand, the frequency step does not match that assumption: I chose that odd span setting in the screenshot to show that the FFT data points are pretty exactly 0.775 Hz apart, corresponding to a record length of 1.29 seconds or 1.29 MPts at 1 Pt/µs. What kind of number is that though? Not a power of two... And actually more than the advertised 1 MPts. Mysterious...

EDIT: At least I figured out what went wrong at 50 ms/div and slower in yesterday's experiments. I had the acquisition mode set to "Roll: Auto", with a 50 ms/div threshold. I just never noticed the rolling trace, since it was a steady sine with individual periods not resolved on the screen. Easily avoided, but it would be nice if the FFT were not bothered by that acquisition setting.

[Antonio90]

Good morning,
have you tried activating a video signal? (pal/secam)my DHO1074 can't trigger a video signal

Hello, yes, it is a known bug, and a software problem with the platform in general. You will have the same problem with any DHO1000, even if you get it exchanged by the seller.

 People interested in this oscilloscope model will read most, if not all of the related threads, no need to post in all of them.

[Alex-lab]

Some new weird behaviour.
I was trying to analyse a saturation limit of the inductor. Blue line is the current (1Ohm).
However, when I changed Y-scale, the pulse changed its shape with some negative spike.
Any hypothesis? Thanks.

[Fungus]

It could be you're going way off the bottom of the screen, in which case you're running into opamp overload/recovery.

Does it change if you move the trace up/down?

Zoom in horizontally to take a good look at the negative peak.

There are many threads on this topic, eg.: https://www.eevblog.com/forum/testgear/rigol-ds1054z-vertical-distortion-problem/

[thm_w]

Some new weird behaviour.
I was trying to analyse a saturation limit of the inductor. Blue line is the current (1Ohm).
However, when I changed Y-scale, the pulse changed its shape with some negative spike.
Any hypothesis? Thanks.

Please use the web interface or USB key to take a screenshot, very hard to tell if the signal actually changed or if its just more visible as a result of zooming in.

[dominicc]

So it's April 2024 and I feel like Rigol has left me and everyone else with a new 12-bit scope out in the cold with no new firmware since 2023/10/18 while a myriad of bugs remain present.  Anyone else feel the same?

[dominicc]

Has anyone been able to get the video triggering working on a PAL or NTSC signal?

Did you ever find a resolution to this problem?
Sam

no, and neither rigolshop.eu or rigol have responded to any of my initial emails regarding the subject.

[dominicc]

Has anyone else here got Color Grading to work?  (DHO4000 manual, section 19.7)  I'm trying to measure crystal oscillator stability, and toggling the button does absolutely nothing.

[thm_w]

Has anyone else here got Color Grading to work?  (DHO4000 manual, section 19.7)  I'm trying to measure crystal oscillator stability, and toggling the button does absolutely nothing.

Sure its working on dho1000, though not amazing. Depending on the memory depth the visibility may go to nothing.
Maybe try turning off hires too.