Rigol DHO800/900 Oscilloscope Bug Reports + Firmware

[norbert.kiszka]

linux does cache a lot of disk writes and won't flush them to physical media until unmounted.

Thats not true. Linux uses cache stored in RAM, but its flushed from time to time and when some process makes a call to malloc() function (program says: I need some memory to store some data and give me start address of it).

You can use sync flag - everything will be written directly.

Also, You can open terminal and type sync [enter] to flush all cache of all drives.

Im curious, Why You wrote Windows with big letter and Linux with small one?

[norbert.kiszka]

From Dave's early discoveries. (This should start where he answers the resolution question)
https://youtu.be/r_BYYgCqScE?si=OWU4W64nf2w_kgHw&t=7

He didnt try to change resolution in test mode of this scope. At least we dont know.

[ebastler]

Im curious, Why You wrote Windows with big letter and Linux with small one?

Hmm... Why did you write "Why" and "You" with a capital letter, but "norbert" and "kiszka" with a lowercase one? Must be some global conspiracy. 

[norbert.kiszka]

Hmm... Why did you write "Why" and "You" with a capital letter, but "norbert" and "kiszka" with a lowercase one? Must be some global conspiracy. 

Very often problem with SQL databases and queries to them (bad programmers). Lowercase always works as it should.

[axantas]

I can't seem to use a FAT32 formatted USB stick to transfer waveform pictures from the scope to my Windows 10 PC without getting a Windows message of:
  "There's a problem with this drive.  Scan the drive now and fix it."

I get this message all the time when moving media from a non-Windows system (linux, cameras, whatever) to Windows.  The likely cause of the message is that the USB stick was unplugged without being properly dismounted.  Apparently Linux sets a dirty bit when a FAT USB is mounted and only cleans it up if you do a proper unmount.  I don't know why NTFS seems to be resistant to this problem (I rarely use NTFS formatted USB sticks).  Maybe it's because NTFS is a journalled file system so it can always roll back to a known good state?

There's no reason to scan the drive for this "problem", however there are a couple caveats:

1. linux does cache a lot of disk writes and won't flush them to physical media until unmounted. I believe that for removable media it flushes writes whenever a file is closed.  But you still should take some care with this.

2. Windows will display that message for a variety of problems, not just this particular problem.  So it's not always a meaningless annoyance.

In practice, I can't remember when I've ever actually run into a problem ignoring the message.

From my experience - letting windows to to this scan - it is a meaningless annoaynce.
after dozens of scans, reporting and causing nothing, I started to click away that message. 

[norbert.kiszka]

I started to click away that message.

If You dont unmount or dont using sync option (flag), then You can lose some data. Files can be corrupted. I dont know how to enable sync flag in Windows or if it is possible, because Im using Linux for last ~17 years - much less annoying messages and much less problems.

Going back to topic a little bit, some time ago I was using Very nice Linux software for scopes (in some cases more usable waveform view than original scope). Im planning to test it with DHO924S after I will stop being lazy a little bit.

[shapirus]

Going back to topic a little bit, some time ago I was using Very nice Linux software for scopes (in some cases more usable waveform view than original scope). Im planning to test it with DHO924S after I will stop being lazy a little bit.

Name?

[norbert.kiszka]

Going back to topic a little bit, some time ago I was using Very nice Linux software for scopes (in some cases more usable waveform view than original scope). Im planning to test it with DHO924S after I will stop being lazy a little bit.

Name?

Yo need to know Linux is not Windows and Linux its just a name of system kernel, not of a whole system with software (so called distribution: kernel + basic system + graphic interface + software). Im using Debian for about ~15 years and it uses package system which uses dependency and repositories (in my case, Im using mostly official repositories). You can use Debian software ("Synaptic" with graphic interface or couple others on text terminal) to see categories of software, description, changelogs, screenshots and of course install/uninstall/purge/update them (Google Play on Android is a copy of this idea but without all bells and whistles).

There are plenty of software for electronics engineers in official Debian repositories. Last time when I was using scope software, it was couple years ago in pre-previous Debian version and I dont remember the name. Last time I check, it was somewhere like 2-4 different scope software in that repositories.

[shapirus]

Name?

Yo need to know Linux is not Windows and Linux its just a name of system kernel, not of a whole system with software

Lol I should've been more specific, I guess. I just wanted to know the name of the scope software that you mentioned, the one that you used and liked -- I'd like to try it too.

I've been using Linux[-based OSes] since late 1990s, so... you know :)

[norbert.kiszka]

I've been using Linux[-based OSes] since late 1990s, so... you know

As I said, that was in previous Debian and my current isn't newest (codename Bullseye)... Just after previous post I made apt-get update and screens from a Synaptic. Maybe it is one of those, but Im not sure.

BTW. very long time ago I made a script to make a remote screenshot of scope and download, which was basically a fork of same thing but with bug fixes and little improvements. Right now tested only on Rigol DSO1054Z. Enjoy: https://github.com/norbertkiszka/rigol-screenshot

[norbert.kiszka]

Maybe it is one of those, but Im not sure.

Now I recalled one thing. Some features to work requires to set memory depth to full or lowest - one of those.

[AceyTech]

From Dave's early discoveries. (This should start where he answers the resolution question)
https://youtu.be/r_BYYgCqScE?si=OWU4W64nf2w_kgHw&t=7

He didnt try to change resolution in test mode of this scope. At least we dont know.

Agreed... He wasn't even aware of "test mode" at the time. 
In any event, the resolution issue has been discussed previously in the other(I.e., general or hacking) threads.  I was just trying to show that he plugged it in(even at 4K), and it didn't result in more onscreen data. -which is what we were all hoping for.

[norbert.kiszka]

and it didn't result in more onscreen data. -which is what we were all hoping for.

Maybe previously mentioned software (for Linux) will make it. Last time I was using it some years ago and I was able to see much much more than on screen of Rigol DS1054Z.

[shapirus]

Maybe it is one of those, but Im not sure.

Must have been pulseview, which is based on sigrok. And sigrok does not support the DHO series, as I have just checked (and they aren't listed at https://sigrok.org/wiki/Category:Supported). It basically supports only the DS series scopes. It's a pity. It would be nice to have this possibility.

[norbert.kiszka]

Maybe it is one of those, but Im not sure.

Must have been pulseview, which is based on sigrok. And sigrok does not support the DHO series, as I have just checked (and they aren't listed at https://sigrok.org/wiki/Category:Supported). It basically supports only the DS series scopes. It's a pity. It would be nice to have this possibility.

There was one more soft on my screens.

And lists... can be updated rarely. Especially in niche applications. Maybe it will work, or maybe not.

[Lathe26]

SPI decode still doesn't work on the digital channels under 1.02 firmware, so back in the drawer it goes.

Just tried it out with 1.02.00.02 firmware on a DHO924S and, same as everyone else here, SPI decoding still doesn't work using the digital channels.  Decoding does work for analog channels.

I just wrote up a bug report on this and emailed it to help@rigol.com.

[norbert.kiszka]

Right now tested only on Rigol DSO1054Z. Enjoy: https://github.com/norbertkiszka/rigol-screenshot

Now its rewrited and it works with DHO924S via wifi. Somehow kinda slow.

[norbert.kiszka]

Maybe I did something wrong, but looks like Vpp measurement went wrong. After settings reset to default (and go back to probe x10), Vpp was as expected ~400 mV.

[ebastler]

Maybe I did something wrong, but looks like Vpp measurement went wrong. After settings reset to default (and go back to probe x10), Vpp was as expected ~400 mV.

Did you change the probe attenuation to 1x after you had set up the measurement, maybe? The measurements are a bit stubborn on the DHOs; various settings can't be changed after a measurement has been set up. Still a bug, but a known one.

[norbert.kiszka]

Maybe I did something wrong, but looks like Vpp measurement went wrong. After settings reset to default (and go back to probe x10), Vpp was as expected ~400 mV.

Did you change the probe attenuation to 1x after you had set up the measurement, maybe? The measurements are a bit stubborn on the DHOs; various settings can't be changed after a measurement has been set up. Still a bug, but a known one.

I was all the time on 10x.

[jsobell]

Am I missing something, or is there a reason the trigger doesn't seem to work below 300mV?
Trace the test point, and set rising edge trigger and it doesn't trigger unless it has a Level over 300mV.
Switch to falling trigger and it doesn't trigger unless it's over 300mV below the top of the waveform.
Is there a setting I've missed?

I just toggle Noise Reject on and off and it reduced to 100mV, but this is still very odd.





In fact, if I reduce the vertical to 5V/div it won't trigger below 1.1V...

[shapirus]

Am I missing something, or is there a reason the trigger doesn't seem to work below 300mV?

Yes, it's reproducible. Appears to be a bug or maybe there's a valid reason because of they way it's implemented.

In fact, if I reduce the vertical to 5V/div it won't trigger below 1.1V...

It looks like it's not an absolute value, but some percentage of range and/or displayed values. Try to zoom in instead without changing the source signal: with the 0..3V square wave, if you zoom in to 200 mV/div or below, it will happily trigger when the trigger level is set to the lowest possible -- down to the noise at the lower portion of the cycle.

It doesn't seem to depend on absolute values. It triggers fine with the lowest possible values when vertical scale is set so that the waveform doesn't fit on the screen vertically. Once it fits, then triggering below a certain percentage of amplitude doesn't work.

Sounds well like a bug to me.

Update: it not only has to be zoomed in to not allow the waveform to fit vertically, but it has to be above a certain level outside the screen too. With a 0..3V square wave, zoom in to 200 mV/div, set trigger to 30 mV, it should be triggering fine. Now press the vertical scale encoder (enable fine zoom) and start to zoom out. It will begin to fail triggering at 220 mV/div with the upper portion of the waveform still well outside of the visible display area.

[Randy222]

Am I missing something, or is there a reason the trigger doesn't seem to work below 300mV?

Yes, it's reproducible. Appears to be a bug or maybe there's a valid reason because of they way it's implemented.

In fact, if I reduce the vertical to 5V/div it won't trigger below 1.1V...

It looks like it's not an absolute value, but some percentage of range and/or displayed values. Try to zoom in instead without changing the source signal: with the 0..3V square wave, if you zoom in to 200 mV/div or below, it will happily trigger when the trigger level is set to the lowest possible -- down to the noise at the lower portion of the cycle.

It doesn't seem to depend on absolute values. It triggers fine with the lowest possible values when vertical scale is set so that the waveform doesn't fit on the screen vertically. Once it fits, then triggering below a certain percentage of amplitude doesn't work.

Sounds well like a bug to me.

Update: it not only has to be zoomed in to not allow the waveform to fit vertically, but it has to be above a certain level outside the screen too. With a 0..3V square wave, zoom in to 200 mV/div, set trigger to 30 mV, it should be triggering fine. Now press the vertical scale encoder (enable fine zoom) and start to zoom out. It will begin to fail triggering at 220 mV/div with the upper portion of the waveform still well outside of the visible display area.

So what happens when you want to scope a 5kHz square wave signal that is 0.150 volt-peak? Scope can't trigger it?

[shapirus]

So what happens when you want to scope a 5kHz square wave signal that is 0.150 volt-peak? Scope can't trigger it?

Of course it can, but not below ~10 mV with the vertical scale set for 50 mV/div. If you zoom it, then it can trigger at a lower trigger level, but it's harder to notice, because of noise, than with a higher amplitude signal.

[Randy222]

So what happens when you want to scope a 5kHz square wave signal that is 0.150 volt-peak? Scope can't trigger it?

Of course it can, but not below ~10 mV with the vertical scale set for 50 mV/div. If you zoom it, then it can trigger at a lower trigger level, but it's harder to notice, because of noise, than with a higher amplitude signal.
[/quotehh, I see.

I don't fully understand how the view changes how the functionality works. If I set a trigger level, v scale, and x scale to get a good signal sync on screen, if I change the x and y scale the trigger level (where it was value set) should remain constant, even if that means the trigger marker went off the screen because y scale on screen changed. This same issue is also seen if you use the Results items (Vpp, Vp, etc). If the input signal remains constant, then none of the Results should change just because I change the view on the screen. Probably a topic for debate for another forum.