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..
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...
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.
Trigger output delay and jitter on Rigol scopes
I hope this may be of interest for some of the readers.
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.
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.
But because of the jitter, the trigger out happens at any random time within that 8 ns.
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...
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...
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......
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...
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.QuoteI 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.QuoteBut 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 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...