Rigol DHO800/900 Oscilloscope Bug Reports + Firmware

[Mechatrommer]

After a restart, it would apparently want to load that last used state (maybe waited for a trigger to happen to fill in that buffer?), and that took ages. But eventually it booted.

that means, last setting is stored somewhere not in sd card. but where? we need to find a way to zero those memory..

In the SRAM chip. I assme they don't want to wear the flash out by writing to it after every single twist of a knob.

what are you smoking again my friend? SRAM is volatile... https://en.wikipedia.org/wiki/Static_random-access_memory they can do it in Flash and save setting at every "Power Off" button, not every knob twist. not everybody can do 100K times power on and off, which is the write endurance of Flash.

[shapirus]

save setting at every "Power Off" button, not every knob twist.

It's neither. I have tested the following scenarios:

1) change vertical scale, immediately pull the power cord
2) change vertical scale, immediately press the (soft) power button twice
3) change vertical scale, wait a couple of minutes, press the power button twice

Only in scenario 3 the change was saved. This is an indication that a buffer + interval save algorithm may be used.

[Mechatrommer]

so the programmer is not as clever as i thought.

[ebastler]

It's neither. I have tested the following scenarios:

1) change vertical scale, immediately pull the power cord
2) change vertical scale, immediately press the (soft) power button twice
3) change vertical scale, wait a couple of minutes, press the power button twice

Only in scenario 3 the change was saved. This is an indication that a buffer + interval save algorithm may be used.

So how about scenario 4: change scale, wait a couple of minutes, then pull the power cord?
If it still remembers the settings change, then saving them is purely timeout-based.

[shapirus]

So how about scenario 4: change scale, wait a couple of minutes, then pull the power cord?
If it still remembers the settings change, then saving them is purely timeout-based.

Yes that's exactly what happens. It does not need the power button to be pressed for the settings to get saved, but it appears to need some time to pass after a change is made.

[Fungus]

So how about scenario 4: change scale, wait a couple of minutes, then pull the power cord?
If it still remembers the settings change, then saving them is purely timeout-based.

Yes that's exactly what happens. It does not need the power button to be pressed for the settings to get saved, but it appears to need some time to pass after a change is made.

It's a very short time, certainly much less than "a couple of minutes".

I'd also be very surprised if the settings aren't checksummed against corruption.

[shapirus]

It's a very short time, certainly much less than "a couple of minutes".

I would assume 5-10 seconds, that would be a sensible setting. I couldn't care less to go for determining it experimentally, though, given the painfully long boot time. Could be tested by restarting just the app, though, by killing its process from the shell (and then it'll restart automatically). That's an idea for someone who wants to volunteer to test it.

I'd also be very surprised if the settings aren't checksummed against corruption.

Haha lol.
(no I have no other comment on this one.)

[sequoia_hope]

Hello everyone. I received my DHO804 today. Its a relatively nice scope, but I immediately discovered some issues with SPI decoding. I searched this thread and I see that DHO900 users are having SPI decoding issues with the logic analyzer, but in my case I am having an issue with the analog SPI decoding.

I am reading a 24 bit SPI value, and the waveform is absolutely rock solid. As far as I know, I have all the right settings, and having tried flipping a few SPI settings nothing else was any better.

What I am observing is that, using the SPi trigger mode, the Hex value overlaid on the SPI waveform is inconsistent even with a very solid displayed waveform. I turned on display persistence and I see no jitter at all in the waveform, but the displayed hex value changes at random. The obvious thing to check is that the SPI is triggered on the correct edge, but looking at my data it is clear I have the correct setting for that.

What is worse is that the inconsistent hex reading is highly dependent on the "Mem Depth" setting. With 100khz SPI, I have to set it to 10k Mem Depth to get even close to consistent hex values. If I change it to any other setting, the interpreted hex values are all over the place, changing every sample.

I'm really hoping I just have a setting wrong. This is my first new scope purchase in 13 years and I was so eager to move on from my buggy old scope, I had hoped I wasn't buying a buggy new scope! (I already found a second bug, but one thing at at time.)

Please see attached screenshots. Cheers.

EDIT: I also just noticed that with faster SPI, in this case 1Mhz clock, it seems to be more stable. At 1MHz SPI and 1k or 10k Mem Depth, the hex reading is very stable, but that reading still changes constantly at 100k or 1M Mem Depth. With more experimentation I see that it is able to display multiple samples at once in a Decode Window, and that the timecale combined with the Mem Depth make all the difference. For a fully zoomed in value, where one sample takes up the entire width of the screen, a lower Mem Depth seems better. If you decrease the timescale so that multiple SPI transactions are on screen at once, you need to increase the Mem Depth. This makes some sense, but the scope give any indication as to what might be wrong if you have the setting wrong. And what makes no sense to me is that higher Mem Depth values can result in bad data decoding. Anyway I am glad I found that some fiddling can lead to more consistent behavior, but it seems like a real bug that high Mem Depth values can lead to SPI decoding errors, and that no warnings or messages are displayed to alert the user to a bad setting combo.

[Aleksandr]

And try additionally enabling the input signal bandwidth limitation of 20 MHz for each channel.

[lunix]

Hi Sequioa: I note that you are triggering on SPI data, using different thresholds for CLK, CS, MISO, and the trigger condition you've chosen is "don't care".  Also pay attention to CS polarity and data sample clock edge. I would not be surprised by changing data since you have not set any particular bits as significant for triggering.

[ebastler]

What I am observing is that, using the SPi trigger mode, the Hex value overlaid on the SPI waveform is inconsistent even with a very solid displayed waveform. [...]
The obvious thing to check is that the SPI is triggered on the correct edge, but looking at my data it is clear I have the correct setting for that.

I no longer have my DHO1000, but I seem to recall that there are separate settings for the clock polarity in the Trigger and in the Decoder settings, respectively. You have only shown us your Trigger settings in the screenshot. Might it be the case that in the Decoder settings you have told the scope to sample at the rising clock edge, i.e. just when the data line changes?