Another Rigol 1000z bug?

[kwass]

On my 1054z I found that FFT doesn't work unless channel 1 is turned on.   The FFT function will work with input from any channel but channel 1 needs to be turned on or the o'scope will display a "Data Invalid" message in the FFT area on the display.  Can anyone else verify this.

firmware is: 00.04.01.SP2
hardware: 0.2.1 (but I swear the last time I checked this is showed 0.1.1, does this change each time you run a calibration?)

[kwass]

More on this....

It seems that you can get around this bug by setting the Source A in the basic Math functions (+. -. etc.) to the channel that you want to run the FFT on. This is in addition to selecting the channel for the FFT itself.  Seems to me that this should be an easy firmware fix.

[LaurentR]

On my 1054z I found that FFT doesn't work unless channel 1 is turned on.   The FFT function will work with input from any channel but channel 1 needs to be turned on or the o'scope will display a "Data Invalid" message in the FFT area on the display.  Can anyone else verify this.

firmware is: 00.04.01.SP2
hardware: 0.2.1 (but I swear the last time I checked this is showed 0.1.1, does this change each time you run a calibration?)

I just bumped into that today...

Trying to FFT on Ch1 with only Ch1 active and got the "Data Invalid!" error until I found this post  and turned on Ch2.

Digging a bit further, it looks like it memorizes the last "SourceB" setting that was used by a dual operand operation and if that Channel is turned off, it sends a "Data Invalid!" error. This doesn't seem to be the exact mechanism, but there is definitely a link with SourceB. Going to a A/B operation, setting SourceB to Ch1 and back to FFT solved the issue. But now, if I change SourceB again, Ch1 never fails again. But I can still make Ch2 fail...

Anyway, something to do with the SourceB setting and an easy workaround.

I am running the same "latest" 00.04.01.SP2 firmware.

[Mark_O]

Digging a bit further, it looks like it memorizes the last "SourceB" setting that was used by a dual operand operation and if that Channel is turned off, it sends a "Data Invalid!" error. This doesn't seem to be the exact mechanism, but there is definitely a link with SourceB. Going to a A/B operation, setting SourceB to Ch1 and back to FFT solved the issue. But now, if I change SourceB again, Ch1 never fails again. But I can still make Ch2 fail...

God, I'd hate to have to maintain the spaghetti source code that would allow errors like that to happen. 

There are all kinds of states and information that needs to update and track, as an o'scope goes through numerous state transitions.  If that's not managed properly, it becomes a real nightmare (and virtually untestable, as the transition chain deepens).

[Howardlong]

The 2 channel signal generator in my MSO1074Z-S doesn't appear to be monotonic. If I go from 999,999Hz to 1,000,000Hz, it goes down in frequency by about 10Hz, not up by 1Hz.

Why is this a big deal you may ask?

Well if you are trying to generate two phase-locked signals, say one at 500kHz and one at 1MHz, it doesn't work properly, one channel is not exactly twice that of the other.

Not sure where there are other discrepancies like this, but it's propably worth pointing out.

[Woodside]

Digging a bit further, it looks like it memorizes the last "SourceB" setting that was used by a dual operand operation and if that Channel is turned off, it sends a "Data Invalid!" error. This doesn't seem to be the exact mechanism, but there is definitely a link with SourceB. Going to a A/B operation, setting SourceB to Ch1 and back to FFT solved the issue. But now, if I change SourceB again, Ch1 never fails again. But I can still make Ch2 fail...

Anyway, something to do with the SourceB setting and an easy workaround.

I am running the same "latest" 00.04.01.SP2 firmware.

Unfortunately this is still the same with 00.04.02 SP4 firmware 

[Mechatrommer]

this bug is fixed in 4.3.2.3 SP2 revision