EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: EEVblog on October 02, 2023, 04:07:45 am
-
As requested, this a thread for posting of and discussion of bugs on the Rigol DHO800/900 Oscilloscope, and firmware updates.
No other discussion please, there are other threads for that:
General discussion: https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/ (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/)
https://www.youtube.com/watch?v=I3FhAhxet7s (https://www.youtube.com/watch?v=I3FhAhxet7s)
-
Thank you Dave. :-+
Here the mentioned posts:
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5087923/#msg5087923 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5087923/#msg5087923)
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5088133/#msg5088133 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5088133/#msg5088133)
It's hard to move and analyze signal.
Or is my scope broken?
Would be good if someone else can test it, with any luck my DHO will arrive this week.
-
This bug is reproducible, and I'm preparing the new video.
1 Set timebase 500ms/div
2 Move the trigger to the start of capture < 10%
3 Do a single capture of some signal
4 Explore the signal, move around, decrease timebase to the limit
5 Return to 1s/div timebase, turn On the Vernier, fine tune timebase, and waveform should dissapear.
(I'm not sure what steps are necessary and what could be omitted).
Old bug report: https://www.youtube.com/watch?v=k3uaGCYCSng (https://www.youtube.com/watch?v=k3uaGCYCSng)
-
Here is the new catch of the waveform disappear bug :)
https://www.youtube.com/watch?v=VD24JlrPjuk (https://www.youtube.com/watch?v=VD24JlrPjuk)
-
The easy way to reproduce the bug. Rigol DHO804 DHO800 oscilloscope waveform disappear in stop mode:
Press Default, set roll mode OFF, change trigger level to some reasonable level, 500 ms/div, 200 mV/div, do SINGLE waveform capture.
When capture is done, change horizontal to 1 s/div, enable Vernier (press horizontal nob), change horizontal to 1.2, 1.3 s/div.
https://www.youtube.com/watch?v=rmhTmmWaM50 (https://www.youtube.com/watch?v=rmhTmmWaM50)
-
Waveform distortion in stop mode bug. Rigol DHO804 DHO800 oscilloscope
Capture any fast signal with a large memory, stop acquisition, increase the timebase until the artifacts are displayed.
https://youtu.be/WK8EEvo7V-Y (https://youtu.be/WK8EEvo7V-Y)
-
The scope has no way to set RTC (and no RTC battery). So the time mark should not be on the screenshots.
-
The scope has no way to set RTC (and no RTC battery). So the time mark should not be on the screenshots.
Dave has reported that if it is connected to a network it will set the time. I assume it has an NTP client.
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5074246/#msg5074246 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5074246/#msg5074246)
The timezone appears to be hardcoded to Asia/Shanghai. The bug would be that there doesn't appear to be any interface to change the timezone.
[persist.sys.timezone]: [Asia/Shanghai]
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5046544/#msg5046544 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5046544/#msg5046544)
-
yes, but surely it's also valid for the user to want to be able to switch off the date/time code entirely? (since once printed onto as a bitmap image it cannot be removed). for example what if the image file itself still gets written to the disk with correct timestamp - then it is not always strictly needed to be printed directly onto the image?
-
yes, but surely it's also valid for the user to want to be able to switch off the date/time code entirely? (since once printed onto as a bitmap image it cannot be removed). for example what if the image file itself still gets written to the disk with correct timestamp - then it is not always strictly needed to be printed directly onto the image?
Bugs / Feature Requests:
- Provide an interface to set the local timezone in non-volatile storage.
- Never watermark screen captures with the date/time if the date/time has not been set via the network and is not valid.
Provide an interface to turn off the date/time watermark even if the date/time has been set via the network and is valid. Edit: Option to turn off the date/time watermark already exists.
-
- Provide an interface to turn off the date/time watermark even if the date/time has been set via the network and is valid.
There is an option for that.
Here is a screenshot that does not contain the date and time. But I agree it should be off by default.
(https://electrodacus.com/RIGOL/RigolDS18.png)
I can confirm the bug when acquisition is stooped and vertical zoom with vernier is done but I was not able to reproduce the 188.1khz bug so not sure what happens there as that looks fairly strange almost like some hardware defect where memory is corrupted.[/list]
-
Here is a screenshot
(https://electrodacus.com/RIGOL/RigolDS18.png)
Cute colors. :-+
And the multi-windowed display looks really useful, I can't wait to try that feature. :popcorn:
(where's my 'scope at...? :-\ )
-
- Provide an interface to turn off the date/time watermark even if the date/time has been set via the network and is valid.
There is an option for that.
Maybe this would have been easy to discover if I had one of these to poke around with. I should have RTFM the manual myself anyway.
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1890076)
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1890070)
-
Bugs / Feature Requests:
- Provide an interface to set the local timezone in non-volatile storage.
- Never watermark screen captures with the date/time if the date/time has not been set via the network and is not valid.
- Provide an interface to turn off the date/time watermark even if the date/time has been set via the network and is valid.
Can the date/time be set manually? No mention in the DHO900 manual, but the DHO1000 manual does have it. And my understanding is that the DHO900 firmware is very similar to the DHO1000 - why would they remove UI to set the date/time? From the DHO1000 manual:
Display Date and Time
Click or tap the Show Time on/off switch to turn on/off showing the date and time on the screen. The date is displayed in "yyyy/mm/dd" format, and the time is displayed in "hh:mm:ss" format in the Notification Area at the lower-right corner of the screen. You can set the system date and time so that saved images are marked with the data and time information.
• Date: Click or tap the "Date" input field, then the date setting menu is displayed. The three dials in the menu represent year, month, and day. Set a proper date, then click or tap OK to confirm the date modification. Otherwise, click or tap or any area outside this menu to cancel date modification and exit the menu.
• Time: Click or tap the "Time" input field, then the time setting menu is displayed. The two dials in the menu represent hour and minute. Select the proper hour and minute to set the time. After setup, click or tap OK to confirm the setting.
-
Can the date/time be set manually? No mention in the DHO900 manual, but the DHO1000 manual does have it. And my understanding is that the DHO900 firmware is very similar to the DHO1000 - why would they remove UI to set the date/time? From the DHO1000 manual:
The DHO1000 has a CR1220 battery next to the Rockchip RK808-D, which has a battery backed RTC.
https://www.flickr.com/photos/eevblog/52452909615/in/album-72177720303155042/ (https://www.flickr.com/photos/eevblog/52452909615/in/album-72177720303155042/)
The DHO800/DHO900 do not have a battery to maintain an RTC when powered off. Would you really want to go through the UI to manually set the time every time you power on a DHO800/DHO900? I suppose it wouldn't hurt to leave that UI in, but doubt most people would ever bother using it.
-
The DHO800/DHO900 do not have a battery to maintain an RTC when powered off. Would you really want to go through the UI to manually set the time every time you power on a DHO800/DHO900? I suppose it wouldn't hurt to leave that UI in, but doubt most people would ever bother using it.
If you have ethernet connected then it sets the date and time automatically (Chinese time zone).
But yes, the big time stamp on the screen shot is annoying.
-
Hello,
Today I got DHO924 and tried to decode RS232 output from several esp32 boards. From the one board decoder works fine but from another board do not decode at all. After sometime I found that on the second board signal voltages are 3.3-0.4V but on the first one are 3.3v-0.01V. Then I put -0.4V bias on the probe and it start decode RS232 on the second board. But decoder threshold set to 2.2V and I believe that decoder should work without bias because voltage cross the threshold.
-
What if you enable "Copy Trig" option -- this should set the decoder threshold to the trigger setting.
-
What if you enable "Copy Trig" option -- this should set the decoder threshold to the trigger setting.
Tom,
He set threshold to 2.2 V but if signal goes negative it stopped decoding..
-
What if you enable "Copy Trig" option -- this should set the decoder threshold to the trigger setting.
Tom,
He set threshold to 2.2 V but if signal goes negative it stopped decoding..
I understood his reports differently: if the Low signal didn't get close enough to zero, it stopped decoding. My suggestion was just meant to figure out if the manual decoding threshold entry might possibly not work properly (not transfered to an internal variable), and the "copy trig" may have a different effect. It appears to be a bug, anyway.
-
Does the threshold work in general?
eg. Does it stop decoding you move it above the top of the signal or make it negative on the working signal.
Edit: Can you drag the threshold voltage up and down with your finger on these? Micsigs can... :)
-
My suggestion was just meant to figure out if the manual decoding threshold entry might possibly not work properly (not transfered to an internal variable)
Threshold might only be used to decide "high".
"low" might be defined by a fixed value which is close to zero. Yeah, I know it ought to be "not high" but you always have to leave a dead space between the two so it might not be. That's why we make Schmitt triggers in hardware.
Maybe somebody could look at the source code of the RS232 decoder in the APK and see.
(Yes, I know it's not the real source code but it's very close...)
-
My suggestion was just meant to figure out if the manual decoding threshold entry might possibly not work properly (not transfered to an internal variable)
Threshold might only be used to decide "high".
"low" might be defined by a fixed value which is close to zero. Yeah, I know it ought to be "not high" but you always have to leave a dead space between the two so it might not be. That's why we make Schmitt triggers in hardware.
Maybe somebody could look at the source code of the RS232 decoder in the APK and see.
(Yes, I know it's not the real source code but it's very close...)
Threshold is threshold.. Above is logical 1, below is logical 0. Everything else is bug. On all decoders there is slight hysteresis in algorithm and that is all. On good decoders you can set hysteresis but usually that is not needed, you would need that only with very noisy signal.
-
so if that is it, then any such threshold is not in hardware but instead rather like an adjustable software debounce? is that really correct behaviour? because i suppose it can be ok when the input is from an analog channels here. that can be done in scope software without such debounce. yet if the input channels are digital inputs from the la. then this is not the case.
-
Disagree with single point threshold. I2C for example has a large noise margin by design. And the same goes for any digital signal; the receiver always has an amount of hysteresis by design. A long time ago I had to debug an I2C bus running at 1kHz with pretty soft edges. The Agilent 7104A couldn't properly decode because the hysteresis was too small. Ideally decoding should use a reasonable amount of hysteresis to make it work most reliable.
-
because when you do buy some lets say 'more sophisticated' dedicaded external standalone l.a., then they can do at least some types of voltage range adjustment. if not threshold always, but maybe some fewer ones. or that the threshold hysteresis becomes linked relative to the total voltage swing. or different threshold setting for the 1.8, 3v3 and so on. in fact this matter reminds me of some higher quality programmers. that is also multi voltage for different types of chips
-
Decoding a digital signal with a fixed timing shouldn't require a hysteresis as long as the two signal levels are far enough apart from the threshold. Any noise and erroneous signal changes should be (temporally) far away from the interval when the level is to be checked for evaluation / decoding. Of course, the fact that a good decoding algorithm still incorporates some hysteresis, stays undisputed.
-
so if that is it, then any such threshold is not in hardware but instead rather like an adjustable software debounce? is that really correct behaviour? because i suppose it can be ok when the input is from an analog channels here. that can be done in scope software without such debounce. yet if the input channels are digital inputs from the la. then this is not the case.
It is not even debouncing per se .. Decode is software that runs on sampled analog data buffer. Or on digital data buffer. Difference being that on analog data signal is digitized based on threshold as a first pass, than fed into state machine to decode protocol. On digital data buffer, that one gets directly fed to decode step.
because when you do buy some lets say 'more sophisticated' dedicaded external standalone l.a., then they can do at least some types of voltage range adjustment. if not threshold always, but maybe some fewer ones. or that the threshold hysteresis becomes linked relative to the total voltage swing. or different threshold setting for the 1.8, 3v3 and so on. in fact this matter reminds me of some higher quality programmers. that is also multi voltage for different types of chips
There is certain hysteresis just fixed one. Few percent at most. That works quite well if captured data has well defined edges. Noise on top won't matter much. Mostly, on scopes I have here (Keysight, Micsig, Siglent) if you have so much noise on data that scopes have problem decoding, you also have problem with hardware having false edge transitions... Pretty much situation where you try to fix hardware to have cleaner signal...
On Rigol DHO nobody knows how well it works. There are just few out in the wild and those are not tested systematically (yet)...
Picoscope has adjustable threshold level and hysteresis on all protocols..
-
eg. Does it stop decoding you move it above the top of the signal or make it negative on the working signal.
Edit: Can you drag the threshold voltage up and down with your finger on these? Micsigs can... :)
I ran several test with the threshold voltage and found that it is the threshold voltage scale issue. If I set the probe to X1 scale then everything works fine but with the X10 probe scale does not work because the actual threshold voltage 10 times less than I set. But if I increase the threshold voltage 10 times (10V instead of 1V) then decoding starts again.
-
That sounds familiar to me.. ;)
-
The easy way to reproduce the bug. Rigol DHO804 DHO800 oscilloscope waveform disappear in stop mode:
Press Default, set roll mode OFF, change trigger level to some reasonable level, 500 ms/div, 200 mV/div, do SINGLE waveform capture.
When capture is done, change horizontal to 1 s/div, enable Vernier (press horizontal nob), change horizontal to 1.2, 1.3 s/div.
https://www.youtube.com/watch?v=rmhTmmWaM50 (https://www.youtube.com/watch?v=rmhTmmWaM50)
Confirmed:
https://www.youtube.com/watch?v=EVRdTY4LNhg (https://www.youtube.com/watch?v=EVRdTY4LNhg)
-
Rigol DHO800 vertical zoom bias limit while stopped. Bug, issue.
It's impossible to look at 12bit details on signals captured outside bias range of lower scales. Even in zoom mode.
https://youtu.be/ANvczYUG8iU (https://youtu.be/ANvczYUG8iU)
-
In second video, with 25Mpts it seems unresponsive and slow. That needs to be tested to see if there is some problem there.
That looks much worse than DS1000Z. DS1000Z was not fast with vertical adjustments but handled 24 Mpts buffer just fine.
How is it behaving with long memory in general?
-
Rigol DHO800 "vertical truncation is not updated while moving vertically" bug issue
Stop the acquisition, move waveform outside the screen, change horizontal position, or horizontal scale, or vertical scale. Move waveform back and it is truncated until you change horizontal position, or horizontal scale, or vertical scale again.
Firmware version 1.00
https://youtu.be/ZpYqQNpFG1g (https://youtu.be/ZpYqQNpFG1g)
-
Boah, this is weird..
-
Boah, this is weird..
It's not weird at all. The waveform normally stops updating when you're moving it vertically so they must just be moving a bitmap around during vertical moves, they're not regenerating it.
If that bitmap is generated when the waveform is offscreen then there's nothing to see when you move it into view.
Move waveform back and it is truncated until you change horizontal position, or horizontal scale, or vertical scale again.
ie. Until you cause a refresh/re-decimation of the signal on screen.
It's really just an annoyance. Nothing is lost and you can easily make the missing part reappear when you know how.
(touch the screen and wiggle it a bit or jiggle your mouse wheel)
-
No way to change any specific XY mode options: all are inactive (the user manual confirms this).
Rigol DHO800 "Bad apple" oscilloscope music file
Frame rate is not sufficient, the picture is not clear, some objects are blurred. Firmware 1.00.
Please, leave a comment if you know how to improve the picture.
https://youtu.be/R88DA15Iv8A (https://youtu.be/R88DA15Iv8A)
-
About the AWG function of the DHO924S
Generator connected directly to inputs 1 and 2
• Set the frequency range to a range of 100 Hz and 200kHz and the resolution is 10 points per decade. If I'm lucky the plot will start. As a result of the coupling I will see a flat response as well as the phase remaining at zero degrees.
• Then I set the response to 10 Hz and 200kHz and all settings remain unchanged. The result of this change is that the plot will not be started.
• I can repeat this test many times and sometimes both settings may or may not work. I am surprised that in this specific case no external device is connected, so I expect that this should always work.
What else strikes me:
• I have tried to adjust the input sensitivity manually but this has no effect. So it seems that there is a kind of auto ranging.
• In the case of auto ranging, I see in the upper part of the plot that the amplitude of both input channels is sometimes empty or that the signals are much too large and therefore it seems as if the auto ranging is not functioning properly.
• If I am lucky enough to have a plot appear it is not possible to adjust the vertical scale (it is always at -60dB to +60 dB). The same applies to the phase, which cannot be adjusted in the case of a small deviation.
• Based on the fixed vertical scales, it is desirable that both phase and amplitude can be adjusted, possibly supplemented with “auto ranging”.
In summary, I now have a device that I purchased explicitly for the bode plot function and which does not appear to work, both directly connected to the inputs of the oscilloscope, but the problems seem to be even worse when measuring an external device such as a simple analogue class. A amplifier for audio with only 10 dB gain.
As long as I take measurements starting at 1 kHz and set the Y axis of both input channels in his most insensitive setting beforehand then the device is able to set the gain correctly afterwards.
-
If that bitmap is generated when the waveform is offscreen then there's nothing to see when you move it into view.
It's really just an annoyance. Nothing is lost and you can easily make the missing part reappear when you know how.
It's a bug in a classical meaning of the term. You are moving the waveform, not the bitmap. The bitmap should be updated automatically.
-
It's not weird at all.
Siglent SDS1104X-E:
https://www.youtube.com/watch?v=J6oo5sGz7u4 (https://www.youtube.com/watch?v=J6oo5sGz7u4)
No problem, regardless of the memdepth, acq. mode, etc..
-
I started a thread about the Bode Plot function on the DHO914S:
https://www.eevblog.com/forum/testgear/rigol-dho914s-bode-plot/ (https://www.eevblog.com/forum/testgear/rigol-dho914s-bode-plot/)
-
today i tried saving wave data in bin, csv and wfm format, both from screen and memory into usb drive (D:). tried 1 and 2 channel active.. after saving wfm, 1Mpts memory.. dso channel traces halted or disappear, i need to restart the dso to get back the signal. can anyone reproduce?
-
Edit: Bug removed in Firmware 00.01.01.00.02
DHO914S, F/W 00.01.00
The scope app reliably crashes when enabling the AWG, changing the frequency to >3 kHz via the touch screen / decimal pad and then trying to change the AWG frequency via encoder 1. Restart is most of the times possible within a few seconds, but sometimes it takes longer than a cold start... This scope's Firmware is Alpha stadium :palm:
Edit: I checked the problem a little more in-detail: It seems, regardless of how it is approached, of the waveform and other settings, everytime when the AWG frequency threshold 2.147kHz -> 2.148kHz is crossed using encoder 1, the scope app crashes. In the aftermath, one may be greeted with "Open App Again" which is rather fast or "Close App" which takes much longer (may vary), almost like a cold start.
Reducing the frequency via encoder 1 from 2.148kHz works, but from above that frequency, the app also crashes. Strange thing...
-
@Mechatrommer:
No problems here, csv and wfm, from memory...
-
Rigol DHO800 "vertical truncation is not updated while moving vertically" bug issue
Stop the acquisition, move waveform outside the screen, change horizontal position, or horizontal scale, or vertical scale. Move waveform back and it is truncated until you change horizontal position, or horizontal scale, or vertical scale again.
Can confirm this (tried vertical), more:
I had the first crash of the day with it.... :P 8)
-
@Mechatrommer:
No problems here, csv and wfm, from memory...
@Mechatrommer:
Did you try a different USB stick? Maybe the DHO took offense with its format, size, volume name, some other file name present in the directory, or the like?
-
,,This scope's Firmware is Alpha stadium :palm:
That is the Agile Development Live..
The only annoyance in this case - the Sprint will be 1 year long >:D
-
@Mechatrommer:
No problems here, csv and wfm, from memory...
@Mechatrommer:
Did you try a different USB stick? Maybe the DHO took offense with its format, size, volume name, some other file name present in the directory, or the like?
thanks for clarification. i formatted the stick FAT32.. i'll try again with different stick next time. earlier the wfm files did (looks like) save correctly to the stick, but the signal halted after that and UI became slowish. i'll try again.
-
Rigol DHO800 "vertical truncation is not updated while moving vertically" bug issue
Stop the acquisition, move waveform outside the screen, change horizontal position, or horizontal scale, or vertical scale. Move waveform back and it is truncated until you change horizontal position, or horizontal scale, or vertical scale again.
Can confirm this (tried vertical), more:
I had the first crash of the day with it.... :P 8)
Is that the same one I showed in my review video?
-
I'll have to look at it again in a few days.
But it was something like this:
Stopped, turned the vertical down until the signal was no longer visible.
Then changed the vertical setting once, then turned the line up again.
And it was then actually only a line, no signal more, "Run/Stop" again pressed, signal was visible, but it was then no matter whether you had changed vertically or horizontally.
The signal remained the same until I switched off the scope and switched it on again.
-
The built-in arbitrary waveform generator doesn't seem to contain any built-in (or pre-recorded) "standard" arbitrary waveforms. Moreover, I cannot find any method to convert a stored waveform file from the oscilloscope section (.CSV or .bin) into a waveform that would be compatible with the built-in AWG (.ARB). So apparently there's no simple way to play back a waveform that had been previously recorded with the scope. That's even possible by directly connecting one of Rigol's "Legacy" Scopes to any of their AWGs via a direct USB link!
I more and more get the impression that those folks who buy this product in two year's time will be quite happy campers... :box:
-
Rigol DHO800 Aliasing effect
It's not a bug, but could be fixed. Press "Default", use 12.5 MHz (or 25, 20, 10, 5 MHz), 1k memory depth, increase the timebase until aliasing appears. Firmware version 1.00.
https://youtu.be/D_kHEUk-zKo (https://youtu.be/D_kHEUk-zKo)
-
Please stop double posting. Thank you!
-
I ran several test with the threshold voltage and found that it is the threshold voltage scale issue. If I set the probe to X1 scale then everything works fine but with the X10 probe scale does not work because the actual threshold voltage 10 times less than I set. But if I increase the threshold voltage 10 times (10V instead of 1V) then decoding starts again.
Yep. I received my 'scope today and serial decoding only works when the probes are set to 1x.
Edit: This is NOT fixed in the 1.01 firmware.
-
Two bugs I found in the web interface:
1) When you open the web control it gives you a 1280x800 display as if it's for the DHO1000/DHO4000. The means image is stretched and blurred.
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1898856;image)
2) The window is the wrong size for the image - it's off by a pixel and that makes the scroll bars appear. Really annoying.
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1898862;image)
Also a peeve: When you take a snapshot could it be in lossless PNG format instead of JPG to preserve detail?
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1898868;image)
-
Can this be a "suggestions for Rigol" thread as well?
(https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/?action=dlattach;attach=1898577;image)
-
Rigol DHO800 waveform update freezing bug
This bug occurs at a horizontal scale of 200 ms per division and above, when you set the trigger position to the time before the capture starts.
Setting the trigger some time before the capture is used widely to debug large signal sequences. By moving the trigger position, you can study the whole signal in small portions.
Firmware version 1.00
https://youtu.be/FyM5jibkgfE (https://youtu.be/FyM5jibkgfE)
-
Can this be a "suggestions for Rigol" thread as well?
(https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/?action=dlattach;attach=1898577;image)
I'm sure that many operators would have a problem with the two-color button display due to vision issues: the check mark is more obvious.
-
As an app dev in the past, I think a toggle switch more preferable at nowadays UIs, and the checkbox is already a relic.
But anyway I totally agree those OFF/ON looks so-so.
(https://cms-assets.tutsplus.com/uploads/users/30/posts/35011/preview_image/checkbox.png)
-
(https://cms-assets.tutsplus.com/uploads/users/30/posts/35011/preview_image/checkbox.png)
BTW, this style of slider looks like "slide left to enable" (the upper one) and "slide right to disable" (the lower one). This could be confusing.
-
BTW, this style of slider looks like "slide left to enable" (the upper one) and "slide right to disable" (the lower one). This could be confusing.
FIXED
-
I suggest we take this discussion over here:
https://www.eevblog.com/forum/testgear/dho800dho900-suggestions-thread/msg5111694/#msg5111694 (https://www.eevblog.com/forum/testgear/dho800dho900-suggestions-thread/msg5111694/#msg5111694)
It was a bad idea to start it in the "needs fixing!" thread.
-
I'd put "ON" to the left but that's just me.
As well as many others. But oh why didn’t I thank Serg65536's post?
What about this? A fine example of "when you only have a hammer"?
Nothing complicated, just need to refine the labels
Ans in that SelfCal section, the toggles also could be used without any problems.
-
I'd put "ON" to the left but that's just me.
As well as many others. But oh why didn’t I thank Serg65536's post?
Answered in the other thread...
-
Don't know if anyone observed this yet: F/W 00.01.01.00.02 -- Channel 3 not working in horizontal roll mode!
Edit: Strange, now that I cold started the scope (and I mean really cold, after ~20hrs of pause), CH3 roll mode works again. I'll let the scope warm up and re-check, since it was pretty "steaming" hot when I observed the problem. This smell from the thing is abominating...
-
There's an option in Setup to make the horizontal timebase knob do a "zoom". This option isn't remembered when you power-off the 'scope.
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1902108;image)
PS: I think "Zoom" should be the default for this knob. It's what people expect and "fine" is much less useful.
People are probably going to use pinch-zoom for "fine" adjustments anyway.
-
[attachimg=1]
1) After taping "save" at the "storage" window with *.wfm format (it's available if "memory" is selected), the file is not saved, and the scope won't run again.
2) The "overlay" option should be named "overwrite", as the industry standard suggests.
-
[attachimg=1]
The operator "AX+B" should be named "kA+c", because in other operators A and B are input channels, but here A and B are constants, and X is the channel.
-
DHO924S arrived yesterday.
I can't get SPI decode to work at all on digital channels. Upgraded firmware to to 00.01.01, same thing (but at least the location of the analogue probe X10 setting is far more obvious).
The decoder seems to be fixed to the analogue channels whether you try changing them to the digital channels or not.
-
(Attachment Link)
The operator "AX+B" should be named "kA+c", because in other operators A and B are input channels, but here A and B are constants, and X is the channel.
Ax+B is industry standard name for that function. With uppercase A and B and lower case x
-
Ax+B is industry standard name for that function. With uppercase A and B and lower case x
Please, check other operators on the DHO800 (A+B, A-B, A||B, etc.): all other operators show A and B as actual captured waveforms, but in the operator "AX+B" letters A and B represent the numeric constants.
So, to prevent confusion, either the mentioned operator should be renamed, or all the other.
PS: I would prefer mathematical conventions: "x y" - for the waveforms, and "a b c" - for the constants.
-
Two more nice features ( |O) I've found on youtube
https://www.youtube.com/watch?v=3TAeSheBUl4 (https://www.youtube.com/watch?v=3TAeSheBUl4)
https://www.youtube.com/watch?v=2cCnPJAncJQ (https://www.youtube.com/watch?v=2cCnPJAncJQ)
-
https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5112108/#msg5112108 (https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5112108/#msg5112108)
;)
-
https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5112108/#msg5112108 (https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5112108/#msg5112108)
;)
Now is on the proper topic "Bug Reports" collection :-DD
-
https://www.youtube.com/watch?v=2cCnPJAncJQ (https://www.youtube.com/watch?v=2cCnPJAncJQ)
That's normal behavior for all oscilloscopes. It's due to the input amp overload. You need to remove input circuitry overload, to see the undistorted signal.
-
https://www.youtube.com/watch?v=2cCnPJAncJQ (https://www.youtube.com/watch?v=2cCnPJAncJQ)
That's normal behavior for all oscilloscopes. It's due to the input amp overload. You need to remove input circuitry overload, to see the undistorted signal.
They should create a message limit to avoid this situation, in my old GW-instek this situation simply blanks the screen, on the cheap zeeweii dso2512g it shows a limit message and you can't change the vertical anymore. This kind of small details make the experience of using the scope much better.
-
Ax+B is industry standard name for that function. With uppercase A and B and lower case x
Please, check other operators on the DHO800 (A+B, A-B, A||B, etc.): all other operators show A and B as actual captured waveforms, but in the operator "AX+B" letters A and B represent the numeric constants.
So, to prevent confusion, either the mentioned operator should be renamed, or all the other.
PS: I would prefer mathematical conventions: "x y" - for the waveforms, and "a b c" - for the constants.
I understood you the first time. I understand your logic and it is not wrong, if observed in isolation...
My point is, that in order to avoid confusion, name should be kept same as on other 100 scopes from different manufacturers.
Those are names of functions and A and B are operands, whatever they might be.. That is why it is named as it is now...
And I agree mathematical way would be prefered. In which case all the functions should be properly named etc..
But sometimes there is established practice and if others have been naming something for 20 years in certain (suboptimal) way it sometimes becomes de facto standard..
-
I just found another bug: Only channel 1 can be set to the full 1.25Ghz sample rate. The other three channels only go to 625MHz sample rate even when they're the only channel enabled.
That's three bugs on my list:
1) The serial decoder threshold voltage doesn't factor in the probe attenuation, it's only correct when probe is set to 1x mode.
2) The setting for fine/zoom (the action when you push the horizontal timebase knob) isn't remembered when you power off.
3) Channels 2,3,4 can't be set to 1.25Ghz sample rate.
-
3) Channels 2,3,4 can't be set to 1.25Ghz sample rate.
Did you change the trigger to the active channel as well?
Aha! Good question. It can still trigger off invisible channels...
Yep, that was it! :palm:
That's only two bugs on my list then:
1) The serial decoder threshold voltage doesn't factor in the probe attenuation, it's only correct when probe is set to 1x mode.
2) The setting for fine/zoom (the action when you push the horizontal timebase knob) isn't remembered when you power off.
-
Moreover, you need to deselect all measurements, especially the "hardware" frequecy counter that may (still) be assigned to another channel. It appears that in the DHO800/900 everything is being done on the "digital side" of the signal, i.e. after the ADC. So if anything's still assigned to another channel than the displayed one and is active, it will cause the ADC to work with its sampling rate split over the affected channels.
-
Moreover, you need to deselect all measurements, especially the "hardware" frequecy counter that may (still) be assigned to another channel.
I just tried it and ordinary measurements show asterisks on hidden channels and don't affect the bandwidth:
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1908843;image)
Frequency counter shows asterisks but still reduces the bandwidth.
-
Data point: on some scopes (Keysight Megazoom) they have analog comparators in parallel with ADC. That same comparator is used for hardware decoding. In which case they can have counter running from that, and not drop sampling rate.
Most modern scopes with full digital trigger work from ADC data and use similar processing block (or reuse one) to edge digital trigger.
So they will use channel like if it is enabled, just for trigger and counter.
That is just how it is.
-
Frequency counter shows asterisks but still reduces the bandwidth.
No, it doesn't reduce the sample rate (according to your picture also).
DVM and counter (from the main menu) and trigger activates the channel in the background. Measurements from the "measure" menu use screen data, but do not occupy the channel.
-
Frequency counter shows asterisks but still reduces the bandwidth.
No, it doesn't reduce the sample rate (according to your picture also).
Oooops, I meant "sample rate", not bandwidth! :palm:
625MSa/s is the max I can get on C2 when the counter is enabled on C1:
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1909110;image)
-
625MSa/s is the max I can get on C2 when the counter is enabled on C1:
just use frequency measurement if you dont want 625MSa/s limit on 1 channel.
-
just use frequency measurement if you dont want 625MSa/s limit on 1 channel.
But how would a frequency measurement done on no data (from a non-enabled channel) do you any good?
If you want to view and measure the same, single channel, I would expect that you can use the dedicated counter without sampling rate penalty. If you want to view one channel and measure the frequency in another, I don't see a way around cutting the sampling rate in half.
-
To summarise: 8)
The DVM and the counter (from the main menu) or the trigger can activate the channel in the background (if it's disabled).
Measurements from the "measure" menu use screen data, but do not occupy the channel.
-
To summarise: 8)
The DVM and the counter (from the main menu) or the trigger can activate the channel in the background (if it's disabled).
Measurements from the "measure" menu use screen data, but do not occupy the channel.
To repeat: 8)
How would measurements from screen data work on a non-enabled channel?
-
How would measurements from screen data work on a non-enabled channel?
I don't argue with you, as far as I can see, you don't contradict my statements. 8) :popcorn:
-
Thanks. Seeing your repetition of your earlier statement, I thought indeed you were assuming a contradiction.
I am not contradicting you either, but don't see how your second statement would be of practical use. Yes, calculating measurements from screen data does not occupy the channel. But acquiring the screen data does. So in which scenario do you get an extra measurement without dedicating sampling rate to the respective channel?
-
I’ve seems to have found some bugs with the LA (with the probes) on the 924S (V01.01) |O .
- It is impossible to move logic tracks, once enabled you get the screen full of tracks, later you can disable some, but the space between them will stay constant, you can increase or decrease size but if like me tend to use 2/3 tracks you are still stuck at the bottom of the screen, TLDR you can’t move (apart from switching them) LA tracks on the screen
- Labels do not update / get stuck on screen if you edit the size of the LA tracks. Example, enable LA choose the first 8 channels, increase to size big, edit label, the edit will not update the screen, even disabling the labels still will not update the screen. Restarting the LA by disabling it and enabling it again fixes the issue. TLDR Can’t edit LA track size if you want labels they won’t follow you.
If needed i can try to get you a video
-
I’ve seems to have found some bugs with the LA (with the probes) on the 924S (V01.01) |O .
- It is impossible to move logic tracks, once enabled you get the screen full of tracks, later you can disable some, but the space between them will stay constant, you can increase or decrease size but if like me tend to use 2/3 tracks you are still stuck at the bottom of the screen, TLDR you can’t move (apart from switching them) LA tracks on the screen
Yes, I concur. As it stands, the LA is far from finished. Won't decode SPI either.
-
Small bug: auto screenshots during the pass|fail test should not contain the file path popup.
[attachimg=1]
-
FFT RBW display is buggy. when increasing timescale, RBW usually go lower, but near 10-50us/div, when you go back and forth, the RBW number will change inconsistently.. setup: viewing single channel at 1.25GSa/s.. FFT span 625MHz (center 312.5MHz) FFT window is arranged at bottom of dsos signal windows for better viewing, while increasing timescale up until 50us, take note on FFT RBW for each timescale, then reduce the timescale, RBW will show different value at around 10-20uS/div...
-
I want to add a request:
Could the on-screen measurement indicators only be shown when the measurement side panel is open?
-
Hi, I am new here. Anyone can unlock 914s to 924s? I am ordering it.
-
Hi and welcome,
But this is the wrong thread for it, here the right one:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5074423/#msg5074423 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5074423/#msg5074423)
-
Hi and welcome,
But this is the wrong thread for it, here the right one:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5074423/#msg5074423 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5074423/#msg5074423)
Thank you, I will try that post.
-
I have a "feature" request: Could Rigol please be more space-conscious in the UI, and waste less space (in particular vertical space) on the small display?
With reference to the attached screenshot from the manual -- showing the DHO900 here, since it needs to accommodate the most features:
7 - Is this "menu" really still useful if it only has two visible icons? It made sense on the 10" screens, but here? Maybe move the status indicator (10) here instead?
15 - Why do we need this separate button? Couldn't the RIGOL logo in the upper left serve this purpose?
10 - Why is this field so large? It used to display date and time, but those are not available on the small scopes.
11 .. 14 - If we can make these fields a bit wider, after omitting/reducing/moving 10 and 15, can they be less tall please? Two lines of text, same total height as the bar on top of the screen.
All sub-Windows on the screen: Why does every window need its own title bar? I can see that they show Waveforms, Math and Measurements respectively; no need to spell that out for me. If additional per-window controls are necessary on the screen, put them all into one burger-style menu (per window), and let that icon float over the data area; don't waste vertical space for a dedicated title bar.
In general, I think Rigol only made half-hearted adjustments to the UI when adapting it from the 10" screen of the DHO1000 and 4000 to the 800/900 series. I do like their graphical design choices (which some might find too playful and not professional-looking). But they should not consume quite that much space on the display.
-
Here's another bug...
Every now and again the Window transparency seems to go to 100% all by itself. I have to go and adjust it back.
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1925988;image)
I prefer it like this:
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1925994;image)
None of the other values changes, only transparency.
I haven't figured out what triggers it.
Anybody else seen this?
As a test I just set my wave intensity to 75%. Let's see if my window transparency jumps to 75% next time it happens.
-
Hi,
I have never had that behavior here.
What I have just found:
After a restart, the decoder function is switched off, you have to reactivate it.
At least the last values set there are retained.
-
I have never had that behavior here.
I get the feeling it's related to another setting. Let's see if it was the wave intensity. I remember setting that to 100% and I forgot to put it back afterwards.
PS: Is your transparency the same as your wave intensity?
-
I think not, could check this later..
-
What the...
I´ve set the transparency to 50%, wave intensity 70%, then restart...
Transparency is now 66%... :scared:
-
What the...
I´ve set the transparency to 50%, wave intensity 70%, then restart...
Transparency is now 66%... :scared:
OK, I've been playing.
When you reboot it: The window transparency is set to whatever the wave intensity was when it booted up.
eg. Boot up with wave intensity=80% then set wave intensity to 20%
On the next boot the transparency will be 80%.
On the boot after that it will be 20%.
So if your wave intensity is 70% or something like that you'll never notice. I only noticed because I had it at 100%.
There's definitely something wrong with state save/restore for some parameters (most are fine).
I'm guessing they're the parameters at the end of the state file and there's a missing/extra item in the save compared to the load.
(or an item with a different size...something like that)
-
Update: I just pressed the "DEFAULT" button and the waveform intensity and window transparency were set to 50%, that's why nobody else noticed it. :)
-
The bug where it doesn't save the setting for Fine/Zoom mode is probably related to this one...
-
I just pressed the "DEFAULT" button and the waveform intensity and window transparency were set to 50%.
Hm,
there seems to be something wrong with the power on state routine which you mentioned earlier.
That's why I never noticed it before, because I had the power on state set to "default" the whole time, until I didn't feel like setting everything up again after every start.
-
OK, steps to reproduce this:
1) Enable "Load last" in the setup
2) Set "Wave Intensity" to 100% in the Display settings.
3) Reboot twice.
You now have 100% transparency in the overlay dialogs.
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1926549;image)
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1926555;image)
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1926561;image)
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1926567;image)
-
3) Reboot twice.
I missed that part in your earlier description. That's surprising, what mechanism would be behind that? Store & retrieve works for the first reboot, and then fails the second time 'round although you have not touched the settings any further?
-
OK, steps to reproduce this:
Can reproduce this...
Wave intensity set to 100%, transparency 50%.
After the first reboot, transparency is 70%, after the second reboot 100%...
-
Wave intensity set to 100%, transparency 50%.
After the first reboot, transparency is 70%, after the second reboot 100%...
Ah, so the problem somehow "accumulates" and gets worse with the second reboot?
Try rebooting a third time. Maybe traces covered by the dialog window now become brighter than around it, because of 150% transparency? ::)
-
Ah, so the problem somehow "accumulates" and gets worse with the second reboot?
It seems so and since power on is set to last state, it holds this and goes one better...
But it stops at 100%. ;D
-
I just pressed the "DEFAULT" button and the waveform intensity and window transparency were set to 50%.
Hm,
there seems to be something wrong with the power on state routine which you mentioned earlier.
That's why I never noticed it before, because I had the power on state set to "default" the whole time, until I didn't feel like setting everything up again after every start.
Any scope should boot at/with last settings as a default operation.
Default to factory settings should be a user only defined operation.
Default should also be definable as a user custom operation and/or all should be able to be bypassed by loading previously saved Setup file.
-
I have to add that I consider this behavior to be a minor bug, not really decisive, just a bit annoying.
In general, my soon to follow interim conclusion about the DHO800 Scope might surprise some of you.
I've had it for almost 5 weeks now and have spent an hour or two with it almost every evening.
-
Can reproduce this...
Wave intensity set to 100%, transparency 50%.
After the first reboot, transparency is 70%, after the second reboot 100%...
That means wave intensity was 70% before you started doing anything.
Ah, so the problem somehow "accumulates" and gets worse with the second reboot?
No, it lags by one boot. It's not "accumulating" or doing any interpolation.
-
\
In general, my soon to follow interim conclusion about the DHO800 Scope might surprise some of you.
I've had it for almost 5 weeks now and have spent an hour or two with it almost every evening.
Can't wait to find out what an "interim conclusion" is... :popcorn:
(Should be in another thread though... this one is bug reports only)
-
In general, my soon to follow interim conclusion about the DHO800 Scope might surprise some of you.
:popcorn:
I trust your impartiality and I would ask for your rating in 2 ways:
1. Suitability as a first scope. Is the UI too complex and does the OS provide suitable protection for the scope newbie managing aliasing ?
2. For the experienced DSO user.
-
Did I ever mention that you recognize a salesman by his selective picking of arguments and angles which suit his agenda? :horse:
He never disappoints... this new demand is brilliant! :-DD
I typed up a long reply but I deleted it because first post says "No other discussion please".
-
I trust your impartiality and I would ask for your rating in 2 ways:
1. Suitability as a first scope. Is the UI too complex and does the OS provide suitable protection for the scope newbie managing aliasing ?
2. For the experienced DSO user.
I don't want to anticipate this because I want to post it in "my" thread, but here it is in brief:
To 1: The user interface of this rigol in particular is a bonus for beginners, you can always fall into the aliasing trap with any scope.
Regarding 2: Experienced users would not buy this scope as their main measuring device, but rather as a second one, the small form factor and the USB supply are an invitation to do so.
-
I don't want to anticipate this because I want to post it in "my" thread, but here it is in brief:
To 1: The user interface of this rigol in particular is a bonus for beginners, you can always fall into the aliasing trap with any scope.
I'm not a fan of the UI TBH: ignoring the soft buttons on the non-touch DS1000Z, there are more physical buttons & knobs on the DHO800/900 than the DS1000Z, but it's harder to use as important physical buttons are relegated to touch only, in favour of infrequently used ones, in particular the search navigation buttons. But then I'm not a fan of touch UIs on scopes anyway.
Regarding 2: Experienced users would not buy this scope as their main measuring device, but rather as a second one, the small form factor and the USB supply are an invitation to do so.
I agree with the basis of this, however with the firmware as it currently stands, it's little more than a desk ornament, particularly the 900. I do look forward to it being my field scope at some time in the future though.
-
I agree with the basis of this, however with the firmware as it currently stands, it's little more than a desk ornament
I don't know of any serious bugs in the DHO800.
There's a few annoyances, that's it. All functions appear to work. It's never crashed or locked up, not once.
We'll see what the next update brings for the DHO900 but let's not pretend this is a Rigol problem. EEVBLOG has long bug threads for every new oscilloscope model from every manufacturer, including some very expensive ones.
-
there are more physical buttons & knobs on the DHO800/900 than the DS1000Z
DHO800: 24
DS1000Z: 38
-
there are more physical buttons & knobs on the DHO800/900 than the DS1000Z
DHO800: 24
DS1000Z: 38
Why did you quote without my explicitly defined context?
What I said:
"ignoring the soft buttons on the non-touch DS1000Z, there are more physical buttons & knobs on the DHO800/900 than the DS1000Z"
MSO1074Z-S: 6 knobs, 24 buttons
DHO924S: 7 knobs, 26 buttons
The physical soft buttons can reasonably be replaced by on screen touch. That I'm not too fussed about.
My point was that there are too many regularly used primary functions that have been moved onto the touch screen, while much lesser-used functions enjoy individual buttons, most obviously the search navigation buttons.
On the same theme, the screen real estate has become unnecessarily cluttered with touch junk now, negatively impacting the waveform window size.
-
I know I have been guilty of an off-topic post myself (which I have just deleted), in response to tautech's "final report request". But can we please relegate this discussion to a different DHO-related thread, if it needs to be continued at all?
If we want any hope of Rigol reading this thread and acting upon it, we should keep it focused on bug reports.
-
I have problem with decode function for LIN signal. I try RS232 it fine, but with LIN data, it could not detect the data, only show wake-up signal.
Also it very hard to detect the signal because my data only send each 2 seconds, all parameter must do manual until see the data signal.
I do it wrong or this is a bug of this scope?
My signal is 2400 baud, probe 1X, the lowest speed support by DHO900 series.
-
SPI decode still doesn't work on the digital channels under 1.02 firmware, so back in the drawer it goes.
-
SPI decode worked for Martin on the DHO804, maybe a setup or SPI freq issue?
https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5177292/#msg5177292 (https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5177292/#msg5177292)
-
SPI decode worked for Martin on the DHO804
It works on the analog channels but not the digital (apparently).
-
SPI decode worked for Martin on the DHO804, maybe a setup or SPI freq issue?
https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5177292/#msg5177292 (https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5177292/#msg5177292)
"SPI decode still doesn't work on the digital channels under 1.02 firmware, so back in the drawer it goes."
-
There are some bugs related to LAN, LXI, mDNS/Bonjour:
- mDNS is disabled after reboot.
According to https://www.lxistandard.org/Documents/about/LXI%201_3%202008-10-30.pdf, (https://www.lxistandard.org/Documents/about/LXI%201_3%202008-10-30.pdf,) Rule 10.5, "Both mDNS and DNS-SD shall be enabled by default on LXI Devices."
It is rather inconvenient to have to activate mDNS manually every time you start the scope. - The port number for the connection to the oscilloscope for control with SCPI commands is 5555.
This should be 5025 (Scpi-raw) or 5024 (Scpi-telnet), according to https://www.lxistandard.org/About/LXI-Protocols.aspx (https://www.lxistandard.org/About/LXI-Protocols.aspx)
- mDNS is incorrectly giving port 80 as the port for the services _scpi-raw and _lxi.
For _scpi-raw it should be 5555 (unless changed to 5025, of course).
Under port 80 you find the web interface of the scope.
-
DHO924S
hardware: 8
and firmware 00:01:00
I haven't had time to properly test it yet, but I found two bugs that were solved by the 00:01:01 update.
First, if I changed the frequency of the AWG with the knob, my program kept crashing above 10kHz.
Second, the UltraAquire function did not work.
luckily the update fixed it.
-
Here I got something:
Feeding in 1Vpp 120Mhz sine wave singnal.
Trigger at below -340mV
A strange second waveform will start to appear and flicker. (Won't happen above this triggering level)
(https://lh3.google.com/u/0/d/1Nj-OH5brSqstdtwY912dek2glKt-NcIk=w3840-h1969-iv1)
Edit: The sine wave signal was generated by a siglent SDG2122X(converted from SDG2042X). The oscilloscope was 50ohm terminated with the terminator from rigol and the BNC cable was from the siglent SDG. The oscilloscope was DHO804 on F/W 01.02 and was hacked to DHO924.
I have also tried lowering the frequency and it did improve as the frequency gets lower. However, it can still occasionally happen at 70MHz.
Edit 2: One more thing I want to mention is that the displayed Vpp on F/W 01.02 was noticeably higher than F/W 01.14, both hacked to 250M.
Edit 3: A source said that reloading the version-related FPGA bit inside the F/W package can ease this issue. I have tested this by reloading the BOOT.bin provided in the F/W upgrade package and it did help, but did not eliminate the problem.
-
Here I got something:
it's the same for me. 924S
try setting the trigger to the falling edge if you trigger the bottom of the wave.
For the top, use the rising edge trigger.
and look at "Either" as well.
-
Here I got something:
Feeding in 1Vpp 120Mhz sine wave singnal.
Trigger at below -340mV
A strange second waveform will start to appear and fliker.
(https://lh3.google.com/u/0/d/1Nj-OH5brSqstdtwY912dek2glKt-NcIk=w3840-h1969-iv1)
This is NOT a bug, you have something in your signal that's causing false triggers.
Adjust trigger settings until it goes away.
it's the same for me. 924S
try setting the trigger to the falling edge if you trigger the bottom of the wave.
For the top, use the rising edge trigger.
and look at "Either" as well.
It's the same for everybody on every oscilloscope ever made.
The solution is to adjust the trigger, as you noticed.
-
Yes, it needs to be set up well.
My other scopes do not produce this.
maybe the Micsig TO2202C, but it's already at the bottom of the signal, it can't trigger well.
I think this event is more noticeable with this scope.
-
I think this event is more noticeable with this scope.
12-bit resolution is more sensitive to noisy signals.
-
I think this event is more noticeable with this scope.
12-bit resolution is more sensitive to noisy signals.
There is a "Noise Rejection" switch in the trigger dialog which might help. It is not explained well in the user manual, but I assume it sets some hysteresis for the trigger threshold. (It does not enable a low-pass filter, presumably, since there is a separate "high frequency rejection" option for trigger coupling.)
-
I think this event is more noticeable with this scope.
12-bit resolution is more sensitive to noisy signals.
NOOOOOOO it is not....
12 bit actually allows for more accurate trigger point interpolation, and less trigger jitter....
It might be that signal has some very fast spikes not visible at this magnification. Trying noise rejection like Ebastler suggested would be good idea to try. Also LF/HF trigger filter...
-
NOOOOOOO it is not....
12 bit actually allows for more accurate trigger point interpolation, and less trigger jitter....
Well, that's the "Let's keep this thread clean and noise free" edict down the toilet...
It is NOT a bug. That's all that needs to be said here.
Any other discussion? How about in the other thread where OP also posted it?
-
Here I got something:
Feeding in 1Vpp 120Mhz sine wave singnal.
Trigger at below -340mV
A strange second waveform will start to appear and fliker.
(https://lh3.google.com/u/0/d/1Nj-OH5brSqstdtwY912dek2glKt-NcIk=w3840-h1969-iv1)
This is NOT a bug, you have something in your signal that's causing false triggers.
Adjust trigger settings until it goes away.
it's the same for me. 924S
try setting the trigger to the falling edge if you trigger the bottom of the wave.
For the top, use the rising edge trigger.
and look at "Either" as well.
It's the same for everybody on every oscilloscope ever made.
The solution is to adjust the trigger, as you noticed.
Thank you, I got confused there as I am expecting to find some abnormally on F/W 01.02 and I just think this is one of them. I later realized this happens all the time but can't quite figure out why as this won't happen on my Siglent 1102x-c or Agilent 3032A. I will try tomorrow, thanks again.
Edit: After enabling the "Noise Rejection" function, the oscilloscope stops triggering at the low voltage level on the "rising edge" trigger type.
Edit2: To clarify: The "Noise Rejection" function did prevent the "ghost waveform" from appearing as it won't trigger below -340mV anymore with the "rising edge" trigger type. I will need to switch to the "falling edge" trigger type for a stable trigger.
Edit3: I have added more information at #133.
-
SPI decode worked for Martin on the DHO804, maybe a setup or SPI freq issue?
https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5177292/#msg5177292 (https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5177292/#msg5177292)
"SPI decode still doesn't work on the digital channels under 1.02 firmware, so back in the drawer it goes."
I have checked most of the Rigol sites worldwide, including their Chinese site here (https://mall.rigol.com/item.html?item_id=1577) (click the 4th tab from the right to see firmware), and only Firmware version 1.01 is currently available as of Nov. 28, 2023. So if you are not mistaken about there being a version 1.02, please provide the source and a link to it. Thanks.
-
I think this event is more noticeable with this scope.
12-bit resolution is more sensitive to noisy signals.
In this context.. :bullshit: |O
If I need good noise (aka bullshit) generator... I will buy you for this work... how much you want salary. :)
-
12-bit resolution is more sensitive to noisy signals.
In this context.. :bullshit: |O
:palm:
Sorry, should I have said "less-than-perfect" signals?
Edit: After enabling the "Noise Rejection" function, the oscilloscope stops triggering at the low voltage level on the "rising edge" trigger type.
Oh, look, the "noise" rejection function fixed it! How is that possible? :scared:
-
12-bit resolution is more sensitive to noisy signals.
In this context.. :bullshit: |O
:palm:
Sorry, should I have said "less-than-perfect" signals?
Edit: After enabling the "Noise Rejection" function, the oscilloscope stops triggering at the low voltage level on the "rising edge" trigger type.
Oh, look, the "noise" rejection function fixed it! How is that possible? :scared:
You misunderstood. He said that if he enables "Noise Rejection" function it stop triggering completely on rising edge type when trigger level is low...
So something is wrong. Either some user error or problem with trigger.
-
So something is wrong. Either some user error or problem with trigger.
Definitely not the signal combined with 12-bit resolution?
PS: It cured his false triggers... leading him to the correct solution of adjusting the trigger level.
-
So something is wrong. Either some user error or problem with trigger.
Definitely not the signal combined with 12-bit resolution?
PS: It cured his false triggers... leading him to the correct solution of adjusting the trigger level.
12 bit resolution should make triggering more stable... Like I said...
Quote:
Edit: After enabling the "Noise Rejection" function, the oscilloscope stops triggering at the low voltage level on the "rising edge" trigger type.
Where do you see word fixed?
-
The test signal was provided by a TinySA Ultra.
In the video, I set the simple edge trigger.
The frequency can be seen on the side, as well as the value of Vpp.
and in the pictures you can see it at 4 frequencies.
At 125Mhz and 250Mhz, you can see that the bad triggering zone is larger, that is, the value of deltaY compared to the total Vpp.
I can't reproduce this phenomenon as strongly on another scope.
https://www.youtube.com/watch?v=5IdFyd60Cv8 (https://www.youtube.com/watch?v=5IdFyd60Cv8)
-
Thanks for sharing the video. And ouch, that looks wrong indeed...
In the experiments with the bi-directional edge trigger setting, the effect might be due to the phase of the sine wave where the trigger gets activated. At certain trigger levels you might always "catch" the sine wave at such a time that the next re-trigger again sees the same edge direction, while at other levels, the active edges alternate? So that would not be a bug.
But I don't have an explanation for the unexpected trigger points in the positive or negative edge setting. The trigger often "strikes" when the signal level is far away from the set trigger threshold. Clearly a bug, I'd say.
-
The test signal was provided by a TinySA Ultra.
In the video, I set the simple edge trigger.
The frequency can be seen on the side, as well as the value of Vpp.
and in the pictures you can see it at 4 frequencies.
At 125Mhz and 250Mhz, you can see that the bad triggering zone is larger, that is, the value of deltaY compared to the total Vpp.
I can't reproduce this phenomenon as strongly on another scope.
https://www.youtube.com/watch?v=5IdFyd60Cv8 (https://www.youtube.com/watch?v=5IdFyd60Cv8)
Are you using Auto trigger mode? Try using normal trigger mode..
-
i think its a bug. no worse signal will trigger like this (attached) iirc i encountered such trigger anomaly while using DS1054Z but didnt care too much as i concentrated on debugging my circuit. dont remember what caused such trigger event... tinysa based on PLL if i'm not mistaken, not some jittery DDS IC.. i dont think PLL (square signal) or filter after that will cause such nasty noises/spikes. its very unlikely to be in that place. ymmv.
-
There's clear lumps and bumps in that signal, wouldn't surprise me at all if you're just catching points where the signal goes backwards.
Again: Can we press STOP on a bad trigger (use record mode), zoom in on the triggered area, and take a close look? Use the 12 bits.
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1939392;image)
And... can we do it in the Test and compare thread:
https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/ (https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/)
The first post in this thread says to keep it clean and tidy and this is already devolving
-
There's clear lumps and bumps in that signal, wouldn't surprise me at all if you're just catching points where the signal goes backwards.
Again: Can we press STOP, zoom in on the triggered area, and take a close look? Use the 12 bits.
I appreciate that you like your DHO800. But please don't let that cloud your judgement.
Look at how far away the level of the mis-triggered signal is from the trigger threshold in some of the demonstrations. What level of "noise" would you expect on the input signal? "Edge trigger" is not just about the signal having a positive or negative edge, but about passing the threshold in that direction!
Also, please consider that most of the demonstration was done with signals >= 125 MHz, at very fast timebase settings. Would you expect the scope to resolve and show tiny, much faster spikes in STOP mode?
-
It is the same for Auto and Normal settings.
I couldn't catch the event in record mode, it's as if it pulls the wave into a good position when I scroll frame by frame.
https://youtu.be/MWDAznqXl3g (https://youtu.be/MWDAznqXl3g)
The event is visible in the background if you look at it, but when I play it again frame by frame, it doesn't appear.
If I play the recorded wave several times, the error does not always appear around the same frame.
I also checked the signal with the STO2202C and also with infinite endurance setting, I didn't see a single hair of signal on it.
I'm still trying, if there's another idea I can try.
-
It sure looks like you caught a display glitch in that video at time ~2:48 https://youtu.be/MWDAznqXl3g?t=167
Is there an easy way of going frame-by-frame in youtube videos?
-
I can reproduce this effect from 90Mhz and then only in the negative trigger range, see pictures.
And:
If you reduce the sample rate (e.g. add a second channel), the spook is over. ;)
-
How is this possible? That's not the trigger level...
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1939563;image)
Video:
https://www.youtube.com/watch?v=AwmTEDC-Tzg (https://www.youtube.com/watch?v=AwmTEDC-Tzg)
-
How is this possible? That's not the trigger level...
That's very far off. Acquisition stopped and trigger level changed afterwards, by any chance?
-
in the video I changed the trigger.
with the rising edge setting, the error is in the negative range.
with the falling edge setting, the error is in the positive range.
Fungus
If I see correctly, your trigger is outside the trigger zone, the trigger line is set very low. Your wave is not calm though. Does the Stop/Run button correspond to the forced trigger?
-
How is this possible? That's not the trigger level...
That's very far off. Acquisition stopped and trigger level changed afterwards, by any chance?
Nope. See the video... :popcorn:
-
But, is it triggering? Or just stopped?
-
How is this possible? That's not the trigger level...
That's very far off. Acquisition stopped and trigger level changed afterwards, by any chance?
Nope. See the video... :popcorn:
In the video there is no trigger line in the picture, so I don't know what you did before the snapshot.
In the video, it is also obvious that you let the scope run in Auto trigger mode, with the trigger threshold set below the signal. So it triggered at random time points, when the auto-trigger timeout struck. And then you stopped the acquisition, which of course shows the signal at a random phase. :palm:
I don't normally use that emoji on others since I find it impolite, but your stupid popcorn thing really got under my skin. Learn how to use that scope, would you?
-
In the video there is no trigger line in the picture, so I don't know what you did before the snapshot.
It's in the same place, see the marker on the right.
-
Learn how to use that scope, would you?
I know how to use it. I'm just saving the second video for after everybody tells me the sky is falling.
-
I know how to use it. I'm just saving the second video for after everybody tells me the sky is falling.
It is buggy behaviour that the scope cannot trigger even when the trigger threshold is still within the signal amplitude range. I just tried on my DHO1000 and it triggers nicely all the way, with the trigger threshold set anywhere between the maxium and the minimum of the signal swing.
Your little "stop-the-acquisition" game does not contribute anything to illustrating or explaining the problem, I'm afraid. csuhi17 has also confirmed that the erroneous triggers occur in normal triggering mode too, so they have nothing to do with the auto-triggering timeout. So what are you trying to tell us?
-
In the video, it is also obvious that you let the scope run in Auto trigger mode
Yep. All the ghostly "bad" triggers being discussed above are just AUTO triggers.
If you turn off AUTO mode it either triggers correctly or stays in WAIT mode indefinitely.
See video:
https://www.youtube.com/watch?v=FgN3q6MSQqc (https://www.youtube.com/watch?v=FgN3q6MSQqc)
Should it trigger down at the bottom of the wave? That's a matter of preference. Me? I prefer that it doesn't.
The video also shows what happens if you turn on "noise reject", i.e. it moves the accepted trigger point further up the waveform.
(presumably looking for a steeper slope)
-
If you turn off AUTO mode it either triggers correctly or stays in WAIT mode indefinitely.
It is the same for Auto and Normal settings.
Seems that you are not testing under the same conditions, or your scopes are behaving differently.
-
I think I have found a little bug.
As you know, I find it a bit unfortunate that you can't change the function of a measurement window, e.g. if you have selected frequency, you can't change it to something else but either select another measurement window or delete the existing one.
This is not yet a bug, just a bit annoying.
The bug:
In this window you can call up the "setting" and set various parameters, including the source.
And that doesn't work.
For example, if you change the source from ch1 to ch2, ch2 is displayed in the setting, but the values remain for ch1.
Then you can also omit the source selection, that would probably be the easiest fix. ;)
-
I haven't seen any erroneous triggering at all.
-
I think I have found a little bug.
if you change the source from ch1 to ch2, ch2 is displayed in the setting, but the values remain for ch1.
Yep, confirmed.
-
Maybe someone could try the following trigger-related thing. I found this on the DHO1000 and wonder whether the DHO800 behaves the same:
- Look at a reasonably fast sine wave (say 50 MHz) with a fast time base (5 ns/div). Set normal DC-coupled trigger, trigger threshold around zero. Stable triggering as expected.
- Switch trigger coupling to either AC or LFR (low frequency rejection). Trigger time suddenly has a jitter of approx. 1.5 ns peak-peak.
What gives? One can argue that there is no spec for the trigger jitter at all -- except for external trigger, in case of the DHO1000 -- so it's not a bug in the sense of "violating a spec". But I don't see any technical reason why applying a high-pass filter should induce such jitter, so it seems to clearly violate reasonable expectations. Does the DHO800 do the same?
-
Just switched the units on.... ;)
-
Confirmed.
AC or LFR, you get these jittering waveform at 50Mhz.
The higher the worser it gets.
It starts already at appx 5Mhz (barely visible).
-
Confirmed.
AC or LFR, you get these jittering waveform at 50Mhz.
The higher the worser it gets.
It starts already at appx 5Mhz (barely visible).
Many thanks for checking and confirming this. On the DHO1000 I was under the impression that it is a constant jitter time -- it just becomes more visible at the fast time bases one uses with higher signal frequencies.
The effect is even more pronounced on your DHO800 screenshot, approx. 2.5 ns peak-peak instead of 1.5 ns on the 1000. That's proportional to the difference in sampling rate, so we may be seeing an effect of the discrete time steps on an FIR filter here.
-
Here pics from 10Mhz, 25Mhz, 100Mhz.
Try this with other scope I have here.
-
Here pics from 10Mhz, 25Mhz, 100Mhz.
Try this with other scope I have here.
Thanks. I'd say that looks like a constant ~2.5 ns p-p, or 3 sampling intervals. If my theory that it's based on a digital FIR filter is correct, I would expect the spread to become twice as large when a second channel gets activated. Didn't think of trying this on my DHO1000 before I hid it away again. (Don't tell Santa Claus that I had unpacked it... ;))
-
I've tested FW 1.02 on my DHO804 with original vendor.bin and activated options:
- "ADC Gain" self calibration option is enabled by default in FW 1.02
- calibration process fails with "ADC Gain" self calibration option turned on with the native vendor.bin
- oscilloscope could be calibrated successfully and with maximum precision (zero and voltage accuracy), but "ADC Gain" self calibration option should be disabled
Also I've tested FW 1.02 with DHO924 vendor.bin:
- oscilloscope could be calibrated successfully with good zero precision and perfect voltage accuracy, but "ADC Gain" self calibration option should be ENABLED (you can use default calibration options)
- "AFE zero" self calibration option spoils calibration results, but the initial state could be restored by pushing original cal files to the scope
-
I found this on the DHO1000 and wonder whether the DHO800 behaves the same:
Couldn't wait until Xmas?
My DHO800 does it.
-
(Don't tell Santa Claus that I had unpacked it... ;))
You can have the box given to you as a present... ;)
Rigol DS1054Z, Siglent 1104X-E : Both are having no problems with it when setting to AC or LFR.
So it is systemic.
-
Thanks. I'd say that looks like a constant ~2.5 ns p-p, or 3 sampling intervals. If my theory that it's based on a digital FIR filter is correct, I would expect the spread to become twice as large when a second channel gets activated.
Yes, it does.
And with three channels it's three times as wide.
-
Thanks. I'd say that looks like a constant ~2.5 ns p-p, or 3 sampling intervals. If my theory that it's based on a digital FIR filter is correct, I would expect the spread to become twice as large when a second channel gets activated.
Yes, it does.
And with three channels it's three times as wide.
Thanks for checking! I would expect the jitter to be even four times as wide whith three (or four) channels active, in proportion to the reduced sampling rate. Is that what you see?
-
(Don't tell Santa Claus that I had unpacked it... ;))
You can have the box given to you as a present... ;)
Rigol DS1054Z, Siglent 1104X-E : Both are having no problems with it when setting to AC or LFR.
So it is systemic.
Sigh... Found the first little disappointment before I even took proper possession of the scope. :(
Not a setting I expect to use often, but still -- they might as well have implemented this properly. I hope one does not get the same effect with an AC-coupled signal, or a math channel that uses high-pass filtering, right?
-
Thanks for checking! I would expect the jitter to be even four times as wide whith three (or four) channels active, in proportion to the reduced sampling rate. Is that what you see?
Looks like 3 to me:
https://www.youtube.com/watch?v=_swNQGsz7aA (https://www.youtube.com/watch?v=_swNQGsz7aA)
(count the divisions on the horizontal axis)
-
I hope one does not get the same effect with an AC-coupled signal, or a math channel that uses high-pass filtering, right?
Just tested it, AC-coupling makes no problems...
-
I hope one does not get the same effect with an AC-coupled signal, or a math channel that uses high-pass filtering, right?
Just tested it, AC-coupling makes no problems...
:phew:
-
I hope one does not get the same effect with an AC-coupled signal, or a math channel that uses high-pass filtering, right?
Nope.
-
Thanks for checking! I would expect the jitter to be even four times as wide whith three (or four) channels active, in proportion to the reduced sampling rate. Is that what you see?
Looks like 3 to me:
(count the divisions on the horizontal axis)
Right. Actually more than 2.5 ns in single-channel mode, about 5 ns dual-channel, 7.5 or so for three channels and a bit more for four.
There goes my time-discrete filter theory...
-
:phew:
No surprises there... I'm sure somebody would have noticed that one before now.
-
I've tested FW 1.02 on my DHO804 with original vendor.bin and activated options:
- "ADC Gain" self calibration option is enabled by default in FW 1.02
- calibration process fails with "ADC Gain" self calibration option turned on with the native vendor.bin
After the default self-calibration failed for me on my DHO804 on the first try, I ran it again (without any settings or file changes) and it worked. (Maybe an exceeded iteration counter was restarted from the last state, or some random reinitialization worked on the second try. I don't know, but it worked...) As found before, the scope retains the "100MHz" and 50M memory enhancements.
Exchanging the vendor.bin file with the 924 version works well without any additional recalibration. No offsets. Hence the vendor.bin files can be switched back and forth in seconds, to increase the BW (to 1.27 ns RT) with the additional decoders and /div features (with better than 24uV/50-Ohm AC-RMS noise floor) as needed, without having to recalibrate...Nice.
-
If calibration works using a DHO900 vendor.bin with the new firmware then I'd be interested to know the measured bandwidth of a "125MHz" DHO914.
It would be good if it was near 200Mhz, that way we could have better Nyquist ratios than the DHO924 and the missing 2ns/div horizontal scale on our DHO800s.
Does anybody have a DHO914's vendor.bin to play with?
-
I've tested FW 1.02...
Ditto my previous post#142 (https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5192319/#msg5192319) where I say that Firmware version 1.02 does NOT exist, as evidenced by its absence even on Rigol's Chinese language firmware download page for the DHO800 series.
So if indeed you folks citing "1.02" are not in error, please cite the download location for that otherwise undiscoverable firmware version.
Thank you.
-
I say that Firmware version 1.02 does NOT exist
Yes it DOES, I've got it. :)
It's in the "unbox and teardown" thread... posted on November 22nd.
Unfortunately it seems to have been removed since then.
-
It's in the "unbox and teardown" thread... posted on November 22nd.
Unfortunately it seems to have been removed since then.
As per your statement above in red, as far as those of us who do not have v1.02 are concerned, it technically does not exist. Once posted back online for all to download, then we who do not have it can truly say it exists. >:D
I still don't understand why Rigol isn't publicly posting v1.02 if it is official and good/safe to use. Or was it created outside Rigol and therefore a questionable update (even if it seems to work fine)? Or perhaps you don't know who created v1.02.
Anyway, I think these are important and valid questions in light of the title of this thread being focused on FIRMWARE. Some people are testing v1.02, but since it is no longer available for download, that restricts the number of people who are using it to just a few. Everyone else is stuck with v1.01.
-
I still don't understand why Rigol isn't publicly posting v1.02 if it is official and good/safe to use.
Rigol's firmware release management seems to be haphazard to put it nicely.
-
[...]
- "ADC Gain" self calibration option is enabled by default in FW 1.02
- "ADC Gain" self calibration option should be disabled
[...]
- "AFE zero" self calibration option spoils calibration results, but the initial state could be restored by pushing original cal files to the scope
Are all these checkboxes standard in the DHO 800/900 self-calibration dialog, or do you have to activate some expert/debug mode beforehand? My DHO1000 does not display any options in that dialog, just the "disconnect everything" message.
EDIT: Could you move or copy your post to the Hacking thread?
I think that's the better place, easier to find there for future reference.
EDIT²: Ah, found it. There is indeed a debug mode:
Found a hidden debug mode in the utility menu that can be enabled if you tap the About button several times. This unlocks more options in the Other and the SelfCal tabs and a new Debug tab. Not sure if it has other effects.
-
The test signal was provided by a TinySA Ultra.
In the video, I set the simple edge trigger.
The frequency can be seen on the side, as well as the value of Vpp.
and in the pictures you can see it at 4 frequencies.
At 125Mhz and 250Mhz, you can see that the bad triggering zone is larger, that is, the value of deltaY compared to the total Vpp.
I can't reproduce this phenomenon as strongly on another scope.
https://www.youtube.com/watch?v=5IdFyd60Cv8 (https://www.youtube.com/watch?v=5IdFyd60Cv8)
I have consulted Rigol tech support and here is their reply:
"No, this is not intended behavior."
“We have recently discovered this phenomenon and have watched your video above and it is currently being verified and determined by a dedicated person.”
“We usually have initial conclusions in one to two weeks, and then we will work out a program and plan the timing.”
Sounds hopeful at least.
-
I have consulted Rigol tech support and here is their reply:
Do you have a direct contact there, or did you go via the regular support hotline or email?
In either case it looks like a more direct line into the company than going through the European or North American branches. So maybe you could alert them of a few other problems as well -- like the jitter observed with AC and LFR trigger coupling, discussed above? Thanks!
-
I have consulted Rigol tech support and here is their reply:
Do you have a direct contact there, or did you go via the regular support hotline or email?
In either case it looks like a more direct line into the company than going through the European or North American branches. So maybe you could alert them of a few other problems as well -- like the jitter observed with AC and LFR trigger coupling, discussed above? Thanks!
I contacted them on their Chinese official website. I will bring that up next time I contact them. :-BROKE
Edit: I tried AC and LFR triggering on my 804(F/W 01.02) from 50Mhz to 120Mhz and did not see the issue. Did I miss something? Video here:
https://youtu.be/ALNmIgmWvGQ (https://youtu.be/ALNmIgmWvGQ)
-
Edit: I tried AC and LFR triggering on my 804(F/W 01.02) from 50Mhz to 120Mhz and did not see the issue. Did I miss something? Video here:
https://youtu.be/ALNmIgmWvGQ (https://youtu.be/ALNmIgmWvGQ)
Hmm, that's intriguing. Could it be that FW 01.02 has fixed this, or maybe (less likely) the upgrade to DHO9xx?
@Martin72, @Fungus -- which firmware version were you running when you confirmed the trigger jitter?
-
@Martin72, @Fungus -- which firmware version were you running when you confirmed the trigger jitter?
1.01
There was nothing in the 1.02 release notes that seemed interesting to me.
If anybody desperately wants 1.02 firmware I can send a copy.
I'm more interested in a DHO914 vendor.bin right now.
(Maybe I'll have to synthesize my own but I don't have much free time at the moment)
-
If anybody desperately wants 1.02 firmware I can send a copy.
My previous words on this topic weren't clear so I will rephrase...
Who is the source of v.1.02? (Who created it, I mean.)
If one contends it is Rigol, is that confirmed or merely an assumption?
v.1.02 is not posted even on Rigol's Chinese language website. Unless the source for v.1.02 is known, it could have originated from a hacker or seedy individual, even if one contends it seemingly works fine. I'm mainly trying to figure out the original source of 1.02.
Not that it matters so much now that the only way to get it is through the handful of people in this thread who actually have it. Normally, I wouldn't care and just sit back and wait for the manufacturer to release a normal update, but it seems Rigol isn't very good when it comes to firmware updates.
-
As long as the file is not available on one of the official websites, I would not download and install anything elsewhere.
I had this 1.02 installed and got massive offset problems that couldn't be calibrated away.
-
If anybody desperately wants 1.02 firmware I can send a copy.
My previous words on this topic weren't clear so I will rephrase...
Who is the source of v.1.02? (Who created it, I mean.)
If one contends it is Rigol, is that confirmed or merely an assumption?
Mine came via the link to rigol.com
https://download.rigol.com/cn/Firmware/Digital%20Oscilloscope/DHO800%26DHO900/DHO800_DHO900(Software)Updatev00.01.02.00.00.zip
I have no idea what you're trying to prove here...
-
DHO814 Fresh out of the box: firmware 0.01.00.00.19, unhacked
Measuring 5volt 125MHz canned oscillator with 350MHz LeCroy passive probe, short spring ground
First screenshot is: Norm trigger mode, falling edge, with threshold set just below max (it doesn't misbehave with threshold near min)
Second screenshot is: same, but rising edge and threshold just above min (it doesn't misbehave with threshold near max)
Edit: I only see this with a 125MHz osc. 100MHz, or below, triggers OK.
-
As long as the file is not available on one of the official websites, I would not download and install anything elsewhere.
I had this 1.02 installed and got massive offset problems that couldn't be calibrated away.
I solved the DC offset issue by:
1. Revert the oscilloscope to F/W 01.00. This is done by flashing the SD card with my backup. The goal here is to get F/W version 01.00 as 01.14 cause issues in my case.
2. Upgrade to F/W 01.02.
3. Run the self-cal without turning on engineering mode.
4. Reload the FPGA Boot.bin of F/W 01.02 with the script that Rigol provided in the /shell folder.
In my case, the oscilloscope works at least as well as on F/W 01.14.
-
Hi,
Far too much effort for a beta version of questionable origin.
I was able to successfully update my scope to the latest official version and will simply wait until there is something real.
-
Far too much effort for a beta version of questionable origin.
Exactly. Which is why I brought up the issue earlier. Only a few select people have versions higher than the official 1.01, and although Fungus mentioned a download URL, he also mentioned it no longer works. Even if it did, as you said, the origin is questionable at best.
That's why I think the only meaningful testing is done on 1.0 or 1.01 because they are official and what anyone (with the scope) can use.
-
Edit: I think this was user error. I'd mistakenly assumed that doing an "Auto" would reset all of the options since it resets all the probe options (e.g. reset to 1X DC). Instead, doing an "Auto" does NOT reset the trigger noise reject mode. With noise reject on, the waveform must exceed the hysteresis/noise level before triggering.
I'm continuing to have intermittent triggering problems. It starts out OK but something that I'm doing gets it into a bad state where it won't trigger until the trigger level is well within the waveform. Before it gets into the bad state, I can sweep the trigger level up and down across the whole waveform without losing trigger anywhere on the waveform (of course, it won't trigger when the level is outside the waveform).
I've been looking at a 8MHz canned oscillator and trying to trigger on the negative undershoot. Currently it's in the bad state and is not triggering (the waveform on the display is from a slightly higher trigger level of 320mV). [Normal triggering mode, DC coupling, 10x 150MHz Rigol probe, noise reject off, min holdoff (8ns),
[attach=1]
I don't know what I did to get it into this state. I've seen it several times now. I'm mostly zooming in and out, while adjusting trigger, and doing some single-shot captures.
-
Edit2: Please ignore this and mark it as a Mistake (or delete the whole discussion) - it was a user error (overdriving the input stage)
------
Here's another weirdness I'm seeing. Looking at the undershoot of a 8MHz canned oscillator while simply adjusting the voltage scale (1v/div down to 50mV/div), the displayed and measured undershoot values change drastically. 200mV and 100mV don't even show the undershoot, but it shows back up at 50mV/div. Is it just me (or my scope), or can someone else repeat this?
Note: I power-cycled after the previous trigger issue, so this should be starting from a good state.
[P.S. how do you safely eject a USB stick after copying images to it?]
-
Here's another weirdness I'm seeing. Looking at the undershoot of a 8MHz canned oscillator while simply adjusting the voltage scale (1v/div down to 50mV/div), the displayed and measured undershoot values change drastically. 200mV and 100mV don't even show the undershoot, but it shows back up at 50mV/div.
You are overdriving the input stage quite significantly at the higher vertical sensitivity settings. I assume what you see is just the effect of the resulting saturation. At 50 ns/div you are not giving the input amp a lot of time to recover.
EDIT: A benefit of having a 12-bit scope is that it offers you another way to look more closely at the overshoot, if that's what you are after: Capture the signal in a vertical range where you don't overdirve the input (or at least don't overdrive it too much); stop the acquisition; then do a vertical zoom into the captured signal "digitally".
-
Here's another weirdness I'm seeing. Looking at the undershoot of a 8MHz canned oscillator while simply adjusting the voltage scale (1v/div down to 50mV/div), the displayed and measured undershoot values change drastically. 200mV and 100mV don't even show the undershoot, but it shows back up at 50mV/div.
You are overdriving the input stage quite significantly at the higher vertical sensitivity settings. I assume what you see is just the effect of the resulting saturation. At 50 ns/div you are not giving the input amp a lot of time to recover.
EDIT: A benefit of having a 12-bit scope is that it offers you another way to look more closely at the overshoot, if that's what you are after: Capture the signal in a vertical range where you don't overdirve the input (or at least don't overdrive it too much); stop the acquisition; then do a vertical zoom into the captured signal "digitally".
Thanks, that makes much more sense. I'd tried the zoom earlier but got confused since it was showing a truncated waveform. I now see that you need to adjust the offset of the stored waveform before zooming, or else the top or bottom gets flat-lined.
-
Hello! Can you share firmware v00.01.02.00.00 for DHO800? You would be a great help!
-
Hello! Can you share firmware v00.01.02.00.00 for DHO800? You would be a great help!
You just asked that in another thread (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5202672/#msg5202672) yesterday night. Please do not double-post. It is frowned upon here (and on most other forums too).
-
I myself do NOT frown upon double posts, especially if the first post is never answered, which seems to be the case here. Let freedom reign!
However...
As I have said multiple times, in different ways (which I guess slips me past the double-post censors, he he), v1.02 hasn't been on any official Rigol sites THAT I HAVE SEEN, and it certainly isn't available now. So that raises suspicion about its origin and purpose. One would be wise to just avoid v.1.02 and stick with v1.01 because at least I see v1.01 available from Rigol. Or at least I did a few days ago, but now...
That other thread (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5203626/#msg5203626) says that v1.01 has been removed from official Rigol sources in some locations, which if true, raises the question about what the heck is going on. :palm:
-
Firmware 1.02 was released on the official rigol site (https://www.rigol.com/products/detail/DHO800), it was downloaded and installed by many forum users (search "1.02" in this thead (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/))
However, it was withdrawn soon.
It has some pros and cons (https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5193930/#msg5193930).
So make your own decision before downloading:
Download FW 1.02 from google drive (https://drive.google.com/drive/folders/12DeJNDU_OoFKIUOAc_RU__SfYzjSr8fp?usp=sharing)
-
That other thread (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5203626/#msg5203626) says that v1.01 has been removed from official Rigol sources in some locations, which if true, raises the question about what the heck is going on. :palm:
That is going down the speculation road... :-//
https://download.rigol.com/cn/Firmware/Digital%20Oscilloscope/DHO800%26DHO900/DHO800_DHO900(Software)UpdateV00.01.01.zip (https://download.rigol.com/cn/Firmware/Digital%20Oscilloscope/DHO800%26DHO900/DHO800_DHO900(Software)UpdateV00.01.01.zip)
-
That is going down the speculation road... :-//
Ah yes... Speculation Road. The road on which one travels when using v1.02 which is truly no longer available, speculating that the pros may outweigh the cons, speculating that it was pulled by Rigol for no good reason.
Yes, Speculation Road. The road well travelled here.
-
Ah yes... Speculation Road. The road on which one travels when using v1.02 which is truly no longer available, speculating that the pros may outweigh the cons, speculating that it was pulled by Rigol for no good reason.
Yes, Speculation Road. The road well travelled here.
It's "Misinformation Road", really, as far as the alleged withdrawal of firmware 01.01 is concerned.
FW 01.01 is officially available on all Rigol sites, International, European and North American. On the NA site, they just forgot to put it into the "Support" section. But it is right there on the product pages, e.g. https://www.rigolna.com/products/rigol-digital-oscilloscopes/dho800/ (https://www.rigolna.com/products/rigol-digital-oscilloscopes/dho800/)
-
No, there was a little time when the 1.01 update could not be accessed on the Rigolna and Rigol eu websites either.
Then I thought they would replace it with a new one.
Has anyone asked Rigol about canceling the 1.02 update?
Then it would be possible to find out if it was real and why it was deleted.
-
Then it would be possible to find out if it was real and why it was deleted.
I'm sure it was real. It was on the Rigol site, APK files are signed, and quite a few people installed it.
It didn't really fix anything though so I don't know why everybody is obsessed with it.
There could be many reasons for pulling it. Maybe it had a new bug or something.
FWIW: I have a copy but I'm running 1.01 because I didn't see anything in the release notes that interested me.
-
I'm not seeing a lot of bugs in the 924s. I've only had it a couple of days so I still have a few areas to check but so far so good. I think I'll sit with the version that came with it.
Also I wonder if Rigol did something with the fan, mine is not noisy and I'm, pretty finicky about those things, I once sold a Keysight instrument because of noise.
I really love this little guy!
-
Also I wonder if Rigol did something with the fan, mine is not noisy
The fan isn't that loud either, in my "lab" the rigol is certainly not the loudest, I have lots of other annoying candidates at the start. ;)
The noise is higher-frequency than others, which is more noticeable - but when you hear something in comparison, it's not loud.
-
They can only make the fan so big, it's going to have a small amount of whine.
-
I think I´ve found a little bug...
Fungus showed a "shortcut" in the menu for selecting coupling without using the dropdown bar - Cool.
https://www.eevblog.com/forum/testgear/rigol-dho814-or-rigol-1054z/msg5220303/#msg5220303 (https://www.eevblog.com/forum/testgear/rigol-dho814-or-rigol-1054z/msg5220303/#msg5220303)
A little yellow line is showing the active part in the block diagram - but there´s another yellow line for inverting on/off.
But this one you can´t touch, it won´t be moved either when you select inverting on/off.
Like I said, a small bug (and probably valid for all rigol dho scopes).
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=1952304;image)
-
I seem to be having a problem with the sensitivity of the touch screen not sensing my touch, any suggestions? I'm assuming this is capacitive, be nice if this had a mouse drive option.
Thanks,
Rob
-
It has...
Just plug in and see.
-
Thanks Martin.
I did try, I find some mice don't work with every scope, I'll play with it.
-
I find it works much better if you use good batteries!
Still it would be nice if the screen was more touch sensitive.
-
Maybe a stylus could help ?
Like I´ve said in another thread, 7" touchscreen is on the edge when using your fingers for it.
-
The stylus I bought years ago for an iPad nano works well on the 914S.
-
I just bought 10 for ~$7 on Amazon.
-
+1 for stylus control. Much faster than a mouse.
The need for a stylus is because finger-touch doesn't work as well, or because a stylus is simply easier to use than touch?
-
+1 for stylus - much faster than a mouse.
Save the USB port for WiFi.
-
+1 for stylus - much faster than a mouse.
Save the USB port for WiFi.
You did not answer my question, although it could be you were not trying to do so. I am talking about finger touches on the LCD screen of the scope. I am not talking about a mouse.
So to be more specific in my questioning...
Your reasons for using a Stylus (while TOTALLY IGNORING a mouse) are what?
Why is a stylus better than touch when it comes to manipulating the DHO804 via its LCD?
Thanks.
-
Your reasons for using a Stylus (while TOTALLY IGNORING a mouse) are what?
Why is a stylus better than touch when it comes to manipulating the DHO804 via its LCD?
Stylus is much faster than dragging a mouse around a table and doesn't take up any bench space.
Stylus is more ergonomic than a finger on a vertical surface.
They only cost $1 or so, why not give one a try...?
-
Your reasons for using a Stylus (while TOTALLY IGNORING a mouse) are what?
Why is a stylus better than touch when it comes to manipulating the DHO804 via its LCD?
Stylus is much faster than dragging a mouse around a table and doesn't take up any bench space.
Stylus is more ergonomic than a finger on a vertical surface.
They only cost $1 or so, why not give one a try...?
I would add one more reason to your great list: NO FINGERPRINTS ON THE LCD!
-
I can't speak to the DHO800/900 but my DHO1074 is quite sensitive to touch. No problems at all getting it to respond. Perhaps it has a better sensor for it's larger screen.
That said, I do keep a stylus handy mainly for the fingerprint issue.
My bench is cluttered enough as it is, I can't imagine trying to wrangle a mouse on it.
-
That's why I love these small footprint instruments, I'll bet all our benches are overcrowded! I always crack up when I see a manufacturer showing a bench with a meter and a scope on it... yeah right!
I do think a stylus might be the way to go, this will resolve the problem handily. By the way I'm left handed and I think the scope's small screen might work better with right handed people, from preliminary tests it looks that way to me, my right hand seems to be more responsive.
-
I'm left handed and I think the scope's small screen might work better with right handed people, from preliminary tests it looks that way to me, my right hand seems to be more responsive.
It seems unlikely that there is an actual difference in the way the screen responds to either hand. Maybe your right-hand movements are not quite as fluid, so you touch the screen a bit longer or with more pronounced pressure?
-
Not sure, you may be right but I tried every possible touch scheme and then I was watching a YT video and the guy changed parameters that I had a real problem changing until I did them with my right hand!
-
I find that many touchscreen UX problems have more to do with hand-eye alignment than with actual calibration or sensitivity of the touchscreen. This is true for cell phones, tablets, or bigger screens. The smaller the screen, the more acute the problem. We tend to have more fine grained control of our dominant hands and so tend to hit the intended target easier, and be more aware of where our touch is actually landing, than we might be with our non-dominant hand.
These days the vast majority of our touchscreen experience is with a handheld mobile device that we're looking down on and is presented at some angle to the body. Whereas a scope is presented in a perpendicular orientation away from our body, that we have to reach for. It makes logical sense to me that this less-familiar awkwardness combined with the small-ish screen of the DH800/900 screen could challenge a new user trying to use their non-dominant hand. I expect just like with texting on a tiny cellphone keyboard, you get better with practice.
-
Received a new scope from China today, firmware was 00.01.02 from factory. Build date: 2023/11/09
-
Received a new scope from China today, firmware was 00.01.02 from factory. Build date: 2023/11/09
I suspect new inventory is hitting china sellers faster than elsewhere, and the new ink-barely-dried items all come with the 01.02 firmware.
SOme have suggested some new parts inside due to supply chain, and as such calibration code is different, hence newer 01.02 code. That's what I gather from the forums.
-
I find that many touchscreen UX problems have more to do with hand-eye alignment than with actual calibration or sensitivity of the touchscreen. This is true for cell phones, tablets, or bigger screens. The smaller the screen, the more acute the problem. We tend to have more fine grained control of our dominant hands and so tend to hit the intended target easier, and be more aware of where our touch is actually landing, than we might be with our non-dominant hand.
These days the vast majority of our touchscreen experience is with a handheld mobile device that we're looking down on and is presented at some angle to the body. Whereas a scope is presented in a perpendicular orientation away from our body, that we have to reach for. It makes logical sense to me that this less-familiar awkwardness combined with the small-ish screen of the DH800/900 screen could challenge a new user trying to use their non-dominant hand. I expect just like with texting on a tiny cellphone keyboard, you get better with practice.
What suggestions for capacitive stylus that work on the Rigol screens? Am-zon has so many. I touched my new Rigol like only 10x and it's got smudge marks all over it now.
Also wondering about the screen protectors, there's some on Am-zon selling specific cut to the DHO800 screen size.
-
Any old cheap $2 stylus with the rubber dome tip should work fine. I have a variety of them in a drawer and just grabbed one. You're not going to be writing or doing complex gestures like you would on a tablet/computer, so you don't need anything fancy.
Screen protectors couldn't hurt if you're super anal about it, but I don't use them on fixed equipment. Mobile devices? Always, because they're handled more roughly and transported everywhere, so the risk of scratching and impact damage is much greater.
-
Any old cheap $2 stylus with the rubber dome tip should work fine. I have a variety of them in a drawer and just grabbed one. You're not going to be writing or doing complex gestures like you would on a tablet/computer, so you don't need anything fancy.
Screen protectors couldn't hurt if you're super anal about it, but I don't use them on fixed equipment. Mobile devices? Always, because they're handled more roughly and transported everywhere, so the risk of scratching and impact damage is much greater.
I have couple soft rubber dome stylus pens, none worked on the Rigol screen, at least not for me.
-
Received a new scope from China today, firmware was 00.01.02 from factory. Build date: 2023/11/09
My 924S came from Saelig through Amazon 12/08/23 and it has 00.01.01, don't know the build date.
-
Received a new scope from China today, firmware was 00.01.02 from factory. Build date: 2023/11/09
My 924S came from Saelig through Amazon 12/08/23 and it has 00.01.01, don't know the build date.
What date is listed when you list firmware in menu?
Do Rigol units have an actual MFD date on them? Mine only has a serial sticker. I guess maybe Rigol support can tell you MFD date by serial?
-
I have couple soft rubber dome stylus pens, none worked on the Rigol screen, at least not for me.
Hmm, that's odd. When I get home I'll confirm which stylus I tried. I've collected a variety over the years, from the cheapest to somewhat pricey Bamboo and other higher end stylii. I'll try a few different ones tonight and report back the results.
-
Randy,
09/20/23.
Do you have the 800? Maybe they sell more of them so the dates are later?
-
I have couple soft rubber dome stylus pens, none worked on the Rigol screen, at least not for me.
Hmm, that's odd. When I get home I'll confirm which stylus I tried. I've collected a variety over the years, from the cheapest to somewhat pricey Bamboo and other higher end stylii. I'll try a few different ones tonight and report back the results.
I grabbed several styluses (styli?) from the drawer to try. Every single one worked great on the DHO1074 screen. I couldn't imagine why they wouldn't work exactly the same on the DHO800/900?
(https://www.morrisonline.us/images/IMG_8021_1.jpg)
-
My 924S works fine with everything.
pen with rubber dome tip, active pen, also with my finger.
it has a layer of display protection film, it is non-reflective.
-
My 924S works fine with everything.
pen with rubber dome tip, active pen, also with my finger.
it has a layer of display protection film, it is non-reflective.
I have some of that non-reflective film but I was concerned if I didn't like it my screen would be damaged trying to remove it. I bought it for my RTB2004 but never used it there either.
-
I don't understand what kind of damage you mean, it's true that it's not scratch-resistant gorilla glass and so on, but if you remove the soft screen protector, it shouldn't be damaged.
at least I didn't scratch the glass with my fingernail.
I tested several types on my large touch screen monitor, I put smaller pieces next to each other to see how much it distorts and reflects the light.
There was a small piece that was almost in the middle of the screen, and I didn't scratch it when I took it off.
-
Do these films have an adhesive or do they just cling to the monitor? I'm thinking the one on my cell which is basically fused to the screen.
-
Do these films have an adhesive or do they just cling to the monitor? I'm thinking the one on my cell which is basically fused to the screen.
They all just cling.
I can't imagine what kind of screen protector you have on your phone that is "fused." I've used dozens of screen protectors on dozens of devices over the years, from soft ones to tempered glass ones, and I've never seen or heard of one adhering to the screen beyond just a static cling. Just get up under one corner and it should peel off easily.
-
I made a mistake with my phone when I bought it, the screen protector was put on by the seller and not removable. I won't do that again! That's why I thought maybe screen protectors had an adhesive back, good to know they don't.
-
Do these films have an adhesive or do they just cling to the monitor? I'm thinking the one on my cell which is basically fused to the screen.
They all just cling.
I can't imagine what kind of screen protector you have on your phone that is "fused." I've used dozens of screen protectors on dozens of devices over the years, from soft ones to tempered glass ones, and I've never seen or heard of one adhering to the screen beyond just a static cling. Just get up under one corner and it should peel off easily.
The glass ones I put on cell phone do have a sticky back, it won't just peel off, but you can warm it with hairdryer and then carefully pry off using plastic wedge like credit card corner.
If I did one for the 800 I would get a glass one, install it and never remove it.
-
Randy,
09/20/23.
Do you have the 800? Maybe they sell more of them so the dates are later?
I did buy 804 model from Alix vendor.
The units from that vendor are very new, perhaps drop-shipped from Rigol china, you can still smell the outgassing of the plastic and stuff, ink-barely-dried, etc. (metaphorically speaking, but fresh off assembly line it seems)
Came with the .02 firmware, a Liteon UK style plug with US style adapter.
-
Also a peeve: When you take a snapshot could it be in lossless PNG format instead of JPG to preserve detail?
+1
Workarounds in the meantime: my Python script (https://sven.killig.de/scope/RigolScreenshot.py) or the screenshot function in Android Studio or
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5228832/#msg5228832 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5228832/#msg5228832)
-
Sort of crossposting, but it's in a thread about the DHO1000 and it fails with my DHO804 (firmware 00.01.02), too;
Video sync, be it NTSC or PAL/SECAM, doesn't seem to work at all:
https://www.eevblog.com/forum/testgear/new-rigol-hdo1000-12-bit-dso-bugs/msg5188338/#msg5188338 (https://www.eevblog.com/forum/testgear/new-rigol-hdo1000-12-bit-dso-bugs/msg5188338/#msg5188338)
This makes me a bit nervous, since this bug seems to be unresolved since more than a year...
-
+1
Workaround in the meantime: screenshot function in Android Studio
I have the "Quick" button set to screenshot and I access the files via FTP.
-
The glass ones I put on cell phone do have a sticky back, it won't just peel off, but you can warm it with hairdryer and then carefully pry off using plastic wedge like credit card corner.
If I did one for the 800 I would get a glass one, install it and never remove it.
That's interesting. I don't think I've ever heard of such a "permanent" glass protector.
I have bought and installed many tempered glass protectors for all of our cellphones and tablets. My wife breaks her glass screen protectors several times a year, so I've installed at least a dozen on her devices alone. Not once have I bought one that used an actual adhesive beyond just the coating that causes it to cling.
-
The glass ones I put on cell phone do have a sticky back, it won't just peel off, but you can warm it with hairdryer and then carefully pry off using plastic wedge like credit card corner.
If I did one for the 800 I would get a glass one, install it and never remove it.
That's interesting. I don't think I've ever heard of such a "permanent" glass protector.
I have bought and installed many tempered glass protectors for all of our cellphones and tablets. My wife breaks her glass screen protectors several times a year, so I've installed at least a dozen on her devices alone. Not once have I bought one that used an actual adhesive beyond just the coating that causes it to cling.
I have packs of Mr Shield glass in front of me, they don't cling like a vinyl protector does, they have a sticky back, not unlike a PostIT, and it will stick on real good, can't just peel it off like a vinyl cling. Yes, the glass will peel off, it's not crazy glue backed, but also not too easy to just peel off. The Apple protector you buy in Apple store, is super sticky, if it needs replacing they often have to break off small pieces as they pry, it won't just peel up and off.
-
I have a feeling we're talking about the same thing. You or someone mentioned "fused" to the glass and requiring hot air to remove. The "post-it" type coating is what I'm talking about, but I'd barely call it adhesive. Very mildly sticky, sure. It's not hard at all to peel once you get a corner up, and if you can manage to not break it or get dust or fingerprints under it, it'll go right back down and stick again.
Like I said, I have to replace my wife's and some of the kids/grandkids quite often. Never had any trouble getting one off.
-
IF you know that yours cannot be taken off, then don't use it.
Buy something you can take off instead.
Or buy another one that you can take off and put on two layers.
Put the permanent on the bottom and then the removable film on top...
-
I have a feeling we're talking about the same thing. You or someone mentioned "fused" to the glass and requiring hot air to remove. The "post-it" type coating is what I'm talking about, but I'd barely call it adhesive. Very mildly sticky, sure. It's not hard at all to peel once you get a corner up, and if you can manage to not break it or get dust or fingerprints under it, it'll go right back down and stick again.
Like I said, I have to replace my wife's and some of the kids/grandkids quite often. Never had any trouble getting one off.
I not say "fused", but I did say warming the glass helps to remove it, as that makes the sticky stuff a bit more pliable and easier to lift off. Heating some and prying/wedging is the procedure Apple uses in the stores. But duly noted, the high-end phone stuff usually has a glass screen. The Rigol appears to have a plastic screen, so not sure using a sticky glass protector is best option, albeit I guess if I use a glass one it will probably just be on for life of the unit.
-
For Apple device repair you do need hot air, but that's to remove the screen from the digitizer as they're glued together.
At any rate, I think we've beaten this horse enough. :horse:
-
I have a feeling we're talking about the same thing. You or someone mentioned "fused" to the glass and requiring hot air to remove. The "post-it" type coating is what I'm talking about, but I'd barely call it adhesive. Very mildly sticky, sure. It's not hard at all to peel once you get a corner up, and if you can manage to not break it or get dust or fingerprints under it, it'll go right back down and stick again.
Like I said, I have to replace my wife's and some of the kids/grandkids quite often. Never had any trouble getting one off.
I not say "fused", but I did say warming the glass helps to remove it, as that makes the sticky stuff a bit more pliable and easier to lift off. Heating some and prying/wedging is the procedure Apple uses in the stores. But duly noted, the high-end phone stuff usually has a glass screen. The Rigol appears to have a plastic screen, so not sure using a sticky glass protector is best option, albeit I guess if I use a glass one it will probably just be on for life of the unit.
Randy, I think the Rigol has a glass screen, my 924s does.
-
If we ever had any hopes of Rigol following this thread to learn about bugs so they can fix them -- I think they are long gone, both Rigol and the hopes. Sorry gentlemen, but this thread is a total mess.
As requested, this a thread for posting of and discussion of bugs on the Rigol DHO800/900 Oscilloscope, and firmware updates.
No other discussion please, there are other threads for that:
-
mea culpa.
Can we talk about the difference between .01.02 and .01.01 firmware?
If we can are there any bugs fixed by .01.02?
(ps: my junk stylus 10 for six bucks from Amazon work) ;D
-
As requested, this a thread for posting of and discussion of bugs on the Rigol DHO800/900 Oscilloscope, and firmware updates.
No other discussion please, there are other threads for that:
On the hope that Rigol people follow these threads: Rigol, please fix reported bugs and add basic capabilities to your software. For example, take the feedback and add averaging, good markers, etc. to your FFT, to be at par or better, and easily compete with other similarly priced 8-bit scopes, which at that point would be limited by differences in hardware. Also please coordinate and fix your firmware release process. Be consistent across your portals, and be complete (even verbose) on your release notes.
-
are there any bugs fixed by .01.02?
Release notes have been posted many times.
Short answer: "None that have been mentioned in this thread".
-
are there any bugs fixed by .01.02?
Not a bug fix per se, but 924 vendor.bin on 804 has no offsets (with "shareable" 804 calibration), good (1-Ch.) peak rise time (1.35 ns), and low noise floor. Not bad for a 12-bit $400 scope...
Edit: Replaced noise floor pic.
-
Pretty amazing!
-
good (1-Ch.) peak rise time (1.35 ns)
1.25 Gs/s means one sample per 0.8 ns. 1.6 ns gives us two samples. Adding interpolation into account, this can be +- 50% of that. Maybe average acquisition method will be more precise to see more real rise time.
low noise floor
Yeah... on unconnected probes. Mine DHO924S (real DHO924S, not hacked one) is very sensitive to common mode from pulse power supply - in my case 15 mVpp. Im thinking about making linear power supply, to get rid of that spikes. Maybe also better probes...
-
I didn't think the probes were that bad, not Tek but easily just as good as my RTB2004 which didn't hold up - these might, they look stronger to me.
-
Just received the DHO924S. Had a vintage Kenwood amp going through restoration. Thought I would do the calibration with the new scope and it’s AFG. Amp requires a 1Khz@1V signal to set the power meters. Set the scope up, connected to the input, and power meters were way to low and could not be adjusted high enough. Hooked the AFG output to my Leader voltmeter and the output is only .343V and not at all stable. I was able to get the scope to output 1V by upping the volts to 2.85. Not quite what I had in mind when I ordered this scope. I sent this to Rigol tech support and waiting for a response. This scope has too many issues to come with a “Calibration” certificate. If no response I’ll have to figure out the RMA process. It’s such a simple, basic setting that doesn’t work. My iPhone with a function generator app puts out a constant 1Khz@1V signal, but it costs $300 more than the scope.
-
Just received the DHO924S. Had a vintage Kenwood amp going through restoration. Thought I would do the calibration with the new scope and it’s AFG. Amp requires a 1Khz@1V signal to set the power meters. Set the scope up, connected to the input, and power meters were way to low and could not be adjusted high enough. Hooked the AFG output to my Leader voltmeter and the output is only .343V and not at all stable. I was able to get the scope to output 1V by upping the volts to 2.85. Not quite what I had in mind when I ordered this scope.
Looks reasonable. The AWG outputs an amplitude (Rigol means peak-to-peak) of 1V, that is 0.35V RMS. If you need 1Vrms then you have to increase the amplitude to 2.83V, which is exactly what you did. The output should be stable though.
-
Not quite what I had in mind when I ordered this scope.
My iPhone with a function generator app puts out a constant 1Khz@1V signal, but it costs $300 more than the scope.
Also 924S.
It seems good to me.
-
Amp requires a 1Khz@1V signal to set the power meters.
RMS or peak to peak?
-
He's looking at RMS.
I didn't see any problems with the AWG, I did some Bode plots and FFT's and it was fine. Check the connector.
-
Somewhere in the amplifier manual it should specify if it requires RMS or peak to peak.
-
Also 924S.
It seems good to me.
can you do me a favor to show low level performance of the AFG, specifically at 100kHz 20mV (pp) at 10mV/div scope setting?
-
Right in the AWG if you pick an amplitude the screen pops up and you can choose Vpp, RMS, etc. so even if the amp doesn't specify it you'll see it right away.
Newbie problem, I'm sure we all made it at some point, that's how we learn.
-
can you do me a favor to show low level performance of the AFG, specifically at 100kHz 20mV (pp) at 10mV/div scope setting?
after a few minutes of heating.
With and without a 20Mhz limit.
after warming up, the measured voltage decreased by 0.5 mV.
That is, the average: 22.543mV
Dev: 320uV
-
Newbie problem, I'm sure we all made it at some point, that's how we learn.
That's what I thought. But most of us learn before we write a complaint to the manufacturer, write a scathing forum post, and threaten to return the product. ;)
-
I repeated the above request, a little longer.
I checked its own AWG at 100kHz and 20mVpp with three power supplies.
Powerbank Allpowers USB-c output is 15V.
Its own LiteON power supply.
A Chinese 12V linear power supply built for audio purposes.
LiteON and Linear power supplies have infinite persistence.
That's why the wave got thicker.
+ When I insert the Pendrive, there will be a small error at the low voltage signal.
After attaching the data storage, the error was still visible occasionally.
I could only try it with its own generator, the other one is very noisy for me at low voltage.
Using a USB-HUB, I don't know if the error is permanent or if it interferes with creating a Bode Plot.
I don't have everything to properly test it.
Or it's just me that has this error.
https://www.youtube.com/watch?v=suF7fzhdYy4 (https://www.youtube.com/watch?v=suF7fzhdYy4)
-
Using a USB-HUB, I don't know if the error is permanent or if it interferes with creating a Bode Plot.
I don't have everything to properly test it.
that signal should be good enough, you dont bode plot with such low level input signal, the output will be invisible to the scope anyway hence you'll get randomized bode plot. unless you want to test high gain amplifier, but then, dont plug the USB in when you do that. problem solved.
-
Using a USB-HUB, I don't know if the error is permanent or if it interferes with creating a Bode Plot.
I don't have everything to properly test it.
that signal should be good enough, you dont bode plot with such low level input signal, the output will be invisible to the scope anyway hence you'll get randomized bode plot. unless you want to test high gain amplifier, but then, dont plug the USB in when you do that. problem solved.
I have no idea what are you talking about. You use signal you need. If you cannot do bode with 20mV signal something is wrong.
It is not problem solved. It is digging head in a sand.
What high gain amplifier? What is high gain to you? 10x?
Why would USB device influence work of a scope?
So you solution to something not working properly is "don't use it so you don't have problem" ?
-
I don't think it's a real case of making a Bode Plot with a 20 mV signal and plugging something in and out of the USB port.
My Micsig scope also has such a problem that when I measure one of my battery chargers with it, which regenerates a 12V battery in repair mode, the touch screen goes crazy.
The error occurs with both Micsigs, but it doesn't bother me.
-
I have no idea what are you talking about. You use signal you need. If you cannot do bode with 20mV signal something is wrong.
did you miss the new year fun? is that why you are having bad days? try to be more competent next time ;) cheers.
-
Have you managed to load an arbitrary waveform? If yes can you share an example file?
I spent way to much time with trial and error, because the documentation is a bit thin.
-
Also 924S.
It seems good to me.
can you do me a favor to show low level performance of the AFG, specifically at 100kHz 20mV (pp) at 10mV/div scope setting?
Some time ago I did small research with mine 924S. Looks like it handles output level just with lowering digital signal sent to DAC instead of variable gain amplifier, relays or anything like that.
On lowest levels I saw more noise than signal.
Bad for Rigol, they didnt told about this nowhere :-[
My idea is to make some simple device with opamp (buffer), switches and potentiometer to set desired level and to have BNCs at front.
-
Some time ago I did small research with mine 924S. Looks like it handles output level just with lowering digital signal sent to DAC instead of variable gain amplifier, relays or anything like that.
On lowest levels I saw more noise than signal.
Bad for Rigol, they didnt told about this nowhere :-[
digital signal are the same, the gain is set by feeding AD9744's FS_ADJ pin and some combination of mechanical relays... to get this signal we need to install 2x ssop8 dual opamp onto DHO800 board (its already there on DHO900 board)
My idea is to make some simple device with opamp (buffer), switches and potentiometer to set desired level and to have BNCs at front.
i did some diy FG years ago using potentiometer, https://www.eevblog.com/forum/projects/ad9850-module-and-dds3x25-dds-based-fg-compared (https://www.eevblog.com/forum/projects/ad9850-module-and-dds3x25-dds-based-fg-compared) its a bit "touchy", slight movement to potentiometer will get noises, glitches on the output, its ok for your "low tech / hardcore" purpose. but i dont use it anymore since i bought UTG-962. i learnt a lot about AFG circuitry from UTG-962, there are some similarities and differences compared to DHO900S module posted in this forum.
-
I have couple soft rubber dome stylus pens, none worked on the Rigol screen, at least not for me.
Hmm, that's odd. When I get home I'll confirm which stylus I tried. I've collected a variety over the years, from the cheapest to somewhat pricey Bamboo and other higher end stylii. I'll try a few different ones tonight and report back the results.
I grabbed several styluses (styli?) from the drawer to try. Every single one worked great on the DHO1074 screen. I couldn't imagine why they wouldn't work exactly the same on the DHO800/900?
(https://www.morrisonline.us/images/IMG_8021_1.jpg)
I obtained a double-end rubber pad stylus, works ok with some pressure, but can be non-accurate when selecting boxes that are small and close together.
I then got an active stylus, works amazingly well, no BT needed, accurate selections and I don't need to contact screen very hard at all.
https://www.amazon.co.uk/Rechargeable-Magnetic-Universal-Smartphone-Device-Black-Black/dp/B0BZKFT697 (https://www.amazon.co.uk/Rechargeable-Magnetic-Universal-Smartphone-Device-Black-Black/dp/B0BZKFT697)
-
Every stylus pen I tried worked. I know this is obvious but is your screen locked?
-
Every stylus pen I tried worked. I know this is obvious but is your screen locked?
Your Q to me?
I had another rubber ended stylus, it did not work on the 804. I got anoter rubber end stylus, it works, but not very elegantly. The active pen stylus I listed works very well.
-
Perhaps not a bug, but definitely some odd logic.
When you go into the Measure menu, why are all the non-selected items turned "on", meaning the icons for non-selected items are highlighted "lit up". That's kinda bad logic. When you select an item, that's when the icon should turn "on".
-
I use the DHO924S's own AWG, with a 20mV signal.
two channels are active CH1 and CH3, the AWG is connected to CH3 (5mV/div), the other is empty.
When I adjust the CH1 voltage scale, between 50mV and 100mV, the signal visibly and measurably shifts by -2mV.
When tested with the other channels, they do not relate to each other in the same way.
In my case, for example, if the signal is on CH3, by adjusting CH1 or CH2, it goes down by 2-3mV, but CH4 does not suppress CH3 as much.
Red REF is when CH1 is active and set to 100mV/div.
-
When I adjust the CH1 voltage scale, between 50mV and 100mV, the signal visibly and measurably shifts by -2mV.
What firmware is that?
Try the latest one:
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5272446/#msg5272446 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5272446/#msg5272446)
-
What firmware is that?
00.01.02.00.02
I updated the last firmware today, then calibrated it after 1 hour of heating.
It happens on all four channels.
I checked the AWG signal with another oscilloscope (Micsig) and when I changed the vertical sensitivity on the Rigol's active channel, the AWG signal shifted.
I don't know if anyone else has noticed this or if it's just me.
I don't remember if anyone mentioned it.
I have not tried with older firmware.
-
I can reproduce the problem.
Setup is a bit jank for some reason the noise is terrible even with BW limit.
I think this is an ARB issue. Because feeding on any other channel and changing CH1 does the same thing.
Reduced freq to 1khz. Measuring with a multimeter changing ch1 does affect output offset. 20mv signal 10mv offset Not termintated with 50ohm, only multimeter connected.
Terminating into an attenuator produces the same thing.
Also latest fw. 00.01.02 build 24/01/03
It is not because of the relay current, because changes even when the relay is not clicking.
Also for the life of me cant upload an arb waveform. Support is silent.
-
Outputting DC from arb. Same thing. Hopefully copy paste problem with calibration, and not hw.
-
Since I don't know I have to ask.
When doing FW upgrade, does it replace FFT cal file? I do assume any edits I have done to Rigol files would be replaced from files that come from the new FW gel upgrade?
-
Since I don't know I have to ask.
When doing FW upgrade, does it replace FFT cal file? I do assume any edits I have done to Rigol files would be replaced from files that come from the new FW gel upgrade?
When updating the firmware from 00.01.01.xx.xx to 00.01.02.xx.xx, the calibration files change, yes. More precisely, one of the files changes - cal_vertical.hex. When updating the firmware from 00.01.02.00.00 to 00.01.02.00.02, the calibration files do not change.
-
00.01.02.00.02
I updated the last firmware today, then calibrated it after 1 hour of heating.
It happens on all four channels.
I checked the AWG signal with another oscilloscope (Micsig) and when I changed the vertical sensitivity on the Rigol's active channel, the AWG signal shifted.
I don't know if anyone else has noticed this or if it's just me.
I don't remember if anyone mentioned it.
I have not tried with older firmware.
Yes, there is something strange with the offsets on the latest firmware 00.01.02.00.02. I don’t know if this was the same on older firmwares. The offsets change when you switch the vertical scale, they change when you turn on/off the 20 MHz band limit... And the offsets are different on different channels, for me this is most visible on channel 4. I'll now try to record a video demonstrating this.
-
https://www.youtube.com/watch?v=RNsjt8UL9ZI (https://www.youtube.com/watch?v=RNsjt8UL9ZI)
-
I think you need a termination on that channel.
-
I have no offset when I turn on the BW limit on its own channel.
I made a video to make it easier to understand.
After uploading it, I played with it a little more and noticed that if I change one of the following values, the AWG signal also slips or starts shaking.
When I change or turn on the "BW Limit", "Bias", "Offset" and "Scale" parameters of another channel.
https://www.youtube.com/watch?v=1dDnE5IYeH8 (https://www.youtube.com/watch?v=1dDnE5IYeH8)
-
I think you need a termination on that channel.
There is a 50 Ohm terminator there :)
-
Okay, thanks missed it.
-
The DHO800 manual says the Probes default to 1x, and I confirmed in the CH menus that is true. But why default to 1x? They ship with the mechanical switch set to 10x. And of course, most users will use the 10x setting much of the time anyway. So it would make sense if the Probe Ratio defaulted to 10x.
I also am not seeing many posts about this. I guess everyone is either silently changing their setting to 10x without posting about it, or DHO800 users are simply leaving it set to 1x, even though the mechanical switch is set to 10x.
-
The DHO800 manual says the Probes default to 1x, and I confirmed in the CH menus that is true. But why default to 1x? They ship with the mechanical switch set to 10x. And of course, most users will use the 10x setting much of the time anyway. So it would make sense if the Probe Ratio defaulted to 10x.
I also am not seeing many posts about this. I guess everyone is either silently changing their setting to 10x without posting about it, or DHO800 users are simply leaving it set to 1x, even though the mechanical switch is set to 10x.
As long as the scope remembers the settings when powered off, I don't see this as a problem. Having to change the probe settings during use is not uncommon -- not so much because you want to use the passive probes at 1x, but because you may want to use direct BNC cable connections to some signal source instead of the 10x probes sometimes. So it's not a big chore for the user to set up his preferred attenuation during the initial use.
Shipping the scope with 10x as the default setting would probably cause another problem: Users complaining that their new scope does not go down to 500 µV/div as advertised, but stops at 5 mV/div.
What I do find unfortunate is that the DHO scopes do not show the current probe setting in the channel info boxes. All other information is there (sensitivity, bandwidth, coupling etc.), but the probe attenuation factor is not displayed, and is actually a bit hidden, two dialogs away.
-
As long as the scope remembers the settings when powered off, I don't see this as a problem.
It does NOT remember the change to 10x when you power off and then on again. It resets to 1x, even if you do not press the AUTO button after restarting. Therefore, it is a problem that I would classify as a BUG. But more than that, it's a huge headache to have to manually change all 4 channels to 10x every time you power on the scope!
-
It does NOT remember the change to 10x when you power off and then on again. It resets to 1x, even if you do not press the AUTO button after restarting. Therefore, it is a problem that I would classify as a BUG. But more than that, it's a huge headache to have to manually change all 4 channels to 10x every time you power on the scope!
Have you set the power-on state to "Load last"? It's a switch in the Utility > Setup menu.
-
it's a huge headache to have to manually change all 4 channels to 10x every time you power on the scope!
What is "Utility->Setup->Load last" set to for you?
Default or Last?
-
I appreciate the excellent tip! Mine was set to Default. I changed it to Load Last, then changed all 4 probes to 10x, then restarted, and now I see it saves the 10x setting. Great! Thank you!
-
With 01.02.xx.xx FW, if you just have a channel w/o connection, or terminated, and you start to dial up the horizontal time base (more time across the window), do you come across a few selections where the "flat line" paints the whole bottom half of the screen?
That's what I get.
-
With 01.02.xx.xx FW, if you just have a channel w/o connection, or terminated, and you start to dial up the horizontal time base (more time across the window), do you come across a few selections where the "flat line" paints the whole bottom half of the screen?
That's what I get.
Hmm, I haven't encountered such a bug.
Maybe some specific conditions are needed for its appearance?
-
Hello all!
New bug found - first call for cursors after startup always show 100% cursor brightness. No matter what is set in display settings.
After opening Display menu - brightness become as it set, even if nothing changed.
DHO924 all firmware, including 0.1.2.0.2
-
Either more bugs coming out from 01.01, or a bunch news bugs created in 01.02
If they are new from 01.02, that's very frustrating.
The odd display offset seen on an open channel (or terminated) while changing vertical scale (volt) does not appear if I set channel BW(limit) to 20.
Disable the BW limit and that odd display offset is seen. Then at some point playing around with the channel BW limit from OFF to 20, the option for OFF went missing.
This is the odd painting I get, why would it paint the whole bottom half like this? I only changed time scale one click wider than +-100ms.
-
Bug: NTSC trigger is non-functional
On a DHO924S, the Video NTSC trigger is not working (i.e., displays random time points using Auto while Normal and Single never trigger). This is using firmware 00.01.01. Different composite NTSC signal sources have been attempted but the main one has been a Tektronix Pathfinder TSG 95 which generates a known good signal that other oscilloscopes, vectorscopes, and TVs are fine with. I have not experimented with other video formats such as PAL, 480p/60, etc.
I've experimented with different triggering settings. The first value for each setting is the value I used most frequently across different experiments.
- Polarity of Positive and Negative. The image for Positive shows a normal composite NTSC signal with a negative voltage sync pulse.
- Trigger level set to various voltages, though most online videos for other Rigol scopes show it is best to set the level to be in the sync pulse's voltage range
- Using with and without 75 Ohm termination. Using with termination shows the expected normal voltage ranges.
- Syncing on All Lines, Line, Odd, or Even
- Noise Reject off and on
- Using DC or AC coupling
- Set probe input to 1X and 10X (yeah, was getting desperate with trying different values)
- Confirmed that triggering set to CH1 where the signal was attached
I'm still willing to concede that the error could be occurring between the chair and the touchscreen, though it is looking unlikely.
Edit: Load Last is currently set to Default to avoid leaving the oscilloscope in a goofy state.
-
I use the DHO924S's own AWG, with a 20mV signal.
two channels are active CH1 and CH3, the AWG is connected to CH3 (5mV/div), the other is empty.
When I adjust the CH1 voltage scale, between 50mV and 100mV, the signal visibly and measurably shifts by -2mV.
When tested with the other channels, they do not relate to each other in the same way.
In my case, for example, if the signal is on CH3, by adjusting CH1 or CH2, it goes down by 2-3mV, but CH4 does not suppress CH3 as much.
Red REF is when CH1 is active and set to 100mV/div.
Might actually be related to this finding: https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5112108/#msg5112108 (https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5112108/#msg5112108)
My take on this is that the AWG module's high output level branch (THS3095) draws its power from (locally) unregulated rails. Since the analog frontends are pretty power intensive and the balance of this power may teeter between positive and negative rails, depending on the settings, the rails powering the AFE's local regulator(s) may very well fluctuate considerably. Rigol should have added local regulation to all AWG module supplies. Either greed, negligence or the lack of voltage headroom pushed them to do without those and voila.... At least, at low AWG level settings, the problem is absent.
-
Bug: NTSC trigger is non-functional
[...]
I'm still willing to concede that the error could be occurring between the chair and the touchscreen, though it is looking unlikely.
I don't think this is a user error. Problems with video triggering have been reported months ago for the DHO1000, https://www.eevblog.com/forum/testgear/new-rigol-hdo1000-12-bit-dso-bugs/msg5007853/#msg5007853 (https://www.eevblog.com/forum/testgear/new-rigol-hdo1000-12-bit-dso-bugs/msg5007853/#msg5007853), and then for the DHO800 as well, https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5223633/#msg5223633 (https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5223633/#msg5223633). Looks like Rigol has not been able to fix this yet?
-
Might actually be related to this finding: https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5112108/#msg5112108 (https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5112108/#msg5112108)
My take on this is that the AWG module's high output level branch (THS3095) draws its power from (locally) unregulated rails. Since the analog frontends are pretty power intensive and the balance of this power may teeter between positive and negative rails, depending on the settings, the rails powering the AFE's local regulator(s) may very well fluctuate considerably. Rigol should have added local regulation to all AWG module supplies. Either greed, negligence or the lack of voltage headroom pushed them to do without those and voila.... At least, at low AWG level settings, the problem is absent.
I'm afraid of that too.
I would still understand, but I would not accept that this event occurs with a higher load on the AWG, but I connected the AWG->CHx with a BNC-BNC cable without load, and only 20mVpp 100kHz...
With the latest firmware, I noticed a bug that I don't know how I managed to cause.
On the left side of the trigger menu, where you select slope, all three rings were empty for me, none of them were selected.
The settings were set well, the channel I was watching was selected, and the trigger was also set to the Edge type.
it was resolved by choosing one of the three.
Unfortunately, I didn't take a picture of it.
-
I appreciate the excellent tip! Mine was set to Default. I changed it to Load Last, then changed all 4 probes to 10x, then restarted, and now I see it saves the 10x setting. Great! Thank you!
The first version of firmware for the DHO800/900 I couldn't even figure out how to change the probe attenuation!
It's this is still not a great solution IMHO because you usually don't want the probe config changing on a "default" button press either, which is a very common use case.
On a scope with no readback, or supplied without readback probes, going to "default" (either from boot or by pressing the button) should either not touch the probe config or set it to 10X. ISTR the same applies to Rigol's MSO5000. The solution in that case was that I have my own default setup config, including probe settings, and I use this rather than the scope's default button. (Other things I like is to have as my "default" are the trigger point at 10%, expand around trigger, and a Ch1 rising edge trigger at 1.5V).
As a comparison, the DS1000Z are at 10X after a default button press.
Even the Tek TDS 2024B I have here defaults to 10X (I can't remember the last time I turned it on, it was many years ago, but the clock is only 6.5 minutes out: the plastic's starting to get brittle though).
The Siglent SDS1000X-E & SDS2000X+ have a better way of implementing this with the Default button using a user-defined default, although even after a factory reset the channels are at 10X.
I am wondering if it's in response to "customer feedback", with noobs getting confused: I could certainly see that happening.
-
As long as the scope remembers the settings when powered off, I don't see this as a problem.
It does NOT remember the change to 10x when you power off and then on again. It resets to 1x, even if you do not press the AUTO button after restarting. Therefore, it is a problem that I would classify as a BUG. But more than that, it's a huge headache to have to manually change all 4 channels to 10x every time you power on the scope!
I had same problem, but not anymore after firmware upgrade - sadly I dont remeber which one it was.
-
Bug: NTSC trigger is non-functional
[...]
I'm still willing to concede that the error could be occurring between the chair and the touchscreen, though it is looking unlikely.
I don't think this is a user error. Problems with video triggering have been reported months ago for the DHO1000, https://www.eevblog.com/forum/testgear/new-rigol-hdo1000-12-bit-dso-bugs/msg5007853/#msg5007853 (https://www.eevblog.com/forum/testgear/new-rigol-hdo1000-12-bit-dso-bugs/msg5007853/#msg5007853), and then for the DHO800 as well, https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5223633/#msg5223633 (https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5223633/#msg5223633). Looks like Rigol has not been able to fix this yet?
Good to know other folks have seen this as well, though mildly concerning the bug hasn't been addressed yet. I missed the earlier post when I skimmed though all 13 pages of this thread last yesterday.
-
Found strange behavior - enabling LA dividing sample rate by 2, even in slow sampling
I set 1ms/dev 100kpts - with 1 channel it's 6.25MSa/s with all 4 - the same 6.25MSa/s
On the same ms/dev starting LA trace with or without any number of analog channels resulting in 3.125MSa/s and real captured data become 2x of buffer related to analog input buffer with same settings.
Probable this behavior didn't allow to capture LA with max sample rate - 625MSa/s is max rate with LA.
DHO924 software 00.01.02.00.02
Steps to preproduce:
1) connect CH1 to 1kHz generator. Synchronize from CH1, set 100kpts, 1.00 ms/dev
DHO set sample rate to 6.25MSps/s
stop capturing.
max capture size is also halved to 25Mpts with LA enabled and still 25Mpts with LA+CH1
switch view to 2ms/s - waveform zoom-out and graph only shown from -8ms to +8ms right and left is empty
2) switch back to 1.00 ms/dev, enable LA,
start capturing - DHA show 3.125MSa/s
stop capturing.
switch view to 5ms/s - now graph is populated from -16ms to 16ms
-
Found strange behavior - enabling LA dividing sample rate by 2, even in slow sampling
Unfortunately this is how the DHO900 behaves, by design: Enabling the logic analyser takes away half of the 1.25 GSa/s bandwidth. So for the analog channels, you only get 625/312/156 MSa/s, depending on how many analog channels you have enabled, once the logic analyser is activated.
It is an unusual (and unfortunate) aspect of the DHO900 design that the sampling rate is not limited by the ADC, but rather by the downstream data handling. And the digital data apparently have to go through that same bottleneck.
And yes, Rigol "forgot" to mention that in the datasheet. Disappointing.
-
Is there any explanation for why the memory is halved if LA is active?
Aren't those two extra memory chips for LA?
-
Is there any explanation for why the memory is halved if LA is active?
Aren't those two extra memory chips for LA?
Nope. People have hacked DHO800 to enable the logic functions.
Those chips are a mystery...
-
I seem to be having a problem with the sensitivity of the touch screen not sensing my touch, any suggestions? I'm assuming this is capacitive, be nice if this had a mouse drive option.
I found that a mouse works with the DHO900, then afterward, I read that in the manual. So I bought a larger touchscreen, and plugged it into the HDMI port, and into the USB on the front panel. It works! But then I wondered whether I could use a USB 2.0 hub to also allow me to use a USB flash drive simultaneously. And, happily, that works too!
(if only the rest of the scope and logic analyzer worked as well)
-
Please check whether the SPI decoding works on logical channels with the latest firmware?
Previously, there were reports that SPI decoding only works on analog channels and doesn't work on digital ones.
-
Please check whether the SPI decoding works on logical channels with the latest firmware?
Previously, there were reports that SPI decoding only works on analog channels and doesn't work on digital ones.
That is absolutely the case on the DHO924 that I have on all firmware up to and including 1.02. Is there a newer version of firmware than 1.02 out there?
-
Please check whether the SPI decoding works on logical channels with the latest firmware?
Previously, there were reports that SPI decoding only works on analog channels and doesn't work on digital ones.
That is absolutely the case on the DHO924 that I have on all firmware up to and including 1.02. Is there a newer version of firmware than 1.02 out there?
Need to be more specifc on FW vers.
There's a few flavors of "1.02"
00.01.02.00.00
00.01.02.00.01
00.01.02.00.02
-
They sent me 1.02.00.02
-
SPI still not working correctly with LA channels in the latest 01.02.00.02 release. Below are the release notes for all of the versions.
[Model Supported] All the DHO800/900 series oscilloscopes
[Latest Revision Date] 2023/12/28
[Updated Contents]
v00.01.02.00.02 2023/12/28
1. Self calibration optimization update
2. Solve the problem that window transparency cannot load the last value
3. Solve the problem that the LA function cannot display the label after setting it
v00.01.02.00.01 2023/12/5
1. Self calibration optimization update
2. Solve edge jitter below 31kHz
v00.01.02.00.00 2023/11/2
1. Self calibration optimization update
2. Solve the problem of UltraLab startup connection failure
3. Solve the problem of failure to save waveform in wfm format
4. Solve the problem of unresponsive touch on startup screen
v00.01.01.00.02 2023/09/12
1. Self calibration optimization update
2. Update Help Documents
v00.01.01.00.01 2023/08/10
1. Remove all time-related displays on the instrument
2. To modify the vertical interface, click the wiring diagram to modify the AC coupling function
3. Modify the delayed scan Chinese display as Zoom
4. Modify the order of the menu in the upper right corner, put the measurement in the front and Default in the back
5. The probe ratio interface is removed, and the probe ratio option is added to the vertical first-level menu
v00.01.00.00.19 2023/07/24
1. The first version is released
-Released the production version.
-
Are you just drawing conclusions from this text? I read the release notes too, but the fact is that Rigol often corrects errors and does not mention them in the release notes. Therefore, it would be interesting if the PLA2016 and DHO900 owner to check it himself with the latest firmware 1.02.00.02
-
Hi guys,
where can you get hold of the latest version of the firmware ? The on on their website reads v00.01.01.00.01 in the release notes and my scope (DHO914S) came with version 00.01.02.
The logic Analyizer lable bug is driving me mad |O.
-
Hi guys,
where can you get hold of the latest version of the firmware ? The on on their website reads v00.01.01.00.01 in the release notes and my scope (DHO914S) came with version 00.01.02.
The logic Analyizer lable bug is driving me mad |O.
The links, and/or FW attached, are throughout the posts, in this thread (I think) and in the DHO800/900 hacking thread.
-
Dohhhh :-+ I must have been using an earlier 02 version ..... its finally fixed :-+ :-+ :-+ :-+ :-+ :-+ this was driving my OCD mental ... read the post about different 02 versions and the penny dropped
-
Bug: NTSC trigger is non-functional
[...]
I'm still willing to concede that the error could be occurring between the chair and the touchscreen, though it is looking unlikely.
I don't think this is a user error. Problems with video triggering have been reported months ago for the DHO1000, https://www.eevblog.com/forum/testgear/new-rigol-hdo1000-12-bit-dso-bugs/msg5007853/#msg5007853 (https://www.eevblog.com/forum/testgear/new-rigol-hdo1000-12-bit-dso-bugs/msg5007853/#msg5007853), and then for the DHO800 as well, https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5223633/#msg5223633 (https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5223633/#msg5223633). Looks like Rigol has not been able to fix this yet?
Good to know other folks have seen this as well, though mildly concerning the bug hasn't been addressed yet. I missed the earlier post when I skimmed though all 13 pages of this thread last yesterday.
If I my chime in as element between the chair and the touch screen. Trigger on analog TV-Signals on a DHO914 is not working. PAL here. It is not possible to trigger a clean, stable analog TV-Signal (from a digital source btw.) it works however, if you stop acquisition. But I prefer not to look at a single screenshot.
Most recent firmware, that I found on Rigols US-Server, because it it not available in Europe...
-
If I my chime in as element between the chair and the touch screen. Trigger on analog TV-Signals on a DHO914 is not working. PAL here. It is not possible to trigger a clean, stable analog TV-Signal (from a digital source btw.) it works however, if you stop acquisition. But I prefer not to look at a single screenshot.
Sounds like trigger delay might help with that. Give it a try.
-
it works however, if you stop acquisition. But I prefer not to look at a single screenshot.
Please explain what you meant? What needs to be done to make the trigger execute once?
PS. If you need "Video" sync, then you can use "Sync by N-th pulse". It works great!
-
it works however, if you stop acquisition. But I prefer not to look at a single screenshot.
Please explain what you meant? What needs to be done to make the trigger execute once?
PS. If you need "Video" sync, then you can use "Sync by N-th pulse". It works great!
If you stop acquisition, you get the "screenshot" of that moment, and a clear signal, not what you usually want to see from a continuous signal :bullshit:.
But: The Sync on Pulse 64Microseconds syncs on one line - question is which one... but it works somehow.
Triggering on Video (line) just looks like it tries to do it on at least two different lines, clearly failing to do that properly at the same time.
"Trigger delay" refers to two channels - which I do not have as a reference.
I do have the impression, that manually adjusting the Trigger in Video, that "knob" just does nothing, you never see the "T'D" - triggered - message, while in Sync on Pulse, you can adjust that.
It is not a very important function, but nevertheless strange, they obviously do not care at RIGOL.
-
It is not a very important function, but nevertheless strange, they obviously do not care at RIGOL.
Today, few people work with analog video signals. So there were probably few complaints to Rigol about this issue.
There are much more significant and serious errors in the firmware, but Rigol doesn’t care either :(
-
If you stop acquisition, you get the "screenshot" of that moment, and a clear signal
So it is basically working...
It is not a very important function, but nevertheless strange, they obviously do not care at RIGOL.
Today, few people work with analog video signals. So there were probably few complaints to Rigol about this issue.
And most of those people probably already have an oscilloscope that can do it.
-
I do have the impression, that manually adjusting the Trigger in Video, that "knob" just does nothing, you never see the "T'D" - triggered - message, while in Sync on Pulse, you can adjust that.
Just a thought: Do you have your probe attenuation set to 1x or 10x?
-
I do have the impression, that manually adjusting the Trigger in Video, that "knob" just does nothing, you never see the "T'D" - triggered - message, while in Sync on Pulse, you can adjust that.
Just a thought: Do you have your probe attenuation set to 1x or 10x?
I've already tried this. :) :) :) Unfortunately - NO. |O
-
If you stop acquisition, you get the "screenshot" of that moment, and a clear signal
So it is basically working...
It is not a very important function, but nevertheless strange, they obviously do not care at RIGOL.
Today, few people work with analog video signals. So there were probably few complaints to Rigol about this issue.
And most of those people probably already have an oscilloscope that can do it.
It is "basically" working, just like every watch, even with depleted battery, shows the correct time once a day...
The probe and setup is 10X, yes. It is just a bit stupid, because it is quite a basic thing to fix that.
As I am a proud potential member of the Therapy Gruoup here, I do have an alternative.
I just - you know... try Rigol :palm: :popcorn:
-
So it is basically working...
[...]
And most of those people probably already have an oscilloscope that can do it.
Yes, sure. Or one could naively assume that an advertised feature, and one which Rigol has managed to get right for the past 10 years, actually works. ::)
As it happens, I just had to check out the video signal from a vintage computer last week. Nice coincidence that the DS1054Z is back on my bench for now after the DHO1000 went back to Rigol. I would not have enjoyed dragging it out again just to take some measurements which the "new, improved, one class above" successor can't handle anymore.
In my book, a non-working trigger, combined with the ability to stop the acquisition manually at some random point in time, does not qualify as "basically working", by the way...
-
It is "basically" working, just like every watch, even with depleted battery, s
How can you call something that is completely broken: "basically working"? The Video trigger in the HDO series is completely non-working. What you wrote above doesn't require any synchronization. You can stop any oscillogram and study it. It doesn't require a trigger at all. Do not mislead people.
-
It is "basically" working, just like every watch, even with depleted battery, s
How can you call something that is completely broken: "basically working"? The Video trigger in the HDO series is completely non-working. What you wrote above doesn't require any synchronization. You can stop any oscillogram and study it. It doesn't require a trigger at all. Do not mislead people.
You might have missed the irony in axantas' post; please re-read it. It was Fungus in his earlier "it is basically working" post who was a bit too generous with Rigol.
-
Maybe. I have been working too much for the last two days :))))
-
Maybe. I have been working too much for the last two days :))))
Yes sometimes I tend to be a bit ironic.
-
It is "basically" working, just like every watch, even with depleted battery, shows the correct time once a day...
The probe and setup is 10X, yes. It is just a bit stupid, because it is quite a basic thing to fix that.
I mentioned it because the threshold voltage for serial decoders only works when probe attenuation is set to 1x.
(probe should be 10x for max bandwidth...)
-
It is "basically" working, just like every watch, even with depleted battery, s
How can you call something that is completely broken: "basically working"?
Somebody said it shows a frame correctly when you stop the 'scope.
This reminds me of a previous post where the scope always shows multiple traces overlaid when it's running and displays a single wave when stopped. Maybe this is the same, I don't know what you're actually seeing on screen.
What's "waveform freeze" set to in your display settings? Play around with that setting.
-
It is "basically" working, just like every watch, even with depleted battery, s
How can you call something that is completely broken: "basically working"?
Somebody said it shows a frame correctly when you stop the 'scope.
This reminds me of a previous post where the scope always shows multiple traces overlaid when it's running and displays a single wave when stopped. Maybe this is the same, I don't know what you're actually seeing on screen.
What's "waveform freeze" set to in your display settings? Play around with that setting.
This is a screenshot of a video I made this afternoon. If you "Stop" it, there is a clear signal, but the continuous Signal shows like that. Source is a PAL signal from a digital source (test pattern). Markers on both scopes are 64uS - single line. The spikes on the Siglent are just glitches in the Signal. The Rigol shows the correct signal as faint background and something, I did not identify yet in the proximity of this line.
[attachimg=1]
-
Hi everyone. I just read this entire thread before posting my observation. I have DHO804 with latest FW 00.01.02.00.02 from
https://download.rigol.com/cn/Firmware/Digital%20Oscilloscope/DHO800%26DHO900/DHO800_DHO900(Software)Updatev00.01.02.00.02.zip
I found that scope has several issues I found. My list is below.
When I set scope to remember last settings after reboot, this settings is not saved properly:
1a.) Trigger mode is always "Auto" after reboot (I using normal mode most of the time and I have to set it all the time after reboot)
1b.) Scope can't remember selected memory depth if it's more than 1Mpts. If I set 10, or 25Mpts for example. It always returns to 1Mpts
1c.) Utility>setup>fine/zoom button returns to 'fine' if I select 'zoom'
1d.) Utility>IO>Host Name cannot be changed. When I delete original Host Name to just RIGOL and press 'Apply', it always return to default long name with sn.
2.) When I save the setup to stp file and load it, it loads fine (even selected memory depth), but again, trigger mode 'Normal' is not. It's always Auto.
3.) When I hit 'default' and then time base is set to 2s (roll mode), vertical is set to 1mV/div, set memory depth to 25Mpts, input some data (I touched CH1 by hand) and fill whole screen. Then hit 'run/stop' to stop the screen, zoom horizontal time base to maximum and try to move waveform left or right (does not matter if by touch, or by rotary encoder). Waveform weirdly jumps back and forth. Overall it moves to desired side, but with small jumps with backward direction.
This was my findings as BUGs. And next is suggestions to improve user experience:
|>User should change trigger mode by dedicated trigger button. For example. When user press dedicated trigger button, trigger settings is displayed. Then by trigger button user should change mode and then by long pressing (for example for more than 500ms) the trigger window exits.
|>From Rigol 1054z I have, the dotted mode of display I personally miss. There is only Vector waveform display mode.
|>In Storage>Save, word 'Overlay' should be renamed to 'Overwrite' for better description of what will happen.
|>In Storage>Load setup, it would be nice if it was be enough to just select saved setup by tapping anywhere in the line where file name is instead of just end of line where select circle is.
|>In small on screen keyboard is displayed, there is delete button. That button should delete whole text before when user use long pres that delete button.
|>Dedicated button 'Default' should load default.stp from system, where user can save its own setup. True factory default can be loaded somewhere from system menu.
|>Full/half/none is options to display grid. But I miss the square looking grid instead of what it looks like in 'full' where one div is rectangle looking one.
I hope that this findings will be well considered. My mind is still blown from earlier model 1054z which is stunning product. Well done Rigol. Thank you very much.
-
This is a screenshot of a video I made this afternoon. If you "Stop" it, there is a clear signal, but the continuous Signal shows like that. Source is a PAL signal from a digital source (test pattern). Markers on both scopes are 64uS - single line. The spikes on the Siglent are just glitches in the Signal. The Rigol shows the correct signal as faint background and something, I did not identify yet in the proximity of this line.
How are you connecting it to the 'scope? Are you using a 50 Ohm terminator?
-
Good new: created a CSV file that the AWG can load!
I generated a number of CSV files intended for other Rigol AWG models, I found 1 that the DHO924S can load. Short version is that it can handle CSV files intended for a DG1022Z that use 8192 points in Frequency mode. Attempts to use CSV files using Sample/s mode or a different number of points failed, as did attempts to use various other Rigol AWG CSV files. The testing was not exhaustive so the various test CSV file are attached for folks to checkout and/or study. Hope this helps folks.
Hardware tested on: DHO924S with v00.01.02.00.02 firmware.
-
This is a screenshot of a video I made this afternoon. If you "Stop" it, there is a clear signal, but the continuous Signal shows like that. Source is a PAL signal from a digital source (test pattern). Markers on both scopes are 64uS - single line. The spikes on the Siglent are just glitches in the Signal. The Rigol shows the correct signal as faint background and something, I did not identify yet in the proximity of this line.
How are you connecting it to the 'scope? Are you using a 50 Ohm terminator?
FYI: Most NTSC and PAL video drivers are designed to drive 75\$\Omega\$, and it still doesn't work correctly if it's 75 Ohm terminated.
-
FYI: Most NTSC and PAL video drivers are designed to drive 75\$\Omega\$, and it still doesn't work correctly if it's 75 Ohm terminated.
Just asking because it looked like a ghost signal in the line.
Set your trigger holdoff to 12ms and see what happens.
-
Set your trigger holdoff to 12ms and see what happens.
This is not how video triggering is supposed to work. You want the ability to trigger on (a) any frame (vertical sync), (b) odd or even frames only, (c) any line (horizontal sync), (d) line #xx in each frame.
A holdoff time alone won't get you any of this. You need a combination of sync pulse duration, levels, and pulse counting, made more complex by the fact that inverted line syncs are sent during the vertical sync time. You can "roll your own" video trigger conditions via filtering, pulse duration and pulse counting triggers, but that's not fun -- there is a reason why scopes still provide dedicated video trigger modes.
-
Set your trigger holdoff to 12ms and see what happens.
This is not how video triggering is supposed to work.
Of course.... but the fact that it appears to be very very close to working makes me wonder what happens if you give it a little bit of help.
-
Of course.... but the fact that it appears to be very very close to working makes me wonder what happens if you give it a little bit of help.
To which of the four video trigger modes I had mentioned is it "close to working" in your opinion?
You can't even trigger on "any line" in a simple way, since the inverted pulses during the vertical sync period will cause spurious triggers. Pulling out the vertical sync via a low-passs filter is probably the best bet if proper video triggering is not available.
-
This is a screenshot of a video I made this afternoon. If you "Stop" it, there is a clear signal, but the continuous Signal shows like that. Source is a PAL signal from a digital source (test pattern). Markers on both scopes are 64uS - single line. The spikes on the Siglent are just glitches in the Signal. The Rigol shows the correct signal as faint background and something, I did not identify yet in the proximity of this line.
How are you connecting it to the 'scope? Are you using a 50 Ohm terminator?
This is just a single frame of a video i made, to show the difference between the Rigol and the Siglent. Identical setup without any terminator. On a real screenshot this is not visible.
-
To which of the four video trigger modes I had mentioned is it "close to working" in your opinion?
I was told it worked when you press "STOP", that it was just unstable when free running.
If so, that seems "close to working".
-
To which of the four video trigger modes I had mentioned is it "close to working" in your opinion?
I was told it worked when you press "STOP", that it was just unstable when free running.
If so, that seems "close to working".
My understanding, in line with what I saw in a quick test with the DHO1074 when I had it: When you stop the acquisition, you see a "stable" signal -- stable in the sense that it is no longer flickering and changing (of course). But you will not catch it in the same, stable phase every time you press STOP; it will be essentially a random point in time.
-
To which of the four video trigger modes I had mentioned is it "close to working" in your opinion?
I was told it worked when you press "STOP", that it was just unstable when free running.
If so, that seems "close to working".
My understanding, in line with what I saw in a quick test with the DHO1074 when I had it: When you stop the acquisition, you see a "stable" signal -- stable in the sense that it is no longer flickering and changing (of course). But you will not catch it in the same, stable phase every time you press STOP; it will be essentially a random point in time.
Indeed. just some random frame. But clear.
-
Good new: created a CSV file that the AWG can load!
I generated a number of CSV files intended for other Rigol AWG models, I found 1 that the DHO924S can load. Short version is that it can handle CSV files intended for a DG1022Z that use 8192 points in Frequency mode. Attempts to use CSV files using Sample/s mode or a different number of points failed, as did attempts to use various other Rigol AWG CSV files. The testing was not exhaustive so the various test CSV file are attached for folks to checkout and/or study. Hope this helps folks.
Hardware tested on: DHO924S with v00.01.02.00.02 firmware.
Sir you solved ARB loading on the DHO924S. Tested the format and works perfectly. I wasted days trying and failing. Thank you!
-
Set your trigger holdoff to 12ms and see what happens.
This is not how video triggering is supposed to work. You want the ability to trigger on (a) any frame (vertical sync), (b) odd or even frames only, (c) any line (horizontal sync), (d) line #xx in each frame.
A holdoff time alone won't get you any of this. You need a combination of sync pulse duration, levels, and pulse counting, made more complex by the fact that inverted line syncs are sent during the vertical sync time. You can "roll your own" video trigger conditions via filtering, pulse duration and pulse counting triggers, but that's not fun -- there is a reason why scopes still provide dedicated video trigger modes.
That's so awesome. I wrote up a big explanation last night, but got too tired to finish and post it. Good looking out., thanks!
p.s., Video trigger is one of the 2-3 considering factors that influenced my DHO purchase. I hope they fix it "soon".
-
Update- I've had some issues with my brand-new DHO924S and the PLA2216 accessory. I got a call from one of Rigol's FAEs today. They are aware of some problems and seem to be trying to fix them. They really want the bug reports, he said. My scope hasn't crashed since the update (never had any piece of test equipment crash in decades of doing R&D). And the PLA2216 is detected, seemingly reliably, on startup now, since taking their suggestion of hitting the "default" button.
We'll see what gets fixed and when. He said that Rigol will post firmware updates on their site as soon as they're available. I will say that I wish they'd keep the old ones, and give the release date for each so that users can see how often they're released before they buy.
-
My understanding, in line with what I saw in a quick test with the DHO1074 when I had it: When you stop the acquisition, you see a "stable" signal -- stable in the sense that it is no longer flickering and changing (of course). But you will not catch it in the same, stable phase every time you press STOP; it will be essentially a random point in time.
Indeed. just some random frame. But clear.
OK, that's a different thing altogether. The signal is free running (AUTO trigger) and you can stop it but it's not aligned to a video frame when you do.
FWIW I dug out an old TV video game thing and tried it. It doesn't trigger at all on the Rigol.
I tried my Micsig and it triggers perfectly. It even has +/- buttons on the line selector so you can zoom in and single-step through the lines.
(the trigger level marker also disappears from screen on the Micsig when you choose that mode)
-
Thanks for the confirmation. Video triggering does work fine on the DS1054Z (and presumably on many other older Rigol models). So they know how to do it and just messed something up in the DHO series -- which can hopefully be fixed soon.
-
Rigol engineers should be warned about this!
-
They really want the bug reports, he said.
Did you suggest him to go read this thread on the eevblog forum? :)
-
They really want the bug reports, he said.
Did you suggest him to go read this thread on the eevblog forum? :)
Hopefully the US market will be pushing them to fix fast and often..
-
Hopefully the US market will be pushing them to fix fast and often..
That's been said since Rigol started delivering product to US market.
Low-end product will get little attention.
Their units that cost $4000+, probably get more attention.
And Rigol is not alone, it's a common practice.
-
Low-end product will get little attention.
Their units that cost $4000+, probably get more attention.
I would not be that pessimistic. Low-end products selling in large numbers have received firmware updates with decent frequency -- look at the DS1000Z series. It seems likely that the DHO800/900 series is taking over as Rigol's top-selling entry level model, hence it will probably get some attention. I would be more concerned about products which sit in "no man's land" in the middle, like the DHO1000.
Having said that, the same software developers who are in charge of the DHO series have probably been busy cranking out those Android-based DMMs, waveform generators and power supplies (do we have those yet?) during the past half-year. Hopefully they will turn more attention back to the scopes now...
-
That's been said since Rigol started delivering product to US market.
Low-end product will get little attention.
Their units that cost $4000+, probably get more attention.
And Rigol is not alone, it's a common practice.
The DHO4000 series costs that much and the firmware is identical to the DHO800.
(well, 90+ percent identical...)
What bugs me is that most of these fixes would take a morning to correct. Developing this firmware must have taken many man-years years but they can't take two weeks to go through a list of fixes that will be a half a dozen lines of code each?
-
I would not be that pessimistic. Low-end products selling in large numbers have received firmware updates with decent frequency -- look at the DS1000Z series.
I remember they moved mountains when the clock jitter bug was found and reported on EEVBLOG.
Maybe @Dave could gather a list of DHO800 bugs and do a video mentioning them all. :)
-
I remember they moved mountains when the clock jitter bug was found and reported on EEVBLOG.
Indeed! That impressed and reassured me so much that I bought a DS1054Z as soon as the jitter was fixed.
(A purchase I certainly have not regretted. I was less impressed with the lack of polish the DHO1000 got during its more than one year on the market. Well, maybe Siglent's upcoming release of directly competing products will give Rigol some encuragement to do more...)
-
Maybe @Dave could gather a list of DHO800 bugs and do a video mentioning them all. :)
This may actually turn out to be very effective!
@EEVblog, there is some work that you can do for the benefit of the community :)
...grr can't figure out how the mention tag works.
-
Low-end product will get little attention.
Their units that cost $4000+, probably get more attention.
I would not be that pessimistic. Low-end products selling in large numbers have received firmware updates with decent frequency -- look at the DS1000Z series. It seems likely that the DHO800/900 series is taking over as Rigol's top-selling entry level model, hence it will probably get some attention. I would be more concerned about products which sit in "no man's land" in the middle, like the DHO1000.
Having said that, the same software developers who are in charge of the DHO series have probably been busy cranking out those Android-based DMMs, waveform generators and power supplies (do we have those yet?) during the past half-year. Hopefully they will turn more attention back to the scopes now...
I would not give too much weight to "frequency" of FW releases.
For 800/900, not that many releases, and, some of us (many of us) keep wondering why each relase notes says "fixing calibration routine". And then other long running bugs go unfixed.
I think we should look at the effectiveness of a new FW release.
Android based is ok, but I am no fan of doing all the coding in Android/java/dalvik/smali. I suspect there's fair amount of math routines in feature-rich scopes, so using "C" to code would be the better choice.
-
Android based is ok, but I am no fan of doing all the coding in Android/java/dalvik/smali. I suspect there's fair amount of math routines in feature-rich scopes, so using "C" to code would be the better choice.
All the "oscilloscope" functions are in a big .so file, written in C++.
-
I remember they moved mountains when the clock jitter bug was found and reported on EEVBLOG.
Indeed! That impressed and reassured me so much that I bought a DS1054Z as soon as the jitter was fixed.
(A purchase I certainly have not regretted. I was less impressed with the lack of polish the DHO1000 got during its more than one year on the market. Well, maybe Siglent's upcoming release of directly competing products will give Rigol some encuragement to do more...)
So, it is not the usual case "do not write about it here, this is just a user forum and the supplier is not reading it". We might be lucky to be hosted by someone reputable as EEVblog. :box: :)
-
I don't think Rigol follows the forum, or puts much weight to it. It was an EEVblog video on Youtube, highlighting the bug, which got their attention back then.
-
SPI still not working correctly with LA channels in the latest 01.02.00.02 release. Below are the release notes for all of the versions.
Agreed. It's so broken it's difficult to know where to start, but I'll have a stab at it.
When you select a digital channel for CS, it still wants a Threshold, but these are defined in the LA, 8 channels at a time. Choosing a digital channel for CLK or MISO greys out the Threshold.
If you set it up on analogue channels first, and get it to work, then try to switch the decoder to digital channels, it still refers to the analogue channels despite what the decoder screen says.
Changing the LA channel size to medium and especially large leaves you with a ton of blank space between the LA channels.
You seem to be able to change the order of the channels on the screen, but they are fixed to very course vertical grid, you can't reduce the blank space between channels other than by selecting small... which is tiny, even for me, and I usually prefer super small text!
Defaulting the LA channels to a zero volt threshold is nonsense on 99.9% of use cases for this scope.
[attachimg=1]
[attachimg=2]
[attachimg=3]
[attachimg=4]
[attachimg=5]
[attachimg=6]
-
SPI still not working correctly with LA channels in the latest 01.02.00.02 release. Below are the release notes for all of the versions.
Agreed. It's so broken it's difficult to know where to start, but I'll have a stab at it.
Reply #390.
While the hackers dig in to try to mitigate, just keep track of calendar days until Rigol releases a FW that fixes these issues.
-
Maybe @Dave could gather a list of DHO800 bugs and do a video mentioning them all. :)
This may actually turn out to be very effective!
@EEVblog, there is some work that you can do for the benefit of the community :)
...grr can't figure out how the mention tag works.
The "mention" button in this case is in the lower right corner of the post(actually EVERY post)
"Report to moderator" :-DD
-
I have a somewhat noob question. I started to adapt the ds1054Z python library to get raw data from the scope. Given this is a 12bit scope, for me the logical way to get samples from the full memory is to put :WAV:FORM into WORD mode instead of BYTE because the samples are bigger than 8 bits. However when running ":WAVeform:DATA?" i get operation not supported, only works for BYTE wave format.
What i'm missing if i want to extract the full memory (not only the display) data, in full 12bit resolution?
-> :WAVeform:DATA?
<- The instruction is not supported!
-> :WAVeform:FORMat?
<- (Return Count:5)
WORD
-
Hey, I forget, did someone have a clock app or something they installed ?
I poking around the auklet.so and found big long list of SCPI commands. What I did not know aboy SCPI command, commands you might find in a PDF and such, the lowercase letters can be truncated.
Example: :DISplay:INTensity is the same as :DIS:INT
I did not know that.
Oddly though, the code has the OR in it, thus bloating the firmware some. Every SCPI command has the extra OR data in the code !
(:?DISplay|:?DIS)(:CLOCk|:CLOC)
But if you want the clock (albeit wrong date-time w/o ext ntp sync)
SCPI :DIS:CLOC 1 cammand activates screen clock directly under LXI logo bottom right of screen.
-
So, it is not the usual case "do not write about it here, this is just a user forum and the supplier is not reading it". We might be lucky to be hosted by someone reputable as EEVblog. :box: :)
No one is saying "do not write about it here". You should absolutely write about and document here. But if no one sends it to Rigol Support there is a 99% chance nothing will be done with that info.
You have to get the ball rolling, send a single email per bug to support with:
- Clear and simple reproduction instructions
- How it affects your company/workflow
- How you were planning to buy 1,000 DHO924's but now you are not sure
Once they verify then they can enter it, somewhere, and hopefully it gets tracked and added to a queue.
-
I poking around the auklet.so and found big long list of SCPI commands. What I did not know aboy SCPI command, commands you might find in a PDF and such, the lowercase letters can be truncated.
Congrats! You're up to page 5 of the programming manual! ;)
Seriously tho', Great job finding that "in the dark". And thanks for the clock hack info. :-+
I suspect the manual per model does not cover all the scpi commands a DHO can do (or not do), after adding options lics, etc. Like the clock item.
Enabling BODE on an optioned 804 (914) does some weird stuff.
I believe one command causes the Scope app to crash.
-
No one is saying "do not write about it here". You should absolutely write about and document here. But if no one sends it to Rigol Support there is a 99% chance nothing will be done with that info.
You have to get the ball rolling, send a single email per bug to support with:
- Clear and simple reproduction instructions
...
Once they verify then they can enter it, somewhere, and hopefully it gets tracked and added to a queue.
Along these lines, I just sent in a detailed bug report regarding the Video Triggering not working (via help@rigol.com). This included details steps and photos. Hopefully this helps.
-
No one is saying "do not write about it here". You should absolutely write about and document here. But if no one sends it to Rigol Support there is a 99% chance nothing will be done with that info.
You have to get the ball rolling, send a single email per bug to support with:
- Clear and simple reproduction instructions
...
Once they verify then they can enter it, somewhere, and hopefully it gets tracked and added to a queue.
Along these lines, I just sent in a detailed bug report regarding the Video Triggering not working (via help@rigol.com). This included details steps and photos. Hopefully this helps.
:-+
-
Along these lines, I just sent in a detailed bug report regarding the Video Triggering not working (via help@rigol.com). This included details steps and photos. Hopefully this helps.
Thanks for that. Did your report include anything about the positive vs negative HSync selectors?
[attachimg=1]
[attachimg=2]
I.e., Positive = Negative and Negative = Positive?
And what kind of device puts out composite video like what is shown in second pic? I sure would like to see a spec for it.
-
I poking around the auklet.so and found big long list of SCPI commands. What I did not know aboy SCPI command, commands you might find in a PDF and such, the lowercase letters can be truncated.
Congrats! You're up to page 5 of the programming manual! ;)
Seriously tho', Great job finding that "in the dark". And thanks for the clock hack info. :-+
I suspect the manual per model does not cover all the scpi commands a DHO can do (or not do), after adding options lics, etc. Like the clock item.
Enabling BODE on an optioned 804 (914) does some weird stuff.
I believe one command causes the Scope app to crash.
I Don't know how many commands you found, and I didn't read ALL 450+ pages of the programming guide., but there sure are a lot of commands that they have listed, which makes me question your comment about how thorough their manual coverage is.
In fact, it takes up over 17 pages, having 30-ish entries each, just to index all the commands, and it takes 400+ pages to explain each of those functions!
I know --and presumably you do as well-- that it isn't exactly prudent to report or complain about bugs on a DHO that has "options/lics" added(as you say), especially given that they haven't yet made/sold/given away "options" for 800/900's.
BTW: My "page 5" reply was an attempt to get you to realize(I even PM'd you) that you posted the clock hack in the "Bug report" thread, but that didn't seem to work.
In next few days I will yank out the coded SCPI commans from the auklet.so file. Long list, but not all of them actually work on the 800/900. My hardware is limited, an 804 that runs as a 914, so I do expect some items to balk.
See attached.
-
I do expect some items to balk.
I do expect some readers to balk at finding this continued SCPI exploration in the "bug reports" thread. 8)
Did you find SCPI commands which are in the manual but don't work? What are you expecting to get from looking for the commands in the code?
-
Did your report include anything about the positive vs negative HSync selectors?
I.e., Positive = Negative and Negative = Positive?
Does the dialog actually state that the "positive" refers to the HSync polarity?
I read it as "positive = normal video signal polarity = positive-going brightness signal".
-
Along these lines, I just sent in a detailed bug report regarding the Video Triggering not working (via help@rigol.com). This included details steps and photos. Hopefully this helps.
Thanks for that. Did your report include anything about the positive vs negative HSync selectors?
---
I.e., Positive = Negative and Negative = Positive?
And what kind of device puts out composite video like what is shown in second pic? I sure would like to see a spec for it.
My bug report covered where positive was selected, though I've attempted both and both fail.
I interpret "positive" to be normal composite video signal (e.g., yellow consumer video connector) and "negative" is inverted. As to where "negative" is used, this how analog broadcast and analog cable RF signals are AM modulated in the US (can't speak for other countries or standards). For example, US analog channel 3 uses a carrier of 61.25 MHz where the sync pulse has the largest amplitude while white has a small amplitude at this frequency.
-
Does the dialog actually state that the "positive" refers to the HSync polarity?
I read it as "positive = normal video signal polarity = positive-going brightness signal".
The Dialog doesn't state it., It shows the HSync polarity. -and even illustrates the "intended' trigger point at the leading edge of HSync... Which is why I posted pix for both button states of Pos/Neg selection.
From my experience with composite video signals: What they are depicting is a HSync signal followed by the color burst signal, then showing a bit of video content. Of course, the diagram is abbreviated, but anyone that has seen grayscale or colorbars on a scope, knows what they're(Rigol are) getting at with that diagram.
Here's the problem: I doubt there's a video input(monitor/capture, etc) device that could sync up to an inverted composite signal as they show via the "Negative" selection, because the syncs, burst, and vid wouldn't be at the right spot in the signal.
I don't want to launch into a big diatribe describing the levels involved in the makeup of video signal, but here's a very rudimentary PDF brief (https://www.syscompdesign.com/wp-content/uploads/2018/09/video-waveforms.pdf) about video signals on a scope without a dedicated video trigger. Analog Devices has a more in-depth article (https://www.analog.com/en/resources/technical-articles/understanding-analog-video-signals.html) regarding various analog video signals.
I interpret "positive" to be normal composite video signal (e.g., yellow consumer video connector) and "negative" is inverted. As to where "negative" is used, this how analog broadcast and analog cable RF signals are AM modulated in the US (can't speak for other countries or standards). For example, US analog channel 3 uses a carrier of 61.25 MHz where the sync pulse has the largest amplitude while white has a small amplitude at this frequency.
I'm pretty sure oscilloscope video triggers only work on demodulated(I.e. not RF) video, so I don't understand what you're getting at?
BTW: Since this trigger function is so broken, maybe they didn't care to make the diagram match reality? I'm guessing they will eventually remove the negative selector when they do. I am ONLY referring to the NTSC/PAL video triggering, BTW. Other video types(like VGA) utilize a variety of horizontal and vertical sync signalling to indicate different video modes., but never(to my knowledge) in a composite signal.
-
Does the dialog actually state that the "positive" refers to the HSync polarity?
I read it as "positive = normal video signal polarity = positive-going brightness signal".
The Dialog doesn't state it., It shows the HSync polarity. -and even illustrates the "intended' trigger point at the leading edge of HSync...
I did not get my point across, it seems. Let me try again:
You select the "positive" radio button. That means you set up the scope for positive video signal polarity -- i.e. the brightness signals are positive, and the HSync is negative. And that's what you get, unless I am mistaken; so no bug.
(Note that the positive/negative selector is not in the "Sync" group of controls in the dialog. It is in the "Video standard" line.)
Edit: Whether there is much practical relevance in even providing the "negative polarity" option is a different matter. I have not come across inverted video signals. But even if they are in use somewhere, couldn't one just invert the scope channel? Seems like a duplication of functionality.
-
I poking around the auklet.so and found big long list of SCPI commands. What I did not know aboy SCPI command, commands you might find in a PDF and such, the lowercase letters can be truncated.
Congrats! You're up to page 5 of the programming manual! ;)
Seriously tho', Great job finding that "in the dark". And thanks for the clock hack info. :-+
I suspect the manual per model does not cover all the scpi commands a DHO can do (or not do), after adding options lics, etc. Like the clock item.
Enabling BODE on an optioned 804 (914) does some weird stuff.
I believe one command causes the Scope app to crash.
I Don't know how many commands you found, and I didn't read ALL 450+ pages of the programming guide., but there sure are a lot of commands that they have listed, which makes me question your comment about how thorough their manual coverage is.
In fact, it takes up over 17 pages, having 30-ish entries each, just to index all the commands, and it takes 400+ pages to explain each of those functions!
I know --and presumably you do as well-- that it isn't exactly prudent to report or complain about bugs on a DHO that has "options/lics" added(as you say), especially given that they haven't yet made/sold/given away "options" for 800/900's.
BTW: My "page 5" reply was an attempt to get you to realize(I even PM'd you) that you posted the clock hack in the "Bug report" thread, but that didn't seem to work.
The clock thing was not a hack. Simple SCPI command to re-enable it.
In hack thread we (most credit to zelea2) managed to get back gen tool for FW 00.01.02.00.02 by reverse engineering the new rigol crypt schema using RKey.data. That was a true hack. ;)
-
I interpret "positive" to be normal composite video signal (e.g., yellow consumer video connector) and "negative" is inverted. As to where "negative" is used, this how analog broadcast and analog cable RF signals are AM modulated in the US (can't speak for other countries or standards). For example, US analog channel 3 uses a carrier of 61.25 MHz where the sync pulse has the largest amplitude while white has a small amplitude at this frequency.
I'm pretty sure oscilloscope video triggers only work on demodulated(I.e. not RF) video, so I don't understand what you're getting at?
BTW: Since this trigger function is so broken, maybe they didn't care to make the diagram match reality? I'm guessing they will eventually remove the negative selector when they do. I am ONLY referring to the NTSC/PAL video triggering, BTW. Other video types(like VGA) utilize a variety of horizontal and vertical sync signalling to indicate different video modes., but never(to my knowledge) in a composite signal.
My expectation is the same; the oscilloscope operates on demodulated signals only.
The reason for the mention of NTCS broadcast signals was to answer the following question:
And what kind of device puts out composite video like what is shown in second pic? I sure would like to see a spec for it.
Based on how NTSC broadcast signals work, there are some limited uses cases where "negative" triggering would be helpful. For example, if someone was debugging / repairing a malfunctioning RF demodulator, then the "negative" triggering could be used immediately after the raw demodulation circuitry but before the video signal was properly inverted and normalized to the correct voltage ranges for composite video.
A second example for "negative" triggering would be that I've seen some weak references to specialized TV studio equipment that operate on inverted video signals. However, given that I've never found actual equipment that does this (nor have I looked too hard), this example was originally omitted to avoid tangential discussions about whether such devices exist.
All that said, I'm also not a fan of the words "positive" and "negative" in the video triggering dialog. It would be clearer to use "normal" for the first option and "inverted" for the second option (or other words to the same effect).
-
I did not get my point across, it seems. Let me try again:
You select the "positive" radio button. That means you set up the scope for positive video signal polarity -- i.e. the brightness signals are positive, and the HSync is negative. And that's what you get, unless I am mistaken; so no bug.
(Note that the positive/negative selector is not in the "Sync" group of controls in the dialog. It is in the "Video standard" line.)
Edit: Whether there is much practical relevance in even providing the "negative polarity" option is a different matter. I have not come across inverted video signals. But even if they are in use somewhere, couldn't one just invert the scope channel? Seems like a duplication of functionality.
You got your point across, your point just happened to be defending a defective/superfluous design decision on the part of Rigol.
Do you have access to a DHO800/900? Watch the interface when you click the radio gadgets for Pos/Neg selectors. Regardless what "line"?? they placed the gadgets on, It "inverts" the video AND the sync diagrams in the interface. That's what I've shown via my pix and the problem that I have with it.
Anyone who has worked with video on an oscilloscope knows that if the video is inverted, the Syncs, color burst, front/back porches etc all stay where they're supposed to be, only the video levels change.
I'm accustomed to video triggers from a bazillion years ago when they cost a small fortune to lease --much less buy-- from the likes of Tek & LeCroy. -which have to be flawless for product design. I have to constantly remind myself about the price point and intended use case when thinking about value brands like these.
I agree with your "Edit:" I'm just really confused why they would put this option in any of their scopes. IMHO, I don't think Pos/Neg selectors are needed on this section of the video trigger.
BTW: if anyone cares to read a quick hackaday post about video on scopes; Here is (https://hackaday.com/2018/01/18/know-your-video-waveform/) some light reading, using a different Rigol scope., -take note of the polarity button! :palm:
-
My expectation is the same; the oscilloscope operates on demodulated signals only.
The reason for the mention of NTCS broadcast signals was to answer the following question:
And what kind of device puts out composite video like what is shown in second pic? I sure would like to see a spec for it.
Based on how NTSC broadcast signals work, there are some limited uses cases where "negative" triggering would be helpful. For example, if someone was debugging / repairing a malfunctioning RF demodulator, then the "negative" triggering could be used immediately after the raw demodulation circuitry but before the video signal was properly inverted and normalized to the correct voltage ranges for composite video.
A second example for "negative" triggering would be that I've seen some weak references to specialized TV studio equipment that operate on inverted video signals. However, given that I've never found actual equipment that does this (nor have I looked too hard), this example was originally omitted to avoid tangential discussions about whether such devices exist.
All that said, I'm also not a fan of the words "positive" and "negative" in the video triggering dialog. It would be clearer to use "normal" for the first option and "inverted" for the second option (or other words to the same effect).
I'm in agreement with you re: normal/inverted, but as @ebastler suggested, why not just invert the channel?
I highly doubt a "video trigger" on a scope would be applicable in your RF demodulator example. First, they're meant to count out fields, frames, and lines, then zoom into a specific area of interest. Maybe I'm reacting to the wording in your "examples". Seems like you're uncertain... Sorry.
It seems to me a standard triggering method would be more appropriate. I highly doubt the design peeps at Rigol plan the video trigger around someone working on Ch.3 @ 61+ Mhz. Altho', HD signals have a pretty high frequency, they're generally discrete or component as opposed to NTSC/PAL composite signals.
Please think about this- In your example above, in the case of "negative" triggering: Are the HSyncs inverted? i.e., positive HSync as shown on the scope in my second screencap?
-
I highly doubt a "video trigger" on a scope would be applicable in your RF demodulator example. First, they're meant to count out fields, frames, and lines, then zoom into a specific area of interest. Maybe I'm reacting to the wording in your "examples". Seems like you're uncertain... Sorry.
It seems to me a standard triggering method would be more appropriate. I highly doubt the design peeps at Rigol plan the video trigger around someone working on Ch.3 @ 61+ Mhz. Altho', HD signals have a pretty high frequency, they're generally discrete or component as opposed to NTSC/PAL composite signals.
Please think about this- In your example above, in the case of "negative" triggering: Are the HSyncs inverted? i.e., positive HSync as shown on the scope in my second screencap?
Standard triggering kind of could used as an alternative, the same way it kind of can be used now with video signals. You can get by, but it isn't ideal.
The first example is definitive. The second example is uncertain.
In the first example, the HSyncs would definitely be inverted (i.e., HSync has positive voltage). They would look like the 2nd screenshot. Thus, "negative" triggering would be used in this case. Keep in mind this is for looking at signals after they have come out of the raw AM demodulator portion of the circuit but before the signal is inverted and normalized to produce the final and correct composite video signal. This is because of how NTSC broadcast signals are defined and how AM demodulation works. Only after the inversion occurs is where "positive" triggering is used (e.g., composite video signal).
As for Rigol including video triggering, I was surprised to see NTSC or PAL at all, whether normal or inverted. A number of companies no longer support NTSC or PAL in their test equipment.
-
Maybe it should be called "inverted" and "non-inverted".
Me? I think anybody with a neuron can understand it by looking at the on-screen graphic.
-
This thread is titled "Bug Reports + Firmware".
Does that make this thread a 2-topic thread, "Bug Reports" and "Firmware" ?
As for FW 00.01.02.00.02, anyone have a bugs list for this latest FW, like new & fixed?
Trying to ascertain actual benefit to do the upgrade from 00.01.02.00.00 on an 800 device.
-
As for FW 00.01.02.00.02, anyone have a bugs list for this latest FW, like new & fixed?
Trying to ascertain actual benefit to do the upgrade from 00.01.02.00.00 on an 800 device.
There's a list inside the firmware .zip file.
-
This thread is titled "Bug Reports + Firmware".
Does that make this thread a 2-topic thread, "Bug Reports" and "Firmware" ?
As for FW 00.01.02.00.02, anyone have a bugs list for this latest FW, like new & fixed?
Trying to ascertain actual benefit to do the upgrade from 00.01.02.00.00 on an 800 device.
Model Supported] All the DHO800/900 series oscilloscopes
[Latest Revision Date] 2023/12/28
[Updated Contents]
v00.01.02.00.02 2023/12/28
1. Self calibration optimization update
2. Solve the problem that window transparency cannot load the last value
3. Solve the problem that the LA function cannot display the label after setting it
v00.01.02.00.01 2023/12/5
1. Self calibration optimization update
2. Solve edge jitter below 31kHz
v00.01.02.00.00 2023/11/2
1. Self calibration optimization update
2. Solve the problem of UltraLab startup connection failure
3. Solve the problem of failure to save waveform in wfm format
4. Solve the problem of unresponsive touch on startup screen
v00.01.01.00.02 2023/09/12
1. Self calibration optimization update
2. Update Help Documents
v00.01.01.00.01 2023/08/10
1. Remove all time-related displays on the instrument
2. To modify the vertical interface, click the wiring diagram to modify the AC coupling function
3. Modify the delayed scan Chinese display as Zoom
4. Modify the order of the menu in the upper right corner, put the measurement in the front and Default in the back
5. The probe ratio interface is removed, and the probe ratio option is added to the vertical first-level menu
v00.01.00.00.19 2023/07/24
1. The first version is released
-Released the production version.
-
As for FW 00.01.02.00.02, anyone have a bugs list for this latest FW, like new & fixed?
Trying to ascertain actual benefit to do the upgrade from 00.01.02.00.00 on an 800 device.
There's a list inside the firmware .zip file.
There's a "new bugs" section in the list, in the FW zip file? I must have missed that. ;)
I know about the release notes, and we are all wondering if "fixed self calibration" actually means anything, because every FW zip seems to have that in the list. So every new release the calibration is more optimized? How so?
What about fixing FFT flat-top calibration issue? Maybe optimizing calibration in each FW release is more important?
-
HI everyone, I am starting to do some test to compare of the DHO924s with my old ds1054z. I have found so far some bug with the ASCII decoding and the pass/fail window and the XY display. I am slowly putting some video showing this and compare to the old ds1054z. They will be at https://www.youtube.com/@stevelevesque939 (https://www.youtube.com/@stevelevesque939)
-
Along these lines, I just sent in a detailed bug report regarding the Video Triggering not working (via help@rigol.com). This included details steps and photos. Hopefully this helps.
Thanks for that. Did your report include anything about the positive vs negative HSync selectors?
(Attachment Link)
(Attachment Link)
I.e., Positive = Negative and Negative = Positive?
And what kind of device puts out composite video like what is shown in second pic? I sure would like to see a spec for it.
I managed to get the (random) line Video trigger working. Triggering on Nth Edge does the job quite good Nth = 64uS PAL / 53.5uS NTSC triggers on one line. Usually this is, what I want to get, so until RIGOL manages to get it running as announced...
-
If that is just plain NTSC- the Vp-p is about double the 140 IRE units (1.0V p-p) it should be. Can you confirm that's accurate? Or is it another RIGOL measurement error? Also, the trace is blue, but chan 1 and the scale are yellow. I don't know how to interpret that.
-
My guess is that the video signal was not 75\$\Omega\$ terminated, hence the larger voltage ranges. This is only a guess and could be wrong.
-
No, it is not terminated indeed, it is just a plain PAL output from a digital player, showing a testcard I created, that I usually use due to the lack of a decent generator. The blue trace is due to the color option I activated in the screen menu. It is channel 1 though...
-
I got my 924s since two weeks now.
I started to make some compare video and bug search for the 924s and compare to the ds1054Z
last video here with a pass fail bug confirmed
https://www.youtube.com/watch?v=1k-F-EWQlHI (https://www.youtube.com/watch?v=1k-F-EWQlHI)
-
Apparently the latest (or maybe the one before the latest, with the ".00" in the end -- not sure how to see the minor revision number) firmware has already made it to the scopes being shipped now. I ordered mine about a month ago, and here's its "about" window, just to add to the knowledge base:
[attachimg=1]
(sorry for the crappy photo -- no network connection and no proper screenshot before I take a backup image of the SD card)
UPDATE: full firmware version is 00.01.02.00.00
-
Apparently the latest (or maybe the one before the latest, with the ".00" in the end -- not sure how to see the minor revision number) firmware has already made it to the scopes being shipped now. I ordered mine about a month ago, and here's its "about" window, just to add to the knowledge base:
(Attachment Link)
(sorry for the crappy photo -- no network connection and no proper screenshot before I take a backup image of the SD card)
Oh, there is not only 00 at the end. The version is 00.01.02.00.02.
As this version is not listed at rigol.eu - here it is:
https://www.rigolna.com/firmware/ (https://www.rigolna.com/firmware/)
I downloaded the ''00.01.02.00.02" manually, see Build 2024/01/03 and Android Build 2023/10/10 on a 900
Strange, strange, there is more behind the first 6 numbers, than we might imagine...
The other values are identical - except the model.
-
Ah, so then mine must be older. Any idea how to see the full version number?
-
Ah, so then mine must be older. Any idea how to see the full version number?
Good question. Just checked the WebInterface. It is truncated as well.
Firmware Revision: 00.01.02
There might be more information via the SCPI commandline - knowing the right spell...
-
Ah, so then mine must be older. Any idea how to see the full version number?
Good question. Just checked the WebInterface. It is truncated as well.
Firmware Revision: 00.01.02
There might be more information via the SCPI commandline - knowing the right spell...
Press "About" three times.
-
Ah, so then mine must be older. Any idea how to see the full version number?
Good question. Just checked the WebInterface. It is truncated as well.
Firmware Revision: 00.01.02
There might be more information via the SCPI commandline - knowing the right spell...
I can't find SCPI that pulls out full version.
Look at the "build date" in Utility --> About
Match to closest date from release notes.
v00.01.02.00.02 2023/12/28
v00.01.02.00.01 2023/12/5
v00.01.02.00.00 2023/11/2
v00.01.01.00.02 2023/09/12
v00.01.01.00.01 2023/08/10
v00.01.00.00.19 2023/07/24
Sorry. Fungus posted while I was typing. ;)
so use chart, or do like Fungus said.
-
3 taps the ABOUT menu item puts unit into "TestModel:On" mode, whatever that means.
3-tap it, then go to "Other", now you have HDMI settings. By default hdmi appears to be "DSP on", assume "DSP" means display. No need to have it on if you are not using hdmi.
Or does "DSP" mean digital sound processor ? :-// I didn't actually test it, I don't use hdmi port.
-
Any more easter eggs?
...like "add all possible licenses for free" :-DD
but thank you for these shortcuts. Do not tell mit, it is just RTFM :palm:
Or does "DSP" mean digital sound processor ? :-// I didn't actually test it, I don't use hdmi port.
7CH Audio with 3D immersive Video - if you have one of these Apple glasses :popcorn:
DSP is usually Digital Signal Processor - but nevertheless an interesting find.
-
Any more easter eggs?
...like "add all possible licenses for free" :-DD
but thank you for these shortcuts. Do not tell mit, it is just RTFM :palm:
Or does "DSP" mean digital sound processor ? :-// I didn't actually test it, I don't use hdmi port.
7CH Audio with 3D immersive Video - if you have one of these Apple glasses :popcorn:
DSP is usually Digital Signal Processor - but nevertheless an interesting find.
Add one small binary onto the DHO, creates all the lics. That's in the hacking thread. :-+
I didn't read the manual, not one page, at least not yet. ;)
-
I didn't read the manual, not one page, at least not yet. ;)
Poking around is more interesting, indeed. I should cultivate this even more - as long as things are not exploding...
I alreday learned (and poked) a lot from the hacking thread and the experts here - impressed in al humbleness. :clap:
-
3 taps the ABOUT menu item puts unit into "TestModel:On" mode, whatever that means.
"That means" the same as it means by tapping "build number" in Android settings menu.
But alas, I digress in the Bug thread. Sorry y'all. Couldn't resist. >:D
-
Not sure if it was mentioned already, but is this reproducible on other firmware and hardware versions, can anyone check this? Mine is an 804 updated to 924, so I wonder if maybe it's because of this (but I doubt that).
Basically the bug is that it fails to change the source channel of a measured parameter:
https://www.youtube.com/watch?v=BEFgrXSkdw4 (https://www.youtube.com/watch?v=BEFgrXSkdw4)
This really sucks, and it also sucks that there is no quick button to change the source channel for all (or chosen) measurements.
p.s. is there any way to remove those icons in the "Result" panel that do nothing except occupying an extra row of precious vertical space for each item? Just like the Counter looks when it's added to this panel.
-
p.s. is there any way to remove those icons in the "Result" panel that do nothing except occupying an extra row of precious vertical space for each item? Just like the Counter looks when it's added to this panel.
Giving the item a finger-swipe to the right is the quickest way. (That's assuming that the DHO800 behaves the same here as the DHO1000 I had.)
-
Not sure if it was mentioned already, but is this reproducible on other firmware and hardware versions, can anyone check this? Mine is an 804 updated to 924, so I wonder if maybe it's because of this (but I doubt that).
Basically the bug is that it fails to change the source channel of a measured parameter:
https://www.youtube.com/watch?v=BEFgrXSkdw4 (https://www.youtube.com/watch?v=BEFgrXSkdw4)
This really sucks, and it also sucks that there is no quick button to change the source channel for all (or chosen) measurements.
Yes, I also encountered this inconvenience.
p.s. is there any way to remove those icons in the "Result" panel that do nothing except occupying an extra row of precious vertical space for each item? Just like the Counter looks when it's added to this panel.
Swiping an icon on the panel to the right removes this icon from the panel.
-
Giving the item a finger-swipe to the right is the quickest way. (That's assuming that the DHO800 behaves the same here as the DHO1000 I had.)
It removes the entire item, not just the header icon:
[attachimg=1]
This icon serves no useful purpose, because it's too tiny to be readable and because the widget already has the name of the parameter in text; at the same time it wastes a whole row which could have been used for something of value otherwise.
I think it's hardcoded in the apk, though, and there's no easy way to get rid of it.
p.s. using cyan and blue in the same palette for channel colors is totally stupid. Is it a case of UI developers not using the product a single time? It's an immediately obvious issue. Not to mention that the probes coming with the scope have green and cyan marking rings, but not blue and cyan! And to modify them, it's required to rebuild the main apk, which is possible, but it's not yet clear whether signing it will be a problem.
-
Giving the item a finger-swipe to the right is the quickest way. (That's assuming that the DHO800 behaves the same here as the DHO1000 I had.)
It removes the entire item, not just the header icon:
Oh -- yes, it does. Sorry, I misunderstood your question then. I don't think you can remove just the little icon.
-
The DHO1000 shows the measurements much more compactly, especially with stats on, you can fit a lot more of them vertically.
I'm not sure why the DHO800/DHO900 don't do it the same way.
THAT would be a good hack... :)
-
Hi
I continue to explore the HDO924s vs the ds1054z showing features and some bugs on both. Last video here compare the memory capture feature.
So far the bugs that hits me so far on 924s is the failure to decode or display ASCII stream. The pass/fail stop and display the current triggered packet which is a real bug that need fixing and here some display issue when zooming on the recorded packet.
https://www.youtube.com/watch?v=MTmREG_oEIY (https://www.youtube.com/watch?v=MTmREG_oEIY)
-
I didn't read the manual, not one page, at least not yet. ;)
@Randy222,
I'm actually enjoying reading the manual (full and quick start guide) as I came from a Rigol DS1054z and felt like a fish out of water, without all the buttons.
It's making a lot more sense now and feeling much more comfortable with the DHO804.
Cheers
dm
-
@Randy222,
I'm actually enjoying reading the manual (full and quick start guide) as I came from a Rigol DS1054z and felt like a fish out of water, without all the buttons.
It's making a lot more sense now and feeling much more comfortable with the DHO804.
I don't think Randy222 is interested in using the scope. ;)
He's more into the Android under the hood, which is not covered in the manual anyway...
-
Has anyone noticed a slight DC offset (with the probes disconnected) in the lower ranges, regardless of whether DC or AC coupling is selected? It's visible in the waveform display, but best seen if you turn on the measurement of Vavg. Set the channel's probe divider setting to 1x, then set vertical scale to ~5mv/div, and it's already seen there: the reading is consistently above zero.
Now, the weirdest part of this, which indicates that this offset is a software bug, is that as you continue to zoom in from 5mv/div all the way down to 200uV/div, it becomes more visible, but if, when already at the lowest scale of 200uV/div, you turn the encoder clockwise once more, the offset becomes zero! The Vavg reading starts jumping between +/- a few uV, like it should. But once you begin to zoom out, the small offset reappears.
-
Has anyone noticed a slight DC offset (with the probes disconnected) in the lower ranges, regardless of whether DC or AC coupling is selected?
Have you tried self-cal?
-
Has anyone noticed a slight DC offset (with the probes disconnected) in the lower ranges, regardless of whether DC or AC coupling is selected?
Have you tried self-cal?
If you "gnd" the probe input in the app probe-setting, still an offset? What if you put a terminator on the BNC?
-
Have you tried self-cal?
Yes, and more than once. No effect.
Haven't tried self-cal with PE connected, though, but not sure if it'll help (or rather I expect it to have no effect). Will try this when I make an extension cord to connect to mains earth.
If you "gnd" the probe input in the app probe-setting, still an offset?
Yes, about one pixel above zero. And when I rotate the vertical scale encoder, it jumps to exactly zero when it switches and stays there for a fraction of second, then moves back one pixel above.
What if you put a terminator on the BNC?
That's what I tried it with. Not really a terminator (don't have one), just a 51 Ohm resistor across the input BNC.
Using the PE cable to connect chassis to the earth ground directly reduces noise, but does nothing to the offset.
Same behavior on Ch2.
Here's what I see on the screen (probe set to 1x in channel settings, 51 Ohm resistor in the input jack).
1. 10mV, below zero.
[attachimg=1]
2. 5mV, above zero this time.
[attachimg=2]
(5mV to 500uV -- pretty much the same up and down, never exactly zero)
3. 500uV
[attachimg=3]
4. 200uV, the offset is very clear now
[attachimg=4]
5. One clockwise step of the vertical scale encoder -- still 200uV, but now the offset becomes negative!
[attachimg=5]
This offset might at least be understandable, but what the heck happens when I switch from 200uV to 200uV? It's supposed to do nothing in this case, and yet there is something mysterious going on under the hood. That's why I suspect some kind of firmware bug here.
Of course it must be made clear that it's a 804 which thinks that it's a 924. This may lead to some side effects. That's why I wonder if anyone else can reproduce this with the same setup.
-
This offset might at least be understandable, but what the heck happens when I switch from 200uV to 200uV? It's supposed to do nothing in this case, and yet there is something mysterious going on under the hood. That's why I suspect some kind of firmware bug here.
Of course it must be made clear that it's a 804 which thinks that it's a 924. This may lead to some side effects. That's why I wonder if anyone else can reproduce this with the same setup.
I noticed this behavior and even described it somewhere here (perhaps in another topic). The 200 µV offset jump is caused by the 20 MHz bandwidth limitation being activated. When you switch from 500 to 200 µV, band limiting is activated and this causes a sharp offset. When the encoder is turned again, a new range switch occurs (from the software point of view), from 200 µV to 200 µV, but since the bandwidth limitation is already activated, the offset does not jump, it returns to its “native” value.
This effect can be observed on other bands by simply turning the 20 MHz bandwidth limit on and off in the channel settings. At different ranges this effect is expressed to varying degrees. And it is also different on different channels.
-
Hi
I continue to explore the HDO924s vs the ds1054z showing features and some bugs on both. Last video here compare the memory capture feature.
So far the bugs that hits me so far on 924s is the failure to decode or display ASCII stream. The pass/fail stop and display the current triggered packet which is a real bug that need fixing and here some display issue when zooming on the recorded packet.
https://www.youtube.com/watch?v=MTmREG_oEIY (https://www.youtube.com/watch?v=MTmREG_oEIY)
Maybe I missed it, but what firmware version are you experiencing the pass/fail bugs on? I have not looked into this feature and am curious.
-
RS232 decoder is very unstable and buggy.
I've checked RS232 decoder on 3 oscilloscopes on one case, where 2 chips communicate (Tx and Rx) on the same wire with very small delay between packets.
Agilent MSO-X3000 easily handles small delay, Rigol MSO5000 decodes Rx and Tx packets fine,
but Rigol HDO804 decodes only 1st packet (request), and completely ignores long second packet (response). Small delay completely ruins it's decoder.
-
The RS232 and other decoders works very stably. The problem is that setting the threshold level in the decoder parameters has an error. Switch the probe to 1:1 mode, set 1:1 probe ratio in the channel settings and make sure that everything works ok.
-
RS232 decoder is very unstable and buggy.
I've checked RS232 decoder on 3 oscilloscopes on one case, where 2 chips communicate (Tx and Rx) on the same wire with very small delay between packets.
Agilent MSO-X3000 easily handles small delay, Rigol MSO5000 decodes Rx and Tx packets fine,
but Rigol HDO804 decodes only 1st packet (request), and completely ignores long second packet (response). Small delay completely ruins it's decoder.
Try turning on zoom mode. It does a full memory decode when you do that.
-
Do you even read questions before writing an answer? :blah:
-
Do you even read questions before writing an answer? :blah:
Looking at the pictures would have been sufficient too. ::)
-
The RS232 and other decoders works very stably. The problem is that setting the threshold level in the decoder parameters has an error. Switch the probe to 1:1 mode, set 1:1 probe ratio in the channel settings and make sure that everything works ok.
I know how to use oscilloscopes, threshold level is correct for all data on a screen (see picture). Of course I tried different threshold values in 0-5V range, this Rigol HDO 804 is simply unable to decode middle part of data with any settings, while my other oscilloscopes do that without issues.
I see the problem in small time delay (approximately 1bit length) between request and response data packets - this delay completely puzzles decoder.
-
It's great that you know how to use an oscilloscope! But the oscilloscope firmware contains a bug that was discussed several pages ago. The error is due to the incorrect display of the threshold level. Because of this bug, decoders do not work correctly. The bug does not appear in 1:1 probe ratio.
Which is what I told you about.
-
The RS232 and other decoders works very stably. The problem is that setting the threshold level in the decoder parameters has an error. Switch the probe to 1:1 mode, set 1:1 probe ratio in the channel settings and make sure that everything works ok.
I know how to use oscilloscopes, threshold level is correct for all data on a screen (see picture). Of course I tried different threshold values in 0-5V range, this Rigol HDO 804 is simply unable to decode middle part of data with any settings, while my other oscilloscopes do that without issues.
I see the problem in small time delay (approximately 1bit length) between request and response data packets - this delay completely puzzles decoder.
To be honest, that is quite aggressive data sending. 1 bit pause is calling for errors.
At least 2-3 bits time would be more conservative and recommended.
With 1 bit, you can get synchronization errors, UART might start decoding in the middle of the packet and proceed to next half of packet.
I'm not talking about scope here but about your equipment.
If communication is happening close with short cables, might work OK.
Fact that those scopes can decode it right is because their decoders have more intelligence than simple UART hardware.
-
To be honest, that is quite aggressive data sending. 1 bit pause is calling for errors.
At least 2-3 bits time would be more conservative and recommended.
With 1 bit, you can get synchronization errors, UART might start decoding in the middle of the packet and proceed to next half of packet.
I'm not talking about scope here but about your equipment.
Hmm, it looked like well more than a single bit time to me in the screenshots. Did I misinterpret the polarity?
And even a single stop bit should be fine for any decoder. After all, that's what a uni-directional RS-232 transmission uses between characters all the time. (Ignoring my old mechanical teletype here, which uses 1.5 stop bits for safe recovery between characters...)
-
Do you even read questions before writing an answer? :blah:
Looking at the pictures would have been sufficient too. ::)
There's no zoom mode in any of those pictures. When he said "some of it works" I thought it was the partial decode that it does when not zoomed.
What it actually is is that part of the signal doesn't go down to zero.
That's the threshold level bug for sure. Set probe ratio to 1:1 to make it work.
-
It's great that you know how to use an oscilloscope! But the oscilloscope firmware contains a bug that was discussed several pages ago. The error is due to the incorrect display of the threshold level. Because of this bug, decoders do not work correctly. The bug does not appear in 1:1 probe ratio.
Which is what I told you about.
Sorry, you're right.
That appears the same bug with threshold. In 1:10 mode decoder starts working with threshold 8V (actual 0.8v?). 1:1 has correct level and correct decoded data.
-
To be honest, that is quite aggressive data sending. 1 bit pause is calling for errors.
At least 2-3 bits time would be more conservative and recommended.
With 1 bit, you can get synchronization errors, UART might start decoding in the middle of the packet and proceed to next half of packet.
I'm not talking about scope here but about your equipment.
Hmm, it looked like well more than a single bit time to me in the screenshots. Did I misinterpret the polarity?
And even a single stop bit should be fine for any decoder. After all, that's what a uni-directional RS-232 transmission uses between characters all the time. (Ignoring my old mechanical teletype here, which uses 1.5 stop bits for safe recovery between characters...)
Yeah in theory.. Short cables, low noise environment... but offtopic here, sorry.
-
What are these hidden functions, especially for DDR?
-
DDR: initial address & length. Google lens ftw.
-
- "AFE zero" self calibration option spoils calibration results, but the initial state could be restored by pushing original cal files to the scope
I wonder what this "AFE zero" actually does. It does indeed spoil the offset calibration (I didn't test gain after it), and it happens regardless of whether the probes are disconnected or shorted, end result is about the same. But they must be using it at the factory in one way or another, it must be there for a reason. Perhaps.
-
This can be useful (DHO924S):
-
This can be useful (DHO924S):
Have you tried it? I understand that the higher resolutions will not give you more actual pixels for the curve display, but will just scale up the 1024*600 picture? Does this cause blur as an interpolation artefact?
-
This can be useful (DHO924S):
Have you tried it? I understand that the higher resolutions will not give you more actual pixels for the curve display, but will just scale up the 1024*600 picture? Does this cause blur as an interpolation artefact?
Currently only one FHD display screen I have is in my laptop. But I have Eizo monotor 1600:1200 with DVI and somewhere I have HDMI->DVI adapter, but where? Also I have old TV with HDMI and even lower resolution - dont remember how low, because I didnt use it for years. I will try it later.
-
BTW. I feel scammed a little bit. FFT sample rate is limited to 50MSa/s :/
-
BTW. I feel scammed a little bit. FFT sample rate is limited to 50MSa/s :/
Fortunately that is not the case. The FFT is limited to 1 MPts of data, so if you choose a long record time of 20 ms (for good spectral resolution), the sampling rate will indeed be 1 MPts / 20 ms = 50 MPts/s. But if you switch to a faster time base for the data acquisition, and hence shorter sweep time, the sampling rate will be increased correspondingly.
The FFT limit of 1 MPts is stated clearly in the datasheet, by the way, hence no cheating on Rigol's part there.
-
This can be useful (DHO924S):
Have you tried it? I understand that the higher resolutions will not give you more actual pixels for the curve display, but will just scale up the 1024*600 picture? Does this cause blur as an interpolation artefact?
This is, what I get on an UHD monitor set to 1600x900. Other resolutions do not display correctly on this DELL thing. UHD is possible as well, but monitor shifts the picture to the left. No higher resolution in this case as well. Interesting: the curves tet more pixelated than the UI.
-
UHD is possible as well, but monitor shifts the picture to the left. No higher resolution in this case as well. Interesting: the curves tet more pixelated than the UI.
Yes, that's what I thought. They apparently let Android render the UI at the proper screen resolution, but the trace display is scaled up after the fact from 1024*400, or whatever the net vertical area availale for curves may be.
-
DHO814 with 00.01.02.00.02 firmware (but this has been going on in all the previous versions too)
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."
Scanning finds and repairs the issue. Turning the scope off before removing the USB stick makes no difference. Using NTFS format, instead of FAT32, seems to work fine.
To reproduce:
- FAT32 format the USB stick on Windows, do a safe removal.
- insert the USB stick into the scope
- press "Quick" to dump a waveform to the stick
- count to 10 (not sure it makes a difference) and remove the stick
- insert the stick into the Windows PC and watch the failure popup show up immediately
Is is just me and my PC setup, or do others have the same problem?
-
DHO814 with 00.01.02.00.02 firmware (but this has been going on in all the previous versions too)
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."
Scanning finds and repairs the issue. Turning the scope off before removing the USB stick makes no difference. Using NTFS format, instead of FAT32, seems to work fine.
To reproduce:
- FAT32 format the USB stick on Windows, do a safe removal.
- insert the USB stick into the scope
- press "Quick" to dump a waveform to the stick
- count to 10 (not sure it makes a difference) and remove the stick
- insert the stick into the Windows PC and watch the failure popup show up immediately
Is is just me and my PC setup, or do others have the same problem?
Typical outcome when a device fails to add a timestamp to a saved file.
-
Is is just me and my PC setup, or do others have the same problem?
Im using 256 GB pendrive with FAT and Linux on all my computers. No problems so far.
-
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.
-
This can be useful (DHO924S):
Have you tried it? I understand that the higher resolutions will not give you more actual pixels for the curve display, but will just scale up the 1024*600 picture? Does this cause blur as an interpolation artefact?
From Dave's early discoveries. (This should start where he answers the resolution question)
https://youtu.be/r_BYYgCqScE?si=OWU4W64nf2w_kgHw&t=7 (https://youtu.be/r_BYYgCqScE?si=OWU4W64nf2w_kgHw&t=7)
Sorry for the off topic post.
-
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?
-
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.
-
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. ::)
-
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.
-
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. :bullshit:
-
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.
-
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?
-
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.
-
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 :)
-
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
-
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.
-
From Dave's early discoveries. (This should start where he answers the resolution question)
https://youtu.be/r_BYYgCqScE?si=OWU4W64nf2w_kgHw&t=7 (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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
[attach=2]
[attach=1]
In fact, if I reduce the vertical to 5V/div it won't trigger below 1.1V...
[attach=3]
-
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.
-
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?
-
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.
-
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.
-
Sounds well like a bug to me.
It's probably deliberate. We're dealing with analog values here, there's probably some sort of hysteresis/threshold things going on the make triggering more stable on noisy signals.
I don't get the obsession with trying to label everything as a "bug". The 'scope will trigger perfectly on that signal, just turn the knob and move the level up a bit.
So what happens when you want to scope a 5kHz square wave signal that is 0.150 volt-peak? Scope can't trigger it?
...and this is the result of that type of thinking. :palm:
Of course it can trigger. Set vertical scale so it's a decent size on screen.
-
So what happens when you want to scope a 5kHz square wave signal that is 0.150 volt-peak? Scope can't trigger it?
...and this is the result of that type of thinking. :palm:
Of course it can trigger. Set vertical scale so it's a decent size on screen.
What does a screen vertical scale have to do with an input signal that is 5kHz 0.150Vp with trigger set to 0.100V ?
Nothing should be the answer.
If I set the screen so that signal shows like a flat line on the screen, the input signal nor trigger level has changed, so the trigger functionality should not be impacted just because I set my screen view to something silly, etc. Trigger should not be tied to x or y screen settings, trigger should be tied to input signal.
Anyways, topic for another thread.
-
The test signal was provided by a TinySA Ultra.
In the video, I set the simple edge trigger.
The frequency can be seen on the side, as well as the value of Vpp.
and in the pictures you can see it at 4 frequencies.
At 125Mhz and 250Mhz, you can see that the bad triggering zone is larger, that is, the value of deltaY compared to the total Vpp.
I can't reproduce this phenomenon as strongly on another scope.
https://www.youtube.com/watch?v=5IdFyd60Cv8 (https://www.youtube.com/watch?v=5IdFyd60Cv8)
I think this has already been discussed before.
At least the two are close.
-
If I set the screen so that signal shows like a flat line on the screen the trigger functionality should not be impacted
Says who?
On a DSO the input voltages don't go past the ADC. The trigger works with sampled values, not raw voltages.
If the signal is two pixels high on screen then why would the trigger work?
(cue all the pedants with fancy scopes that have separate analog trigger circuits inside them...)
-
If I set the screen so that signal shows like a flat line on the screen the trigger functionality should not be impacted
Says who?
On a DSO the input voltages don't go past the ADC. The trigger works with sampled values, not raw voltages.
If the signal is two pixels high on screen then why would the trigger work?
(cue all the pedants with fancy scopes that have separate analog trigger circuits inside them...)
If the signal is not even on the screen, the signal is still however being input to the front end and can still be processed. This issue has to do with single "threading" signal processing. What you see on the screen should be a seperate process from actual signal processing.
Anyways, no need to debate this here.
-
In case of fast unstable gen with avg acquisition:
https://www.youtube.com/watch?v=XuOmD-gSe6I (https://www.youtube.com/watch?v=XuOmD-gSe6I)
-
In case of fast unstable gen with avg acquisition:
https://www.youtube.com/watch?v=XuOmD-gSe6I (https://www.youtube.com/watch?v=XuOmD-gSe6I)
.
Have you tried increasing the memory depth?
-
Have you tried increasing the memory depth?
Same problem at 50Mpts.
-
If I set the screen so that signal shows like a flat line on the screen the trigger functionality should not be impacted
Says who?
On a DSO the input voltages don't go past the ADC. The trigger works with sampled values, not raw voltages.
If the signal is two pixels high on screen then why would the trigger work?
(cue all the pedants with fancy scopes that have separate analog trigger circuits inside them...)
If the signal is not even on the screen, the signal is still however being input to the front end and can still be processed. This issue has to do with single "threading" signal processing. What you see on the screen should be a seperate process from actual signal processing.
Anyways, no need to debate this here.
Fungus is correct here. What you see on the screen is what actually goes into the ADC. If you set input attenuator so the signal looks small on the screen, that in reality means the ADC receives small signal which may not be sufficient to trigger on after it gets digitized. What you say should be is just wishful thinking and is not how it works. Even in scopes which have a separate trigger channel, it is still tied to V/ of the signal channel and gets accordingly attenuated as you change V/.
-
with the success of my diy LA probe https://www.eevblog.com/forum/testgear/low-cost-compatible-rigol-pla2216-logic-probe-for-dho900-(and-hacked-dho800)/msg5352677/#msg5352677 (https://www.eevblog.com/forum/testgear/low-cost-compatible-rigol-pla2216-logic-probe-for-dho900-(and-hacked-dho800)/msg5352677/#msg5352677) i noticed one bug in LA GUI, whenever we set threshold other than 0, let say 3V, when we switch off the dso, switch on again and activate LA GUI, it saved threshold (non zero) we set earlier, so far so good. but probing threshold voltage level going into comparator (internal of LA probe) and playing on actual signal probed with LA, the actual threshold is zero! even if in GUI its non-zero, the workaround is we need to set the threshold again and hit OK without changing value, to make the dso send the correct threshold voltage into the comparator circuit, fwiw.
-
Did you have the probe already connected when the scope was powered on? Maybe the power-on initialization only sets the logic analyzer parameters when it sees a probe. (And Rigol does state that the probe should not be hot-plugged anyway.)
But of course it is entirely possible that there is another little bug there...
-
If I set the screen so that signal shows like a flat line on the screen the trigger functionality should not be impacted
Says who?
On a DSO the input voltages don't go past the ADC. The trigger works with sampled values, not raw voltages.
If the signal is two pixels high on screen then why would the trigger work?
(cue all the pedants with fancy scopes that have separate analog trigger circuits inside them...)
This dreadful! With noise rejection on A 3V Sine wave from the signal generator at almost full-screen won't trigger below -1.2V! That's almost 10% of the bottom of the waveform, yet it triggers perfectly at the top of the waveform (1.48V)
There is definitely something very wrong with the triggers. There is no reason for the discrepancy between the top and bottom of a sine wave.
-
This dreadful! With noise rejection on A 3V Sine wave from the signal generator at almost full-screen won't trigger below -1.2V! That's almost 10% of the bottom of the waveform, yet it triggers perfectly at the top of the waveform (1.48V)
There is definitely something very wrong with the triggers. There is no reason for the discrepancy between the top and bottom of a sine wave.
This has all been discussed before, probably on this very thread. I seem to recall that the asymmetry in the trigger behavior changes with the polarity of the active edge you select for the trigger. I.e. when you switch to falling edge, the trigger will not work near the maximum of the signal.
There is some logic to this: The trigger hysteresis is implemented such that there always needs to be some "runway" for the signal as it approaches the trigger threshold. Whether or not it keeps changing further beyond the trigger threshold does not matter.
I don't consider this a bug.
-
You're right. I just powered up my Siglent SDS1204X-E and it has exactly the same behavior.
In all the years I've used these scopes I've never noticed that before!
Thinking about it, when looking for small transient spikes I have sometimes had to set it to falling edge to catch them at low levels, but I always assumed it was something I was doing wrong, rather than the behavior of the triggers.
Thanks,
J.
-
In all the years I've used these scopes I've never noticed that before!
Now you will, and you will have to live with it from now on. Thank the forum :)
-
Did you have the probe already connected when the scope was powered on?
yes. but i tried again just now without LA probe connected and turning on the dso, and then hot plugging the probe.. same thing, dso will show up "LA Probe Connected" message and then i can operate LA. but during hot plugging, the message popped up and disappear several time indicating intermittent hot plugging by hand which imo is not so ideal, so yes on safer side, its better soft plugging and leave the LA probe there. btw, when the probe connected, the comparators will increased temperature in open air maybe up to 60degC or so, fwiw ymmv..
-
Did you have the probe already connected when the scope was powered on?
yes. but i tried again just now without LA probe connected and turning on the dso, and then hot plugging the probe.. same thing, dso will show up "LA Probe Connected" message and then i can operate LA. but during hot plugging, the message popped up and disappear several time indicating intermittent hot plugging by hand which imo is not so ideal, so yes on safer side, its better soft plugging and leave the LA probe there. btw, when the probe connected, the comparators will increased temperature in open air maybe up to 60degC or so, fwiw ymmv..
Can you post the logic analyzer PCB files? Or maybe they can already be downloaded somewhere?
-
Is it just my 924S, or does everyone see this issue?
Run the test signal into CH1, and enable CH2 with no probe attached.
Set the timebase to 50ms, so the scope enters roll-mode, and the screen shows CH2 'smeared' down to CH1's value.
Here's what I see when I try it:
https://youtu.be/pMFDayEhk_Y (https://youtu.be/pMFDayEhk_Y)
-
Is it just my 924S, or does everyone see this issue?
Run the test signal into CH1, and enable CH2 with no probe attached.
Set the timebase to 50ms, so the scope enters roll-mode, and the screen shows CH2 'smeared' down to CH1's value.
Here's what I see when I try it:
https://youtu.be/pMFDayEhk_Y (https://youtu.be/pMFDayEhk_Y)
On my 814, modified to 914, I don’t see this. What is the firmware version on your oscilloscope?
-
Is it just my 924S, or does everyone see this issue?
Run the test signal into CH1, and enable CH2 with no probe attached.
Set the timebase to 50ms, so the scope enters roll-mode, and the screen shows CH2 'smeared' down to CH1's value.
Here's what I see when I try it:
https://youtu.be/pMFDayEhk_Y (https://youtu.be/pMFDayEhk_Y)
Tried to replicate this with 924S with firmware 00.01.02.00.02 in many attempts with no luck. However, once CH1 was shifted upwards for one roll - another bug?
Maybe You have random short between two channels on ADC, because of too much solder, but its my guess.
-
Maybe You have random short between two channels on ADC, because of too much solder, but its my guess.
It’s unlikely, because this doesn’t appear in all modes.
-
Maybe You have random short between two channels on ADC, because of too much solder, but its my guess.
It’s unlikely, because this doesn’t appear in all modes.
I checked Dave photos and looks like its (very little) possible only between those LC filters. Of course I cant see below ADC IC, but there is no reason to be any traces there.
Edit: added photo fragment.
-
924S firmware 02.00.02 I did not manage to cause the bug.
I tried all the settings combinations that I could think of and it didn't work.
If you set a measurement to channel 2, does it measure anything?
For example Vpp or frequency?
-
It seems that something similar was mentioned earlier among oscilloscope bugs. Either here on the forum, or in one of the videos. But that was a long time ago, on one of the old firmware versions.
I checked Dave photos and looks like its (very little) possible only between those LC filters. Of course I cant see below ADC IC, but there is no reason to be any traces there.
Edit: added photo fragment.
Well, these LC filters belong to the same channel, so there certainly can’t be a problem with them :)
Although in general, excess solder may well end up on the board. This is what I found on the board of my oscilloscope when I recently took it apart.
-
previously running old version v1.14 for DHO924S... now running latest version v0.1.2.0.2 digital trigger (D0-D15) was working before, now its not working, it keeps changing back to analog signal (CH1-CH4) :palm:
-
New Bug?? Cursors stop working
Scope: DHO804
FW: 00.01.01 (not modded)
This is the fw that was delivered with the scope purchased about 1 month ago.
Hey Group,
I believe I have found a bug where the cursors stop working and the only way to get them back is to reboot the scope.
Conditions:
Connect scope probe from CH2 (not CH1) to 1KHz sq wave cal point on right hand of scope.
Press AUTO to get proper display of sq wave.
Turn on Cursors
Press AUTO again
Cursor panel now only shows "*****" for all cursor parameters and even if you move probe to CH1 you can not get cursors back ON.
Also Cursor control knobs do not light up (they do both blink for a short moment when pressing "Cursor")
The cursor data panel does disappear and come back on display but all values still show "*****"
The only way I have found to get the cursors working again is to reboot the scope.
Possibly this is fixed in the latest factory firmware which I have not tried yet.
Just wanted to post here first so please forgive me if the standard is to always check for updated firmware before posting here.
If you start with the probe in CH1 Cursors work fine even after hitting AUTO but if you move the probe to CH2 and press AUTO you can not get the cursors to work even after moving the probe back to CH1.
Once the cursor data panel shows "*****" you have to reboot to get them to work again.
Anyone else see this behavior??
It only seems to happen when a signal is on CH 2,3,4
I can't get it to fail if I ONLY use CH1
cheers
Dwight
-
924S firmware 02.00.02 I did not manage to cause the bug.
I tried all the settings combinations that I could think of and it didn't work.
If you set a measurement to channel 2, does it measure anything?
For example Vpp or frequency?
I'm also on the latest firmware 0.01.02.
Channel 2 seems to work fine, but when a Maths of A+B is run on CH1 and CH2 it shows a voltage of 745V P-P, so it really does believe the input on CH2 is huge, but the same effect happens for CH3 and CH4, so it looks software related.
I've done a recalibrate, tried to reset everything I can find, and still it occurs.
-
Ah-ha! As a last resort I re-re-installed the latest GEL file (which I already did once to try and resolve my non-operating fan), and the problem seems to have cleared.
I don't think it was an issue with the original installation, but I think the re-running of 'Upgrade' has done a low-level reset of all of the configuration data.
What does concern me is that something I did when messing around (with the FFT settings?) may have caused the problem to occur in the first place, but I'll just have to keep an eye open for it in future.
-
Once the cursor data panel shows "*****" you have to reboot to get them to work again.
Lol yes I can reproduce it. However you don't need to reboot to get them back: tap the cursors box in the measurement results side panel, then Setting in the menu that pops up, then change source: NONE to Ch2, and they should start working again.
After this is done, I can no longer reproduce the original behavior with the auto button.
I have the latest firmware installed.
-
Cursor panel now only shows "*****" for all cursor parameters and even if you move probe to CH1 you can not get cursors back ON.
You have to tell cursors what they're supposed to be measuring otherwise they show "*****"
By messing around with AUTO so much the cursors aren't sure what to display.
Lol yes I can reproduce it. However you don't need to reboot to get them back: tap the cursors box in the measurement results side panel, then Setting in the menu that pops up, then change source: NONE to Ch2, and they should start working again.
Yep.
-
After this is done, I can no longer reproduce the original behavior with the auto button.
I have the latest firmware installed.
Switch the cursors to Ch1, turn off Ch1 and press Auto again. The cursors will again move to the source NONE :)
-
Somebody asked about different resolutions and different monitors, so I can confirm it works well with Eizo S2100 which is 1600x1200 (4:3). Via HDMI-DVI adapter.
-
I built Nikki Smith-s logic probe from the hacking thread, but the decoder in the scope is disappointing.
With the scope in stop mode, scrolling trough the horizontal the decode appears and disappears. Viewing long messages is almost impossible, because the character size is too big and scrolling is useless.
(D0 D1 UART decode 115200)
https://www.youtube.com/watch?v=ratTksr1WjE (https://www.youtube.com/watch?v=ratTksr1WjE)
-
I built Nikki Smith-s logic probe from the hacking thread, but the decoder in the scope is disappointing.
With the scope in stop mode, scrolling trough the horizontal the decode appears and disappears. Viewing long messages is almost impossible, because the character size is too big and scrolling is useless.
(D0 D1 UART decode 115200)
I don't know how sympathetic Rigol will be about your "Bug Report" when you are using homebrew interface on one of their scopes.
But, if you go back through the bug report pages here, you'll see that Rigol has issues to work out with several decoders on this model. Sorry if that doesn't help your plea.
Did you try the same test using Analog(instead of digital) channels?
BTW: After thinking a bit about your video, I wonder if the "data flashing" is just the system having to redraw the decoded data, not actually dis/re-appearing... Since, it doesn't actually lose the data. Just a thought.
-
Since the scope is in stop mode I'm 100% sure the same issue can be reproduced with the original probe, and having the advantages of voltage treshold for logic levels. Note this is a kitted out DHO924S and not a hacked one. Only the cable is a simple lvds driver and not comparator based.
Problem is the decode dissapears in some offsets and comes back only if I moove along the trace.
Comparing the price point and functionality of a salaee and the logic cable of the rigol I'dont see how usefull this is for serial busses.
Also I don't care fore their sympathy, they were unable to answer the simple question of how to generate arb files for this scope, until someone tried all combinations of other devices and found one that works.
-
i reported 2 LA bugs in my video... edited/update: this is not a bug...
https://www.youtube.com/watch?v=xQMI5cH_AkI (https://www.youtube.com/watch?v=xQMI5cH_AkI)
I don't know how sympathetic Rigol will be about your "Bug Report" when you are using homebrew interface on one of their scopes.
i hope they listen since i highly believe the same bugs will also occur with the original LA probe since there is no way of knowing for the DSO to detect whether its seeing a knock off or original probe, its just not much people own original probe so we dont have a high chance of seeing reports from them, fwiw...
-
i reported 2 LA bugs in my video...
https://www.youtube.com/watch?v=xQMI5cH_AkI (https://www.youtube.com/watch?v=xQMI5cH_AkI)
I don't know how sympathetic Rigol will be about your "Bug Report" when you are using homebrew interface on one of their scopes.
i hope they listen since i highly believe the same bugs will also occur with the original LA probe since there is no way of knowing for the DSO to detect whether its seeing a knock off or original probe, its just not much people own original probe so we dont have a high chance of seeing reports from them, fwiw...
I was unable to reproduce all your issues with the LA using a DHO924S with PLA2216 active probe.
The issue with the LA threshold appearing in menus/windows other than the LA dialog box is a problem with SPI decode too, and so it confuses itself. (Worse is that the digital threshold defaults to 0V.)
I could switch between digital and analogue channels for the trigger with no problem. I also had no problem adjusting the thresholds in the LA screen, and noted there's about 150mV of hysteresis on the LA channels.
It did show up another issue though: the build in AFG has a -150mV offset on my unit.
Each and every time I turn on this scope, I despise it more, almost all down to firmware bugs.
-
I built Nikki Smith-s logic probe from the hacking thread, but the decoder in the scope is disappointing.
With the scope in stop mode, scrolling trough the horizontal the decode appears and disappears. Viewing long messages is almost impossible, because the character size is too big and scrolling is useless.
(D0 D1 UART decode 115200)
https://www.youtube.com/watch?v=ratTksr1WjE (https://www.youtube.com/watch?v=ratTksr1WjE)
Same thing occurs with a PLA2216.
-
I was unable to reproduce all your issues with the LA using a DHO924S with PLA2216 active probe.
thanks for letting me know. are you using latest FW 00.01.02.00.02? https://supportint.rigol.com/SUPPORTS/software-firmware-download.html
I could switch between digital and analogue channels for the trigger with no problem. I also had n problem adjusting the thresholds in the LA screen.
as i mentioned in the video. i was able to do this in older FW 1.14 for DHO900 from hubertyoung's FW image. maybe some files specific to DHO900 are missing in my DHO800 that LA GUI is looking for it. thanks you gave me some idea, maybe this is not a bug.
It did show up another issue though: the build in AFG has a -150mV offset on my unit.
Each and every time I turn on this scope, I despise it more, almost all down to firmware bugs.
i built AFG replica as well and my latest prototype indicates about -15mV offset. i guess its due to resistors pair mismatch on the AD9744 DAC or differential opamp AD8009 (marked as HKJ) after it. maybe tuning them with parallel resistor may correct it in HW if this issue is too disturbing, but i understand you as a legit user will not expect this kind of fix. not sure if there is another file in DHO900 specific for this correction, but my workaround is i set the offset in GUI 15mV in the other direction to compensate, unfortunately its not saved when i turn the dso off. but for bode plot, set the dso analog input to AC coupled should eliminate this problem. iirc both CH input used as bode plot will automatically switched to AC coupled when bode plot is started. ymmv.
-
I was unable to reproduce all your issues with the LA using a DHO924S with PLA2216 active probe.
i changed back to older FW 1.14 for DHO924S, i demonstrated logic channel triggering is working in the video, just upgrading to FW1.2.2, its not working anymore... fwiw... edited/update: this is not a bug..
https://www.youtube.com/watch?v=McU4yO4jeYo (https://www.youtube.com/watch?v=McU4yO4jeYo)
-
I was unable to reproduce all your issues with the LA using a DHO924S with PLA2216 active probe.
i changed back to older FW 1.14 for DHO924S, i demonstrated logic channel triggering is working in the video, just upgrading to FW1.2.2, its not working anymore... fwiw...
https://www.youtube.com/watch?v=McU4yO4jeYo (https://www.youtube.com/watch?v=McU4yO4jeYo)
Here's a screenshot of my firmware etc where I could change the LA trigger channels successfully.
I thought this was 1.02.00.02, I updated it on 29 January according to my records, and the build time on the scope says 3 January. Is this the same as your "FW1.2.2"?
-
I thought this was 1.02.00.02, I updated it on 29 January according to my records, and the build time on the scope says 3 January. Is this the same as your "FW1.2.2"?
maybe my hardware 12 has something to do with it, thanks for your info. (yes i currently use the same FW as yours.)
-
DHO814:
Random triggers on single and timeout:
It does it too, when in the ns scale, so there are no spikes to find.
It happens after 1 to 5.7 seconds (4s average). Noise reject does not help, and changing the level has semingly no effect.
-
I take it that the desired trigger condition still occurs frequently -- so the scope does not "run out of patience" in Auto-trigger mode and trigger for that reason?
(Does anything change if you switch triggering to Normal?)
-
I take it that the desired trigger condition still occurs frequently -- so the scope does not "run out of patience" in Auto-trigger mode and trigger for that reason?
(Does anything change if you switch triggering to Normal?)
I also tested 924S and yes.
It is present for both Normal and Single triggers.
It looks like if the Slope is set to "Falling, Either", it triggers randomly without a signal.
It looks good on the "Rising" setting.
I was wrong.
If the trigger is set to a negative value, the "Rising" setting triggers randomly. "Falling" looks good.
If the trigger is set to a positive value, the "Falling" setting triggers randomly. "Rising" looks good.
"Either" is wrong in both cases. |O
-
If the trigger is set to a negative value, the "Rising" setting triggers randomly. "Falling" looks good.
The "trigger" has several values. Which one are you talking about?
-
If the trigger is set to a negative value, the "Rising" setting triggers randomly. "Falling" looks good.
The "trigger" has several values. Which one are you talking about?
Sorry, I meant the trigger level. voltage
-
Trying the recording function:
I have CAN frames, that i would like to look at. Tried using the record feature, that should be perfect for this. Set up the interval to the frame interval. Doesnt work: the smallest interval i had achieved was somewhere around 5ms, and fluctuating.
Can anyone achieve better? If not, i then call this another bug, but a major one, as this makes the feature practically useless. :palm:
-
About 5 ms time intervals were the best I could achieve with my DHO1074 as well. That included a test with a trivial edge trigger, looking at fast square-wave bursts.
Notably, the time stamps were even lying about those 5 ms increments: The last of 1000 records was captured at approx. 5000 ms according to its time stamp. But looking at a stop watch, it had taken about 14 seconds to capture those 1000 records! (And the progress bar had moved at a constant rate throughout.)
One of the reasons I no longer have the DHO1074...
-
Trying the recording function:
I have CAN frames, that i would like to look at. Tried using the record feature, that should be perfect for this. Set up the interval to the frame interval. Doesnt work: the smallest interval i had achieved was somewhere around 5ms, and fluctuating.
Can anyone achieve better? If not, i then call this another bug, but a major one, as this makes the feature practically useless. :palm:
Is this running the latest FW 00.01.02.00.02 ?
-
Is this running the latest FW 00.01.02.00.02 ?
Does that imply that you have achieved faster recording rates with the latest software? Could you please summarize what you get? Thanks!
-
Is this running the latest FW 00.01.02.00.02 ?
Alltough you have to create a account at the rigol site, which did not work at all, to download the firmware, i managed to get it from another source. Yes it is running this firmware.
None of the major bugs i stumbled upon were fixed...
-
By the way: I am not aware that a login is required to download Rigol firmware from the official site. I found the product pages to be better organized than the "support" section, and they also include manuals/firmware/software.
On the product page, scroll down a bit until you get to the white section of the page, then select the "software & firmware" tab: https://int.rigol.com/products/detail/DHO800
-
That did NOT work here:
https://supportint.rigol.com/SUPPORTS/software-firmware-download.html
What a mess it is!
First product i bought from Rigol, and i think it will also be the last...
-
The signal is good when it runs, but when i stop the acquire, it gets messy (see picture). Is this a bug or a feature? Persistance is set to min
-
The signal is good when it runs, but when i stop the acquire, it gets messy (see picture). Is this a bug or a feature? Persistance is set to min
Is Gear/Display/Waveform Freeze set to On or Off? If it's ON, try it in the Off position.
-
I am not sure whether you are concerned about decoding or about the trace display itself. Assuming it's the trace rendition:
The DHOs let you choose whether, after stopping the acquisition, you want to see only the most recent capture, or want to "freeze" the intensity-graded overlay of multiple sweeps. The latter is the default, a bit unconventionally. You can change this in the display settings, see section 19.8 of the manual.
-
That did NOT work here:
https://supportint.rigol.com/SUPPORTS/software-firmware-download.html (https://supportint.rigol.com/SUPPORTS/software-firmware-download.html)
What a mess it is!
First product i bought from Rigol, and i think it will also be the last...
There european site is a simple mess. We already had that here. Get the firmware in the U.S. - this is working without login.
https://www.rigolna.com/firmware/ (https://www.rigolna.com/firmware/)
-
The latter is the default, a bit unconventionally.
Why would i want to see intensity when stopped, if i had not set it up before? That is stupid, but at least this stupidity can be turned off. :phew:
-
Bug: Trigger is off big time..
Its kinda hard to work on a prototype with a chip that you dont have much experience with. Yet here comes rigol, making your day even harder:
-
Why would i want to see intensity when stopped, if i had not set it up before? That is stupid, but at least this stupidity can be turned off. :phew:
Maybe they wnated to make sure that all users realize the DHO has that capability. ::)
But once you turn it off, the scope should remember the setting, so it won't bother you again until you ask for it.
Don't be too harsh on your new scope and on Rigol. Always look on the bright side... ;) On the other hand, if you really find that the scope does not do what you need it to do, there's still time to swap it for something a bit less shiny but more serious...
-
But once you turn it off, the scope should remember the setting, so it won't bother you again until you ask for it.
If I remember correctly.
According to the factory settings, it does not load the last one, you will have to change it first.
-
According to the factory settings, it does not load the last one, you will have to change it first.
Yes, yet another stupid default setting...
I was shocked the first time when i started it the next day, when all settings were lost, because i thought there would be no such option. Funny enough i need to restart it, when i want all setting reset, and wait 53 secounds? :palm:
-
I was shocked the first time when i started it the next day, when all settings were lost, because i thought there would be no such option. Funny enough i need to restart it, when i want all setting reset, and wait 53 secounds? :palm:
It's debatable whether "restart with factory defaults" should be the default setting. But having that startup mode available certainly makes sense in environments where the scope is used by multiple people for different tasks, and most notably in education & training use.
And of course restarting the scope is not the only (and slow) way to get back to the default settings. There is a dedicated button for that, part of the hexagon in the upper right. Press it twice, or press once and confirm in the touch-screen menu, to return to the factory defaults quickly.
-
Funny enough i need to restart it, when i want all setting reset, and wait 53 secounds? :palm:
Or just press this...
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=2076896;image)
-
Persistance is not persistant on first few triggers:
I have some signals, that appear about every 0,5 to 1 s, and the div is set at 10us. You can see the first signal beeing triggered, but they dissapear immediately. Only after a few of those they stay. Persistance is set at "infinite". The trigger is a simple falling edge.
So persistance is not working, recording is not working and ultraacquire is also not working.
This Rigol rubbish is definately going back. Cant even do simple things reliable. :--
-
Funny enough i need to restart it, when i want all setting reset, and wait 53 secounds? :palm:
Or just press this...
Here's an idea for you, Fungus: Why don't you try and make it a habit to read the following post or two before you fire off a reply? ::)
It would improve the signal-to-redundancy ratio of many threads quite a bit.
-
Or just press this...
It would help a lot if you would actually read a few more posts, to not parrot :blah: from other users, or to just comprehend whats going on. You already stood out for me like someone that creates more confusion as really helping. Just like in my noise problem thread... :--
-
According to the factory settings, it does not load the last one, you will have to change it first.
Yes, yet another stupid default setting...
I was shocked the first time when i started it the next day, when all settings were lost, because i thought there would be no such option. Funny enough i need to restart it, when i want all setting reset, and wait 53 secounds? :palm:
then why you post this mourning if the default button is not what you want?
-
BTW, is there any way to disable the Auto button?
It is very annoying, as it doesn't request confirmation before proceeding. It is quite easy to press it accidentally. It is ridiculous that scope manufacturers (not only Rigol) waste front panel space for this button, and for Default as well, instead of moving them to an on-screen menu. Luckily, the Default button does at least request confirmation to proceed. It's still not impossible to press it twice accidentally though.
-
then why you post this mourning if the default button is not what you want?
The info about the Default button was relevant for eTobey, I think. But coming from Fungus, it was also redundant, since I had just said the same thing -- in the very next post after eTobey's original complaint, and right before Fungus' post.
Which is quite often the case with Fungus. He seems to be in the habit of firing off a reply as soon as he sees a post, not bothering to read even a single following post to check what has already been said.
-
BTW, is there any way to disable the Auto button?
You can disable/enable it via a SCPI command, :SYSTem:AUToscale <bool>.
I think Rigol deliberately hid that option in a SCPI command with educational settings in mind: The teacher can disable AUTO for his students so they learn how to set up the scope on their own, and they can't easily re-enable it.
-
...
It is very annoying, as it doesn't request confirmation before proceeding. It is quite easy to press it accidentally. It is ridiculous that scope manufacturers (not only Rigol) waste front panel space for this button...
I was just on this point a few hours ago... There is a button to revert that. But you better dont miss that button! I missed it |O... Really frustrating.
I sometimes have the feeling, that touchscreen behaves a bit strange. Missing buttons and closing windows. Might be some electrostatic problems?
-
My waveform dissappeared. Just catched an error... :palm:
I did not use vernier, like dave did in the video.
I was just scaling and moving it time wise.
Anyone knows how to avoid this problem, or where it happens?
This bug was documented by dave 5 months ago! And yes, i have the newest firmware.
https://www.youtube.com/watch?v=EVRdTY4LNhg (https://www.youtube.com/watch?v=EVRdTY4LNhg)
-
Level of trigger is not saved when turning off....
This is even worse than saving nothing at all, as you would not expect this, and then you may end up looking at the board... :-/O
Edit: Even the hex format is lost. I could live with this, but still its so poor.
First days i thought "not so much complaining like with the owon", but today i realized, that i just was to slow to find those problems.
-
Level of trigger is not saved when turning off....
This is even worse than saving nothing at all, as you would not expect this, and then you may end up looking at the board... :-/O
Lol what a mess.
It does save trigger level (any type) for channels 1 and 2, and does not (any type) for channels 3 and 4.
Besides, it always boots with channel 1 turned ON, even if it was off before the power-off, if one of 2, 3, 4 is turned on.
Rigol's software engineering is absolutely terrible. No, it's ok to have bugs in your code. It's not ok to fail so miserably at QA before releasing the product, and even less ok to fail to release bugfixes in a timely manner.
I think it's my first and last Rigol product. No, it's a nice little scope, I do like it, even more so because of the fact that it's very hacking-friendly. I'm keeping it. But I think I've already had enough of dumb bugs that a junior QA engineer would catch minutes after a development release was built, and of the attitude that makes this possible.
-
Perhaps I missed the chatter in last page or so around remembering settings at power-off.
Isn't there an on/off setting for just that, to "start with last settings"?
-
Perhaps I missed the chatter in last page or so around remembering settings at power-off.
Isn't there an on/off setting for just that, to "start with last settings"?
Yes there is. It doesn't help to get those trigger levels remembered.
-
Now i know why they dont let the scope reload settings after restart by default: Its a complete MESS! :-BROKE
As not loading single value wasnt bad enough, it gets even WORSE: :wtf:
The trigger ID format is not only not remembered (sets to binary), the right value is shown, but not triggering. It triggers on any ID it seems! :palm:
Cant wait to get the sds814 today to get things done, and not to get confused!
-
The trigger ID format is not only not remembered (sets to binary), the right value is shown, but not triggering. It triggers on any ID it seems!
That's a likely type of software bug, and I think we saw at least one of a similar flavor, where a threshold setting (?) was remembered in the UI but was not actually functional. It's an easy error to make for the firmware developers: Store and recall the parameters in some set of variables on the CPU side, but forget that something also needs to be actively set up in the FPGA or other hardware component.
But because it is so easy to get wrong, it should of course also be verified as part of a systematic software QC...
-
hello, i have recently acquired a DHO924S and created some bode plots for various passive components with success and no issues at all.
Untill today that i tried to do the same but using ch1 as input and ch4 as output (untill now i only used ch1 and ch2 respectively).
In short it doesnt work :-\ . It auto ranges the vertical scale of ch4 to minimum voltage of 200 microvolts and sets the bandwidth limit at 20Mhz for that channel also, bode plot results of course were way off normal. My testing bandwidth was 100hz to 25Mhz with 5vpp output.
I checked the manual and it doesnt mention that bode plot feature can be only used with ch1 and ch2.
Any other combination i tried (ch1 and ch3, ch2 and ch3, ch3 and ch4, ch2 and ch4 ) didnt work as well.
I also tried to default the settings, restart etc but with no luck.
Maybe i do something wrong as a newbie i dont know ;D
(firmware version is 00.01.02)
* and the reason that i tried to use ch1 and ch4 is that i pulled from my bag the ch4 compensated probe and didnt want to adjust it again for ch2
-
I am having trigger problems for any channel even single waveforms below 100us timebase.
I cannot trigger it correctly since for a simple 0-5Vp square waveform appears flickering as shown in attacment.
I have reduced the Horizontal Acquisition, the Memory depth. nothing.
The problem appears for any waveforms also in the 100us timebase.
What am I doing wrong?
Thank You in advance.
-
I am having trigger problems for any channel even single waveforms below 100us timebase.
I cannot trigger it correctly since for a simple 0-5Vp square waveform appears flickering as shown in attacment.
I have reduced the Horizontal Acquisition, the Memory depth. nothing.
The problem appears for any waveforms also in the 100us timebase.
What am I doing wrong?
Thank You in advance.
You can try "Normal" trigger, it may be caused by "Auto" trigger timeout.
-
I am having trigger problems for any channel even single waveforms below 100us timebase.
I cannot trigger it correctly since for a simple 0-5Vp square waveform appears flickering as shown in attacment.
I have reduced the Horizontal Acquisition, the Memory depth. nothing.
The problem appears for any waveforms also in the 100us timebase.
What am I doing wrong?
Thank You in advance.
Try to trigger on rising edge OR falling edge, not *both*, that you have in the screenshot.
-
I cannot trigger it correctly since for a simple 0-5Vp square waveform appears flickering as shown in attacment.
What am I doing wrong?
The screenshot and video show that you have selected the trigger to act on both, positive and negative edges. So it will sometimes trigger at the beginning, sometimes at the end of the "high" phase of the signal. Select either positive or negative edge in the trigger setting.
In the video, you have also set the trigger threshold pretty high -- so the trigger could also be caused by the small oscillation after the signal's positive edge. Better to set the trigger threshold about halfway between the 0V and 5V levels, for best noise immunity.
Finally, this appears to be a signal with fast pulses (800 ns long) but long gaps inbetween (assuming it comes from the internal generator, which is set to 1 kHz). So the scope may "lose patience" while waiting for the next trigger event, and start a capture on its own. That's what it does in "Auto trigger" mode, to avoid a situation where you see no signal at all. As suggested by electronics hobbyist, set the scope to Normal trigger instead.
-
playing with 16bit data out of DHO800 to PC and plot FFT... i'm sensing 156.25MHz -30dB artefact when no signal on input (50 ohm terminated), attached also different artefact profile from 8bit DS1054Z, maybe it matters? or something i did wrong :-//
-
wishlist: please rigol, enable single window overlayed display on DHO800/900 like in DHO1000, its just a simple enable/disable toggle switch in FW? what do you care if we want overlayed display on small screen? :palm:
https://www.eevblog.com/forum/testgear/choosing-between-entry-level-12-bit-dsos/msg5432216/#msg5432216 (https://www.eevblog.com/forum/testgear/choosing-between-entry-level-12-bit-dsos/msg5432216/#msg5432216)
https://www.eevblog.com/forum/testgear/choosing-between-entry-level-12-bit-dsos/msg5432306/#msg5432306 (https://www.eevblog.com/forum/testgear/choosing-between-entry-level-12-bit-dsos/msg5432306/#msg5432306)
https://www.eevblog.com/forum/testgear/choosing-between-entry-level-12-bit-dsos/msg5432441/#msg5432441 (https://www.eevblog.com/forum/testgear/choosing-between-entry-level-12-bit-dsos/msg5432441/#msg5432441)
https://www.eevblog.com/forum/testgear/choosing-between-entry-level-12-bit-dsos/msg5432615/#msg5432615 (https://www.eevblog.com/forum/testgear/choosing-between-entry-level-12-bit-dsos/msg5432615/#msg5432615)
DHO1000:
(https://www.eevblog.com/forum/testgear/choosing-between-entry-level-12-bit-dsos/?action=dlattach;attach=2098949;image)
DHO800/900 (no "Display Area" option):
(https://www.eevblog.com/forum/testgear/choosing-between-entry-level-12-bit-dsos/?action=dlattach;attach=2099156;image)
-
playing with 16bit data out of DHO800 to PC and plot FFT... i'm sensing 156.25MHz -30dB artefact when no signal on input (50 ohm terminated), attached also different artefact profile from 8bit DS1054Z, maybe it matters? or something i did wrong :-//
I can try to take out the bin file from DHO1074, just tell more about the settings.
Also, I am interested regarding the software you have used. It's open source or :(
-
playing with 16bit data out of DHO800 to PC and plot FFT... i'm sensing 156.25MHz -30dB artefact when no signal on input (50 ohm terminated), attached also different artefact profile from 8bit DS1054Z, maybe it matters? or something i did wrong :-//
This peak at a frequency of 156-odd MHz (and its harmonics) is clearly visible even on the oscilloscope itself in the FFT window. Some kind of internal interference from the operation of the circuit.
-
This peak at a frequency of 156-odd MHz (and its harmonics) is clearly visible even on the oscilloscope itself in the FFT window. Some kind of internal interference from the operation of the circuit.
It's 1/8 of the main 1.25 GHz sampling clock, right?
-
This peak at a frequency of 156-odd MHz (and its harmonics) is clearly visible even on the oscilloscope itself in the FFT window. Some kind of internal interference from the operation of the circuit.
It's 1/8 of the main 1.25 GHz sampling clock, right?
Very similar to that. Maybe the interface between the ADC and the FPGA operates at this frequency?...
-
This peak at a frequency of 156-odd MHz (and its harmonics) is clearly visible even on the oscilloscope itself in the FFT window. Some kind of internal interference from the operation of the circuit.
It's 1/8 of the main 1.25 GHz sampling clock, right?
my concern if this is another riglol scenario, but since ds1000z also has it probably it is normal or not easily fixable? i'll leave that open to more expert people, and i will just enjoying my scope and try to compensate at that frequency (or avoid that region) if a task requires it. ymmv.
I can try to take out the bin file from DHO1074, just tell more about the settings.
my setting was 625MSps because i was watching a 20MHz signal, full sample rate 1.25GSps will make that signal goes further to the left, less undesirable. but that FFT plot i linked above is when no signal at 1X dso input setting and 50 ohm terminator in place. anything greater than 1Mpts points will make a descent FFT resolution plot (at least when using my app). as AndyBig mentioned you should be able to see it on your scope's display as well if the artefact presents or not. ymmv.
Also, I am interested regarding the software you have used. It's open source or :(
you can google VisaDSO in soasystem.com for setup file download. i've given up promoting it since i guess new kids on the block dont like older VB app, let the lucky persons found it by themselves. sometime stranger from unknown emailed me for the code, but once i sent it, they never come back to give feedback, so its like a waste of time, and probably nobody like nor can comprehend the old VB syntaxes anyway... i saw some bugs on latest upgrade to support DHO800/900, since afaik i'm the only one who's using it, i dont bother to fix asap, unless when necessity arrived. ymmv.
-
This peak at a frequency of 156-odd MHz (and its harmonics) is clearly visible even on the oscilloscope itself in the FFT window. Some kind of internal interference from the operation of the circuit.
It's 1/8 of the main 1.25 GHz sampling clock, right?
Looks like typical ADC interleaving spurs, i.e. small mismatch between the interleaved ADC branches. The spurs here1) look particularly like offset spurs. Self-calibration may help, but the accuracy and resolution of the calibration may still not be sufficient to eliminate them completely (note that offset mismatch in the amount of only a fraction of an LSB are sufficient to show up as spurs in a FFT with a large number of points).
1) located at sample_rate/N*n, where N is the number of ADC branches, and n is 1...N/2.
-
I can try to take out the bin file from DHO1074, just tell more about the settings.
my setting was 625MSps because i was watching a 20MHz signal, full sample rate 1.25GSps will make that signal goes further to the left, less undesirable. but that FFT plot i linked above is when no signal at 1X dso input setting and 50 ohm terminator in place. anything greater than 1Mpts points will make a descent FFT resolution plot (at least when using my app). as AndyBig mentioned you should be able to see it on your scope's display as well if the artefact presents or not. ymmv.
Also, I am interested regarding the software you have used. It's open source or :(
you can google VisaDSO in soasystem.com for setup file download. i've given up promoting it since i guess new kids on the block dont like older VB app, let the lucky persons found it by themselves. sometime stranger from unknown emailed me for the code, but once i sent it, they never come back to give feedback, so its like a waste of time, and probably nobody like nor can comprehend the old VB syntaxes anyway... i saw some bugs on latest upgrade to support DHO800/900, since afaik i'm the only one who's using it, i dont bother to fix asap, unless when necessity arrived. ymmv.
Very interesting information on this little site. I am a Linux user, but I think I will try VisaDSO in a virtual machine.
Thanks for sharing!
P.S. Your "natural habitat" is incredibly small and crowded!
-
Hello !
I have a Siglent SDS1104X-E , no issue with it, but this DHO with Android inside and this user interface seems to be really great :-+
But I have a question about the 256 level intensity grading.
I have seen some reviews, starting by Dave one's ;) and it seems to me that the grading is not very good, compare with my Siglent.
Most of the time, I see big yellow color on waveform, without any grading :-//
Here are some pictures I have made with my Siglent, compared to the Dave's opening video of this topic :-+
What do you think ? Is there a kind of bug on the graphical output display of the Rigol ?
Also, while I was making the screenshots, I have found that the Rigol has only 10 divisions on the time axes , whereas the Siglent shows 14.
So on the 2 first screenshot, we can see more of the signal on the Siglent than on the Rigol ???
-
I have seen some reviews, starting by Dave one's .......
You've been not here for a bit you said so may have missed......Dave just received 2 of the new Siglent 12bit scopes to review....
-
I'm not sure. In practice, I find it doing its job very well at intensity grading to help discern noise from useful signal, catch infrequent events etc.
There's a lot of room for possible adjustment using the trace brightness and the persistence timeout settings.
One caveat: intensity grading works only when the trigger is triggering. Otherwise, the trace is drawn at 100%.
-
Also, while I was making the screenshots, I have found that the Rigol has only 10 divisions on the time axes , whereas the Siglent shows 14.
So on the 2 first screenshot, we can see more of the signal on the Siglent than on the Rigol ???
Rigol grid squares are wider...
So on the 2 first screenshot, we can see more of the signal on the Siglent than on the Rigol
I can see more detail on the Rigol.
-
Seems like Rigol has slowed down firmware releases for the DHO800/900 family. They were averaging ~1 release per month but that change after December 2023.
- v00.01.02.00.02 2023/12/28 (latest release)
- v00.01.02.00.01 2023/12/5
- v00.01.02.00.00 2023/11/2
- v00.01.01.00.02 2023/09/12
- v00.01.01.00.01 2023/08/10
- v00.01.00.00.19 2023/07/24
-
Seems like Rigol has slowed down firmware releases for the DHO800/900 family. They were averaging ~1 release per month but that change after December 2023.
- v00.01.02.00.02 2023/12/28 (latest release)
- v00.01.02.00.01 2023/12/5
- v00.01.02.00.00 2023/11/2
- v00.01.01.00.02 2023/09/12
- v00.01.01.00.01 2023/08/10
- v00.01.00.00.19 2023/07/24
Much of it needs rewriting TBH!
It's difficult to know whether they're knuckling down to make it into a usable tool, or whether they've just given up with it.
-
FW is 01.02.00.02.. i'm trying to feed 0.5Vpp 5MHz sine (RigolDS1.png) to get long memory 10Mpts capture @ 31.25MSps Peak Detect mode (RigolDS2.png)... hit "Single" trigger button (RigolDS3.png)... when triggered, dso will stop capturing.. dial back to 100ns/div,
what a fucked up capture (RigolDS4.png). the workaround, need to do it in Normal mode, not Peak detect (RigolDS5.png), WTF?
edited: this is not a bug, this is a trap for young player... this is supposed to be this way :palm:
https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5454092/#msg5454092 (https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5454092/#msg5454092)
-
Apparently it just fails to interpolate the samples at this sampling rate. Or, rather, it just uses linear interpolation, hence the jagged edges. With Normal acquisition it needs it to be at least 5 times the signal frequency so that the zoomed in result stays barely acceptable (anything lower, and it becomes heavily aliased), and any mode other than Normal requires an even higher sampling rate to signal frequency ratio.
It's a shame it doesn't have Dot display mode, it could be helpful in this scenario, at least to have a better understanding of what's going on.
-
Apparently it just fails to interpolate the samples at this sampling rate.
looking at samples distance (sharp edge to edge the same between RigolDS4.png and RigolDS5.png) its not interpolation issue, its a fucked up averaging (if anything oversampled Peak detect) or sometype bit overflow or simply misplaced y value or whatever. i noticed this when downloading data to PC, i thought my PC app got bug, but it turned out from dso.
-
looking at samples distance (sharp edge to edge the same between RigolDS4.png and RigolDS5.png) its not interpolation issue, its a fucked up averaging (if anything oversampled Peak detect) or sometype bit overflow or simply misplaced y value or whatever. i noticed this when downloading data to PC, i thought my PC app got bug, but it turned out from dso.
Well, the samples are spaced exactly as they are supposed to be at this sampling rate: 32 ns per sample:
(in this case a 10 MHz input signal was captured)
[attachimg=1]
It's an aliasing issue all right, zoom out and you can clearly see it:
[attachimg=2]
The same can be reproduced in Normal acquisition mode, it just needs the sampling rate to be even lower to manifest itself.
Here's a 10 MHz signal captured at 6.25 Msa/s in Normal mode:
[attachimg=3]
I think Peak (or Average for that matter) acquisition just needs more samples per second to work properly compared to Normal. The issues related to the insufficient sampling rate simply manifest themselves earlier in acquisition modes other than Normal.
And it's clearly using linear interpolation, regardless of the acquisition mode, when acquisition is stopped and the captured buffer is zoomed in.
-
But yeah, Peak mode is doing some weird stuff. Probably that's just the way the algorithm works.
Here's a 10 MHz signal captured at 165.25 Msa/s (6 ns per sample), Peak acquisition mode:
[attachimg=1]
The original waveform can be guessed, but hey, what are those jagged peaks (spaced exactly 6 ns apart!), which are by the way seen only on the rising slope? Clearly they are some artifacts of Peak mode.
Sounds like it requires the sampling rate to be way higher than the signal frequency, or maybe it's not suitable for zooming in at all. After all, it needs to capture multiple waveforms to do the math and detect the peaks. Probably there are more hints in the manual that can give insights on how it actually works and why this happens.
-
It's an aliasing issue all right, zoom out and you can clearly see it:
you are comparing apple to orange... you are testing very close to nyquist limit (only 3 samples per cycle) and sinc interpolation is OFF during stopped mode is adding spice to the injury. i carefully did any test to avoid such limit. my case 5MHz @ 31.25MSps (6 points per cycle) is not aliasing issue.
But yeah, Peak mode is doing some weird stuff.
ditto!
Probably that's just the way the algorithm works.
no, thats not how the algorithm works.
The original waveform can be guessed, but hey, what are those jagged peaks (spaced exactly 6 ns apart!), which are by the way seen only on the rising slope? Clearly they are some artifacts of Peak mode.
i did captures much earlier with jagged wave, i thought its the noise in background, but now it become suspect of flawed algorithm.. attached is my capture downloaded to PC much earlier.. granted signal noise is about 10mVpp (about right in display) but my noise is occuring every 500KHz (smps switching), looking closely, the jagged wave is 15MHz (half sampling rate), not my noise!..
-
Peak mode is not expected to result in "reconstructible" samples (according to the Shannon-Nyquist sampling theorem).
It has a completely different aim: Don't miss narrow spikes (narrower than the sampling interval) even if you capture at a low sample rate. In order to achieve this aim, it is usually supposed to record two values per sample, (a) maximum value and (b) minimum value of the signal within the sampling interval.
Don't use peak mode if the signal is bandwidth limited to < fs/2 and if you want to be able reconstruct the continuous signal from the samples.
-
that probably explained that... but iirc i didnt notice such issue on DS1054Z, maybe i'll try again on DS1054Z to verify that theory...
-
This naturally raises the question of how to visualize it? I could imagine:
1) display only the minimum
2) display only the maximum
3) display the average between minimum and maximum
4) display a vertical error bar at each sample which celarly shows the min...max range
etc.
Personally, I'd prefer (4).
The screenshots look to me like the points of the trace alternate between min and max values (but I could be wrong).
-
In order to achieve this aim, it is usually supposed to record two values per sample, (a) maximum value and (b) minimum value of the signal within the sampling interval.
its confirmed the same in DS1054Z, i just didnt aware, i took Normal Acq for granted.. so its not a bug, its a trap for young player :palm: i guess i should set to Normal Acq for my purpose posted earlier. (i edited my post above)
-
another bug... not sure if its already been reported... dso doesnt save and load all previous setting correctly upon power cycle. CH vertical scale can be reloaded correctly, but memory depth and CH visibility etc, reverted back to whatever dso think is default. :palm:
RigolDS0.png: i set only CH4 visible, 10Mpts memory length
RigolDS1.png: after switch OFF and ON again, CH1 becomes visible and memory length goes back down to 1Mpts.
-
another bug... not sure if its already been reported... dso doesnt save and load all previous setting correctly upon power cycle.
Yes, it has.
-
I am transferring the found bugs or flaws in the firmware of the Rigol DHO800-900 oscilloscope to this topic.
1) The first Bug is that there is a certain phase shift at a frequency of 70 MHz, between two channels (20 degrees or about 800 picoseconds), namely in the following combinations:
a) 1 + 2 (synchronization on 1 or 2 channels)
[attachimg=7]
b) 1 + 3 (synchronization on 1 or 3 channel)
[attachimg=1]
c) 1 + 4 (synchronization on 1 or 4 channel)
[attachimg=2]
d) 2 + 3 (synchronization on 2 or 3 channel)
e) 2 + 4 (synchronization on 2 or 4 channel)
f) 3 + 4 (synchronization on 3 or 4 channel)
When channels are turned on in such combinations, there is no phase shift, or within acceptable limits = 1 degrees or about 50 picoseconds:
a) 2 + 3 (synchronization on 1 or 4 channels)
b) 2 + 4 (synchronization on 1 or 3 channel)
c) 3 + 4 (synchronization on 1 or 2 channels)
d) 2 + 3 + 4 (synchronization on 1 or 2 or 3 or 4 channels)
e) 1 + 2 + 3 (synchronization on 1 or 2 or 3 or 4 channels)
[attachimg=3]
f) 1 + 2 + 3 + 4 (synchronization on 1 or 2 or 3 or 4 channels)
[attachimg=4]
Any types of calibration do not give anything, I tried different combinations in the extended “SelfCal” menu item, except for the “ADC Phase” calibration item, since this is the second bug, which is described below.
2) The second Bug is that the "ADC Phase" calibration ends with the error "Unknown error occurred while calibrating"
[attachimg=5]
[attachimg=6]
I think that this is precisely the calibration with which the phase shift of the channels is calibrated.
Does anyone know how to calibrate "ADC Phase"?
Please share your information as I haven't found anything yet...
3) The third Bug or simply a low-quality trigger of the “Edge” type is that when you turn on the Coupling trigger function - “AC”, the sine wave (from 10 to 70 MHz) becomes unstable and trembles (jitter) in the horizontal plane within 3 nanoseconds, and the "Holdoff" setting doesn't help. Perhaps the OWON DGE2070 Generator is to blame, I would like you to check this on your oscilloscopes too.
[attachimg=8]
p.s.
Measurements were carried out using:
- The Rigol DHO804 oscilloscope itself (with unlocked options 50 Mgpt and a frequency of 100 MHz) latest firmware v00.01.02.00.02
Warmed up within an hour. Calibrated with different combinations, no difference.
- Original probes from the PVP3150 kit (at 150 MHz) in position X10.
- The OWON DGE2070 generator is configured for output frequency = sine 70 MHz and output voltage = 3.5 Vpp. Connected via the supplied coaxial cable bayonet - crocodiles.
- The oscilloscope probes (I connected two together and three and four, they only affect the signal range) are connected to the coaxial cable with crocodile clips at one point parallel to the signal terminal and parallel to the ground terminal.
-
I trust your impartiality and I would ask for your rating in 2 ways:
1. Suitability as a first scope. Is the UI too complex and does the OS provide suitable protection for the scope newbie managing aliasing ?
2. For the experienced DSO user.
I don't want to anticipate this because I want to post it in "my" thread, but here it is in brief:
To 1: The user interface of this rigol in particular is a bonus for beginners, you can always fall into the aliasing trap with any scope.
Regarding 2: Experienced users would not buy this scope as their main measuring device, but rather as a second one, the small form factor and the USB supply are an invitation to do so.
Martin, I realize this is an old post - I have just now read through this complete thread, but came back to what you said above. Can you point me to "your post" where you expound on your conclusions? And have these conclusions changed any since you posted this?
-
I think I just managed to brick my 924s. :-DD :-DD
The point is that out of curiosity I played with the "search" function, if I remember correctly I simply closed it with the x and turned off the scope. :clap:
I would turn it on this morning, but it froze at the boot label. 8)
Black background, RIGOL inscription, Run/Stop, channel "1" and "2" buttons light up.
After switching on, you could hear the relays clicking, and the display also darkened a bit while boot, as usual.
I haven't found any hard reset option for this yet.
The fat32 flash drive did not help, there is no help button here.
Does anyone have any ideas on how to fix it? :palm:
p.s. never "load last settings" again :--
-
I am not exactly sure what you're seeing. But I thought I had bricked mine (DHO924S) at one time, as it wouldn't start the scope app in Android. I unplugged everything, and left it overnight (about 10-12 hours). Then it worked again. I will say, I have never seen such a buggy piece of test equipment.
-
What are all the indicators at the top of the screen, and why can't I get my Trigger level indicator to work unless Chan 1 is DC-Coupled?
Note the RED, and the empty white inverted triangles at the top of the waveform screen. What are they? (I can find nothing about these in the manual)
-
I am not exactly sure what you're seeing.
I've been seeing this on the display for almost an hour.
Then I'll wait with him to see if it revives you.
Hooray, it worked :scared: , just had to wait a few hours. :-DD :-DD
This is a bit funny, I think I'll make a couple of backup file images from the memory card. :box: Just in case.
-
I think I just managed to brick my 924s. :-DD :-DD
The point is that out of curiosity I played with the "search" function, if I remember correctly I simply closed it with the x and turned off the scope. :clap:
I had something similar once. I think I used zoom function with a large captured buffer, probably something in addition to that. 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.
-
It could have been something similar with me, I checked how long I could record two channels with it, and left it in the slowest time base.
After I managed to turn this on, I noticed it.
But now for some reason I can't produce the bug.
He might need something else
I didn't manage to push the buttons, it didn't respond to anything, I could only wait.
he came to his senses in about 3-4 hours.
The bugs presented by Slavius are also produced for me, 924s is the latest firmware
-
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..
-
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..
How do you come to that conclusion? That still might be so, but I didn't say that I re-flashed the SD card in that instance, so the settings might still be saved on it.
There is some SPI flash chip that stores some information, but I believe it gets overwritten with data stored on the SD card on every boot (there are respective commands in the boot scripts).
-
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..
How do you come to that conclusion? That still might be so, but I didn't say that I re-flashed the SD card in that instance, so the settings might still be saved on it.
that means, putting back original fw image file in sd card will fix dso bricked issue?
-
that means, putting back original fw image file in sd card will fix dso bricked issue?
Potentially. It has yet to be tested.
-
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.
-
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.
-
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.
-
so the programmer is not as clever as i thought.
-
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.
-
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.
-
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.
-
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.)
-
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.
-
And try additionally enabling the input signal bandwidth limitation of 20 MHz for each channel.
-
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.
-
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?
-
I keep returning to this thread with an increasingly forlorn hope that there'll be a spectacular firmware rabbit pulled out of a hat at some point, making my DHO924S more than a desk ornament one day.
Should I consider this scope a write-off?
-
I keep returning to this thread with an increasingly forlorn hope that there'll be a spectacular firmware rabbit pulled out of a hat at some point, making my DHO924S more than a desk ornament one day.
Should I consider this scope a write-off?
have you purchased siglent sds800x-hd and LA module? since iirc your job is mainly LA, so i hope you can make comparison how far off dho900 compared to sds800x+LA. and i think your life need to move on rather continuously depending on crippled dho900 as i understand your situation from previous descriptions. but for us who dont really depend our life on LA (serial nor parallel) serious work, we hope there will be FW fix in the future. so we will put our dho800 in box for a while since person like me still have DS1054Z to work with. and since they are so much affordable now like smartphones, if i'm going crazy, i'll get one sds800x-hd to try, or even to use it as main bench scope if its really that good, ymmv. (the problem with sds804x or sds824x is they keep disappearing (out of stock) from aliexpress when i want to look for them)
-
I keep returning to this thread with an increasingly forlorn hope that there'll be a spectacular firmware rabbit pulled out of a hat at some point, making my DHO924S more than a desk ornament one day.
me too, it's very disappointing that Rigol has not published a DHO software update for almost half a year now :--
I have some direct contact with their support. every time I asked "when" they simply replied "It's not scheduled but we are working on it" (and I just asked once again yesterday). by contrast, their competitor is updating firmware very frequently :-//
I do hear from some sources they are facing some human resource problems right now due to various reasons, mainly poor management.
Anyway, I will still keep my DHO because it is not that bad for my use case. I do hope they can release new software asap. :-BROKE
-
I keep returning to this thread with an increasingly forlorn hope that there'll be a spectacular firmware rabbit pulled out of a hat at some point, making my DHO924S more than a desk ornament one day.
Should I consider this scope a write-off?
have you purchased siglent sds800x-hd and LA module? since iirc your job is mainly LA, so i hope you can make comparison how far off dho900 compared to sds800x+LA. and i think your life need to move on rather continuously depending on crippled dho900 as i understand your situation from previous descriptions. but for us who dont really depend our life on LA (serial nor parallel) serious work, we hope there will be FW fix in the future. so we will put our dho800 in box for a while since person like me still have DS1054Z to work with. and since they are so much affordable now like smartphones, if i'm going crazy, i'll get one sds800x-hd to try, or even to use it as main bench scope if its really that good, ymmv. (the problem with sds804x or sds824x is they keep disappearing (out of stock) from aliexpress when i want to look for them)
So I do already have an SDS1204X-E with the external SLA1016 LA pod, and I find the LA implementation to be a horrible implementation with plenty of functional and non-functional limitations. As far as I can tell, the SDS800X-HD has a very similar form factor to the SDS1204X-E, and uses the same LA pod.
It was the diminutive form factor of the Rigol DHO924S that I was interested in.
Here's a comment I made on the combo a few years ago about the SDS1204X-E and SLA1016 pod:
https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg3259848/#msg3259848 (https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg3259848/#msg3259848)
Although this scope isn't bad, I have a couple of comments about the optional LA and AFG.
If you're thinking of adding the LA to make it an MSO, I find the LA on this scope to be very weak indeed. For an MSO at this level, I consider the older Rigol DS1000Z+ with LA probes to be a significantly better solution. On the 1104X-E, the UI performance grinds to a halt with the LA attached and it's a substantial extra package to carry about that can't help but take up bench space.
Similarly, the external AFG on the Siglent also is nowhere near as neat as the Rigol's internal dual channel unit, but you have to buy the Rigol's at the time of scope purchase.
So if you're only looking for a 4 channel scope only, the Siglent is definitely a better than the Rigol DS1000Z series. Just that I find the LA and AFG on the Siglent are rather disappointing.
To be fair I have more scopes than I can shake a stick at, it's not like I really need another one. However for field use, had the DHO924S worked out as anticipated and advertised, it would have found its way on trips. In recent times I've found myself making do with the Analog and Digital Discoveries for field work more and more, with a scope becoming more of an exception. Carrying a portable monitor with me helps in that regard so there's enough screen real estate. The AD lacks in memory depth, with the DD filling in in that regard. I'd still prefer a compact fully integrated standalone MSO though for my field work nirvana.
-
So I do already have an SDS1204X-E with the external SLA1016 LA pod, and I find the LA implementation to be a horrible implementation with plenty of functional and non-functional limitations. As far as I can tell, the SDS800X-HD has a very similar form factor to the SDS1204X-E, and uses the same LA pod.
100% and exactly where the similarities end.
SLA1016 must be SW upgraded to work with SDS800/1000X HD models.
X-E implementation is now changed for the new models with a much better UI and touch and mouse control provides for a superior user experience.
(https://www.eevblog.com/forum/testgear/siglent-sds1000x-hd-coming/?action=dlattach;attach=1988677;image)
-
So I do already have an SDS1204X-E with the external SLA1016 LA pod, and I find the LA implementation to be a horrible implementation with plenty of functional and non-functional limitations. As far as I can tell, the SDS800X-HD has a very similar form factor to the SDS1204X-E, and uses the same LA pod.
100% and exactly where the similarities end....
[img]...
i wish parallel LA (in dho800/900) can show hex or dec value at each digital transition so i dont have to decode myself. much like serial LA decoding function/UI... your screenshot of siglent scope also show lack of parallel LA decoding, or is it turned OFF?
-
So I do already have an SDS1204X-E with the external SLA1016 LA pod, and I find the LA implementation to be a horrible implementation with plenty of functional and non-functional limitations. As far as I can tell, the SDS800X-HD has a very similar form factor to the SDS1204X-E, and uses the same LA pod.
100% and exactly where the similarities end....
[img]...
i wish parallel LA (in dho800/900) can show hex or dec value at each digital transition so i dont have to decode myself. much like serial LA decoding function/UI... your screenshot of siglent scope also show lack of parallel LA decoding, or is it turned OFF?
Nothing connected, just an image of the UI.
Mech, we are about to attend a 3 day exhibition (see sig) and we will have many instruments with live displays so sometime this coming week I will capture something to show you.
-
I wonder how the Rigol would compare to the siglent with the following measurement:
- A squarewave at 10Hz, with a level from 0 - 6.6V (maybe interleaved with a 3.3V level) and 50% duty.
- Zoomed in to 0V at a scale of 20mV.
- Avaraging function activated
See the picture attached.
-
I wonder how the Rigol would compare to the siglent with the following measurement:
- A squarewave at 10Hz, with a level from 0 - 6.6V (maybe interleaved with a 3.3V level) and 50% duty.
- Zoomed in to 0V at a scale of 20mV.
It would not compare at all, because the Rigol cannot do vertical zoom. Count your blessings! :)
Well, one can stop the acquisition and crank up the vertical amplification after the fact to see the settling behaviour. If you want others to try and test on their scopes, you should also specify how the signal was coupled into the scope. Using the stock probes? BNC cable with 50 Ohm termination at the scope? If so, what terminator did you use -- was it a decent one?
-
I wonder how the Rigol would compare to the siglent with the following measurement:
Like most scopes that do not have a vertical zoom function.
If you saved the wave to Ref, it is possible to check the bottom and top, but I did not look into how many points you lose with it.
It can't in Run mode.
-
I wonder how the Rigol would compare to the siglent with the following measurement:
- A squarewave at 10Hz, with a level from 0 - 6.6V (maybe interleaved with a 3.3V level) and 50% duty.
- Zoomed in to 0V at a scale of 20mV.
It would not compare at all, because the Rigol cannot do vertical zoom. Count your blessings! :)
whats the point of it? trying to zoom in to 1% overshoot is marketing ploy... 5% and more? is readily available to see without zoom in to tell whether your circuit need rectification or within acceptable range..
-
Without knowing the probing method, replicating the test won't produce significant results. Nenvertheless, out of curiosity, I attempted a similar "shot" on my DHO1000, yet (obviously) in stopped mode. F/W is 02.12, as a generator I used an SDG6000X, "Radar" ARB waveform since this contains several square pulses of varying amplitude. I could only select 5Vp since I connected the generator via a short RG316 cable and in-line BNC terminator, hence the available amplitude got halved. Except for some very fast overshoot, there was no deformation of the trace observable (as expected). I'ld be surprised if the DHO800 or the SDS800X HD would perform any different under the same conditions.
-
I wonder how the Rigol would compare to the siglent with the following measurement:
- A squarewave at 10Hz, with a level from 0 - 6.6V (maybe interleaved with a 3.3V level) and 50% duty.
- Zoomed in to 0V at a scale of 20mV.
- Avaraging function activated
See the picture attached.
a) Is that actually useful?
b) You can use a math channel if you really want to see that. Put in any offset/scale that you want.
Sure, (b) isn't as "cool", but see point (a).
The math channel here is showing a range of 6mV at the top corner of a 300mV square wave.
(https://www.eevblog.com/forum/testgear/choosing-between-entry-level-12-bit-dsos/?action=dlattach;attach=2100716;image)
-
I should have postet the link, how it looks on my side. (https://www.eevblog.com/forum/beginners/probe-compensated-but-level-of-square-signal-gt-20ms-not-looking-good/ (https://www.eevblog.com/forum/beginners/probe-compensated-but-level-of-square-signal-gt-20ms-not-looking-good/))
I did not add my connection details, because i would have accepted anything that you would have been shown. Except, that the scales were not really comparable in one occasion.
I do want to measure currents, that would rapidly increase, and also very prescisely. All that in conjunction with the programming of my controller, so i could detect any issues, or see its precision. Not really possible it seems with the Siglent. :-\
Interestingly, my cheap and tiny scopes do better here.
-
The math channel here is showing a range of 6mV at the top corner of a 300mV square wave.
Why didnt you go with 3.3V as i had written?
-
The math channel here is showing a range of 6mV at the top corner of a 300mV square wave.
Why didnt you go with 3.3V as i had written?
Because that's an old screenshot from a previous thread and I couldn't be bothered. :)
-
Hi everyone,
I received my DHO804 yesterday, bought it exactly to use the decoding capabilities.
After reading all the content from this thread, I finally managed to make the SPI decoder work with the probes configured to 10x ;).
Due to this bug related to the thresholds, took a bit of time to figure out what was going on.
Actually, it had to adjust all the threshold to 10x (I was using 2V threshold with 1x probe → 20V threshold for 10x probe).
Interesting that the trigger configuration seems normal, I didn't need to adjust it in the same way.
Channel settings:
- CH1: CLK
- CH2: MOSI
- CH3: MISO
- CH4: CS
Attached follow my settings and output, hope that it can help the others to use such feature.
One question: I'm currently working more with firmware development, so these decoding features are the most important ones for me (SPI, I2C, UART, ..).
Is there any really critical bug related to these features right know that I'm maybe not aware of?
At the office I have a Rohde Schwarz RTB2004 scope, bought this Rigol one for home office.
Just asking because I have 30 days to return the product, then I want to make sure it will meet my needs.
-
Is there any really critical bug related to these features right know that I'm maybe not aware of?
I never heard of one.
Note that if you want a full memory decode you have to go into zoom mode.
-
Oh, that's good to know, thanks for the hint.
Just to make sure, this bug with the 10x probe settings is related just with the decoder thresholds, right?
I mean, the trigger thresholds are not affected.
-
One question: I'm currently working more with firmware development, so these decoding features are the most important ones for me (SPI, I2C, UART, ..).
Is there any really critical bug related to these features right know that I'm maybe not aware of?
At the office I have a Rohde Schwarz RTB2004 scope, bought this Rigol one for home office.
Just asking because I have 30 days to return the product, then I want to make sure it will meet my needs.
Just my 2c - for serial comms analysis and decoding I much prefer a dedicated LA to the decoding features included in entry level scopes. Unless you only need to inspect a few data packets that easily fit on the screen, a dedicated LA offers more flexibility and can generally be easier to capture and locate the data you are looking for. A cheap $20 LA that works with the open source Sigrok software is sufficient for most serial comms protocols. If you do frequent decoding analysis, you might consider stepping up a notch to something like the $149 DSlogic Plus LA that has a much greater feature set.
I tried decoding on my old SDS1104X-E scope but the constraint of being able to only decode what was captured on the screen was frustrating for me. I suspect the decoding features on the newer models are very similar.
-
One question: I'm currently working more with firmware development, so these decoding features are the most important ones for me (SPI, I2C, UART, ..).
Is there any really critical bug related to these features right know that I'm maybe not aware of?
At the office I have a Rohde Schwarz RTB2004 scope, bought this Rigol one for home office.
Just asking because I have 30 days to return the product, then I want to make sure it will meet my needs.
Just my 2c - for serial comms analysis and decoding I much prefer a dedicated LA to the decoding features included in entry level scopes. Unless you only need to inspect a few data packets that easily fit on the screen, a dedicated LA offers more flexibility and can generally be easier to capture and locate the data you are looking for. A cheap $20 LA that works with the open source Sigrok software is sufficient for most serial comms protocols. If you do frequent decoding analysis, you might consider stepping up a notch to something like the $149 DSlogic Plus LA that has a much greater feature set.
I tried decoding on my old SDS1104X-E scope but the constraint of being able to only decode what was captured on the screen was frustrating for me. I suspect the decoding features on the newer models are very similar.
I really appreciate your feedback. As far as I know, the Rigol DHO804 does not debug only what appears in the screen but also the memory content (I remember to watch a video in this thread of someone showing such feature). Maybe I'm wrong :-//
I have a cheap Saleae copy that I can use as a workaround for now, I really wasn't aware of this DSlogic Plus, seems very capable for the price tag. Good to know.
At the end, makes sense for me to have a scope at home. The company I work develop sensors, then here and there I need also to do some measurements :-BROKE.
-
Just to make sure, this bug with the 10x probe settings is related just with the decoder thresholds, right?
Yes. It all works perfectly when you set probe attenuation to 1x on the 'scope.
-
I tried decoding on my old SDS1104X-E scope but the constraint of being able to only decode what was captured on the screen was frustrating for me. I suspect the decoding features on the newer models are very similar.
Nope.
The DHO800/900 let you fill the memory and decode it all.
You can open a separate window to show all the decoded data as packets in a scrollable table.
-
Just my 2c - for serial comms analysis and decoding I much prefer a dedicated LA to the decoding features included in entry level scopes. Unless you only need to inspect a few data packets that easily fit on the screen, a dedicated LA offers more flexibility and can generally be easier to capture and locate the data you are looking for. A cheap $20 LA that works with the open source Sigrok software is sufficient for most serial comms protocols. If you do frequent decoding analysis, you might consider stepping up a notch to something like the $149 DSlogic Plus LA that has a much greater feature set.
Horses for courses. I use both LAs and MSOs for serial decode, but the workflow and features are different.
o Triggers
Scopes with serial decode tend to have more complex protocol specific trigger capabilities available that cheap USB LAs lack. This has a fundamental affect on how one uses a scope compared to a USB LA.
o Memory depth & streaming
USB LAs often support unlimited streaming, whereas scopes rely on and are limited by memory depth for longer captures. Using a scope's triggers and segmented memory can usually mitigate the lack of unlimited streaming.
o Sample rate
Scopes tend to have higher sample rates over a larger number of concurrent channels compared to USB LAs. This typically impacts higher speed SPI decodes.
o Mixed signal time correlation
MSOs have integrated time correlation so you can directly analyse the interaction between digital and analogue signals.
o Workflow
For longer runs, on a scope, because of the triggers and lack of streaming, one tends to set up relevant triggers interactively and iteratively to capture specific events. On an LA that supports streaming, one tends to set up a long capture and then analyse the results retroactively.
For longer serial data streams, particularly longer slave device configurations, the results of a USB LA can often be more easily viewed and manipulated on the host PC than navigating and interpreting a longer capture on a scope.
I tried decoding on my old SDS1104X-E scope but the constraint of being able to only decode what was captured on the screen was frustrating for me. I suspect the decoding features on the newer models are very similar.
On the SDS-1104X-E, yes, you need to have the entire capture, and have sufficient sample rate for the capture, but it will decode long captures, and you can save the entire decode to a CSV file. The implementation on this scope is certainly one of the better ones IME. The LA digital channel implementation on this scope is, on the other hand, terrible!
The DHO800/900, the decode is flakey AF. It misses bytes in I2C, and it subsamples, although it's not quite as bad as the DS1000Z. Getting a decode export on anything more than a short stream won't work. The SPI decode on the LA channels of the DHO900 series is currenty completely broken. I2C decoding on the analogue or digital channels is a constant fight, and is very unreliable.
There was certainly a significant drawback with the DS1000Z series where it undersamples the capture, so only a few bytes at a time are decoded. Typically you can work around it, but it's slow and messy.
-
The DHO800/900, the decode is flakey AF. It misses bytes in I2C, and it subsamples, although it's not quite as bad as the DS1000Z.
It has two ways of working.
Have you tried it in "zoom" mode?
-
The DHO800/900, the decode is flakey AF. It misses bytes in I2C, and it subsamples, although it's not quite as bad as the DS1000Z.
It has two ways of working.
Have you tried it in "zoom" mode?
Yes. Frankly, it's crap. I wasted another hour with it today trying to work around its decode behaviour, only to find more and more crapiness.
Every time I try to use this scope, it never fails to disappoint. It seems to be random when you can export a csv too. And when you can, just like the onscreen decode, bytes are missing.
I simply cannot recommend this scope. One day maybe they'll fix it, but right now, it's an ornament.
-
Yes. Frankly, it's crap. I wasted another hour with it today trying to work around its decode behaviour, only to find more and more crapiness.
I don't know know what you're doing, exactly, but it always worked for me.
-
Yes. Frankly, it's crap. I wasted another hour with it today trying to work around its decode behaviour, only to find more and more crapiness.
I don't know know what you're doing, exactly, but it always worked for me.
How long are your decodes?
-
How long are your decodes?
Long enough for it to say "There are too many results" on screen.
https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5152896/#msg5152896 (https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5152896/#msg5152896)
-
How long are your decodes?
Long enough for it to say "There are too many results" on screen.
https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5152896/#msg5152896 (https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5152896/#msg5152896)
That's not I2C.
-
Why don't you tell us what you're doing instead of asking what everybody else is doing?
You're the one claiming it doesn't work.
-
Why don't you tell us what you're doing instead of asking what everybody else is doing?
Simply because it takes time, and I've already burned enough time on this steaming pile of turd.
You could, of course, always try it yourself.
You're the one claiming it doesn't work.
However, as you're so insistent, I've burned at least another couple of hours just to satisfy you.
Test data is on a 3.3V I2C bus running at 100kbps with a single master and single slave.
Sample rate is over 10MSa/s in all cases.
There are a total of 228 bytes in 84 frames.
I've run this on four scopes: an DHO924S, SDS-1104X-E, MSO3104T and MDO3014 (upgraded to 500MHz BW).
What are your results for I2C testing? Or are you simply relying on your overt and unflinching love for Rigol?
As you well know, I have long been a proponent for Rigol, but this scope has proved to be a real lemon.
They released it with unfinished and untested firmware almost a year ago, and very little has happened that we're aware of to even try to resolve that. It's still a very long way from even a beta release.
[attach=2]
[attach=10]
[attach=4]
[attach=5]
[attach=6]
[attach=7]
[attach=8]
[attach=9]
-
Why don't you tell us what you're doing instead of asking what everybody else is doing?
You could, of course, always try it yourself.
Not without knowing your conditions, sampling rate, etc.
-
Why don't you tell us what you're doing instead of asking what everybody else is doing?
You could, of course, always try it yourself.
Not without knowing your conditions, sampling rate, etc.
What sampling rates have you tried I2C decoding with? Have you even tried I2C decoding at all on these scopes?
-
What are your results for I2C testing? Or are you simply relying on your overt and unflinching love for Rigol?
Here's a quick test writing two bytes to a device then reading the second byte back again.
Looks OK to me...
(https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/?action=dlattach;attach=2296715;image)
-
Have you even tried I2C decoding at all on these scopes?
Yes, of course I have.
-
Just checking: You do have your probe attenuation set to 1x on the 'scope, right?
-
Here's a quick test writing two bytes to a device then reading the second byte back again.
Looks OK to me...
Attached is how it looks with the Batronix demo board.
-
Just checking: You do have your probe attenuation set to 1x on the 'scope, right?
No. 10x on the probes, 10x on the probe settings. Is there some reason why I shouldn't be doing that for decoding?
-
Just checking: You do have your probe attenuation set to 1x on the 'scope, right?
No. 10x on the probes, 10x on the probe settings. Is there some reason why I shouldn't be doing that for decoding?
It's a well-known bug in the decoders. You need to set 1x attenuation on the 'scope or the decoder threshold voltage is wrong (10x too small).
(keep the switch at 10x on the probes, obviously)
-
It's a well-known bug in the decoders. You need to set 1x attenuation on the 'scope or the decoder threshold voltage is wrong (10x too small).
I can't tell if you're joking or not?
-
I ran several test with the threshold voltage and found that it is the threshold voltage scale issue. If I set the probe to X1 scale then everything works fine but with the X10 probe scale does not work because the actual threshold voltage 10 times less than I set. But if I increase the threshold voltage 10 times (10V instead of 1V) then decoding starts again.
Yep. I received my 'scope today and serial decoding only works when the probes are set to 1x.
Edit: This is NOT fixed in the 1.01 firmware.
...
-
It's a well-known bug in the decoders. You need to set 1x attenuation on the 'scope or the decoder threshold voltage is wrong (10x too small).
I can't tell if you're joking or not?
This bug has been discussed many times here... :-//
It's been on the bug list since at least November:
https://www.eevblog.com/forum/testgear/another-bug-in-the-rigol-dho914sdho924s-bode-plot-feature/msg5184534/#msg5184534 (https://www.eevblog.com/forum/testgear/another-bug-in-the-rigol-dho914sdho924s-bode-plot-feature/msg5184534/#msg5184534)
Edit: This is NOT fixed in the 1.01 firmware.
It's supposedly fixed in the DHO1000 since a few weeks ago.
(last item in the changelog)
https://www.eevblog.com/forum/testgear/new-rigol-hdo1000-12-bit-dso-bugs/msg5553587/#msg5553587 (https://www.eevblog.com/forum/testgear/new-rigol-hdo1000-12-bit-dso-bugs/msg5553587/#msg5553587)
-
It's a well-known bug in the decoders. You need to set 1x attenuation on the 'scope or the decoder threshold voltage is wrong (10x too small).
I can't tell if you're joking or not?
This bug has been discussed many times here... :-//
It's been on the bug list since at least November:
I honestly don't know what to say, other than to reiterate that this scope is an ornament, and it will remain so until the firmware comes out of alpha.
I'd already run out of patience with this scope half a dozen times before, with rose tinted glasses thinking it can't be that bad. Every time it's been a disappointment.
No one should be considering purchasing this scope with its current firmware state, unless they like adorning their bench with ornaments.
-
It's a well-known bug in the decoders. You need to set 1x attenuation on the 'scope or the decoder threshold voltage is wrong (10x too small).
I just tried it with the Batronix demo board and 10x on probes and scope are working fine with I2C (DHO800).
-
It's a well-known bug in the decoders. You need to set 1x attenuation on the 'scope or the decoder threshold voltage is wrong (10x too small).
I just tried it with the Batronix demo board and 10x on probes and scope are working fine with I2C (DHO800).
It can work on 10x but your signal has to go all the way to zero.
If there's even a tiny offset (eg. 0.2V) due to probing or whatever then you can get caught out by this bug.
Setting probe to 1x makes sure.
-
It's been on the bug list since at least November:
I honestly don't know what to say
It was literally being discussed in the post you originally quoted.
That's why I said:
Just checking: You do have your probe attenuation set to 1x on the 'scope, right?
nb. I'm not name-calling, we all miss stuff, but this bug has been discussed endlessly here.
-
It's been on the bug list since at least November:
I honestly don't know what to say
It was literally being discussed in the post you originally quoted.
That's why I said:
Just checking: You do have your probe attenuation set to 1x on the 'scope, right?
nb. I'm not name-calling, we all miss stuff, but this bug has been discussed endlessly here.
As I already stated, I've already wasted enough time on this scope and its litany of bugs. When there's a new firmware release I'll revisit.
Until that time, anyone considering purchasing a scope should avoid this one.
-
Multiple bugs / limitations that make it hard to save / export Logic Analyzer data, at least with the v01.02.00.02 firmware:
- WFM file format only supports saving analog data. It doesn't save digital data from the LA, even though the UI makes appear this is possible. This was uncovered while decompiling the libscope-auklet.so file while reverse-engineering the WFM file format. Unclear whether this is a bug or limitation of the file format.
- BIN file format supports saving digital data and analog data. However, due to a bug, BIN files can only be successfully saved if both the LA and a CH are active. If only the LA is on, then the BIN file's header will be written but LA data is missing. On the upside, the BIN file format is well documented in the DHO800/900 User Guide PDF.
- CSV file format supports saving digital-only, analog-only, and digital+analog. The file format is easy to read. The only downside is the large file size and how slow large samples takes to write to disk.
- SCPI support for retrieving digital data is broken. Setting the source to a D0 thru D15 channel fails (e.g., ":WAVeform:SOURce D0"). The scope displays "Remote Cmd Execute Error" on its screen. Querying ":SYSTem:ERRor?" often returns "-200,"Command execute failed" and querying ":WAVeform:SOURce?" always returns the previous setting.
Anybody know of work-arounds or additional ways to save / export LA data?
-
Hello community! Im Happy with my DHO914s so far. But when I tried to decode a simple spi message the scope would not show anything. I've set Mosi, CLK and CS. I've the open source digital interface. As can be seen in the picture the spi message gets picked up perfect but no decoding is happening. Is this a bug or am I missing out on something?
-
Hello community! Im Happy with my DHO914s so far. But when I tried to decode a simple spi message the scope would not show anything. I've set Mosi, CLK and CS. I've the open source digital interface. As can be seen in the picture the spi message gets picked up perfect but no decoding is happening. Is this a bug or am I missing out on something?
SPI decode doesn't work on the LA channels. See post #124. It's a bug that's never been addressed in any public firmware release.
-
SPI decode doesn't work on the LA channels. See post #124. It's a bug that's never been addressed in any public firmware release.
Seems like decoding LA channels would have been basic QA testing? And not only did that bug get through testing, but is still unresolved? Sometimes it feels like the VESA mount got more attention than the firmware…
-
SPI decode doesn't work on the LA channels. See post #124. It's a bug that's never been addressed in any public firmware release.
That's a real bummer :palm:. But thank you for the clarification :-+
-
That's a real bummer
Not least because this exact use case is exceptionally common on an MSO, leaving the analogue channels available to probe around other time-correlated stuff.
-
https://www.youtube.com/watch?v=43ZotURUxiE (https://www.youtube.com/watch?v=43ZotURUxiE)
By the way, here is an example of work I2C. And it works somehow.
-
https://www.youtube.com/watch?v=43ZotURUxiE (https://www.youtube.com/watch?v=43ZotURUxiE)
By the way, here is an example of work I2C. And it works somehow.
Yes, I2C does work on the LA.
For SPI, there is a lot wrong with the decoder dialogue box with the LA such as it asks for things like threshold voltages on LA channels. It's likely that feeds into the issue where it appears just not to work.
The SPI LA issue alone means it stays in the cupboard.
Disappointing is that there's no evidence Rigol are interested in fixing this, or a multiplicity of other issues that show themselves within an hour or two of using it.
The MSO5000 I sometimes have on the bench is, apart from a few relatively minor irritations that I can bear with, far better in comparison. (Although I had a repeating issue with a regulator blowing on the main board, covered elsewhere: I now have a replacement unit now with a 3 year guarantee).