New Rigol DS1054Z oscilloscope

[uvamosk]

Well that did the trick thank you.. 
Also was doing a little playing around its not the 5us stuff like i thought its actually any time i move the horizontal trigger off the screen to the left. I can move horizontal triger left as long as it stays on screen no jitter. Soon as its off the screen I get ahat you see in my pictures. If I go all the way right nothing happens stays nice and clean.
 Im going to see about a replacement. Of course it did show up in a single box with a fist sized hole in it. But was fine till firmware update. So who knows..

[2N3055]

Well that did the trick thank you.. 
Also was doing a little playing around its not the 5us stuff like i thought its actually any time i move the horizontal trigger off the screen to the left. I can move horizontal triger left as long as it stays on screen no jitter. Soon as its off the screen I get ahat you see in my pictures. If I go all the way right nothing happens stays nice and clean.
 Im going to see about a replacement. Of course it did show up in a single box with a fist sized hole in it. But was fine till firmware update. So who knows..

Before you do, run autocal again, but leave scope on for an hour to warm up nicely... Than try again... If still iffy, try to get replacement...

[uvamosk]

Well that did the trick thank you.. 
Also was doing a little playing around its not the 5us stuff like i thought its actually any time i move the horizontal trigger off the screen to the left. I can move horizontal triger left as long as it stays on screen no jitter. Soon as its off the screen I get ahat you see in my pictures. If I go all the way right nothing happens stays nice and clean.
 Im going to see about a replacement. Of course it did show up in a single box with a fist sized hole in it. But was fine till firmware update. So who knows..

Before you do, run autocal again, but leave scope on for an hour to warm up nicely... Than try again... If still iffy, try to get replacement...

Got a hold of Rigol and they are having me send screen shots and directions on how to replicate it. He said he hasn't heard of this happening after a firmware update if it was working correctly at first.
Was pretty helpful person so far customer support has been pretty good.

[uvamosk]

Status Update,
 Well after going back and forth with Rigol they decided to take my scope back and try to see what happen when the firmware got updated.
They also pulled their firmware update off their site until they can look more into what caused my scope to develop the jitters after firmware update.

 Didn't expect all that to happen. So far been extremely happy with how fast they dealt with the problem.

[TurboTom]

Trigger output delay and jitter on Rigol scopes

After the recent postings about possible jitter problems on the 1000Z series, I couldn´t resist to run some tests of my own, especially since I´ve got access to the three (lower) lines of recent Rigol scopes which are DS1054Z, MSO2072A-S, MSO4014, all "improved" to the highest possible version and with the latest firmware installed. Actually, I´m now able to report some interesting findings and maybe a bug or two...

What did I test?
I fed a 100kHz square wave signal (on MSO2072A-S and MSO4014 from the internal generator of the MSO2072A-S and on the DS1054Z from a Hantek HDG2002B). I verified before that these sources are fairly free of phase jitter by phase comparison with a rubidium oscillator.
I connected the trigger out signal of the scopes to the second or third channel (of the same scope of course) in order to measure trigger out delay and phase jitter. In case of the DS1054Z, I also inserted a delay of 50ms to view the 5000th slope of the 100kHz signal after the trigger.

What did I find?
DS1054Z:
Trigger out delay: 355ns
Trigger out phase jitter: 8ns
5000th slope delay jitter: neglible, some 1/f type drift observable

MSO2072A-S:
Trigger out delay: 219ns
Trigger out phase Jitter: 8ns

MSO4014:
Trigger out delay: 30.5ns
Trigger out phase jitter: approx. 300ps

The trigger out delay is extended by the delay of the BNC cable, so in reality it may be a few nanoseconds less than specified.



What does that mean?
Apparently, the trigger out phase jitter of the two lower models isn´t related to PLL jitter since the 5000th slope is virtually jitter-free. The trigger out phase jitter must have its origin somewhere in the signal processing downstream of the triggering logic / slope discrimination itself. The relatively long delay between the trigger event itself and the signaling at the trigger output also indicates that something´s got to be going on there. Maybe the triggering is done in software. This may also explain the high phase jitter of 8ns on both the DS1000Z and the MSO2000A machines (the same is probably valid for all the models in the corresponding classes).
On the contrary, the MSO4000 series almost for sure has implemented the triggering logic completely in hardware (FPGA). The extremely short delay of the trigger out (about 30ns) and the virtually not present jitter is a clear indication for this.

What peculiarities did I find?
These basically concern the DS1000Z:
- If the scope is operated in "Zoom" mode (press the timebase sec/div button), and the acquisition is stopped (press RUN/STOP button), only the last trace is displayed on the screen, just as if the scope was operated in single shot mode. It´s doing this regardless of the selected display persitance time.
- In Zoom mode, if persitance time other than minimum or infinite is selected, the user interface gets so laggy it´s almost unusable.
- In Zoom mode and display persitance time other than minimum or infinite selected, the attempt to do a screenshot locks up the scope and requires a power cycle to get out of this (at least I didn´t find an alternative or didn´t wait long enough ).

Attached are some screenshots of the tests.
I hope this may be of interest for some of the readers.

Cheers,
Thomas

[metrologist]

Very interesting. Thank you all.

To be clear, uvamosk is posting a display trace jitter of the primary input signal (with trigger delay), the other posts jitter of the trig output signal? The latter is only relevant if you are using the trigger output of the Rigol to trigger other equipment?

[bitseeker]

Status Update,
 Well after going back and forth with Rigol they decided to take my scope back and try to see what happen when the firmware got updated.
They also pulled their firmware update off their site until they can look more into what caused my scope to develop the jitters after firmware update.

 Didn't expect all that to happen. So far been extremely happy with how fast they dealt with the problem.

That is surprising and good to hear. Thanks for the update. Curious what they'll end up finding.

[bitseeker]

Trigger output delay and jitter on Rigol scopes

I hope this may be of interest for some of the readers.

Interesting stuff, Thomas. Thanks for posting your findings. It's not surprising that the less expensive models do a lot of things in software -- maybe too much, leading to sluggish or no response.

[David Hess]

What does that mean?
Apparently, the trigger out phase jitter of the two lower models isn´t related to PLL jitter since the 5000th slope is virtually jitter-free. The trigger out phase jitter must have its origin somewhere in the signal processing downstream of the triggering logic / slope discrimination itself. The relatively long delay between the trigger event itself and the signaling at the trigger output also indicates that something´s got to be going on there. Maybe the triggering is done in software. This may also explain the high phase jitter of 8ns on both the DS1000Z and the MSO2000A machines (the same is probably valid for all the models in the corresponding classes).
On the contrary, the MSO4000 series almost for sure has implemented the triggering logic completely in hardware (FPGA). The extremely short delay of the trigger out (about 30ns) and the virtually not present jitter is a clear indication for this.

There is no mystery here although you got it wrong.

The 1000Z and 2000A series implement triggering inside the FPGA after digitizing the signal.  The ADC has 128 nanoseconds of pipeline delay and some other delays by itself (for the 1000Z) then the FPGA has its own pipeline delay as it processes the trigger before is is recognized.  The trigger output jitter comes from the FPGA clock which appears to be 125 or maybe 250 MHz.  FPGA implementation of the trigger makes modern low end DSOs less expensive.

The 4000 trigger output delay and jitter are consistent with an analog trigger but you could test it with a more advanced trigger which will likely be implemented in the FPGA.  An analog trigger would usually be used to support equivalent time sampling; does the 4000 series support equivalent time sampling?  I could not sell from the specifications or user manual.

[TurboTom]

David -

thanks for that information. You are probably right with your assumption regarding the pipelined processing of the trigger on the "lower end" oscilloscopes.

Yet, I always had the impression that FPGAs also support asynchronous logic (have to ask a collegue here, I´m not at all into FPGA programming...) and using this, it should be possible to program a digital "comparator" like the ancient TTL ´688. The delay of such a device should just depend on the individual gate delays and not on any pipeline or clocked circuitry. And in my opinion, a system like this will be necessary to get a stable image of the waveform (maybe it´s done like this on the 4000 series -- as far as I know this model doesn´t support equivalent time sampling). The trigger itself cannot rely on a lower frequency than the sampling rate, otherwise the waveform will always show some jitter. But it is well possible that the trigger point is evaluated after the ADC data has been transferred to memory, i.e. at multiples of the sampling time. And this can happen as a pipelined (or partially parallel) processing as you suggested and would exactly result in the trigger out jitter observed on the DS1k and DS2k machines, provided the sampling clock and the FPGA pipeline clock are not synchronized. If they were, one should be able to observe the synch out jitter to be time discrete and not (more or less evenly) spread over the whole interval.

Over the next weekend, I will do another test and check the trigger characteristics with an external scope and not by "auto-measurement" - this will also show the pre-processing times and should also make it clear if the (edge) trigger of the DS4k is implemented as analog (before the ADC) or digital (logic magnitude comparator) circuitry. Im already curious... 

Cheers,
Thomas

[yngndrw]

Yet, I always had the impression that FPGAs also support asynchronous logic (have to ask a collegue here, I´m not at all into FPGA programming...) and using this, it should be possible to program a digital "comparator" like the ancient TTL ´688. The delay of such a device should just depend on the individual gate delays and not on any pipeline or clocked circuitry. And in my opinion, a system like this will be necessary to get a stable image of the waveform (maybe it´s done like this on the 4000 series -- as far as I know this model doesn´t support equivalent time sampling). The trigger itself cannot rely on a lower frequency than the sampling rate, otherwise the waveform will always show some jitter. But it is well possible that the trigger point is evaluated after the ADC data has been transferred to memory, i.e. at multiples of the sampling time. And this can happen as a pipelined (or partially parallel) processing as you suggested and would exactly result in the trigger out jitter observed on the DS1k and DS2k machines, provided the sampling clock and the FPGA pipeline clock are not synchronized. If they were, one should be able to observe the synch out jitter to be time discrete and not (more or less evenly) spread over the whole interval.

Most (All?) FPGAs support multiple clocks, so yes they do support asynchronous logic. The issue with the 1000Z series is that the ADC chip itself has this 128 nanosecond delay before the signal even gets to the FPGA. In order to ease synchronisation of everything, they do the triggering in the digital domain rather than having a separate comparator on the analog side and trying to synchronise the delay with the digitised waveform.

If I were in Rigol's shoes, based on little more than the ADC's datasheet and a whole load of assumptions, I'd implement the following:
1GHz clock into the ADC
ADC's output clock (Which clocks at the same rate as the data, I believe it's 125MHz) into the FPGA along with the data, making the FPGA synchronous with the ADC
Inside the FPGA, constantly write each channel's data to a continuous looping buffer
Inside the FPGA, implement a trigger module on the raw data from the ADC - When a triggering event occurs, continue sampling for half the buffer's length and then switch to a second buffer
At this point the FPGA is back to writing continuously to the second buffer and the first buffer contains a full sample which is centered on the trigger
Have another FPGA module which draws the display from the non-active buffer, essentially double-buffering the display to remove any tearing

If you think about it, each channel can be done totally separately except for the shared trigger lines (Although you could easily have a separate trigger per channel) and the drawing module which is shared across all channels. This makes it scalable to more than 4 channels and suggests how Keysight's multi-ASIC design could work. This of course has the side effect that the sample memory cannot be longer if less channels are used, but memory's cheap these days.

Anyway I'm way off point - My point was that by doing it in the FPGA they have at least the 128ns pipeline delay from the ADC, but I don't see why there's such a long delay after that. Maybe I'll have a go at designing an 8+ channel DSO one day, or maybe I'm missing something really important.

[2N3055]

Actually trigger event to trigger out connector delay is not a problem if it's well defined and deterministic. You can always just compensate time scale on captured data.. And you would have to for the cables, interconnect and other equipment delays anyway...
Problem is trigger event to trigger out signal jitter... And that jitter is not trigger event jitter, but a jitter that happens between trigger event and trig out connector...
That connector is also used for Pass/fail, it could be as well that it is not toggled from FPGA state machine directly, but triggered by display engine or something that is not synchronous to trigger /capture...
That would explain jitter..

[metrologist]

But because of the jitter, the trigger out happens at any random time within that 8 ns.

[2N3055]

But because of the jitter, the trigger out happens at any random time within that 8 ns.

Yes but it is trigger out jitter, not trigger sample jitter....  It is a problem when you try to trigger something else,  but trigger on the scope is ok....

It is a defect nevertheless...

[metrologist]

yes, making the external trig out useless unless your timing needs are not that critical.

I can't recall ever using a trig out from a scope anyway. Is this something other's use or useful in a particular application? I'm not seeing it...

[2N3055]

yes, making the external trig out useless unless your timing needs are not that critical.

I can't recall ever using a trig out from a scope anyway. Is this something other's use or useful in a particular application? I'm not seeing it...

It is useful... you can trigger external logic analyzer on an analog signal for instance...

But many people will use it very rarely.... I'm more in a situation to trigger the scope from a logic analyzer than vice versa for instance...

But  I find it annoying, because I guess it can be done right if they would want to......

[bitseeker]

Well, they are more responsive to firmware issues than in the past. I don't recall them pulling firmware before and rather quickly. So, although it's a bummer that there's yet another problem, they are taking action.

[Fungus]

I can't recall ever using a trig out from a scope anyway. Is this something other's use or useful in a particular application? I'm not seeing it...

It's for linking multiple devices together. If you've never done that then you probably never used it.

On the DS1054Z it also outputs 'fail' pulses when you're doing pass/fail testing. You could use it to sound an alarm or something.

[David Hess]

yes, making the external trig out useless unless your timing needs are not that critical.

And at slower time/div settings, the trigger output jitter will not even be visible.

I can't recall ever using a trig out from a scope anyway. Is this something other's use or useful in a particular application? I'm not seeing it...

It is useful... you can trigger external logic analyzer on an analog signal for instance...

But many people will use it very rarely.... I'm more in a situation to trigger the scope from a logic analyzer than vice versa for instance...

I have used the trigger output to trigger another oscilloscope effectively adding more channels but of course not on the same display.  Sometimes I have used it to trigger a second oscilloscope using the advanced trigger capabilities of the first oscilloscope.  You might have a 50 ohm input instrument like a frequency counter and the trigger output allows the use of the oscilloscope's 1M signal conditioning to trigger it.  A vertical output may even be more useful for this but they are rare.

A gate output is much more useful compared to a trigger output; it can serve as a trigger output but can also be used to gate another measurement instrument.  So for instance I can connect the B gate output from one of my analog oscilloscopes to my external universal counter and make a 9+ digit measurement on a part of the waveform defined by the B sweep. So the oscilloscope is selecting the portion of the waveform where the measurement is taking place *and* displaying which part that is visually.  Some old analog oscilloscopes include this capability with their built in hardware universal counter; it is incredibly useful if you have a need for this sort of thing.

Some modern DSOs have "hardware" universal counters but I am dubious of their claims when they only return a low number of digits.  That is hardly better than the firmware counters in my DSOs.

But  I find it annoying, because I guess it can be done right if they would want to......

Fixing it would involve adding a variable delay between the FPGA and output and why bother?  Most users will never notice it and fewer have an application that would require it.

I just wish Rigol had included the jitter in the trigger output specifications.  To do otherwise is misleading.

[2N3055]

Well, they are more responsive to firmware issues than in the past. I don't recall them pulling firmware before and rather quickly. So, although it's a bummer that there's yet another problem, they are taking action.

I agree, they seem to react much better..That is very good.. We'll see the results though, I guess...

If they manage to make it better, that would be plus to scope and a big plus to them for customer support...

[bitseeker]

I agree, they seem to react much better..That is very good.. We'll see the results though, I guess...

Yeah. I guess I lucked out because my boot version is 0.0.1.3 and my scope has been fine, so far, on the recalled firmware. If I had one version older, I might not be a happy camper.

[2N3055]

yes, making the external trig out useless unless your timing needs are not that critical.

And at slower time/div settings, the trigger output jitter will not even be visible.

I can't recall ever using a trig out from a scope anyway. Is this something other's use or useful in a particular application? I'm not seeing it...

It is useful... you can trigger external logic analyzer on an analog signal for instance...

But many people will use it very rarely.... I'm more in a situation to trigger the scope from a logic analyzer than vice versa for instance...

I have used the trigger output to trigger another oscilloscope effectively adding more channels but of course not on the same display.  Sometimes I have used it to trigger a second oscilloscope using the advanced trigger capabilities of the first oscilloscope.  You might have a 50 ohm input instrument like a frequency counter and the trigger output allows the use of the oscilloscope's 1M signal conditioning to trigger it.  A vertical output may even be more useful for this but they are rare.

A gate output is much more useful compared to a trigger output; it can serve as a trigger output but can also be used to gate another measurement instrument.  So for instance I can connect the B gate output from one of my analog oscilloscopes to my external universal counter and make a 9+ digit measurement on a part of the waveform defined by the B sweep. So the oscilloscope is selecting the portion of the waveform where the measurement is taking place *and* displaying which part that is visually.  Some old analog oscilloscopes include this capability with their built in hardware universal counter; it is incredibly useful if you have a need for this sort of thing.

Some modern DSOs have "hardware" universal counters but I am dubious of their claims when they only return a low number of digits.  That is hardly better than the firmware counters in my DSOs.

But  I find it annoying, because I guess it can be done right if they would want to......

Fixing it would involve adding a variable delay between the FPGA and output and why bother?  Most users will never notice it and fewer have an application that would require it.

I just wish Rigol had included the jitter in the trigger output specifications.  To do otherwise is misleading.

I pretty much agree on all you said... I still think that if they could make it better without much of effort, they should do it... That's all.. And I agree, an honest "sorry, but this is architecture limitation, specs are..."  would be fantastic too, as a sign of professional attitude..
Take care!!

[2N3055]

I agree, they seem to react much better..That is very good.. We'll see the results though, I guess...

Yeah. I guess I lucked out because my boot version is 0.0.1.3 and my scope has been fine, so far, on the recalled firmware. If I had one version older, I might not be a happy camper.

I think problem was with versions lower than 0.0.1.3. ... I have the same and is also running fine...

[bitseeker]

I think problem was with versions lower than 0.0.1.3. ... I have the same and is also running fine...

Yes, the post I saw was boot versions prior to 0.0.1.3 were susceptible. I suppose they could also push out newer boot software with the firmware like they did once before. I dunno. We'll see.

[TurboTom]

Okay, here's a (hopefully shorter) follow-up to my previous trigger-characteristics observations:

I changed my setup as follows: Signal source now was a DG4102 with 100kHz square wave selected, 1Vpp amplitude @ 50 ohms impedance. This signal was fed to the CH1 input of the oscilloscope to be tested (high-impedance selected). At this input, a BNC T was installed and from there on, the signal routed further on to CH1 of a second oscilloscope (to do the measurement).  The trigger output of the oscilloscope under test was connected (by an identical BNC cable) to the measurement oscilloscope's CH3 (MSO4000) or CH2 (MSO2000A). All the inputs in use of the measurement oscilloscope were internally terminated at 50 ohms. This setup should eliminate any cable delays and will also show the true trigger out jitter (limited by measurement accuracy).

Since the oscilloscope under test won't trigger on every slope of the 100kHz input signal, and otherwise the waveform looks very ugly, I decided to trigger the measurement oscilloscope on the trigger output of the oscilloscope under test. This will only reverse the reference, the jitter will be observed at the signal input and not the trigger input.

What I found:

Very much similar to my previous tests, the figures are as follows:

DS1000Z -- delay 352ns; jitter 8.2ns
MSO2000A -- delay 213ns; jitter 8.16ns
MSO4000 -- delay 27.1ns; jitter 640ps

The measurements for the DS1000Z and the MSO2000A have been done with the MSO4000 and should be fairly accurate while the measurements for the MSO4000 have been done with the MSO2000A which was sampling at 1GS/sec (both channels in use), hence the jitter figures can be taken as an upper limit since the jitter width is just a little more than half a sample period. I was too lazy to carry my 2465 upstairs to do a more accurate test of the MSO4000

I guess David Hess is correct with his assumption that the trigger of the DS/MSO4000 must be of the analog type while the smaller models do a digital "after-conversion" trigger. The HMCAD1511 of the DS1000Z has a pipeline delay of 128 sampling clock cycles (128ns) plus some additional delay until the sampling data is transferred (in the ballpark of 10ns). This compares to the ADC08D1000 clone in the DS/MSO2000 with about 18ns delay (1GHz sampling clock) as a latency difference of 120ns. And this is pretty close to the measured difference in trigger delay time between the DS1Z and the DS2 series scopes.

All this basically means that for an accurate daisy-chained trigger-output coupled measurement system, the DS1Z and the DS2k series can be used up to signal frequencies of maybe 10MHz (in order to provide less than 10% phase jitter), for higher speed stuff and when it's necessary to accurately synchronize some other equipment with the trigger out signal, only the DS4k series can be used (I don't know anything about the DS6k models, never seen one in real life).

Cheers,
Thomas