Rigol DS1074 oscilloscope shows very wrong timing

Question

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.

Answer 1

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.

/*
  doubleBlink
  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.

Answer 2

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, [email protected]), 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.

Answer 3

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.

Answer 4

Thanks for reopening this thread. So I can post my answer.

My first response from Rigol support was this:

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.

Follow this link to download actual firmware for your DS1074Z oscilloscope:

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.

The Upgrade Instructions say:

• 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.