# Rigol DS1074 oscilloscope shows very wrong timing

I have an inverted RS232 signal with 5 baud (200 ms per bit) which is sending the byte 0x33. (The first "Low" is the start bit)

When I configure my oscilloscope to 200 ms per unit it shows this signal absolutely perfect. I use the single trigger mode (button "Single" at the right top)

As you see the timing is precise.

Now comes the weird: I caputure the same signal with the setting 500 ms per unit. It looks like this.

To see the timing better I switch the timing to 200 ms per unit for the SAME capture and get this:

As you see the signal seems to be slower than 200 ms per bit now. How is that even possible on a digital oscilloscope?

In the first step the oscilloscope stores the captured data in memory. In the second step it displays the data. All timing is based on a precise crystal oscillator.

The only difference which I see is at the top of the screenshot where it says:

Correct capture: 10.0 MSa/s and 24.0M pts

Wrong capture: 4.0 MSa/s and 24.0M pts

The only explanation to me seems to be a fat software bug. Are the Rigol engineers not able to do the correct conversion to display a 4.0M Samples signal? How did this oscillocope series even pass the quality control?

And yes: I have made sure that my signal is precise. I can repeat that a hundred times: Capturing with 200 ms per unit is perfect. Capturing with 500 ms per unit gets wrong.

P.D: Now I tested more time bases. These are the results:

5 seconds per unit --> OK
2 seconds per unit --> OK
1 second per unit --> OK
500 ms per unit --> wrong (constantly 4% timing error)
200 ms per unit --> OK
100 ms per unit --> OK
50 ms or less --> a period does not fit anymore


But this is just one of multiple bugs. The oscilloscope has several more bugs.

When you enable the RS232 decoder and the horizontal resolution is too small it is understandable that it does not show the hex bytes. But this is implemented so buggy that it displays completely wrong data! This screenshot shows a RS232 signal with 10400 baud and long pauses between the data packets. All the displayed "FF" are wrong.

And one of the ugliest bugs is the knob "Horizontal Position". This is complete crap. It should move the signal horizontally on the screen. But it works so bad that moving the knob fast results in the signal suddenly jumping to a completely different loaction. When you move it slowly it nearly does not move at all. Such a basic functionality as navigating in a long capture with a Rigol oscilloscope is a pain!

And when you move that knob too fast you get suddenly artifacts in the signal. The same signal which I caputured above, suddenly looks like this:

Amplifying this bug you see a square signal of 2 ms period. This signal has never existed on the input of the oscilloscope. It is produced by a software bug in the oscilloscope just by moving the captured signal in memory horizontally on the screen!! Here you see a zoom of the left artifact:

And this is a zoom of the right artifact:

And as if all this would not be enough, there are more bugs. All these bugs are not reproducable. For example:

1. There is a signal but the oscilloscope does not trigger. It triggers mostly, but not always.
2. The "Single" trigger mode is enabled, but the scope does not stop after the screen is full.
3. It happened that I plug in a USB stick and the oscillscope completely freezes. All buttons were dead.
• sorry, no matter how many times you think you made sure your signal is correct, I'd still put arbitrary bets that Rigol is right and your signal is wrong. Full stop – it's never the oscilloscope, it's always either the signal, misuse of the measurement device, or impedance. In your case, we can rule out the last. Aug 21 '20 at 17:10
• Fire up your cursors and make a deltax measure of the pulse duration. What does it read? Aug 21 '20 at 17:25
• Don't know whats for you to gain here by asking this question, if you suspect a firmware bug, e-mail Rigol.
– S.s.
Aug 21 '20 at 17:55
• Well fan my brow. If I set memory depth to 24M I get the same pulse dilation on my 1054z. Everything is fine and dandy with the default settings but when I put 24M my 1000ms Arduino heartbeat gets longer. Aug 21 '20 at 21:50

Looks like a bug to me. I reproduced it on my 1054z using an Arduino with an LED blinking program.

This is the signal with 12M memory depth acquired at 500ms timescale, and then expanded at 200 ms scale. The 'beat' is 1000 ms long. (Ok, technically it's 900ms long plus the overhead, but if I add the first part of the next train I get a nice 1000 ms sequence that makes numbers nicer.)

The one above is the result I get with AUTO memory settings as well. But if I set memory depth to 24M I get problems at the 500ms scale. As above, this is the signal aquired at 500ms timescale and then expanded to 200ms timescale:

Pulse length appears extended by 40 ms, that's the same 4ms every 100ms shown by the OP (he goes from 600ms to 624ms). Acquisition at 200ms timescale shows the correct pulse length of 1000ms

But if I acquire at 500ms timescale, I get 1040 ms

Here's the Arduino Sketch, if anyone wants to replicate it.

/*
Turns on and off an LED in a predetermined sequence, repeatedly.

Most Arduinos have an on-board LED you can control. On the Uno and
Leonardo, it is attached to digital pin 13. If you're unsure what
pin the on-board LED is connected to on your Arduino model, check
the documentation at http://www.arduino.cc

This example code is in the public domain.

modified 8 May 2014
by Scott Fitzgerald
modified 15 February 2016
by Sredni Vashtar
*/

// the setup function runs once when you press reset or power the board
void setup() {
// initialize digital pin 13 as an output.
pinMode(13, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
digitalWrite(13, HIGH);   // turn the LED on (HIGH is the voltage level)
delay(100);              // wait for 0.1 second
digitalWrite(13, LOW);    // turn the LED off by making the voltage LOW
delay(100);              // wait for 0.1 second
digitalWrite(13, HIGH);   // turn the LED on (HIGH is the voltage level)
delay(500);              // wait for 0.5 second
digitalWrite(13, LOW);    // turn the LED off by making the voltage LOW
delay(200);              // wait for 0.2 second
}


(I have to say it's been a while since I last updated my scope's firmware - I'm on 00.04.04.01.01 - but the bug has been confirmed othe latest version to date)

EDIT: Following mkeith advice, here is the 1kHz scope test signal, acquired at 500ms timescale and then expanded at 200us, when memory depth is set to 24M.

The period becomes 1.040 ms. Same 4% error. Acquisition at 200us directly will give the correct value of 1.000 ms.

And it gets better! If I acquire the test signal with a timebase of 5s, and then expand it to 200us, the period becomes 800 us!
That's a 20% error.

At other timebases (with the same stopped acquisition) I get the correct value. I would love to see how they do the rounding in Rigol.

Anyhwow, this bug is affecting the latest firmware version - as noted by the OP - and since the question has been closed, people interested might want to follow this thread on the EEVBlog forum.

• Rigol is really chinese CRAP. Have a look at my posting. I added some more screenshots. Did you also see this? Aug 24 '20 at 22:53
• @Elmue I was aware of the sluggishness in the trace positioning but I had no occasion to see the artifacts in serial decode. I consider these minor problems for an entry level scope in this price range. They are inconveniences but I consider them a tradeoff for the low price. The timing bug, on the contrary is a serious bug and there is no "but the price is low" excuse for that. That bug needs fixing. For the rest, I consider my 1054z a nice toy to have at home. A toy I would not trust with my life, or the life of my mosquitos... Aug 24 '20 at 23:08
• Also, it is a known shortcoming of the 1000z series that all measurements are made on the displayed data and not on the data stored in memory. I consider those measurements a help to a 'manual' reading by counting the spacing on the graticule, nothing more. And yes, I concur that the decoding function is little more than a gimmick as it relies on the data being clearly displayed on the screen. Aug 24 '20 at 23:14
• @Bruce Abbott Answer updated. It's 00 04 04 01 01 Aug 26 '20 at 23:47

Own DS1054Z too, the latest software (00.04.04.04.03) is installed, this bug shows up too. Had a call with Rigol, they say that this references their bug #297 opened in August 2020 and they had reproduced it internally, but there is no concrete plans for the next firmware release in their system. The support engineer was unable to give any timeline for this (and mentioned the "old hardware that is hard to predict new software version releases"), so, I think, more Rigol DS1xxxZ owners should poll Rigol support and ask them to fix the issue: may be such a pressure will make them to produce a new software version.

The engineer in question was Chris Armstrong (https://www.youtube.com/watch?v=u3ZbcRb6AeM, chris_armstrong@rigol.com), so people can keep him CC'ed in their bug reports: he seems to be a sane and nice person.

Hope that will help us all.

• Or maybe he told you just an excuse? Maybe they don't have any plans at all to fix their ugly bugs? This is my impression. Oct 7 '20 at 19:45
• I am going to poll the status in a week, so we'll see. But at least the mentioned date of the bug being opened correlates with report/discussion dates at EEVblog, eevblog.com/forum/testgear/… Oct 7 '20 at 20:30
• I wish I were so optimistic as you. Note that since one year they did not release a new firmware version for the entire DS1000Z series although there are multiple ugly bugs. Oct 7 '20 at 23:02
• Got answers from various Rigol divisions: European folks are going to reproduce it next week in their lab. Chinese folks said that they are analyzing the signal from the screen data (and not from the raw acquired points) and it is the design limitation of DS1000Z. I am not convinced that nothing can be done, so trying to understand what/why really happens in the 1000Z series. Oct 10 '20 at 9:37
• All timings are working except 500ms. They have a function in their code which translates the capture data into screen data. This function has a bug for 500ms per display unit. What is there which you don't understand? This is a bug which is VERY easy to fix, because all timings are working correctly except one. If I had the source code I would fix that in a few hours. Oct 12 '20 at 14:47

I don't have a solution, but I can confirm this affect other models.

I just measured the 1kHz scope probe test signal on my MSO1104Z, and when I have it sampling at 4MSa/s I also see a period readout of 1.040ms. If I sample at 2MSa/s or 10MSa/s it reads correctly at 1.000ms.

My MSO1104Z system info page also shows it is running version 00.04.04.SP4, but according to my records the last firmware I loaded was 00.04.04.04.02. So I downloaded and installed 00.04.04.04.03 from the Rigol website. Now the system info page helpfully still shows 00.04.04.SP4, and as expected the timing problem still exists with 4MSa/s acquisition.

I've return the acquisition memory depth setting to auto on my scope to hopefully avoid seeing this again when I use the scope and forget that I changed it to 24Mpts.

Edit to add: I attempted to reproduce with the logic analyser inputs, but I couldn't get a 4MSa/s data rate with those enabled. I couldn't reproduce with any of the other acquisition settings I tried either.

• Do you get 800us for the test signal when acquired at 24M with 5 seconds timebase? Aug 27 '20 at 18:59
• I get total garbage for the period measurement at 5s/div. Depending on zoom I get various readings like 10us, 20us, 400us, 800us, and 1ms.
– Kean
Aug 28 '20 at 0:26

I think this a known problem on the DS1000Z series! Please upgrade the firmware to version 04.04.04.03 and the capture problems should be solved.

https://eu.rigol.com/products/oscillosopes/ds1000z.html

( A short registration is required, but it's done in a minute ) Hope I could help you on a little !

Interesting is the phrasing: "I think..." and "should be". That already gave me the impression that this is a standard answer to all their bugs: Install the latest firmware and it "should be" fixed.

This is on the Rigol homepage:

And my scope shows:

So I have 3 different versions now:

Support email:  04.04.04.03
Rigol Homepage: 00.04.04.04.03
Oscilloscope:   00.04.04.SP4


As you see: The firware versions at Rigol are not unified.

I wrote another email asking if these 3 versions are the same. The support responded that they are all the same.

Then I wrote a third email: "So I have the latest firmware. But the severe bugs are still there. When will these bugs be fixed?"

I got no answer anymore. I wrote a fourth email to the same support guy a week later. He does not answer me anymore.

The firmware on their homepage is one year old now. The "support" does not answer anymore. So it is obvious that Rigol has zero motivation to fix their bugs.

Please note that this is the firmware for the entire DS1000Z series. So there are multiple oscilloscope models affected by these bugs.

The Rigol firmware is a RAR file of only 1,9 MB. I find this very strange. I expected much more.

• MSO/DS1000Z series digital oscilloscope does not support the downgrading operations.

This is another problem. Even if there was a new firmware available: What if the new firmware has a new bug which is even worse than the existing bugs? In this case I have no chance to go back to my previous firmware version. Rigol firmware update is a one-way road. You will never know where it leads you.

The Rigol homepage is a mess. If you go to "Support" -> "Software-Firmware Download" and enter Category: "Oscilloscopes" and search for "DS1074Z" you get no result at all.

If you select under product line: "DS1000Z-E" and leave "keywords" empty you will not find the same firmware as on the DS1000Z page.

https://eu.rigol.com/En/Index/listView/catid/28/tp/6/cat/7/xl/40

It seems that DS1000Z and DS1000Z-E are different series. The release notes say:

[Model Supported] DS1202Z-E.
[Latest Revision Date] 2019-09-20
[Updated Contents]
v00.06.01.00.00 2019-09-20
- The first version is released.
[Previous Versions and Updated Contents]
- none


So this is not for my scope.

• I agree with you, as long as people don't make this more public, Rigol will not correct their mistakes. To be honest, your post/question is more suitable for a forum rather than this site which is question/answer based. If I were you, I would try to make as much noise as possible about this, go to the EEVBlog and EDAboard forum and post your findings, perhaps more people like you will get things done. Good luck!
– S.s.
Aug 31 '20 at 18:42
• Sredni has already posted on EEVBlog. eevblog.com/forum/testgear/… But there are no interesting answers. Additionally I posted links under several Youtube videos about Rigol oscilloscopes. You can also help and post more comments in other places. Aug 31 '20 at 23:55
• It's useful to know that this is an imperfect tool, so that we can keep it in mind if we chose to use it. At the same time, it's a heck of a lot of routinely useful functionality in a cheap package. The real tragedy here is that there isn't yet a way to combine what these companies do well in mass manufacturing economical hardware with a community maintained open source software for the SoC and FPGA. Oct 7 '20 at 18:25
• Unfortunately the market wants to try to compete on (and even sell incremental post-purchase "features") while the engineering community would be happier with "give us a sampler and a software-controlled front end and some knobs and we'll do the rest". A clever user who understands an imperfect tool beats an ignorant user expecting magic any day. Oct 7 '20 at 18:25
• I don't understand: "we'll do the rest"?? The firmware is not open sorurce, how will we "do the rest"? Are you able to fix their nasty bugs? Generally I disagree with your comment. A clever user expects a correctly working device. This is what he has paid for! And Rigol is as most other chinese companies: They simply betray their clients with cheap crap. I bet fixing this bug takes about an hour for a developer who knows the code. There is NO excuse for not fixing it. I will never buy Rigol again in my entire life! Oct 7 '20 at 19:51