New Rigol DS1054Z oscilloscope

[frozenfrogz]

What multiplier setting is set in the "probe" menu item?

I am using the 10x setup on both the probe and the Rigol.

Turns out, the issue must have been there before, as I could clearly identify the power cable as the source of radiation. Putting my hand near the cable gives an increased readout of about 10Vpp. I guess it did not occur to me as I have not been using the clip-on heads a lot, but to my liking this is inducing to much noise.
Do higher quality power cables come as shielded?

Regards,
Frederik

PS: This buildings electrical installation is in sub-optimal state and the owner could not care less. There is no RCD / ground line, everything is two-wire with neutral bridged to ground (as it was done in the 1980s I guess). Could this be the root of all evil?

[frozenfrogz]

double check your mains ground too.

That's what came up in my mind while typing xD
So I guess I’ll have to live with it until moving to a better location...

[Housedad]

Ouch.  That sucks not having a proper ground.  I had to have the ground rods replaced at my house because of too much resistance.   It was causing all the metal around my garage to reflect and re-radiate the wideband RF from my old spark gap Tig welder instead of grounding it out. (all of the stuff there is bonded to ground.)

[Karel]

Installed the new firmware. Upgrading went smooth. Now it shows version 00.04.04.SP3 in system info.
Unfortunately they didn't fix the USB bug (which doesn't come as a surprise because Rigol told me that it's
probably too hard to fix...).

edit: Installed options are still present.

[JPortici]

I noticed that the rise times say "<XXus" when you're zoomed out. Did it do that before? I don't remember.

i've always seen it happen.. probably when there are not sufficient points to calculate. zoom in and the magic happens

(is there another update?)

[metrologist]

I noticed that the rise times say "<XXus" when you're zoomed out. Did it do that before? I don't remember.

i've always seen it happen.. probably when there are not sufficient points to calculate. zoom in and the magic happens

(is there another update?)

Yes. It came in right after the cats left...

Looks like Rigol just posted new firmware version 00.04.04.03.02
http://beyondmeasure.rigoltech.com/acton/fs/blocks/showLandingPage/a/1579/p/p-0019/t/page/fm/0

[Housedad]

finally got the time to update mine.   Worked with no problems. 

[metrologist]

the USB bug...

I'm sorry, I forgot the detail of this... it does not affect use of the Rigol software and use with USB, right? You were using it with Linux and DSRemote?

[Fungus]

the USB bug...

I'm sorry, I forgot the detail of this... it does not affect use of the Rigol software and use with USB, right?

IIRC it was something with using a USB cable to control it instead of Ethernet.

(which seems pointless anyway, what's wrong with Ethernet?)

[Karel]

the USB bug...

I'm sorry, I forgot the detail of this... it does not affect use of the Rigol software and use with USB, right? You were using it with Linux and DSRemote?

The bug causes problems depending on your pc/laptop hardware & driver. To be more precise, it depends
on which USB hostcontroller chip is mounted on your motherboard.
The scope uses HS bulk endpoints with a packetsize of 64 bytes which is illegal because the standard says it must be
512 bytes. So, some controllers don't forward the packet to the driver (or the driver doesn't forward it to an upper layer)
because it expects more data to arrive. Usually there's a timeout of 5 seconds but that doesn't help much.

Honestly, I don't know how windows deals with it. It could be that windows is more forgiving (less strict with the standard)
than Linux. What I do know for sure is that with Linux and same kernel versions, the problem occurs depending on the hardware.

The problem has been reported to Rigol and they confirmed it. They also said that it's too hard to solve.

[bitseeker]

OK! Just another succesive update. PLUSES still remain!

Honestly, we'll miss it the day they fix the typo!!! 

I'm starting to think that's an inside joke at Rigol...

Yeah, maybe. Or perhaps they want this scope to always be different from everyone else's.

[bitseeker]

IIRC it was something with using a USB cable to control it instead of Ethernet.

(which seems pointless anyway, what's wrong with Ethernet?)

Nothing wrong with Ethernet. Someone may not have an Ethernet port (or requires a dongle) or a hub/switch/null cable handy to connect to it. It doesn't do auto-crossover does it? Anyway, USB may just be more convenient for some.

[metrologist]

OK, there is new Firmware posted here in April. It fixed a problem with the previous version locking up old scopes.

What does this version fix otherwise? Does anyone have info on any possible suspects for the following?

• Bugs about measure.
• Bugs about filter.
• Bugs about SCPI reading memory data.
• Bugs about downloading waveform to source module

[JPortici]

the filter always started about 2 divisions right. i use the lowpass to make certain measurementes because i have a terrible issue here with FM radio interference.

Buck converter. chan2 is pre-inductor, chan1 is post inductor. with filter i can see the actual waveform

Before update:


Spoiler alert: 
running self cal...

After update it starts earlier but also stops earlier. whatever is positioned correctly


Look what happens if you just touch the "start" control. the end control doesn't do nothing


** saving a screenshot seems a bit faster

[Karel]

Good news is that it looks like the multi-channel waveform data download bug as described here:

https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg862373/#msg862373

has been resolved.

[Dwaine]

Rigol, it's not too hard.  Your device driver is reporting the wrong Max Packet Size value for high-speed bulk endpoint
Or just force the USB Controller driver to use 512.

Index: usb-3.18/drivers/usb/host/xhci-mem.c
===================================================================
--- usb-3.18.orig/drivers/usb/host/xhci-mem.c
+++ usb-3.18/drivers/usb/host/xhci-mem.c
@@ -1464,9 +1464,6 @@ int xhci_endpoint_init(struct xhci_hcd *
       max_burst = ep->ss_ep_comp.bMaxBurst;
       break;
    case USB_SPEED_HIGH:
+      /* Some devices get this wrong */
+      if (usb_endpoint_xfer_bulk(&ep->desc))
+         max_packet = 512;
       /* bits 11:12 specify the number of additional transaction
        * opportunities per microframe (USB 2.0, section 9.6.6)
        */

[bitseeker]

After update it starts earlier but also stops earlier. whatever

Look what happens if you just touch the "start" control.

So, it was just a visual bandaid. D'oh! Fail.

Good news is that it looks like the multi-channel waveform data download bug...has been resolved.

That's great news for remote multi-channel capture and processing.

Rigol, it's not too hard.

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

[JPortici]

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

[RoGeorge]

OK, there is new Firmware posted here in April. It fixed a problem with the previous version locking up old scopes.

What does this version fix otherwise? Does anyone have info on any possible suspects for the following?

• Bugs about measure.
• Bugs about filter.
• Bugs about SCPI reading memory data.
• Bugs about downloading waveform to source module

Inside the archive 'DS1000ZUpdate.zip' is the usual text file 'DS1Z_release_notes.txt', where all the fixes are listed:

Code: [Select]

[Supported Model]    All the MSO/DS1000Z Series Digital Oscilloscopes
[Latest Revision Date]  2017/03/24

[Updated Contents]
--------------------
v00.04.04.03.02  2017/02/06
     - Improved the LXI module
     - Fixed the freeze problem when upgrading based on the boot version of
       0.0.0.13
     - Improved the menu in the language of Traditional Chinese and Korean
     - Modified the failure when downloading waveform to the source module
     - Fixed bugs about reading the memory data through SCPI commands
     - Fixed bugs about Measure
     - Fixed bugs about Filter

[History]
-------------
v00.04.04.01.01  2016/09/14
     - Supported the multi-inteface of LXI
     - Fixed bugs about Measure

v00.04.04.00.07  2016/07/19
     - Added the full-screen display in the XY mode
     - Modified the Trace data of average sample mode
     - Fixed the bug of system halted for wave persistance in the Zoom mode
     - Fixed bugs about Measure

v00.04.03.02.03   2015/10/20
     - Added commands concerning the type and format of the image
     - Added four measurement items (+Pulses, -Pulses, +Edges, -Edges) and
       related commands
     - Added commands concerning the digital filter
     - Added more information to the last setting

     - Fixed option installation
     - Fixed Intg operation

v00.04.03.01.05   2015/06/16
     - Added French in system language
     - Added the mutual communication with DG4000 Series
     - Added the digital filter
     - Supported using memory data to carry out FFT operation
     - Supported invert and format setting when reading a image remotely

     - Fixed bugs when the data of the digital channel is saved in the CSV
       format

v00.04.03.00.01   2015/05/05
     - Added DS1104Z Plus and DS1074Z Plus

     - Fixed pass/fail test
     - Fixed FFT operation

v00.04.02.04.07   2014/12/31
     - Fixed triggering function
     - Fixed storage function
     - Fixed bugs of jitter in the signal under the AC or low-frequency
       coupling

v00.04.02.03.00   2014/10/21
     - Added commands concerning remote reading and download of pass/fail test
       rules
     - Improved the command set for decoding and waveform recording

     - Fixed bugs in RS232 decoding
 
v00.04.01.02.00   2014/07/28
     - Added traditional Chinese language for the measurement menu
     - Optimized the event table display
     - Pressed and held [Measure] to remove all the measurement items
     - Added hardware version number to the displayed system information

     - Fixed bugs in storage function
     - Fixed bugs in the Undo operation for AUTO
     - Fixed bugs in signal source function
 
v00.04.00.00.00   2014/03/18
     - Added remote reading of LA waveform data
     - Added commands concerning the measurement of MATH waveform
     - Optimized the prompt message of LA probe calibration

     - Fixed bugs in triggering function
...
...
...


[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?

[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?
As always, I'll be happy to be proven wrong.

I did demonstrate that one of the fixes wasn't a fix  on a function i happen to use a lot. I think i have the right to be skeptical and say do not take the changelog as gold

[frozenfrogz]

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

[dimkasta]

I have a question since what I read around is a bit controversial.

Does the 1054z have configurable high/low/band pass filters on each channel like its small brother?
I use them a lot on my 1052 and I was thinking to upgrade to 1054 at some point.

[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
the range of cutoff frequencies depend on the selected timebase

question to other users, i was writing an I2C management stack the other week and i was using the Z to debug it. besided being very hard to make it trigger on i2c start contidion (i don't remember the exact trickery) i noticed that after a power cycle it wouldn't trigger unless i changed from i2c trigger to another and then back to I2C (without changing any parameter)

[ebastler]

I did demonstrate that one of the fixes wasn't a fix  on a function i happen to use a lot. I think i have the right to be skeptical and say do not take the changelog as gold

You are referring to the filter function, I assume.
Well, what you did demonstrate is that Rigol did not make a specific improvement which you were hoping for. But how can you claim that they did not fix anything in the filter function, and hence the change log entry is false? I agree that Rigol's change log entries are annoyingly brief, so one does not know what they have actually fixed or improved. But I don't think you can claim that they lie in the change logs, stating improvements that have not been made.

Speaking of the filter function, I am not sure what the actual issue is which you are concerned about. Is it the fact that the filtered waveform does not extend over the full width of the display?

(I assume that behavior stems from Rigol's approach of using only the display data for all measurements and calculations. 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!  )