-
#2650 Reply
Posted by
borjam
on 29 Jul, 2016 11:56
-
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.
-
#2651 Reply
Posted by
Fleetz
on 29 Jul, 2016 14:20
-
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
-
-
@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.
-
#2653 Reply
Posted by
Fleetz
on 29 Jul, 2016 15:16
-
@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.
-
-
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.
-
#2655 Reply
Posted by
JPortici
on 29 Jul, 2016 17:15
-
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)
-
#2656 Reply
Posted by
metrologist
on 29 Jul, 2016 19:25
-
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...
-
#2657 Reply
Posted by
edavid
on 29 Jul, 2016 21:32
-
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.)
-
#2658 Reply
Posted by
thomastheo
on 29 Jul, 2016 22:32
-
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.
-
#2659 Reply
Posted by
JPortici
on 29 Jul, 2016 23:28
-
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
-
#2660 Reply
Posted by
thomastheo
on 29 Jul, 2016 23:57
-
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.
-
#2661 Reply
Posted by
Assafl
on 30 Jul, 2016 06:16
-
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.
-
#2662 Reply
Posted by
LokiChaos
on 30 Jul, 2016 06:50
-
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.
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
-
#2663 Reply
Posted by
McBryce
on 31 Jul, 2016 13:39
-
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.
-
#2664 Reply
Posted by
tggzzz
on 31 Jul, 2016 14:09
-
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.
-
#2665 Reply
Posted by
JPortici
on 31 Jul, 2016 17:05
-
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
-
#2666 Reply
Posted by
Sredni
on 31 Jul, 2016 23:28
-
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)
-
#2667 Reply
Posted by
drdanke
on 01 Aug, 2016 00:23
-
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!
-
#2668 Reply
Posted by
technogeeky
on 01 Aug, 2016 02:20
-
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.
-
#2669 Reply
Posted by
Fungus
on 01 Aug, 2016 04:26
-
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.
-
#2670 Reply
Posted by
LokiChaos
on 01 Aug, 2016 04:27
-
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?
-
#2671 Reply
Posted by
drdanke
on 01 Aug, 2016 04:34
-
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!
-
#2672 Reply
Posted by
Assafl
on 01 Aug, 2016 09:43
-
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.
-
#2673 Reply
Posted by
Sredni
on 01 Aug, 2016 10:59
-
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...)
-
#2674 Reply
Posted by
TurboTom
on 01 Aug, 2016 11:37
-
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...