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.