New Rigol DS1054Z oscilloscope

[bitseeker]

From your vid, the two anomalies I see are

1. Sudden phase shift when altering the filter start parameter. It appears that the fix for phase-shifted display doesn't apply when the start point is changed from default.

2. The filter end only works after a filter start is applied.

Correct?

[JPortici]

yes, this is what i'm seeing (then other minor things one could argue about)

[bitseeker]

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.

Katie posted a message there today calling for a volunteer to manage the bug thread.

[Fungus]

Katie posted a message there today calling for a volunteer to manage the bug thread.

Really it's time for a new bug thread. Several rounds of firmware updates have gone by since that thread was started so most of the old one is irrelevant

Rigol also doesn't appear to be reading this forum so the "wish list" part is probably a waste of time.

[MrW0lf]

Out of curiosity - what this filter-thing do if you zoom in? Say you want to get rid of missing area - maybe applying larger timebase and zooming in helps (if can sustain sample rate etc)?
And second thing - can you apply auto-measurements to filtered trace?

[JPortici]

no, it always uses the on screen data
yes you can apply the auto measurements. i don't remember if the items on the leftmost becomes purple when you select the math channel.. but if you go inside measurements menu oyu can select math trace as a source and then apply the measurements you want

[k8943]

Anyone experienced with using the SPI decoder?

I've setup:

- edge trigger to CLK (with noise suppression turned off - didn't work with);
- in Timeout mode

Am getting quite confused. In the decoder MOSI/ MISO lines the scope seems to display a hex block for each iteration of the CLK line. To the point I'm starting to doubt I know the difference between a bit and a byte!

If, on the other hand, I zoom out (to include many more clock iterations) the decode blocks appear just as little lines. As though the scope can't see the bytes for the bits?

What am I (probably) doing wrong?

ps tried turning Timeout all the way up and all the way down but didn't solve the problem.

[ebastler]

Anyone experienced with using the SPI decoder?

This video (not by me) shows a walk-through demo of the SPI decoder. Not sure whether it helps in resolving your issue:

[JPortici]

i can't understand the signal you are looking at. where/which is the clock? which is the data? which is CS?
with timeout, it will try to decode a packet of n bits after the first edge. if it hits the timeout, aborts decoding and wait for next edge

[k8943]

@ebastier that video was helpful, working much better now. Can start debugging my code!

- he's right: seems that CS mode works where timeout mode fails or is unreliable. Set up the 4th channel for CS and now get meaningful results;

- he also advises to manually set Thresholds - auto-threshold might lead to a misinterpretation of signals depending on when you start the process;

@jportici, CLK stand out in the photo as the pink trace, the blue traces are MISO and MOSI, there was no CS. You mention that it starts counting bits after "edge". It's not clear to me - nor the guy who made that video - which "edge" is being referred to in the Decoder menu? Presumably it's not necessarily the same as the Edge that might have been selected in the Trigger menu. Is it the CLK signal edge?

[JPortici]

the decoder has to first delimit a frame... it counts n rising/falling clock edges after the frame start.
With CS signal the start of frame is easy: the first rising/falling clock edge after CS.
with timeout.. the decoder is idle, at the first edge it will start counting.. the frame ends either at the nth edge or at timeout.

in your configuration you have put 4.23 us for timeout. that's too short, your packet is about 100 us long. what is happening is that it acquires the first bit (zero) then there is timeout, so it shows a zero byte. at the following edge it starts again, again zero. if you increased the timeout you would see the complete byte

if you zoom out you will see the events labels too tight, that's when the event list comes in handy.
if you zoom out too much you will see garbage because the decoding is done from the screen memory (even if trace is 1Meg samples long, the screen buffer is not.) so it doesn't decode properly

[k8943]

Super clear explanation.

Thanks.

In consequence just discovered the small detail on the Timeout Icon that explains that if you push on the rotary dial it brings up a keyboard that allows you to enter long durations for the timeout period (previously I'd just been rotating under which conditions it's difficult to even reach 10us.).

With that, and your explanation of timeout and edges, the problem is now officially resolved!

[Howardlong]

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.

Similar here, I managed to reproduce a problem on I2C start triggering on another thread immediately after updating to the latest firmware, I am certain this used to work, it's such a common use case.

I "fixed" it slightly differently, and then couldn't get it to go wrong again.

https://www.eevblog.com/forum/testgear/rigol-ds1054z-i2c-decoder-trigger-on-start-condition/

[metrologist]

I have a question on segmented memory record as I think there is a bug with the settings. I may have gone through this once already, so apologies if I've forgotten.

The first thing I am confused about is how can I set a recording Interval time that is less than my sweep time? I think Interval is the time between the start of recording a new segment (or frame). How can a new segment start recording before the sweep of the current recording completes? Will it just wait for the sweep and then the next frame starts right on the next sweep? That might explain the following.

I had record set up for a few us interval of 5000 length. I get all 5000 segments (frames) recorded in a few ms. I had messed around with the Interval, making it very long (1s) with a short length of 60. I see each segment is recorded at a 1 second rate. Later I had the Interval set low in the ns range with short length, and it was recording segments (frames) at a ~1s rate. I am expecting it to zip through the record and it is taking like a minute to get Interval of 100 ns and Length of 60 to complete.

So, I think the Interval setting gets out of control, unless I just hadn't noticed I had a very long sweep, if Interval waits for the sweep...

[metrologist]

Anyone find anything else with the new firmware? The frenzy seemed to die pretty quick.

[canibalimao]

Anyone find anything else with the new firmware? The frenzy seemed to die pretty quick.

I think that now very few people are willing to try an update.

[Karel]

Anyone find anything else with the new firmware? The frenzy seemed to die pretty quick.

I think that now very few people are willing to try an update.

https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg1178514/#msg1178514

[McBryce]

I've updated my MSO1104Z-S with the latest Firmware too, and all went smooth. Haven't noticed anything negative yet, but I also haven't used it much since then.

McBryce.

[ebastler]

Anyone find anything else with the new firmware? The frenzy seemed to die pretty quick.

I think that now very few people are willing to try an update.

Why would that be the case?! We have not seen a huge wave of reports on this firmware update, but the ones that were posted did not suggest any negative side effects, and confirmed a few improvements.

I think we have simply moved to "business as usual" with the DS1000Z. It's not the scope itself anymore that is the hobby, or a "project" of it's own, but people simply use it. It is nice that Rigol still publishes the occasional firmware update, but there are no major problems anymore (and no breakthrough improvements in the firmware). Overall, that's a good state of affairs in my view. 

[BravoV]

It is nice that Rigol still publishes the occasional firmware update, but there are no major problems anymore (and no breakthrough improvements in the firmware). Overall, that's a good state of affairs in my view. 

+1, business perspective, I respect and honor Rigol, even though this model is released for quite some years now, they're not ignoring it even though its the entry level cheap scope, and keeping the man powers to maintain it.

[canibalimao]

Anyone find anything else with the new firmware? The frenzy seemed to die pretty quick.

I think that now very few people are willing to try an update.

Why would that be the case?! We have not seen a huge wave of reports on this firmware update, but the ones that were posted did not suggest any negative side effects, and confirmed a few improvements.

I think we have simply moved to "business as usual" with the DS1000Z. It's not the scope itself anymore that is the hobby, or a "project" of it's own, but people simply use it. It is nice that Rigol still publishes the occasional firmware update, but there are no major problems anymore (and no breakthrough improvements in the firmware). Overall, that's a good state of affairs in my view. 

Because on the last update some users got a faulty scope.
And, unlike usual, we didn't see that much user reports here on the forum related to the new firmware. Just some occasional thumbs up to the update, but not a big discussion. This makes me believe that not much people did the update...

[Fungus]

Anyone find anything else with the new firmware? The frenzy seemed to die pretty quick.

I think that now very few people are willing to try an update.

 

People updated and reported the results. What exactly were you expecting?

[Fungus]

Because on the last update some users got a faulty scope.

Did you want a repeat of that?

And, unlike usual, we didn't see that much user reports here on the forum related to the new firmware. Just some occasional thumbs up to the update, but not a big discussion.

There was several pages of discussion, mostly about the low pass filter fix.

Maybe just not the discussion of complete disaster and bricked oscilloscopes you were hoping for...?

This makes me believe that not much people did the update...

 

[frozenfrogz]

I started a new thread to cover bugs and issues in the latest firmware release, because kwass can not spare the time to maintain the original thread atm.
Right now the first posting is just a place holder (FYI)

Edit: Thread has started to become functional and a bunch of the reported bugs seem to be resolved.

[metrologist]

Well, for the record, I'm gunshy too... I suspect there is no rigorous regression testing... so the guinea pigs need to do that and report back what bug about measure was fixed and the complete effects, like what was done for the bug about filter.