the Math Horizontal Error at 500 ns/div seems to be GONE !!
I am still testing for the Measurements Fail bug. This one was totally random in the time it took to fail so it may take me a while to be confident that it is gone.
The interface doesn't seem quite as sluggish as it was before, but that might just be subjective.
That's pretty much all the major complaints fixed.
If I were to speculate, it is a problem how they handle data for RMS calc.. RMS is calculated as a running filter on a circular buffer... multiplexed between channels.. could be that some data in some buffer leaks to a next channel or something like that..
If that's true then how do you explain that the bug comes and goes depending on the vertical scale?
@Fungus
What don't you understand...
It's amplifies error voltage with vertical settings goes higher (like volume pot
![Tongue :P](https://www.eevblog.com/forum/Smileys/default/tongue.gif)
) and multiplies with Ch2's probe compensation setting.
Did you see my ds1000z vs. ds2000a compared side by side with same settings?
I was an idiot and tried the following procedure to firmware upgrade:
- Turn scope off.
- Turn scope on.
- Wait for Rigol LOGO and 1 beep.
- Press Help 3 times.
- <something good happens here>
Instead of that, all of the CH buttons lit up, the scope speaker generated a continuous tone, and it
destroyed my USB drive! Yes, you read that right. Now the nice high-speed 32GB USB drive I put the firmware on won't even connect to any device or computer I try.
I thought that this had messed up the USB interface on the scope, too -- because afterward, it did not recognize other USB drives. But a power disconnect and reconnect fixed that.
Anyway, I've upgraded using the normal procedure. I'll report back later.
Also, are you guys doing the self-cal on the scope as requested, after firmware upgrade? I only ask because I now see a new button on the Self-Cal menu that I haven't seen anyone mention.
It now reads:
Was this there before? I certainly don't remember it.
I tried LFCal, it does something and then says it failed. It looks like it might need a probe attached or something.
I am very happy to report that the Math Horizontal Error at 500 ns/div seems to be GONE !! The Math trace now displays correct time relationships to the input signals.
I am still testing for the Measurements Fail bug. This one was totally random in the time it took to fail so it may take me a while to be confident that it is gone.
Thanks alsetalokin4017 and JohnPen. So far, so good on the rectification of those functional issues.
Instead of that, all of the CH buttons lit up, the scope speaker generated a continuous tone, and it destroyed my USB drive! Yes, you read that right. Now the nice high-speed 32GB USB drive I put the firmware on won't even connect to any device or computer I try.
Unless it has changed in newer firmware, according to the Dec. 2015 documentation the largest USB drive that's supported is still only 8GB (see Ch. 17).
Interestingly, the manual now states that only FAT32 is supported (see Ch. 14), whereas earlier versions didn't specify. So, that definitively establishes what I had suspected when I was having trouble with smaller USB drives (FAT16 and large clusters).
A corollary - if you increase the Y axis even more - the error in Vrms calculation increases. That is also "broken".
If the trace goes off screen it will fail because the 8-bit ADC will be saturated to readings of 0 & 256.
There's nothing anybody can do about that.
Indeed that is the flip side of what I was saying. Increasing the V/div would decrease the size of the trace on screen. At some point (as the square wave deliquesces into a line) the errors increase and Vrms goes haywire.
However, Meka77's bug is not that phenomena - it is a separate issue that happens between consecutive channels.
Instead of that, all of the CH buttons lit up, the scope speaker generated a continuous tone, and it destroyed my USB drive! Yes, you read that right. Now the nice high-speed 32GB USB drive I put the firmware on won't even connect to any device or computer I try.
Unless it has changed in newer firmware, according to the Dec. 2015 documentation the largest USB drive that's supported is still only 8GB (see Ch. 17).
Interestingly, the manual now states that only FAT32 is supported (see Ch. 14), whereas earlier versions didn't specify. So, that definitively establishes what I had suspected when I was having trouble with smaller USB drives (FAT16 and large clusters).
For purposes of making screenshots, I have used an identical 32GB FAT-formatted flash drive in the 1054z. It worked fine, and detected it as 32GB (or whatever, 31GB).
However, this doesn't come near to explaining why it murdered my drive. It's so tiny of a drive it will be near impossible to take apart.
Also, are you guys doing the self-cal on the scope as requested, after firmware upgrade? I only ask because I now see a new button on the Self-Cal menu that I haven't seen anyone mention.
It now reads:
Was this there before? I certainly don't remember it.
I tried LFCal, it does something and then says it failed. It looks like it might need a probe attached or something.
I don't see that...
I just checked, me neither...
Also, are you guys doing the self-cal on the scope as requested, after firmware upgrade? I only ask because I now see a new button on the Self-Cal menu that I haven't seen anyone mention.
It now reads:
Was this there before? I certainly don't remember it.
I tried LFCal, it does something and then says it failed. It looks like it might need a probe attached or something.
I don't see that...
My Bad - it is a "secret" menu accessible only after hittin MENU MENU FORCE MENU fast. And there is a spelling error there too...
For purposes of making screenshots, I have used an identical 32GB FAT-formatted flash drive in the 1054z. It worked fine, and detected it as 32GB (or whatever, 31GB).
However, this doesn't come near to explaining why it murdered my drive. It's so tiny of a drive it will be near impossible to take apart.
Yeah, it might work, but no guarantees. Granted, that doesn't explain why it trashed the drive, but thought I'd mention the official limit in case you hadn't seen it.
I am very happy to report that the Math Horizontal Error at 500 ns/div seems to be GONE !! The Math trace now displays correct time relationships to the input signals.
I am still testing for the Measurements Fail bug. This one was totally random in the time it took to fail so it may take me a while to be confident that it is gone.
Thanks alsetalokin4017 and JohnPen. So far, so good on the rectification of those functional issues.
Whohoo! What's left besides trivial spelling?
Re: RMS measurements, do these values fall within the specifications, usually as a % of full scale, with 1 bit resolution? I also recall a channel isolation spec.
OOPS.....
I warmed the scope up, did a self-calibration, restarted, and reloaded a saved test setup that I was using to see if the Measurements would fail after a random time. I'm using the same input to both channels, from a BNC T on the FG and two matched BNC cables into the scope. And I saw this very strange thing.....
The Measurements are updating properly except that the Average and Std.Deviation in the CH1 Period_VRMS window are not being computed!
![WTF? :wtf:](https://www.eevblog.com/forum/Smileys/default/wtf2.gif)
More weirdness: Turning CH1 off with its button removes the trace from the screen but does not stop its Measurements: they continue to be updated with apparently correct values except for the missing Average and Deviation. (It does stop the Math computation though.) Setting CH1 coupling to Ground stops them, except for VRMS which continues to show a value and updating Measurements. Neither of these manipulations start the CH1 P_VRMS Average and Deviation working again.
But changing the timebase started the CH1 P_VRMS Average and Deviation readings working again !!
OOPS.....
More weirdness: Turning CH1 off with its button removes the trace from the screen but does not stop its Measurements: they continue to be updated with apparently correct values except for the missing Average and Deviation. (It does stop the Math computation though.) Setting CH1 coupling to Ground stops them,
![Confused :-//](https://www.eevblog.com/forum/Smileys/default/confused0024.gif)
Exactly what I saw too...
I get the same but the Per. Vrms stats only continue if you are triggering the scope from the CH display you have turned off. Put another way trigger from CH1, displaying CH1 and CH2. Turn off CH2 stats cease to be collected on CH2. Turn off CH1 stats continue to be collected. Move trigger to CH2 and the situation swaps around. I was unable to reproduce the Avg and Dev not collecting state but maybe it is a difficult one to create.
John
Perhaps all of these issues are related to the Meka77 bug (where RMS calculations are linked between subsequent channels - CH1 effect on CH2, CH2 effect on CH3 measurements..). It would seem likely that there is a parameter or a data set that is being incorrectly shared between channels.
I tried to send the Meka77 bug to Rigol - I don't know if they read email or not....
Instead of that, all of the CH buttons lit up, the scope speaker generated a continuous tone, and it destroyed my USB drive! Yes, you read that right. Now the nice high-speed 32GB USB drive I put the firmware on won't even connect to any device or computer I try.
Maybe it didn't physically damage your flash drive but corrupted its firmware somehow. Maybe this link will help.
http://www.rmprepusb.com/tutorials/repair-your-usb-flash-drive
How do I completely clear a measurement? I was trying to set my scope to duplicate some of the setups here and if I pressed the wrong measurement, I can't figure out how to make it go away completely. If I delete it, it stays grayed out and a new measurement will just be added.
How do I completely clear a measurement? I was trying to set my scope to duplicate some of the setups here and if I pressed the wrong measurement, I can't figure out how to make it go away completely. If I delete it, it stays grayed out and a new measurement will just be added.
If I understood correctly what you want, following button sequence :
[MEASURE]->[CLEAR]->[ALL ITEMS]
That will clear all measurement started from a menu buttons on the left of the screen..
You can "clear" all of them, but individual "removed" ones won't go away until they're replaced with a different one. Unfortunately, it doesn't remove a measurement and move the remaining ones to close the gap, as one would expect.
You can "clear" all of them, but individual "removed" ones won't go away until they're replaced with a different one. Unfortunately, it doesn't remove a measurement and move the remaining ones to close the gap, as one would expect.
OK so I didn't understand ...
![Face Palm :palm:](https://www.eevblog.com/forum/Smileys/default/facepalm.gif)
But I tried what you say .. I setup 5 measurements, deleted number 3, and when I pressed a new one, item 4 and 5 shifted left to 3 and 4 and new one appeared on place 5.. 1 and 2 did not change..
Tried twice, and worked like that both times... I guess you can't delete them like that... it might has to do with delete /recover function... maybe for individual measurements, they should have called it enable/disable not delete.....
You did it correctly. When you "delete" number 3, it's just grayed out. If you add the same one again, it's just re-enabled in the same location. If, instead, a new one is enabled, then the others shift to replace the grayed out ones and the new one is added at the end. I guess you could call the behaviors enable/disable/replace -- no delete.