Products > Test Equipment

New Rigol HDO1000 12-bit DSO - BUGs

<< < (22/28) > >>

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/tsweep.
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, fmax = fsampling/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:

--- Quote from: ebastler on January 01, 2024, 04:18:59 pm ---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/tsweep.
* The sampling rate controls the maximum frequency, fmax = fsampling/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.

--- End quote ---

Excellent work and post!

Martin72:

--- Quote ---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.
--- End quote ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod