New Rigol HDO1000 12-bit DSO - BUGs

[TK]

I am starting a new topic where members can share their experience with the new Rigol HDO1000 and report / discuss BUGs in the hardware/software.

As first post, I am going to share my experience trying to decode UART and SPI protocols with the HDO1074 scope.  Of course this is the first version of the software and calibration sheet shows manufacturing date October 2022.

The scope froze and rebooted several times during the simple testing.  I cannot make it decode a simple UART signal @ 115200, 8N1.  The signal is from an Arduino Uno board and it is the sketch that prints the ASCII table.  It starts with the message "ASCII TABLE...".  The scope fails to decode the signal.  I tried on my MSO5074 and it decodes correctly the letter 'A' I am showing in the screenshot.

This is the screenshot:

UART Decoder also only allows timebase up to 20ms.  Any timebase 50ms and up the scope disables decoding functionality.  So you cannot capture many packets and zoom to see the frames.  Actually it completely disables the decoding option with timebase higher than 20ms.  Probably software cannot handle decoding large number of frames and Rigol decided to disable it to not affect other areas of the scope.

Decoder divides the screen in 2 sections if you open the event table.  You can put it side-by-side or top and down.  I cannot make the windows detach and move, resize.

Let's start the BUGs discussion from here

[JPortici]

UART Decoder also only allows timebase up to 20ms.  Any timebase 50ms and up the scope disables decoding functionality.

Wow really? A true riglol. Hope they eventually manage to get decoding running at any timebase (as most scope do)

[Martin72]

AFAIK this is 1054Z behaviour..MSO5000didn´t do this, AFAIK too.

[Fungus]

What's the sample rate at 50mS/div? It might not be high enough to do any useful decoding.

[TK]

What's the sample rate at 50mS/div? It might not be high enough to do any useful decoding.

sample rate at 50mS/div is 2GSa/s, sample memory set to 50Mpts

[JPortici]

And one should define useful decoding. 50ms/div is not unusual at all for me:
-LIN, with the scheduler scheduling frames spaced 10s of milliseconds apart
-plain UART, but at 1200bps
-SENT slow channel frame (1-2 bit per sent frame, 14-16 frames per message at about 1ms per frame)
And i don't have to think too hard about test setups involving such long timebases in which i monitor analog sensors with their digital counter parts, or events and communication correlation.
And in all of this i tend to limit the memory to 1MS per acquisition to have some acquisition history and to keep the scope responsive

But i get it if it's an imposed limitation to separate the product lines, makes sense, they have to justify the good scopes somehow

[Fungus]

And one should define useful decoding. 50ms/div is not unusual at all for me:

Jeez.

All I asked was what the sample rate was when people reported it stopped decoding.

[TK]

While trying to decode i2c, I discovered why UART was not decoding correctly.  I had to set the threshold to above 3V for a 5V UART signal.  The same with i2c, I have to set the threshold to 4.4V for the decoder to decode correctly (The i2c signal on the Arduino has a slow rise time due to internal resistor value).  But still many issues, like the decode values being out of position when the signal is moved and stops updating, decode value getting too small when timebase is changed and then staying tiny when timebase is moved back to a setting where decode value should be very visible, constant freezing (RIGOL SCOPE has stopped... Open app again)...

But what is it with being so picky with the threshold value, when at around 50% signal still is the same as at higher values?  Is it trying to use digital logic high and low values?  But the menu does not have any option to select the digital signal (TTL, CMOS, etc).

AND THE MOST ANNOYING BUG... IT RESETS THE COUPLING TO AC AND 20M BW LIMIT ON CH1 EVERY TIME THE APP RESTARTS!!!!!!

[markone]

While trying to decode i2c, I discovered why UART was not decoding correctly.  I had to set the threshold to above 3V for a 5V UART signal.  The same with i2c, I have to set the threshold to 4.4V for the decoder to decode correctly (The i2c signal on the Arduino has a slow rise time due to internal resistor value). 

Wait, pulse distorsion (mismatch in R/F edges slope) destroys any kind of UART transmission, what you see it's not up to Rigol decoder.

Is the probe set to 10:1 ?

[2N3055]

Yeah, they released it too soon.
They were probably under enormous pressure to show something after huge investment and effort in making what is now 2nd chipset generation...

What I see so far is not very good.
We will have to wait until they fix at least basic bugs to make judgment.

[Fungus]

Yeah, they released it too soon.
They were probably under enormous pressure to show something after huge investment and effort in making what is now 2nd chipset generation...

Christmas sales season is coming. The bean counters probably prioritized getting the hardware out there instead of waiting another year.

(and it's not as if Rigol is the only company that does that...)

[2N3055]

Yeah, they released it too soon.
They were probably under enormous pressure to show something after huge investment and effort in making what is now 2nd chipset generation...

Christmas sales season is coming. The bean counters probably prioritized getting the hardware out there instead of waiting another year.

(and it's not as if Rigol is the only company that does that...)

Well apparently R&S does it too... 

Yes, companies do that.. that is right. But there should be a threshold of how low do you go.. It damages reputation, especially if you are in the process trying to build one ....

[Fungus]

Yes, companies do that.. that is right.

Yep. I remember Siglent offering to post little bags of capacitors to to their "early adopters" so they solder them to the PCB and finally be able to compensate their probes properly.

Don't even get me started on second-rate companies like Apple telling people they were holding their new iPhones wrong, or the reason the phones were bending was that people were putting them in their pockets.

[2N3055]

Yes, companies do that.. that is right.

Yep. I remember Siglent offering to post little bags of capacitors to to their "early adopters" so they solder them to the PCB and finally be able to compensate their probes.

That Siglent issue was not the same. It was a production batch problem.
Not saying it isn't a problem, but wasn't the same as releasing something that simply doesn't even work out of the box.
Errors when you have "we didn't anticipate this problem, and we had to learn it the hard way" is not the same as "we only developed 60% of product but we need to start selling it despite we know it doesn't even work. Who cares, we'll fix it later".

And it is not even advocating for Siglent here ( and they in fact learned from that and pay more attention to maturity before release..) but not even Rigol used to do that... Rigol used to be much more solid company in that regard years ago than right now. Let's hope they realize a mistake and make it right.

Siglent and Rigol are only ones keeping western brands in check. Otherwise it would be back to old cartel behaviour and blackmailing us with prices.. We need Siglent and Rigol to do well, so everybody benefits from it. Staunch Keysight users that would never buy "those chinese toys" never had Keysight at current prices. They should write a thank you note to their Chinese friends..

[skander36]

Maybe it is too much said "... simply doesn't even work out of the box..."
It works but it having some quirks  . For sure they will be solved in time as happened with Rigol 5K.
MXO4 has also some quirks, and is in top makers.
About Siglent capacitor problems, they at least, talked about the problem, and offered complete board exchange for free. Rigol does not say a word ... 
Personally I am interested in buying HDO 1000, despite early problems. It is 12 bit scope at the price of a DMM ( Keysight 1282A) or less than Fluke 289 ...   

[Fungus]

Rigol does not say a word ... 

Have you contacted them?

[skander36]

Rigol does not say a word ... 

Have you contacted them?

Don't say you don't understand what I mean...

[Fungus]

It's a bit early to condemn this model, Rigol isn't even selling them yet in many parts of the world.

I'm sure there will be a firmware update soon.

[2N3055]

Maybe it is too much said "... simply doesn't even work out of the box..."
It works but it having some quirks  . For sure they will be solved in time as happened with Rigol 5K.
MXO4 has also some quirks, and is in top makers.
About Siglent capacitor problems, they at least, talked about the problem, and offered complete board exchange for free. Rigol does not say a word ... 
Personally I am interested in buying HDO 1000, despite early problems. It is 12 bit scope at the price of a DMM ( Keysight 1282A) or less than Fluke 289 ...

Well it literally does not ... Look at the TK bug thread...
It sure does not meant it should be "condemn" but at this moment it is not something I would buy.
And given track record  I'm not sure of anything anymore...
And yes, I have been equally critical of R&S..
They all should know better.. regardless of the brand.

[skander36]

"Look at the TK bug thread..."

TK found the right threshold values for deconding to work. I have the same problem for other scopes. At least R&S has a button "Find Threshold" on trigger menu, which help.
Let see if Rigol step up with a fix. Even if they don't talk I'm pretty sure that they listen.
In December a  stock of HDO1000 should arrive.

[Kleinstein]

It makes perfectly sense to already offer the hardare before the software is fine tuned with all details. The pricing of the HDO1000 sugests that they can earn good money from the HDO4000 - there are quite some changes with the higher resolution Scops the last years .  From what Daves videos show, the interface looks OK and workable, at least for the main features. Chances are there are enough customers eager to get one even with some more minor features not (yet) working. Currently it is not so much about would buy, but could buy. 

The HDO1000 is not not so much made for mixed signal tasks - so the seriell decoders are likely not high priority for such a scope. Though in some cases it may still be the only scope for some - so it would be nice to have the seriel decode over a larger range of setttings.  It should be reasonable esay to add / fix, but with the more B brands one never knows when and if things are fixed in the software.
It is still very early - and the limited time scale is more like a missing feature / anoying point that may be fixed in the future.  If this would be Fluke or R&S it may come up a pay extra option though.
So early there is a good chance to get at least some FW updates - though likely not just for this feature.

A not fully working seriel decoder as the first "bug" to come up is a good sign.

[tv84]

A not fully working seriel decoder as the first "bug" to come up is a good sign.

The "first" bug was what they did with the licensing scheme...

[Fungus]

That new Tek 'scope that appeared a couple of months ago didn't have the serial decoders enabled on launch because they weren't finished yet.

If the serial decoders on this one work above 50mS/div then that's something. I'm sure most people would rather have that today than a promise of "maybe next year sometime", like the Tek.

To the people that have one: What's the decoding like? Does it work well when it decides to do it?

[nctnico]

That new Tek 'scope that appeared a couple of months ago didn't have the serial decoders enabled on launch because they weren't finished yet.

If the serial decoders on this one work above 50mS/div then that's something. I'm sure most people would rather have that today than a promise of "maybe next year sometime", like the Tek.

No. Because with the Tektronix it is specified the decoders don't work -yet- so you can base your choice on that. It is all about unspecified surprises (= bugs) that make buying the Rigol an adventure. If you need working decoders today, you don't buy the Tektronix (unless decoders have been added in the meantime) but something else that you know works. MicSig did the same when they released the TO1000 series; the decoders where added later and MicSig was totally open about that. In the end nobody benefits from a feature that is half baked at the release.

[Martin72]

"...Do you know what we call it internally when it is clear at launch that the product is not quite ready yet ?
Banana version...banana version ??
Yes, banana version - matures with the customer."

(V.Pispers, satirist)

 

[markone]

I Just saw, for the first time,  Dave's HDO4000 Unboxing & First Impression video until the end, apart bugs in line with a young product, what i really can't stand for are things like waveform utterly stuck during vertical positioning, hardware wise this platform can do a lot better.

My old GW Instek toy GDS2072E does a much better job in this aspect, here we have a product line that reaches 5K euros in listing, if I were in place of Rigol marketing manager i would stress R/D department for a decent FW delivery ASAP.

[nctnico]

"...Do you know what we call it internally when it is clear at launch that the product is not quite ready yet ?
Banana version...banana version ??
Yes, banana version - matures with the customer."

I love it. So from now on we call incomplete test equipment firmware 'banana-ware' 

[TK]

Besides decode functionality, scope SW seems to be stable.

[markone]

Besides decode functionality, scope SW seems to be stable.

Do you confirm that during trace's vertical positioning the whole screen update is interrupted ?

[Martin72]

Do you think this is a bug?
Then all scopes I know have this bug.

[TK]

Do you think this is a bug?
Then all scopes I know have this bug.

Not the Keysight.  It updates the waveform during vertical positioning

[Martin72]

That´s right, I don´t know keysight scopes..

[markone]

That´s right, I don´t know keysight scopes..

You do not know also my GWINSTEK GDS-2072E, as i already said, it updates screen during vertical trace positioning, and it is a toy, so no need to mention expensive DSOs like Lecroy or Keysight.

What i saw in Steve video is an utterly frozen trace dragged on the screen, AFAIK this happens also with the 5K euro HDO4804 

[2N3055]

Do you think this is a bug?
Then all scopes I know have this bug.

Not the Keysight.  It updates the waveform during vertical positioning

Are you sure? Because MSOX3000T (it cost 3x more than HDO4804) stops triggering when you move vertical on a channel. It stops updating as long as you move it around quickly. It restarts without any delay so as soon as you stop moving it is back but stops while moving. You are moving last, frozen, capture up and down until you stop moving knob. And then it resumes.

And what is practical purpose of "updating while moving"? In what way is that useful? Or it has to be that way because CRTs do that (by nature of being analog) so it is "a right way"...

I couldn't care less if scope stops triggering completely (3000T stops ) because you are moving things on screen.
Scope simply waits for you to decide what command you will give it so it can resume doing that with new parameters.

That is a non problem.

[TK]

That´s right, I don´t know keysight scopes..

You do not know also my GWINSTEK GDS-2072E, as i already said, it updates screen during vertical trace positioning, and it is a toy, so no need to mention expensive DSOs like Lecroy or Keysight.

What i saw in Steve video is an utterly frozen trace dragged on the screen, AFAIK this happens also with the 5K euro HDO4804 

I have a toy Keysight EDUX1052A and it updates screen during vertical trace positioning.  I think the issue is not that it is useful or not for the scope to update the screen during repositioning of traces, but it shows how the SW is working inside and synchronizing all its modules concurrently.  The fact that some operations need to be frozen, means concurrency is not correctly implemented and taking advantage of the powerful CPU cores and it's communication with the FPGA and it also causes freezing and application reloads.  It is my humble opinion, as a software engineer.

[markone]

That´s right, I don´t know keysight scopes..

You do not know also my GWINSTEK GDS-2072E, as i already said, it updates screen during vertical trace positioning, and it is a toy, so no need to mention expensive DSOs like Lecroy or Keysight.

What i saw in Steve video is an utterly frozen trace dragged on the screen, AFAIK this happens also with the 5K euro HDO4804 

I have a toy Keysight EDUX1052A and it updates screen during vertical trace positioning.  I think the issue is not that it is useful or not for the scope to update the screen during repositioning of traces, but it shows how the SW is working inside and synchronizing all its modules concurrently.  The fact that some operations need to be frozen, means concurrency is not correctly implemented and taking advantage of the powerful CPU cores and it's communication with the FPGA and it also causes freezing and application reloads.  It is my humble opinion, as a software engineer.

That's exactly the point.

[Martin72]

That is a non problem.

Signing this.
What benefits you got when it´s not "freezing" while playing with the vertical adjustment..

[skander36]

Do you think this is a bug?
Then all scopes I know have this bug.

Not the Keysight.  It updates the waveform during vertical positioning

Keysight 2K stop when do vertical positioning.

[2N3055]

That´s right, I don´t know keysight scopes..

You do not know also my GWINSTEK GDS-2072E, as i already said, it updates screen during vertical trace positioning, and it is a toy, so no need to mention expensive DSOs like Lecroy or Keysight.

What i saw in Steve video is an utterly frozen trace dragged on the screen, AFAIK this happens also with the 5K euro HDO4804 

I have a toy Keysight EDUX1052A and it updates screen during vertical trace positioning.  I think the issue is not that it is useful or not for the scope to update the screen during repositioning of traces, but it shows how the SW is working inside and synchronizing all its modules concurrently.  The fact that some operations need to be frozen, means concurrency is not correctly implemented and taking advantage of the powerful CPU cores and it's communication with the FPGA and it also causes freezing and application reloads.  It is my humble opinion, as a software engineer.

That's exactly the point.

But that is exactly the point. Toy scope that has special architecture with minimum memory (it has 100-200X less memory than HDO1000), measurement from decimated data and no statistics. It's architecture was optimized for CRT scope emulation and fast as possible UI at the cost of everything else..

But I do think all of these news scopes could use some optimization. It can freeze waveform while I move knob. It shouldn't wait for a second to resume though. That is the key. Keysight 3000T that also stops triggering while moving button, resumes triggering immediately, so most people think it keeps displaying while moving.

[Martin72]

Starting a new Thread to keep this free for Topic...

[thm_w]

That new Tek 'scope that appeared a couple of months ago didn't have the serial decoders enabled on launch because they weren't finished yet.

If the serial decoders on this one work above 50mS/div then that's something. I'm sure most people would rather have that today than a promise of "maybe next year sometime", like the Tek.

No. Because with the Tektronix it is specified the decoders don't work -yet- so you can base your choice on that. It is all about unspecified surprises (= bugs) that make buying the Rigol an adventure. If you need working decoders today, you don't buy the Tektronix (unless decoders have been added in the meantime) but something else that you know works. MicSig did the same when they released the TO1000 series; the decoders where added later and MicSig was totally open about that. In the end nobody benefits from a feature that is half baked at the release.

Yeah that is totally valid.

Still you'd think at this point people would realize that serial decoding is low on the priority list for a number of scope manufacturers, for a reason (as Kleinstein points out).

[markone]

That is a non problem.

Signing this.
What benefits you got when it´s not "freezing" while playing with the vertical adjustment..

That you do not loose control on monitored system that could be an high power inverter in alpha stage development. 

Anyhow I decided to overcome this whole matter in necessity of quiet instrument :  scope purchased during black Friday sale and arrived today, first impression :

- screen quality is simply awesome, high contrast sharp image, responsive and good feeling touch operations, very good analog intensity emulation
- nice screen layout
- analog resolution is actually very high, for the first time i can spot DAC stepping of mine SDG2042X
- fan is loud as well as DS1054Z
- bug fest with serial decoder engaged

Does anyone know if it's available a FW update ?

Main Rigol sites do not have nothing.

[markone]

I would like to report a quite annoying bug, some settings are not stored / restored correctly across a shutdown, even manually recalling a setup saving.

For instance, at least in my case, channel one coupling is erroneously set to AC after reboot.

[tooki]

The same with i2c, I have to set the threshold to 4.4V for the decoder to decode correctly (The i2c signal on the Arduino has a slow rise time due to internal resistor value).

FYI, you probably just need to add an appropriately sized pull-up resistor for your bus capacitance.

See the attached guide from TI, it has a formula.

[skander36]

I would like to report a quite annoying bug, some settings are not stored / restored correctly across a shutdown, even manually recalling a setup saving.

For instance, at least in my case, channel one coupling is erroneously set to AC after reboot.

Yes, I can confirm this behaviour. I was thought that it is on purpose but I don't remember to read about this in user manual.
Also Flex knob does not always action even if it has focus on that field.

[TK]

I would like to report a quite annoying bug, some settings are not stored / restored correctly across a shutdown, even manually recalling a setup saving.

For instance, at least in my case, channel one coupling is erroneously set to AC after reboot.

Yes, I can confirm this behaviour. I was thought that it is on purpose but I don't remember to read about this in user manual.
Also Flex knob does not always action even if it has focus on that field.

I have the same issue.  My unit also defaults channel one to 20MHz bandwidth limit.  Happens with and without probe attached.

[markone]

Spotted right now another issue with Trigger with low level signal, i.e Sine 1MHz 50mVpp does not trigger with zero and negative thresholds (see attached image).
Rising threshold to 5mV and / or signal amplitude to 60mVpp scope starts to trigger ...

[TK]

Spotted right now another issue with Trigger with low level signal, i.e Sine 1MHz 50mVpp does not trigger with zero and negative thresholds (see attached image).
Rising threshold to 5mV and / or signal amplitude to 60mVpp scope starts to trigger ...

Does it not trigger at all or you see erratic triggering?  My experience with trigger at 0V is that it is subject to the input signal noise as it fluctuates and causes the trigger to fail

[markone]

Spotted right now another issue with Trigger with low level signal, i.e Sine 1MHz 50mVpp does not trigger with zero and negative thresholds (see attached image).
Rising threshold to 5mV and / or signal amplitude to 60mVpp scope starts to trigger ...

Does it not trigger at all or you see erratic triggering?  My experience with trigger at 0V is that it is subject to the input signal noise as it fluctuates and causes the trigger to fail

Does not trigger at all but i guess it would be enough to slowly rise the threshold to find the condition you describe.

Funny thing is that if you change signal shape you get different results.

[skander36]

  My unit also defaults channel one to 20MHz bandwidth limit.  Happens with and without probe attached.

Indeed. Also on Rigol 5K (Rigol tradition ). On HDO 1K you can disable if you want after start. Rigol 5k don't let you disable bw limit on signal levels under 2 mVpp.

[markone]

Spotted right now another issue with Trigger with low level signal, i.e Sine 1MHz 50mVpp does not trigger with zero and negative thresholds (see attached image).
Rising threshold to 5mV and / or signal amplitude to 60mVpp scope starts to trigger ...

Recalled default setting, trigger problem disappeared ... 

[Fungus]

The same with i2c, I have to set the threshold to 4.4V for the decoder to decode correctly (The i2c signal on the Arduino has a slow rise time due to internal resistor value).

FYI, you probably just need to add an appropriately sized pull-up resistor for your bus capacitance.

There's nothing "probable" about it. You're supposed to add external pullups. It's I2C 101.

[TK]

The same with i2c, I have to set the threshold to 4.4V for the decoder to decode correctly (The i2c signal on the Arduino has a slow rise time due to internal resistor value).

FYI, you probably just need to add an appropriately sized pull-up resistor for your bus capacitance.

There's nothing "probable" about it. You're supposed to add external pullups. It's I2C 101.

Not sure, AVR microcontrollers have internal pull-up resistors and Arduino is using them on I2C lines and the values are not good for I2C, so it is I2C 101 to have pull-up resistors on the BUS, just not easy to have the right value when using Arduino boards.

[Fungus]

AVR microcontrollers have internal pull-up resistors

Yes, in the 30-40k Ohms range - for minimal low power consumption in low-power devices.

I2C signals needs fast rise times so you need a lot less resistance than that for it to work properly.

(or you can limit your bus speed to something slow that works with the Arduino's pullups)

[Marchello]

DHO1074, firmware - 2.04

I have a problem with disabling the display of scales at the edges of the screen. If I turn them off in the menu (Display->Show Scale "Off") they turn off. But if I press Start or Stop Waveform Capture, the scales turns on by itself again!
I think it's not normal.

Can someone repeat this?

[dominicc]

There's a bug with the SPI trigger thresholds in FW 00.02.07, and probably earlier:

Steps to repeat:

1)   Setup 4  channels on SPI CS/CLK/MOSI/MISO using a 3.3v p-p SPI signal.
2)   Adjust each channel to a non-zero offset.
3)   Change the trigger to SPI trigger, using CS to trigger with a 1.5V.
4)   Configure SPI decoding, Set the SPI decoding levels to 1.5V on each channel.
5)   Ensuring the decode event view is visible and displaying correct data.
6)   Now go back into the trigger and simply change the CS channel to a different channel and back again.
7)   Observe the event view is now empty, this is because the SPI decode trigger levels have changed (!!!)
   Now go back into the SPI decode setup, observe all the trigger levels still show 1.5V (!!!)
9)   Now click one, observe the UI now shows it’s current value, which is different to 1.5V (!!!)
10)   Adjust them all back to 1.5V, and observe that the event view is again correct.

See video recorded from the webui:



Other things, other than the Step 6 above, also cause the issues with incorrect or reset trigger levels.  For instance, turning off and on and on any channel will reset one or more to 0v.

I've reported this to my supplier and will follow up with Rigol based on their response.

[dominicc]

The rotary encoders on my DHO4204 aren't reliable, as this video demonstrates:



It feels like the light isn't passing through some of the holes in the encoder wheel as the issue is present at the exact same spot on the dial.  I've not taken mine apart, just guessing based on what I know about how MCUs process the signals from a rotary encoder (example attached).

[dominicc]

Has anyone been able to get the video triggering working on a PAL or NTSC signal?

I can't get it to work here...  (see images attached).

It works OK on my old DS1074Z with the same signal... Did I miss something?

[maxwell3e10]

When saving data to .csv file in full memory format the x-scale tInc is wrong. Sometimes it is the same as for "screen" format- which only has 1000 points, but other times seems to be off by another factor. So often one cannot tell the time axis of the data saved.

When the scope is running in average acquisition mode, it stops triggering randomly and one needs to press "run" again.

[hfiennes]

Just got my DH1074 today, and I'm having issues with i2c decode.

Basically, the scope is always assuming 10 bit addressing. There is nowhere to set 10 bit (I guess the "without/with" sets 7/8 bit) so I can't clear it. I've tried setting 7 bit addressing in the I2C trigger and copying this across with the "copy trig" button in the decoder setup, but no luck.



It came with 2.00 and have updated to 2.11, but the bug persists. Anyone else see this? I was going to try a factory reset in case there's something randomly stale, but couldn't find one of those either.

[Fungus]

Basically, the scope is always assuming 10 bit addressing. There is nowhere to set 10 bit (I guess the "without/with" sets 7/8 bit) so I can't clear it. I've tried setting 7 bit addressing in the I2C trigger and copying this across with the "copy trig" button in the decoder setup, but no luck.

(Attachment Link)

It came with 2.00 and have updated to 2.11, but the bug persists. Anyone else see this? I was going to try a factory reset in case there's something randomly stale, but couldn't find one of those either.

I counted the clock pulses between the first start and stop in that image and there were 18 of them. Is the 'scope wrong in assuming 10 address and 8 data?

[skander36]

...
It came with 2.00 and have updated to 2.11, but the bug persists.
...

First mention that the Fw. 2.11 is out. I missed that.

From release notes:
00.02.11 2023/08/17

     - PassFail function optimization
     - Ref function optimization
     - Read screen data, fix the abnormal number of return values
     - Waveform distortion before triggering with large time base
     - CAN trigger related issues resolved
     - Fixed the wrong format of saved memory bin wave file
     - Fix low storage depth, after ZOOM is turned on, the square wave will be stabbed
     - Fix the data abnormality at the end of the high-resolution mode waveform
     - Fixed the inconsistent behavior of XY window switch operation
     - Fix the invalid initialization of webcontrol network settings
     - Fix Pass/fail cannot be terminated
     - Fixed the problem that SCPI could not get the measurement value
     - Fixed the problem of loss of test mask in special cases

Anyone is still encounter trivial bugs like scope crashing or Android stop messages (like in Dave's tests with DHO 800)?
From 2.07 version I did not encounetr this kind of problems but maybe I'm not using the scope enough.
 

[tooki]

The rotary encoders on my DHO4204 aren't reliable, as this video demonstrates:

[...]
It feels like the light isn't passing through some of the holes in the encoder wheel as the issue is present at the exact same spot on the dial.  I've not taken mine apart, just guessing based on what I know about how MCUs process the signals from a rotary encoder (example attached).

FYI, practically all rotary encoders used as human-machine interface (HMI) elements are electromechanical, basically a type of rotary switch, using flat contacts on one half and slightly offset leaf spring contacts on the other half. (Which contact type is on which part -- the rotor and the base -- varies by model.) Optical rotary encoders are very expensive and are used only on high-reliability HMIs like aircraft cockpits, and as the absolute-position encoders on rotary shafts in things like robotics.

The only optical rotary encoders found commonly in consumer devices are the ones used on mouse scroll wheels. (And long ago, when mice had balls, as the ball encoders, too.) I suspect it's simply because the wheel needs to be clickable, and the simple slot-type photointerrupter allows the use of a slotted wheel that can move up and down a bit.

See e.g.
https://newscrewdriver.com/2022/06/08/quadrature-encoder-rotary-knob-with-detent/
and

[Valentin72]

I recently received my Rigol DHO1072 from Aliexpress. Wow, big & beautiful. Almost the first time I turned it on and I found a bug, recipe:
- enable 10x probes on both channels (note, without 10x it is not repeated)
- trigger rs232 115.2k
- decoder channel 1 rs232 115.2k bus status on
- turn multipurpose button 1 until full screen "RIGOL.SCOPE has stopped"

ps many thanks to this forum, opened my rigol up to DHO1202

[Fungus]

Almost the first time I turned it on and I found a bug

Update your firmware and try it again. 

[skander36]

Almost the first time I turned it on and I found a bug

Update your firmware and try it again. 

Yes. I can't confirm this behaviour with the last ver. 00.02.11.

L.E. I remember that in one of the early fw. versions I've had a problem with the multifunctional knob(nr.1) where this does not taking any action. This behaviour has disapeared suddenly after few days.

[Valentin72]

You are right, I had version 02.07, I updated to 02.11 and the bug is not reproduced, thanks

[Fungus]

Out of interest: Does the reference voltage for serial decoding work correctly when the probe attenuation is set to 10x? Or is it 10x smaller than the value you set?

There's a bug in the DHO800 series at the moment and I was wondering is it's in the DHO1000.

[skander36]

Out of interest: Does the reference voltage for serial decoding work correctly when the probe attenuation is set to 10x? Or is it 10x smaller than the value you set?

There's a bug in the DHO800 series at the moment and I was wondering is it's in the DHO1000.

On 10X it is ten times bigger than on 1X, if I understand correctly your question.

[Fungus]

On 10X it is ten times bigger than on 1X, if I understand correctly your question.

Yes, that sounds like the same bug.

The problem is that the marker for threshold voltage is shown in the wrong place on screen so it can lead to it not working properly. To get it in the correct place you have to set the probe attenuation to 1x mode.

[skander36]

Yes. I always need to "drag" it from the bottom ...
I forgot about this. Usually I'm using Rigol 5k for protocol decoding.

[Alex-lab]

Some new bugs and "features":
a) If you select save both PNG and CSV on Quick, after restart it will save PNG and BIN.
b) File names are still like Rigol1, Rigol2... quite annoying, I would prefer to have simple date-time stamp, as we have for smartphone photos.
c) Appearance of waveforms in PNG files depends on the Run/Stop state. - Not sure, if this is a bag. In running mode it looks much smoother (High-res).
d) Real bug. If you stop the waveform, then change x-scale (s/div) for more details, after that varying the x-position breaks x-scale factor. So you have the original appearance of the waveform (as it was at stop pressed), but with a wrong X-scale. Doing the same in reverse order can bring it back into correct original view.

[Fungus]

a) If you select save both PNG and CSV on Quick, after restart it will save PNG and BIN.

Might be related to the whole "state isn't saved correctly" bug on the DHO800. There's a few things that don't save there.

b) File names are still like Rigol1, Rigol2... quite annoying, I would prefer to have simple date-time stamp, as we have for smartphone photos.

Does it have a RTC with battery? If not, it's going to be worse.

c) Appearance of waveforms in PNG files depends on the Run/Stop state. - Not sure, if this is a bag. In running mode it looks much smoother (High-res).

On the DHO800 there's a display setting called "Waveform freeze" to control this.

[NE666]

Does it have a RTC with battery?

Yes, it does.  So an option for timestamp based filenames would be nice.

[Alex-lab]

On the DHO800 there's a display setting called "Waveform freeze" to control this.

Indeed, but it doesn't change anything.

Some more bugs:
a) Adjusting Y-position makes incorrect rounding for zero value on the scale. In fact it is not a zero, but instead a very small value (like 26.048uV).
b) Incorrect evaluation of Vbase value. Here is just example, same issue is for many periods of the same signal.

[skander36]

Hi alex-lab,
I'm not sure that all are bugs as I didn't succeed to recreate all but please keep posting these findings here.
Thank you!

[scopeman]

Has anyone been able to get the video triggering working on a PAL or NTSC signal?

I can't get it to work here...  (see images attached).

It works OK on my old DS1074Z with the same signal... Did I miss something?

Did you ever find a resolution to this problem?

Sam

[TurboTom]

Here's a peculiar one:

Conditions:
- DHO1074 (200MHz and 100MSa options enabled), F/W 00.02.12
- Only channel 4 enabled
- 10MHz fast-rise square wave of 2.5Vp (ground-referenced) coupled to channel 4 (1V/div) and to EXT Trig input (correctly terminated)
- Trigger engine configured EXT, rising edge, 1.25V Threshold, "normal" mode
- Memory depth "Auto", but 1MSa "works" as well - others not tested

Findings:
The scope won't trigger if the time base is set faster than 50ns/div or zoom is enabled faster than that and becomes very sluggish to respond to user inputs. At 50ns/div or slower, everything works normally. This peculiar behaviour isn't present if another channel is used. Also, just enabling another, additional channel will return the scope to "normal" operation. Triggering on channel 4 works completely normal, just channel 4 and external trigger shows this behaviour. It appears that "playing around in menus" may resolve this problem eventually though I'm not sure what operation in particular causes this. After a fresh reboot, the described problem returns.

More findings:
In Trigger menu with "External" trigger source selected, the "50%" button should be made inactive since it only resets the trigger threshold to 0V. The trigger threshold setting appears not to be very accurate when the external trigger input is used - I find the scope to trigger well between approx. -500mV and +3.5V threshold setting when I apply my 2.5Vp signal. Maybe the ~100ps edges affect the external trigger circuitry.

Web Interface:
Did anybody notice that when using the web interface, the browser window size gets "automatically" reset every now and then and as a consequence, the scroll bars get enabled and obstruct some of the screen area (very annoying). I want my manually resized remote scope screen to stay that way... It even resets the screen size to "window" if "full screen" is selected!  Machine is a Windows 10 PC with Firefox browser, but a test with Edge shows the same problem. I'm not too much a Windows expert to know if this may be solved by browser configuration, but a quick scan through the setup menus didn't show up anything that might help (at least to my understanding). Any hint appreciated  !

[ebastler]

- DHO1074 (200MHz and 100MSa options enabled), F/W 00.02.12

Is that a typo for FW 02.11 or did I miss a new version?

[TurboTom]

Available here: https://www.rigol.com/products/detail/DHO1000 (chinese page) and click the third button just beneath the big presentation picture with the dark background.

[ebastler]

Available here: https://www.rigol.com/products/detail/DHO1000 (chinese page) and click the third button just beneath the big presentation picture with the dark background.

Thanks!

I wonder why it is so hard for Rigol to publish firmware updates consistenty across their international sites. And to put release dates on the website which actually describe the release date. (FW 02.12 contains files generated on October 18th, so it probably was not released in August as stated...) And maybe make release notes accessible on the website, so you can review them before downloading the whole firmware. -- Sigh...

[joeyjoejoe]

I'm trying to update my firmware on the DHO1074.

The firmware from Rigol is DHO4000Update.GEL - am I supposed to rename this?

[thm_w]

I'm trying to update my firmware on the DHO1074.

The firmware from Rigol is DHO4000Update.GEL - am I supposed to rename this?

Just copy it as is to USB, it should detect. If not, might need renaming.

[joeyjoejoe]

It was not detected. I'll try renaming

[joeyjoejoe]

No luck. I guess I'll email Rigol? It saves screenshots to the USB disk no problem. I'm using the one next to the power button. Renamed to 1000 still no file found it says.

[thm_w]

It was not detected. I'll try renaming

The file name should be "DHO4000Update.GEL" as per: https://www.eevblog.com/forum/testgear/dho1000-missing-gel-file-in-0-2-7-upgrade/
edit: see below use storage function to upgrade. normal upgrade menu might be some kind of web based one.

[Fungus]

It was not detected. I'll try renaming

Did you select the file from the list, can you see the file name in the firmware update box?

[joeyjoejoe]

Nope I hit upgrade and it just says no file found. Don't even get a chooser. I'm hitting the icon in the bottom left of the screen and choosing upgrade

[Fungus]

On the DHO800 you have to go to "Storage->Upgrade"

[sonic]

Has anyone been able to get the video triggering working on a PAL or NTSC signal?

I can't get it to work here...  (see images attached).

It works OK on my old DS1074Z with the same signal...

The same for my DHO804.

[joeyjoejoe]

I think a bug - Every time I power up, the attenuation on my probes is set to 1X and I have to set it again. I have not seen any options to save this setting between power cycles. DHO1074

[thm_w]

I think a bug - Every time I power up, the attenuation on my probes is set to 1X and I have to set it again. I have not seen any options to save this setting between power cycles. DHO1074

Tap the date in the bottom right corner -> Setup -> Load last = Last

[gburdzin]

I think a bug - Every time I power up, the attenuation on my probes is set to 1X and I have to set it again. I have not seen any options to save this setting between power cycles. DHO1074

Tap the date in the bottom right corner -> Setup -> Load last = Last

A couple of things that I noticed were not saved by selecting the "Last" setting.

1. Screen Brightness - I set it to 50% and it always goes back to 100% on bootup
2. External 10MHz Reference - I have to turn it on each time the scope is booted

[Fungus]

1. Screen Brightness - I set it to 50% and it always goes back to 100% on bootup

The DHO800 is the same. Try setting the trace intensity to 100% then reboot twice...

[the Chris]

There seems to be a bug in the statistics feature for the DEViation figure when choosing larger than 1k counts, at least for the rise time measurements.

I just wanted to verify a bandwidth upgrade on my DHO1074 with FW 00.02.12 when I saw that the deviation figure for the risetime measurement statistics with 10k counts maximum was very solid while the number of measurements was counting up, but the dev figure started to rise continuously without a cause once the 10k were reached. I could replicate the error several times, at least with 10k, but I assume any number higher than default is affected or the effect is more pronounced the higher the maximum count is set (kind of a hardcoded 1k count in the calculation once the limit is reached).

So better to either stick to 1k or go with 100k to be on the safe side and take the reading as long as it is below 100k.

EDIT: set it to 100k, door bell rang, came back about 10min later with counter at ~15k and DEV was at 0.000. So there is some other bug as well 

[RobbiOne]

Nope I hit upgrade and it just says no file found. Don't even get a chooser. I'm hitting the icon in the bottom left of the screen and choosing upgrade

DHO1074 with v2.04 FW just arrived. I renamed the new v2.12 FW file from dho4000... to hdo1000... and that worked like a charm.

[t3chiman]

...
DHO1074 with v2.04 FW just arrived. I renamed the new v2.12 FW file from dho4000... to hdo1000... and that worked like a charm.

I went through the Storage->Disk->File menu sequence. The Upgrade Button worked fine with the original file name.

[RobbiOne]

...
DHO1074 with v2.04 FW just arrived. I renamed the new v2.12 FW file from dho4000... to hdo1000... and that worked like a charm.

I went through the Storage->Disk->File menu sequence. The Upgrade Button worked fine with the original file name.

What was your FW before updating to v2.12?
My dho1074 with the original v2.04 didn't recognize the update file dho4000 until renaming.

[t3chiman]

Apologies, I am repeating from a prior thread. I got in a DHO1074 from RigolNA. Firmware was 04.02.02 before upgrading, initially to 00.02.11, then to 00.02.12.

Just an observation: Rigol's firmware upgrade procedure and  release control management are both "unsophisticated". A bunch of talented and motivated engineers--the eevblog team--experience hesitancy and confusion during what should be a naive button pushing exercise.

[thm_w]

There seems to be a bug in the statistics feature for the DEViation figure when choosing larger than 1k counts, at least for the rise time measurements.

I just wanted to verify a bandwidth upgrade on my DHO1074 with FW 00.02.12 when I saw that the deviation figure for the risetime measurement statistics with 10k counts maximum was very solid while the number of measurements was counting up, but the dev figure started to rise continuously without a cause once the 10k were reached. I could replicate the error several times, at least with 10k, but I assume any number higher than default is affected or the effect is more pronounced the higher the maximum count is set (kind of a hardcoded 1k count in the calculation once the limit is reached).

So better to either stick to 1k or go with 100k to be on the safe side and take the reading as long as it is below 100k.

EDIT: set it to 100k, door bell rang, came back about 10min later with counter at ~15k and DEV was at 0.000. So there is some other bug as well 

Was able to reproduce but not in the same way:
- Turn on CH1, 1V/div, 1us
- Turn on AC RMS, Vamp, and RiseTime measurements
- Tap measurement, setting, change counts to 10000
- Dev for Vamp (second measurement) shows as 0.000V
edit: I removed and re-added Vamp and it still showed as 0.000V. So it doesn't matter what position the measurement is in on the screen. Removed it completely and another random measurement shows 0V

Did you report to Rigol?

[the Chris]

Did you report to Rigol?

No, but it probably doesn't harm trying. Is there an official way to report bugs?

[thm_w]

Did you report to Rigol?

No, but it probably doesn't harm trying. Is there an official way to report bugs?

You can send an email to info-europe@rigol.com in EU or help@rigol.com for NA. They will respond back with a confirmation and add to list of bugs.

edit: I was actually on 2.11 and most of the 0.000V Dev issues seem to be fixed on 2.12, but not all. For Frequency I had it get stuck on a certain Dev value and never change. Which has to be wrong if its calculated based on the last 1,000 points. I assuming its storing those numbers, as the max you can set is 100,000.

[thunderbolt93]

I tried that with FW 2.12 and noticed something
there seems to be some jitter of about 2ns when using the external trigger input.

Both screenshots are taken with infinite persistance

[TurboTom]

It's not a bug, it's a feature  . See pg. 10 of Rigol's HDO1000 Data Sheet document. There you'll find jitter for the external trigger input to be specified at < 1ns rms (which equals <2ns pp or even more, depending on the histogram), exactly what one would expect from an all-digital trigger system that had been "extended" with an additional one-bit ADC (comparator...) for the fifth, external trigger input. Obviously, for this input, an interpolative trigger, based on the waveform isn't possible, hence the jitter of an interval that is defined by the speed the sampling engine's FPGA can process the trigger comparator input signal.

What's much more worrying is the trigger jitter that is present at AC and HF trigger coupling as had been reported by others before. That shouldn't be there and Rigol will have to take care of this.

[gf]

It's not a bug, it's a feature  . See pg. 10 of Rigol's HDO1000 Data Sheet document. There you'll find jitter for the external trigger input to be specified at < 1ns rms (which equals <2.8ns pp), exactly what one would expect from an all-digital trigger system that had been "extended" with an additional one-bit ADC (comparator...) for the fifth, external trigger input. Obviously, for this input, an interpolative trigger, based on the waveform isn't possible, hence the jitter of an interval that is defined by the speed the sampling engine's FPGA can process the trigger comparator input signal.

In principle, it would have been possible to measure the time interval between the trigger point (as determined by the comparator) and the ADC clock edge with a TDC, but it was obviously a cost-saving design decision not to do it.

[pilatomic]

Hello fellow bug collectors,

I took delivery of a DHO1074 last week, and found 2 bugs I didn't see mentionned anywhere. (FW ver 00.02.12).

1. Decoders threshold levels bug.

    If probes are set to a value other than X1, decoders thresholds level do not keep their value each time a new acquisition is done, or a trace is moved.

How to reproduce :

    Set CH1 probe to X10, enable I2C decoder with CH1 as SDA (for example), and set threshold to 1.0V. Press "Single" to . Decoder threshold still shows "1.0V", but when clicked immediately switches to 10.0V. Decoding does __not__ happen until setting back the threshold to 1.0V, which implies the threshold is internally set to 10.0V.

This is a blocking issue in my workflow, as it completely prevents SPI decoding using X10 probes.

2. Cannot change channel of measurement

How to reproduce :

    Enable any measurement, on a specific channel. Press on measurement, press "settings" and change measurement channel. This has no effect.


I wrote to Rigol (info-europe@rigol.com) about that, I'm waiting for their answer.
I hope to see at least the 1st one resolved, as it makes the decoders basically useless with anything else than 1X probes.

[Fungus]

Both have been mentioned before but another person writing to Rigol is good... 

[ebastler]

I have spent some time playing with the FFT on my DHO1074 now. Here's my summary of the good, the bad and the ugly -- repeating various findings others have reported before, but also adding a bit more clarity on some aspects, I hope. Apologies for a long post...

1. Good news first: One does get full control over the FFT record length and sampling rate, and hence the frequency step (resolution) and maximum frequency range. It is just not part of the FFT dialog, but controlled via the regular acquisition settings -- which makes sense to me, since FFT is a math operation based on the normally acquired data:

• The total duration of a sweep (10 * time/div) controls the frequency step in the FFT, df = 1/t_sweep.
  EDIT: While that is "qualitatively true", the exact frequency step (as read from the kinks in the linear-interpolated FFT spectrum) is not exactly as stated. Steps can be smaller than expected, pointing to a larger record length being used. See the posts by gf and myself a bit further down.
• The sampling rate controls the maximum frequency, f_max = f_sampling/2 as expected. Can be set to taste via the time base and the memory depth (acquisition settings).
• Caveat 1: As advertised, the FFT only uses up to 1 MPts of data. If more memory is selected in the acquisition settings, the acquisition will run at a faster sampling rate, but the data will be down-sampled for the FFT, limiting the max. frequency. The sampling rate indicated in the FFT window will be the one actually used for FFT, as one would expect. This is all fine and in spec.
• Caveat 2: At slow time base settings, 50 ms/div and slower, something breaks. The FFT's maximum frequency drops to only 1/10 of what one would expect. E.g. for 1 MPts, 50 ms/div, the sampling frequency is 2 MSa/s as expected, but fmax = 100 kHz instead of the expected 1 MHz. This is a bug, I believe.
  EDIT: Automatic Roll mode was activated and kicked in at 50 ms/div. While it is unfortunate that this throws the FFT off track, it is easily avoided by disabling Roll mode in the acquisition settings.

2. As discussed in earlier posts, the "RBW" displayed in the FFT window title is a mess on multiple levels:

• Terminology is wrong; it is apparently not meant to be a Resolution Bandwidth, but a frequency step. Values don't change when you change window functions, and the numbers are too even to be actual RBWs.
• The displayed RBW value does not have a unit. And the missing unit does not seem to be simply Hz in most cases...
• The displayed RBW is not even reproducibly linked to the FFT settings! Turn the time base up and back down by a step or two, and the RBW does not always return to its prior value?! The actual frequency step and resolution of the FFT behave correctly though. Clearly a bug.

3. Peak search works well for me. Sorting the peak table by frequency or amplitude, setting the minimum peak level and the minimum excursion (valley depth) between peaks all work as expected. However I ran into situations a few times where the FlexKnobs got confused as to what they were controlling. Clearly buggy, although I struggle to find a crisp sequence of steps to reproduce it. Not sure whether this is specific to FFT/Peak Detection, or can also happen with other dialogs which have many numeric input fields to choose from?

• E.g. the yellow "1" and "2" markers were on the peak detection settings, but the markers knobs actually controlled the FFT span and center frequency.
• Related, but not directly correlated with the above: Sometimes the white illuminated arrows next to the FlexKnobs point in the wrong direction, e.g. showing horizontal arrows while the control acts on a vertical (voltage) parameter.

4. As found and fixed by TurboTom, Rigol's Flattop window is broken. With Tom's fixed weights, FlatTop is my go-to window function.

5. As mentioned many times (not only by the friends of Siglent  ), it is a pity that neither Averaging nor Peak Hold modes are implemented for FFT. Not a bug but an important feature wish.

[2N3055]

I have spent some time playing with the FFT on my DHO1074 now. Here's my summary of the good, the bad and the ugly -- repeating various findings others have reported before, but also adding a bit more clarity on some aspects, I hope. Apologies for a long post...

1. Good news first: One does get full control over the FFT record length and sampling rate, and hence the frequency step (resolution) and maximum frequency range. It is just not part of the FFT dialog, but controlled via the regular acquisition settings -- which makes sense to me, since FFT is a math operation based on the normally acquired data:

• The total duration of a sweep (10 * time/div) controls the frequency step in the FFT, df = 1/t_sweep.
• The sampling rate controls the maximum frequency, f_max = f_sampling/2 as expected. Can be set to taste via the time base and the memory depth (acquisition settings).
• Caveat 1: As advertised, the FFT only uses up to 1 MPts of data. If more memory is selected in the acquisition settings, the acquisition will run at a faster sampling rate, but the data will be down-sampled for the FFT, limiting the max. frequency. The sampling rate indicated in the FFT window will be the one actually used for FFT, as one would expect. This is all fine and in spec.
• Caveat 2: At slow time base settings, 50 ms/div and slower, something breaks. The FFT's maximum frequency drops to only 1/10 of what one would expect. E.g. for 1 MPts, 50 ms/div, the sampling frequency is 2 MSa/s as expected, but fmax = 100 kHz instead of the expected 1 MHz. This is a bug, I believe.

2. As discussed in earlier posts, the "RBW" displayed in the FFT window title is a mess on multiple levels:

• Terminology is wrong; it is apparently not meant to be a Resolution Bandwidth, but a frequency step. Values don't change when you change window functions, and the numbers are too even to be actual RBWs.
• The displayed RBW value does not have a unit. And the missing unit does not seem to be simply Hz in most cases...
• The displayed RBW is not even reproducibly linked to the FFT settings! Turn the time base up and back down by a step or two, and the RBW does not always return to its prior value?! The actual frequency step and resolution of the FFT behave correctly though. Clearly a bug.

3. Peak search works well for me. Sorting the peak table by frequency or amplitude, setting the minimum peak level and the minimum excursion (valley depth) between peaks all work as expected. However I ran into situations a few times where the FlexKnobs got confused as to what they were controlling. Clearly buggy, although I struggle to find a crisp sequence of steps to reproduce it. Not sure whether this is specific to FFT/Peak Detection, or can also happen with other dialogs which have many numeric input fields to choose from?

• E.g. the yellow "1" and "2" markers were on the peak detection settings, but the markers actually controlled the FFT span and center frequency.
• Related, but not directly correlated with the above: Sometimes the white illuminated arrows next to the FlexKnobs point in the wrong direction, e.g. showing horizontal arrows while the control acts on a vertical (voltage) parameter.

4. As found and fixed by TurboTom, Rigol's Flattop window is broken. With Tom's fixed weights, FlatTop is my go-to window function.

5. As mentioned many times (not only by the friends of Siglent  ), it is a pity that neither Averaging nor Peak Hold modes are implemented for FFT. Not a bug but an important feature wish.

Excellent work and post!

[Martin72]

4. As found and fixed by TurboTom, Rigol's Flattop window is broken. With Tom's fixed weights, FlatTop is my go-to window function.

Afaik flattop window was not the only one or did you check all of them ?

[ebastler]

4. As found and fixed by TurboTom, Rigol's Flattop window is broken. With Tom's fixed weights, FlatTop is my go-to window function.

Afaik flattop window was not the only one or did you check all of them ?

I did look at the spectra generated with other window functions, and they look much more plausible. There is, however, a slight asymmetry in the main peak when you zoom in a lot, with all the window functions. That's probably not real, so yes, there might be (lesser) deviations in other window functions too.

As a consequence of setting the sampling parameters via the regular time base and memory depth controls, the FFT always works on record lengths which are not a power of two, apparently. I wonder whether the implementation handles that cleanly?

[gf]

Afaik flattop window was not the only one or did you check all of them ?

I did look at the spectra generated with other window functions, and they look much more plausible. There is, however, a slight asymmetry in the main peak when you zoom in a lot, with all the window functions. That's probably not real, so yes, there might be (lesser) deviations in other window functions too.

The left sides of these images definitively do not look correct. Seems to be rather a general problem, not window function specific. Maybe related to the interpolation upon zoom-in?

As a consequence of setting the sampling parameters via the regular time base and memory depth controls, the FFT always works on record lengths which are not a power of two, apparently. I wonder whether the implementation handles that cleanly?

There do exist FFT algorithms for non-power-of-2 sizes. All "1-2-5 sizes" can be decomposed into combinations of radix-2 and radix-5.

[ebastler]

The left sides of these images definitively do not look correct. Seems to be rather a general problem, not window function specific. Maybe related to the interpolation upon zoom-in?

Ah, thanks for the link. I remembered that Martin had done FFT measurements with the DHO800, but could not find them yesterday.

I just repeated with the same settings on the DHO1074, and with an input signal at 1 kHz - 1/2 delta_f. As one would expect things look pretty much the same. I had seen that distortion in yesterday's experiments; it's the "slight asymmetry" of the peak shape I referred to above. Certainly an artefact, but not as problematic as the massive peak broadening and ripple produced by the incorrect flat-top window.

EDIT: I don't think the distorted peak shapes are due to interpolation artefacts. For the FFT, simple linear interpolation between data points is used; while there is no "dot" mode, the individual straight line segments are visible when zoomed in. The asymmetry is on a scale of several delta_f steps.

Maybe, if TurboTom finds himself with too much time on his hands, he could look into those other window functions too? 

There do exist FFT algorithms for non-power-of-2 sizes. All "1-2-5 sizes" can be decomposed into combinations of radix-2 and radix-5.

Sure, I know they exist. My question was whether Rigol got them right.
That might be another reason for FFT artefacts, besides deviations in the window functions.

EDIT 2: Looking at Martins DHO800 screenshots again, they do show more reasonable "RBW" values. The displayed "RBW" is actually the frequency step in Hz in all those screenshots. On the DHO1074, I get displays of "9.999m" or such. And as mentioned, if I switch the time base up and down again, the RBW often does not come back to where it was before, so there is no clear correlation between delta_f and RBW at all. Looks like they at least fixed that in the DHO800, so there is hope for the larger models... If they furthermore added the "Hz" unit and called it "Step" instead of RBW, I'd be happy. 

[gf]

I don't think the distorted peak shapes are due to interpolation artefacts. For the FFT, simple linear interpolation between data points is used; while there is no "dot" mode, the individual straight line segments are visible when zoomed in. The asymmetry is on a scale of several delta_f steps.

The Siglent screenshots I've seen did indeed interpolate linearly between frequency points. But do you also see straight line segments on the DHO?

With linear interpolation between frequency points, you would not see the side lobes of Rectangular, Hann, Blackman, Flattop (and some others) windows, because the frequency points outside the main lobe happen to coincide with zeros of the frequency response of these window functions - and linear interpolation would give zero anywhere in between, too. But in various posted DHO screenshots, I do see side lobes. This leads me to believe that the DHOs do not interpolate linearly.

EDIT: I have to correct: We still can see contributions of side lobes, of course, if the signal frequency is not an integer multiple of delta_f.

[ebastler]

The Siglent screenshots I've seen did indeed interpolate linearly between frequency points. But do you also see straight line segments on the DHO?
[...]
We still can see contributions of side lobes, of course, if the signal frequency is not an integer multiple of delta_f.

Yes, the interpolation clearly shows linear segments -- see the attached screenshot.

In the attached, I set the signal frequency to 1 kHz, a full multiple of delta_f, and there still is an asymmetry. Also, strangely there never seems to be an FFT data point right at 1 kHz; they are always a bit displaced to the left and right, and asymmetrically from the 1 kHz mark. (Assuming that the kinks in the curve denote the data points.) Is that a consequence of the non-power-of-two FFT? EDIT: I don't see how that would be the case though, with an even 10 MHz sampling rate.

[gf]

Also, strangely there never seems to be an FFT data point right at 1 kHz;

The FFT frequency points should be integer multiples of delta_f. So with delta_f=20Hz, yes, there should be a point at 1kHz. Strange if not.

EDIT:

Ist it possible that we do not see a 500,000 point FFT, but rather a 524,288 (power-of-2) point FFT?
Then the actual delta_f would be 19.073 Hz, and frequency points would exist at 991.82 and 1010.9 Hz.

This would at least imply that the reported delta_f (RBW) is wrong/misleading.
(The reported number of FFT points can't be wrong, since it is not reported )

EDIT:

Figure.png shows what to expect from a 10MSa/s, 524288 point FFT with Hamming window and linear interpolation.
It also does not match the shape in your screenshot.

EDIT:

And figure2.png show what to expect with 500000 points.
Since 1kHz is an integral multiple of 20Hz, no side lobes are visible.

[ebastler]

You might be onto something there! Here's the FFT of a 991.82 Hz signal -- looks nice and symmetrical, with a data point right in the center of the peak. (Although the horizontal scale thinks it's peaking at 992.2 Hz, for whatever reason.)

On the other hand, the frequency step does not match that assumption: I chose that odd span setting in the screenshot to show that the FFT data points are pretty exactly 0.775 Hz apart, corresponding to a record length of 1.29 seconds or 1.29 MPts at 1 Pt/µs. What kind of number is that though? Not a power of two... And actually more than the advertised 1 MPts. Mysterious...

EDIT: At least I figured out what went wrong at 50 ms/div and slower in yesterday's experiments. I had the acquisition mode set to "Roll: Auto", with a 50 ms/div threshold. I just never noticed the rolling trace, since it was a steady sine with individual periods not resolved on the screen. Easily avoided, but it would be nice if the FFT were not bothered by that acquisition setting.

[Antonio90]

Good morning,
have you tried activating a video signal? (pal/secam)my DHO1074 can't trigger a video signal

Hello, yes, it is a known bug, and a software problem with the platform in general. You will have the same problem with any DHO1000, even if you get it exchanged by the seller.

 People interested in this oscilloscope model will read most, if not all of the related threads, no need to post in all of them.

[Alex-lab]

Some new weird behaviour.
I was trying to analyse a saturation limit of the inductor. Blue line is the current (1Ohm).
However, when I changed Y-scale, the pulse changed its shape with some negative spike.
Any hypothesis? Thanks.

[Fungus]

It could be you're going way off the bottom of the screen, in which case you're running into opamp overload/recovery.

Does it change if you move the trace up/down?

Zoom in horizontally to take a good look at the negative peak.

There are many threads on this topic, eg.: https://www.eevblog.com/forum/testgear/rigol-ds1054z-vertical-distortion-problem/

[thm_w]

Some new weird behaviour.
I was trying to analyse a saturation limit of the inductor. Blue line is the current (1Ohm).
However, when I changed Y-scale, the pulse changed its shape with some negative spike.
Any hypothesis? Thanks.

Please use the web interface or USB key to take a screenshot, very hard to tell if the signal actually changed or if its just more visible as a result of zooming in.

[dominicc]

So it's April 2024 and I feel like Rigol has left me and everyone else with a new 12-bit scope out in the cold with no new firmware since 2023/10/18 while a myriad of bugs remain present.  Anyone else feel the same?

[dominicc]

Has anyone been able to get the video triggering working on a PAL or NTSC signal?

Did you ever find a resolution to this problem?
Sam

no, and neither rigolshop.eu or rigol have responded to any of my initial emails regarding the subject.

[dominicc]

Has anyone else here got Color Grading to work?  (DHO4000 manual, section 19.7)  I'm trying to measure crystal oscillator stability, and toggling the button does absolutely nothing.

[thm_w]

Has anyone else here got Color Grading to work?  (DHO4000 manual, section 19.7)  I'm trying to measure crystal oscillator stability, and toggling the button does absolutely nothing.

Sure its working on dho1000, though not amazing. Depending on the memory depth the visibility may go to nothing.
Maybe try turning off hires too.

[dominicc]

Sure its working on dho1000, though not amazing. Depending on the memory depth the visibility may go to nothing.
Maybe try turning off hires too.

Still not working here at 500Mpts, 5GSa/s at 200ns/div with infinite persistence (or any lower persistence) and high-res off:

[thm_w]

Turn down the memory depth, not up. Or set it to auto.

[TurboTom]

When displaying a reference waveform, overlaid together with an actual channel waveform in "stopped" mode, zooming in on the time base may lose the phase correlation between reference and waveform at certain time base (especially vernier mode) settings. F/W is 02.12. When the time base is running, this discrepancy may momentarily also show up but gets corrected upon the next trigger. See attached screenshot for an example. Anybody to confirm this?

[pilatomic]

Firmware 2.13 is now  available on Rigol's website !
https://alc-sh-wwwdownload.oss-cn-shanghai.aliyuncs.com/cn/Firmware/Digital%20Oscilloscope/DHO1000%26DHO4000/DHO1000-DHO4000(software)Update00.02.13.00.07.zip

And they fixed my main grudge, the decoder levels jumping around ! 

Here is the complete changelog :

0.02.13 2024/03/27
      - Fixed the problem of deleting files when copying the same files.
      - Requirements for optimizing the total time for oscilloscope delivery, configuration, and reading.
      - Fixed the problem of crash when LAN is not connected and click Apply.
      - Fixed the problem that after passing the test screenshot, it cannot be stopped.
      - After fixing the default, *IDN? cannot read the project version number.
      - The problem of not closing the project version number lxi/identification.
      - Fixed the issue of statistics not being reset when moving the measurement cursor.
      - Fixed the problem that the measurement value of the moving cursor area is not updated after STOP.
      - Fixed the problem of occasional no waveform when booting.
      - Fixed the issue of the waveform disappearing in small gears after a pause.
      - Implementation of USB external keyboard requirements.
      - Fixed the problem of obtaining Math waveform error.
      - Fixed vertical scaling mask error by testing.
      - Fixed SPI timeout triggering problem, also for four-channel mode.
      - Modify the problem that ultraLab cannot connect to the server after shutting down and restarting.
      - When the Zoom function is turned on, the cursor adjustment area is not limited to the Zoom window.
      - Modify the offset range below 50 ohm and 500uV/div to solve the flip problem.
      - Fixed the problem of failure to modify the settings of measurement source B.
      - Fixed the problem of window transparency and failure to load the last value.
      - Fixed the problem of error in saving screen waveform to csv and SCPI command to obtain waveform in Math filter operation.
      - Fixed the problem of crosstalk caused by adjusting vertical offset.
      - One-click to open the measurement items required by the user and realize the functional requirements of the trigger source tracking channel.
     - Error displayed when modifying the measurement cursor for multi-source measurement.
     - Fix the problem of IIC SCL threshold and SDA threshold random reset&trigger level line random jumping caused by probe ratio at 10X gear.

[Fungus]

Weird that it's dated March 27th...

I wonder when will it be available for DHO800?

[hooch99]

I noticed that on my 1072 frequency measurement is empty until I fit at least 2 cycles on the display using horizontal scale. Is this a bug or a feature?

[Fungus]

I noticed that on my 1072 frequency measurement is empty until I fit at least 2 cycles on the display using horizontal scale. Is this a bug or a feature?

Feature.

One cycle is a pulse, not a signal with a frequency.

[sorenkir]

Hi,
I have an annoying issue with RS232 decoding in ASCII format on my DHO1074.
What do you think is the best way to contact Rigol for support.
Did any of you had success mailing to help@rigol.com ?
Thanks,
Michel.

[Fungus]

I have an annoying issue with RS232 decoding in ASCII format on my DHO1074.

What's the issue?

What do you think is the best way to contact Rigol for support.
Did any of you had success mailing to help@rigol.com ?

I'm sure they'll pass your email along to Rigol China but don't set expectations too high after that.

[sorenkir]

Hi,
Mail to help@rigol.com done!

The issue :
I have a DHO1074 with the latest firmware (00.02.13).
When decoding a RS232 signal, everything works fine when displayed in Hex, Dec or Bin. Also, everything  works OK in Zoom mode with these display formats.

But when I set it to display in ASCII format, below a certain timebase setting, the decoding data does not follow the trace when it is moved with Horizontal position (see screenshot below).
Also ASCII decoding data is not displayed properly in Zoom mode.

Michel.