New Rigol DS1054Z oscilloscope

[borjam]

Happened all the time when everybody wanted to root their smartphone and threatened to sue the retail store and the manufacturer when we found out (after they lied to us) and refused to repair them under warranty.
You have modified the software. We have no idea of what else you did when you touched where you weren't supposed to *washing both hands*

It's not the same. You haven't modified the software in an undocumented way, you just fed it a license code, which is an entirely different matter. Of course it would be a problem (and real "hacking") if you patched the firmware, for example, in order to change a logo or whatever. That would be a Modification (capital M intentional).

It means that you are not entitled to complain about a serial decode failure unless you actually purchased the license.

And those warnings about voiding warranty when you update the firmware firmware following manufacturer's instructions? I am sure it wouldn't stand in court.

[Fleetz]

Pretty much sold on buying a DS1054Z scope and doing the upgrade hack.

Where is the best place to buy a DS1054Z from? I have looked at your reviews Dave and you refer to $399 all the time.....I assume $399AUD? Where from?

Cheers,

Fleetz

[Muttley Snickers]

@Fleetz

If you are in Australia Emona Instruments are the best option, the DS-1054Z is $579 AUD plus 10% GST so round $640 odd, I can't link from this device but you can Google them, the $399 price referred to was in US dollars.

[Fleetz]

@Fleetz

If you are in Australia Emona Instruments are the best option, the DS-1054Z is $579 AUD plus 10% GST so round $640 odd, I can't link from this device but you can Google them, the $399 price referred to was in US dollars.

Cheers Muttley...never can work out why we pay a premium for the same products here in OZ? I get exchange rates and shipping etc, but alway seem well short of explaining the delta in prices.

[Muttley Snickers]

The same concerns were raised a while ago and I think it was earlier in this particular thread with a valid response from John South at Emona, there are import duties and other taxes they have to pay on top.

Take a look at reply 1062 on page 43 of this thread. 

[JPortici]

Happened all the time when everybody wanted to root their smartphone and threatened to sue the retail store and the manufacturer when we found out (after they lied to us) and refused to repair them under warranty.
You have modified the software. We have no idea of what else you did when you touched where you weren't supposed to *washing both hands*

It's not the same.

Yes it is. The license agreement vou have agreed to says so. If you modify the firmware it is at your own risk, void warranty. You don't like that? Go deal with someone else

It means that you are not entitled to complain about a serial decode failure unless you actually purchased the license.

Makes totally sense. And that's also why there is an evaluation period of 60 hours ("Try Before You Buy")

And those warnings about voiding warranty when you update the firmware firmware following manufacturer's instructions? I am sure it wouldn't stand in court.

i'm afraid it's up to you (or to your government) to verify that (AGCOM here does that sort of things)
Actually i see their point. Upgrading the firmware is done at your own risk... The device is working, after all!!
If you've ever written a bootloader you will know that things can go very badly despite all the security measures... best thing would be having a flash programmer and flash the uncrypted image but would you do that? would you give the code away just like that? I wouldn't for many projects.

But that's more to cover their asses on case of what you called Modifications with a capital M, they will usually charge a nominal fee... or nothing at all (plus the shipping of course)

[metrologist]

The following discussion about specs, how to interpret them, and how they are to put into perspective is gold. I very much appreciate all that. I had not even brought into the discussion DC offset and channel separation, nor how to interpret that value, which I was wondering anyway. Thanks again. Still love the scope too...

[edavid]

The license agreement vou have agreed to says so. If you modify the firmware it is at your own risk, void warranty. You don't like that? Go deal with someone else

Maybe that's Italian law, but it's not generally true.

First, most jurisdictions have warranty laws that override EULAs and similar one sided non-contracts.

Also, in many places, in order for a modification to void the warranty, the manufacturer has to show that the modification caused the failure.

For example, here's an article about US warranty law:
http://motherboard.vice.com/read/warranty-void-if-removed-stickers-are-illegal

(Updating firmware or entering license codes is not exactly the same as removing a sticker, but if the manufacturer can't establish a logical connection between the modification and the failure, they can't legally deny warranty coverage.)

[thomastheo]

The E.U. directive 1999/44/EC concerning the rights of the consumer with regard to warranty, among other things, stipulates that it is not possible for a EULA or something similar to deny the consumer the right to warranty in such a case. There have been multiple court cases in various European countries that have served to show this is the case, often regarding the 'jailbreaking' of iphones and the like. Unfortunately, having a right and by extension using that right is not always possible without a fight, but at least for the EU market, you *should* officially be able to hack the software without losing your warranty, no matter what the manufacturer claims or what you might agree to as a consumer before or after a purchase.

[JPortici]

as european we are subject to those directives, but *should*..
that's the magic word.

there are many things that *should* or *should not* be but they are/aren't anyway. going to court over it usually, but not always, clear the situation

Or at least that is what happens here

[thomastheo]

Yeah, agreed. What good is a warranty for a 400e scope if you have to go to court to get it? But hey, things will improve with time I hope. It's important to remember though that here in the EU, the company you bought the end product from is responsible for honoring the warranty, and not Rigol for example, so choose carefully where you place your order. I've had great success dealing with Batronix (DE) in that regard, and chose them over a supplier in my own country because of their reputation for good service.

[Assafl]

Usually you will talk to a manager and deny any allegations that the problem is due (or related to) the hack. Tell them you were testing if these features worked for you and offer that they can remove them (just like you intended to) with Uninstall command (had the scope not died).

That is the single most important thing. That the failure is not related to the hack - so if you problem is memory - don't complain about the 24mpts memory - complain about 12. 

BTW - That is why Apple does whatever is in its power to brick Jailbroken phones. The bricking is due to the hacking - if it wasn't hacked it would be bricked.

Now if the cellphone is Jailbroken but the mouthpiece dies - they have to fix it under warranty. Under most laws today - that is.

[LokiChaos]

I've recently acquired a 1054Z and I love it.  I've been playing with it, messing with the functionality and trying to replicate bugs.  I expect everything to have bugs, but I want to be sure I know what they look like and how to reproduce them so that I am able to recognize them should they occur when I am actually taking a measurement. 

The RMS bug seems to be the major remaining issue since the last firmware update (which I have done) and I noticed something odd with it.  I'm using the 4 probes that came with it on the pins of a 47ohm resistor and am feeding a 1kHz sine wave from a function gen (yeah, a cheap FY3200S).  The Vpp is 4.8V, so the Vrms should be ~1.71V.  I can reproduce the bug just fine, I get 1.69V, 1.81V, 1.82V, 1.83V for the RMS on CH 1-4 respectively (My EEVBlog meter reads 1.680V).  Nothing new or interesting there, Ch1 is correct and the other 3 are high.  I can disconnect the probe for channel N and N+1 drops down to 1.69V.  Again, nothing new, exactly as reported by others.  However, when I disable channel N with the probe connected the relay clicks and the trace disappears, however the value on CH N+1 doesn't drop!  I can even physically disconnect the probe after the channel has been turned off and the "extra" is still appearing in CH N+1.  If I turn CH N back on (without reconnecting the probe), CH N+1 then drops to ~1.69V (±0.02 or so).

This I think cements that it is truly a problem in software, and some value somehow bleeding over.

I can take screen shots, but I think this table would be clear enough, and more concise. 
NB: All channels on, All probes connected, triggering off CH 1 and all values are the Rms measurements.

Code: [Select]

CH1    CH2    CH3    CH4
1.69V  1.81V  1.82V  1.82V
Disable Ch2
1.69V  *****  1.82V  1.82V
Disconnect Ch2 probe
1.69V  *****  1.82V  1.82V
Enable Ch2 probe (still disconnected)
1.69V  691mV  1.69V  1.82V
Reconnect Ch2 probe
1.69V  1.81V  1.82V  1.82V

Same as above, but performing the same cycle with Ch3
1.69V  1.81V  1.82V  1.82V
1.69V  1.81V  *****  1.82V
1.69V  1.81V  *****  1.82V
1.69V  1.81V  683mV  1.69V
1.69V  1.81V  1.82V  1.82V

Same as the first two, except I moved the trigger to Ch4
and am performing the cycle with Ch1
1.69V  1.81V  1.82V  1.82V
*****  1.81V  1.82V  1.82V
*****  1.81V  1.82V  1.82V
27.8mV 1.67V  1.82V  1.82V
1.69V  1.81V  1.82V  1.82V


[McBryce]

Just updated my MSO1104Z-S with the latest firmware. Everything went as expected, the scope is responsive and the "liberated features" are still there.

McBryce.

[tggzzz]

The E.U. directive 1999/44/EC concerning the rights of the consumer with regard to warranty, among other things, stipulates that it is not possible for a EULA or something similar to deny the consumer the right to warranty in such a case. There have been multiple court cases in various European countries that have served to show this is the case, often regarding the 'jailbreaking' of iphones and the like. Unfortunately, having a right and by extension using that right is not always possible without a fight, but at least for the EU market, you *should* officially be able to hack the software without losing your warranty, no matter what the manufacturer claims or what you might agree to as a consumer before or after a purchase.

So you go to court, and the courts have to decide between

• the vendor's assertion that an unauthorised procedure modifying the internal function has caused the problem, and that you are an incompetent example of the Dunning-Kruger effect and deserve what you get
• your assertion that an unauthorised procedure modifying the internal function did not cause the problem, that you are competent and that the vendor is attempting to evade their responsibilities

In the absence of impartial evidence, which will they choose to believe?

You will increase your chances if you can find an independent expert willing to testify to your competence and actions; good luck with that.

[JPortici]

Yeah, agreed. What good is a warranty for a 400e scope if you have to go to court to get it? But hey, things will improve with time I hope. It's important to remember though that here in the EU, the company you bought the end product from is responsible for honoring the warranty, and not Rigol for example, so choose carefully where you place your order. I've had great success dealing with Batronix (DE) in that regard, and chose them over a supplier in my own country because of their reputation for good service.

thought that it was the manufacturer for the first year* (in this case Rigol Technologies EU GmbH, if the scope is an "european" model and it is not imported from outside the union) and the seller for the following years*

*unless you could and have bought extended warranty period from either one, if possible

[Sredni]

Hi there,

new to the forum, I registered to throw my hat in the RMS bug arena.
So, I happen to be the incarnation of laziness and my scope (1054Z) is still unhacked and with the firmware it came from the factory more than a year ago.
This means 00.04.02.SP4 (which, I guess, is v00.04.02.03.00).

I did try this verbatim

1. Set timebase to 100 uSec/div..
2. Enable CH1 and CH2, DC coupling, and trigger on CH1, setup trigger to 1.5V to have a stable trace..
3. Set VRMS measurement on both CH1 and CH2..
4. Plug in the probe ONLY to CH1 and connect it to CAL. DO not connect anything to CH2..
5. Set CH1 to 1V/div..
6. Set CH2 to20V/div..

and I do not experience wild values for the RMS voltage on channel 2.
On the contrary, while ch1 is rock solid a 2.10 Vrms, ch2 at 20 V/div (and no probe connected to that channel) shows a rms voltage of 566 mV. Not exactly nil but I believe it to be in line with the background noise and computation errors at that scale. (at 100 V/div the reading becomes 2.83 V)
With the probe connected to channel 2 and to the CAL output, I get at 20 V/div a RMS voltage of 2.04V (which goes to stable 2.10 V at 1V/div)

Did I miss something, or is this proof that the RMS bug has been introduced in later versions of the firmware?
Is there anybody that can confirm or deny this?

(I wanted to update the firmware to the latest version to get the better X-Y mode but now I am doubtful)

[drdanke]

I know the fft function of the DS1054Z is very limited, but what kind of stuff would it still be useful for?  Can anyone give any examples where the fft function would still be adequate?  Would it be of any use on a guitar effects pedal circuit (9-volt preamp circuit) ?   Thanks!

[technogeeky]

I know the fft function of the DS1054Z is very limited, but what kind of stuff would it still be useful for?  Can anyone give any examples where the fft function would still be adequate?  Would it be of any use on a guitar effects pedal circuit (9-volt preamp circuit) ?   Thanks!

It is not very limited. The FFT when taken from memory (only certain timebases) is very good. You can also use the trace version with PC software here and/or pull all of the data points from memory (very slow, but it works), and you can get a great result.

The main limitation is the 8-bit ADC, and this can be partially overcome by hires or averaging mode.

You can use it for all non-serious spectrum analysis stuff, like checking for resonances in function generators, on power supplies, on audio, etc.

[Fungus]

I know the fft function of the DS1054Z is very limited, but what kind of stuff would it still be useful for?  Can anyone give any examples where the fft function would still be adequate?  Would it be of any use on a guitar effects pedal circuit (9-volt preamp circuit) ?   Thanks!

It is not very limited.

You can use it for all non-serious spectrum analysis stuff, like checking for resonances in function generators, on power supplies, on audio, etc.

Yep. Just because there's better FFTs out there it doesn't mean the DS1054Z FFT is useless. It does a good enough job for many things.

[LokiChaos]

It is not very limited. The FFT when taken from memory (only certain timebases) is very good. You can also use the trace version with PC software here and/or pull all of the data points from memory (very slow, but it works), and you can get a great result.

The main limitation is the 8-bit ADC, and this can be partially overcome by hires or averaging mode.

You can use it for all non-serious spectrum analysis stuff, like checking for resonances in function generators, on power supplies, on audio, etc.

I seem to be able to get this running on Linux (Gentoo specifically), however PyDSR, sigrok, and DSremote all seem to not be able to communicate with my scope over USB.  I know it is not simply a permissions issue.  DSremote works over LAN.

DSremote worked before I upgraded to the latest firmware.  Any Linux using 1054Z owners have any ideas?

[drdanke]

I know the fft function of the DS1054Z is very limited, but what kind of stuff would it still be useful for?  Can anyone give any examples where the fft function would still be adequate?  Would it be of any use on a guitar effects pedal circuit (9-volt preamp circuit) ?   Thanks!

It is not very limited. The FFT when taken from memory (only certain timebases) is very good. You can also use the trace version with PC software here and/or pull all of the data points from memory (very slow, but it works), and you can get a great result.

The main limitation is the 8-bit ADC, and this can be partially overcome by hires or averaging mode.

You can use it for all non-serious spectrum analysis stuff, like checking for resonances in function generators, on power supplies, on audio, etc.

Wow, thanks for the heads up on the PyDSA software (better spectrum analyzer for your Rigol).  I didn't even know it existed, and will definitely check it out.  I hear so many people saying the fft function is useless, but it's good to hear that it is indeed useful, or at least, can be..  Thanks again!

[Assafl]

Hi there,

new to the forum, I registered to throw my hat in the RMS bug arena.
So, I happen to be the incarnation of laziness and my scope (1054Z) is still unhacked and with the firmware it came from the factory more than a year ago.
This means 00.04.02.SP4 (which, I guess, is v00.04.02.03.00).

I did try this verbatim

1. Set timebase to 100 uSec/div..
2. Enable CH1 and CH2, DC coupling, and trigger on CH1, setup trigger to 1.5V to have a stable trace..
3. Set VRMS measurement on both CH1 and CH2..
4. Plug in the probe ONLY to CH1 and connect it to CAL. DO not connect anything to CH2..
5. Set CH1 to 1V/div..
6. Set CH2 to20V/div..

and I do not experience wild values for the RMS voltage on channel 2.
On the contrary, while ch1 is rock solid a 2.10 Vrms, ch2 at 20 V/div (and no probe connected to that channel) shows a rms voltage of 566 mV. Not exactly nil but I believe it to be in line with the background noise and computation errors at that scale. (at 100 V/div the reading becomes 2.83 V)
With the probe connected to channel 2 and to the CAL output, I get at 20 V/div a RMS voltage of 2.04V (which goes to stable 2.10 V at 1V/div)

Did I miss something, or is this proof that the RMS bug has been introduced in later versions of the firmware?
Is there anybody that can confirm or deny this?

(I wanted to update the firmware to the latest version to get the better X-Y mode but now I am doubtful)

You should connect both channels to the CAL terminal to see the bug.

[Sredni]

You should connect both channels to the CAL terminal to see the bug.

The above procedure said not to (but it's not the first time I misread instructions).
Anyway, I did that too, and I get RMS values that are in line with what expected. 2.04 V on channel 2 with 20V/div.



(By the way, there must be a bug in the web platform: the attached imaged was 'viewed 92 times' 1 second ufter uploading...)

[TurboTom]

The RMS bug was first introduced with firmware version 00.04.03.01.05 from 2015-06-16. It had been discussed exhaustively about a year ago already (for the new owners of a DS1000Z  ). The only disappointment is that Rigol didn't fix it in the recent update. So no need to get nervous about that now, all of those who installed the mentioned update learned to live with that bug and surely will survive the next several months until Rigol comes up with a fix (I'm quite optimistic they will...).

Cheers,
Tom



Edit: Typos...