New Rigol DS1054Z oscilloscope

[MrW0lf]

yes, there are, with selectable cutoff frequency. i should mention they are also bugged as i have shown in the screenshots above: the filtered trace is shifted on the right and the filtering is not applied to the whole displayed trace

Is it really shifted or just starts later? AFAIK for filter to work with 100% confidence it has to have certain "wrapper" leading amount of data, which depends on filter freq. I just tried to filter 1kHz square with 1kHz lowpass on Pico Demo and it starts 0.25ms after data start, ends 0.25ms before data end - 1/4th of filter freq period.
If not doing it that way filter would have to presume that signal is similar/repeating before and after actual capture, which would be wrong.
Theoretical workaround is acquire longer length and zoom in a bit in area of interest, if it works on specific scope...

[Fungus]

(I assume that behavior stems from Rigol's approach of using only the display data for all measurements and calculations.

Me too.

If they use some FIR filter, that needs a bit of runway, i.e. needs to be fed prior data points before it can output anything. Not nice, but I can't see how they could provide a filtered trace across the whole display width without accessing data before and/or after the displayed section. EDIT: So Rigol should be applauded for displaying only mathematically correct information in this case, instead of "faking" something!  )

Yep.

It may not be what some people imagined it would be but that doesn't mean it's incorrect.

[dimkasta]

yes, there are, with selectable cutoff frequency. i should mention they are also bugged as i have shown in the screenshots above: the filtered trace is shifted on the right and the filtering is not applied to the whole displayed trace
Anyway, the range of cutoff frequencies depend on the selected timebase

I saw your screenshots but I was tired and did not pay much attention to them.
So the filters are applied on the math channel? Not directly on each channel?
Does this mean that you can apply a filter on just one channel at a time?

The cutoff freqs depend on the timebase on the 1052 too. But I learned to juggle around it and get the band I wanted with relatively nice results.
But if I cannot apply filters on each channel at the same time, it is a bit of a deal breaker for me.
I do not really need the 4 channels or any of the digital trigger stuff. I mostly work with audio. I just wanted to upgrade for the nice big screen.

[Karel]

... i wonder if the multitransfert bug was really solved or just hid under the rug

If you have a DS1054Z, why don't you try and let us know? If you don't, why do you care?

better question: why don't you?

Because I don't make assumptions based on nothing.

If with "multitransfert bug" you mean the multi-channel waveform download bug,
I checked it and it seems to be resolved like I wrote before.

[Fungus]

After update it starts earlier but also stops earlier. whatever

Sure, but the peaks and troughs line up nicely with the original signal so where's the bug?

[RoGeorge]

Indeed, Rigol MATH functions are using only the displayed points to calculate the result, so for a filter to cover the whole display it would mean to rewrite a big part of the scope's functions in order to access some extra data points from the scope's memory, instead of accessing only the displayed data points. I bet Rigol will never do that for DS1000Z.

There still is a bug with the filter. The filter works OK only if the start point is 0.
If one changes the start data point for the filter, then the whole filter trace suddenly shifts to the right (like a phase delay). For me this is not a big issue, but it is definitely a bug.

Also, another minor bug is that you cannot change the end data point until you first change the start data point. But if you change the start data point, then the filter trace becomes shifted to the right.

[JPortici]

Sure, but the peaks and troughs line up nicely with the original signal so where's the bug?

i can count two:
 - doesn't use the full trace, can't see why it shouldn't (i see it now)
 - "end" control doesn't do nothing

also, the start parameter moves the trace right. i can't decide wether it is a feature or a bug, to me start should mean that it start filtering from this point (as i recall it happens in other functions)

[JPortici]

... i wonder if the multitransfert bug was really solved or just hid under the rug

If you have a DS1054Z, why don't you try and let us know? If you don't, why do you care?

better question: why don't you?

Because I don't make assumptions based on nothing.

If with "multitransfert bug" you mean the multi-channel waveform download bug,
I checked it and it seems to be resolved like I wrote before.

cool then, sorry.. i must have missed the whole post..

[JPortici]

yes, there are, with selectable cutoff frequency. i should mention they are also bugged as i have shown in the screenshots above: the filtered trace is shifted on the right and the filtering is not applied to the whole displayed trace
Anyway, the range of cutoff frequencies depend on the selected timebase

I saw your screenshots but I was tired and did not pay much attention to them.
So the filters are applied on the math channel? Not directly on each channel?
Does this mean that you can apply a filter on just one channel at a time?

The cutoff freqs depend on the timebase on the 1052 too. But I learned to juggle around it and get the band I wanted with relatively nice results.
But if I cannot apply filters on each channel at the same time, it is a bit of a deal breaker for me.
I do not really need the 4 channels or any of the digital trigger stuff. I mostly work with audio. I just wanted to upgrade for the nice big screen.

yes. the only "filtering" per channel is the 20 MHz bandwidth limit, the selectable filter as you saw it is a math trace, can be used on a channel at a time

[ankerwolf]

Hello,

i can count two:
 - doesn't use the full trace, can't see why it shouldn't
 - "end" control doesn't do nothing

Sorry for you!
Ther is no bug or issue. It's the algorithm of calculation IIR, FIR or what ever Filter you want of a limited range of data points. (See Mathematica or other math program an the theorie of digital filters ...)
LG Wolf

[dimkasta]

Indeed, Rigol MATH functions are using only the displayed points to calculate the result, so for a filter to cover the whole display it would mean to rewrite a big part of the scope's functions in order to access some extra data points from the scope's memory, instead of accessing only the displayed data points. I bet Rigol will never do that for DS1000Z.

Which is a pitty because 1052 already did it...

[ebastler]

- doesn't use the full trace, can't see why it shouldn't

As RoGeorge and I tried to explain above, it seems that the filter function does use the full trace as input to calculate the filtered output. (That's the full trace in display memory, as for all math functions.) Since the filter requires some "runway", depending on its time constant, that means that the output is a filtered trace which cannot run over the full width of the display.

That's a design limitation, stemming from the "math and measurements are based on display memory" paradigm, but not a bug in my view.

[JPortici]

I admit that digital filters are not my area of expertise, but from what i remember for an M tap filter i would expect that the first M output samples would be """wrong""" and i can see why they would be discarded. what i don't see is a reason to discard the samples on the right

note that moving the start cursor right by a couple of pixels extends the trace. (start/end is not saved in a screenshot.. i should make a video if you can't try)

[ebastler]

I can't lay claim to being an expert on digital filters either. They do introduce phase delays, and I assume that Rigol shifts the filtered output to the left to correct for that (i.e. make the filtered and unfiltered traces line up better). That would cause the missing output on the right side of the screen.

Maybe the Start/End options are simply there to allow manual tweaking of this alignment?

I'm sure an actual expert on digital filters can provide a better/clearer/more correct explanation ...

[JPortici]

i suppose, but on my unit start moves the waveform around and end doesn't seem to do nothing.

looking at my screenshots again..
on #2 the trace starts at 2/5 of a division, ends 4/5 before.
on #3 i moved the start about 2/5 division right. the trace starts at 4/5 of a division... but ends at the end of the trace!! what is this?
seems the filters is suddently displaying more points.. what?

also, the trace is no longer aligned, confirm again that start moves the waveform around.

about the missing samples on the right, that is also my idea: i think what they did is apply the filter to a buffer the same width as the screen buffer, discarding whatever was left outside due to filter introduced delay. then shift everything left

** because some individuals like to say me and some others are here only to complain, i'd like to add that i'm trying to understand what's really happening. **

[MrW0lf]

I can't lay claim to being an expert on digital filters either. They do introduce phase delays, and I assume that Rigol shifts the filtered output to the left to correct for that (i.e. make the filtered and unfiltered traces line up better). That would cause the missing output on the right side of the screen.

This would make sense. In my test 1/2 of filter freq period was missing. 1/4 from start, 1/4 from end. Half of period sounds about right amount to get correct value. So Rigol engineer deserved some LICKI treatment with this one. It works (almost) correctly! However Start|End should rather change area being filtered, not move trace...

[Fungus]

Rigol, it's not too hard.

Hard vs. easy doesn't seem to be a factor. One word: "Pluses".

I think "Pluses" is an inside joke at Rigol. 

[Fungus]

I admit that digital filters are not my area of expertise, but from what i remember for an M tap filter i would expect that the first M output samples would be """wrong""" and i can see why they would be discarded. what i don't see is a reason to discard the samples on the right

Yes, but an M-tap filter is usually done as a compromise in places where you can't do a proper filter.

A window which extends both ways is much better.

eg. https://en.wikipedia.org/wiki/Gaussian_filter

And this explains perfectly why there's a gap at both ends.

[JPortici]

Hello,

i can count two:
 - doesn't use the full trace, can't see why it shouldn't
 - "end" control doesn't do nothing

Sorry for you!
Ther is no bug or issue. It's the algorithm of calculation IIR, FIR or what ever Filter you want of a limited range of data points. (See Mathematica or other math program an the theorie of digital filters ...)
LG Wolf

Ah! I just had to sit down for a moment and draw a quick graph, it's so simple i feel even more of a fool. Apologies, guys.

So, the filter is filtering correctly, now if you want we have to decide what start and end should do

[ankerwolf]

Hello,

So, the filter is filtering correctly, now if you want we have to decide what start and end should do

I have no idea what RIGOL it had thought. I have currently no application for it. But likely to restrict the datarange what it does well.
LG Wolf

[metrologist]

So, the filter is filtering correctly, now if you want we have to decide what start and end should do

Mental note - start and end filter adjustments break the filter trace by phase shifting about 1/2 division (I think always 1/2 division and not 1/2 period).

Can someone compile a list of all the known bugs from the previous firmware release together with some pointers on how to reproduce the issues?
I need to admit that I lost track of all the quirks in the course of this thread, but would be happy to test on the new firmware and share my findings.

Frederik

Indeed! They seem to keep coming out of the woodwork. Life was grand when all I knew about was 5 bugs at once... which I think have all been resolved.

Now we have this filter endpoint bug and sin(x)/x interpolation toggle, and the USB packet size reporting. These seem minor unless you have a specific application for them, which would be significant obstacle. I'm probably missing something else...

[ebastler]

Can someone compile a list of all the known bugs from the previous firmware release together with some pointers on how to reproduce the issues?
I need to admit that I lost track of all the quirks in the course of this thread, but would be happy to test on the new firmware and share my findings.

Frederik

There is a separate thread for this: https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/

Katie, the original poster, has done a great job keeping the initial post update for a while, but I believe it has now gone out of date. Maybe we can revive it? In any case, please let's keep the bug collection in that thread, rather than start a new one here.

[frozenfrogz]

There is a separate thread for this: https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/

Katie, the original poster, has done a great job keeping the initial post update for a while, but I believe it has now gone out of date. Maybe we can revive it? In any case, please let's keep the bug collection in that thread, rather than start a new one here.

Thanks,
I totally forgot about that and basically it just popped up after I wrote the request here.

Font size does not keep resetting on restart if "last" is selected, with the new FW.
I will contact the buglist thread OP, to review the buglist and offer my help on testing.

[JPortici]

Now we have this filter endpoint bug

no, that is actually correct... but wait! i'm uploading a video about start and end cursors.
I have also something one could call a bug in the I2C trigger, if i'm able to reproduce it (basically, set it up so you can trigger on start condition. power down, power up: same settings, can't trigger. change trigger type, change it back to I2C, now it can trigger. setting are the same as before power down) i found that out while i was working on an i2c comm. stack, i was done for the day and the following morning i powered the scope on, couldn't trigger unless i set it up again

Meanwhile, with invert on, all modes.

[JPortici]

Argue away..



- Used the probe compensation signal
- Horizontal, vertical, math scale, type of filter and cutoff settings don't affect the result.

Start cursor at the leftmost, end cursor does - NOT - effect the filter. Move the start cursor on right and the trace is shifted right, like it was before the update.
Then keep moving it right and after about 1 div it starts limiting the filter area. (note: it's the point where the correctly positioned trace starts.)
note how the filtered trace changes: it's not blanking what's before, it seems like it starts filtering from that point, right?
i think i'd say it's the correct behaviour (or at least the one i'd expect) but then why not show the complete trace from the start? the appereance should be the same, right?

update on "invert" bug, the bugged portion is what's on the right of the END marker