Electronic – Rigol DS1074 oscilloscope shows very wrong timing

oscilloscopetiming

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)

Rigol Oscilloscope correct timing

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.

Rigol Oscilloscope wrong timing

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

Rigol Oscilloscope wrong timing

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.

Rigol Bug Wrong RS232 Decoder data

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:

Rogol DS1074 bug artifacts

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:

Rigol bug 2ms square wave signal

And this is a zoom of the right artifact:

Rigol bug 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.

Best Answer

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

12M 500ms expanded to 200ms 1000ms

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:

24M 500ms expanded to 200ms 1040ms

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

24M 200ms 1000ms

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

24M 500ms 1040ms

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.

24M 1kHz signal 500ms expanded to 200us

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.

24M 1kHz signal 5s expanded to 200us

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.

Related Topic