-
Those offset calibration shots at 24 hours are not bad at all considering the input frontend is discrete. You can hardly complain about what looks like maybe half or three-quarters of a millivolt...
Thing is that these offset are there always. And it get's _really_ funny depending on what channels you have turned on and in what sequence. Even worse, the offset and amplitude will change for the same channel depending on what channels were on before and then turned off. Attached are some photos i made (yea, i still have not hooked it up to the computer, sorry). The images where taken after tthe unit was on for about half an hour.
1: Only channel 3 active
2: Again only Ch. 3 active, but after randomly turning on/off the other channels
Note that this is not due to warmup of the scope. After randomly turning on/off channels again it will sometimes fall back to what is in the first image, sometimes to what is in this image, sometimes something else
3: Ch. 3 and 1 on, Ch. 1 being selected. Note how Ch. 3's trace dropped down a bit
4: Ch. 3 and 4 on, Ch. 3 selected. Now Ch. 3 is even further down
5: Ch. 3 and 2 on. Ch. 2 selected. Ch. 3 is now a tad further down even.
6: Only Ch. 2 on. Note the amplitude and offset while it is set to 100V/div (10x probe setting)
Of course after fiddling with other channels it sometimes becomed a thinner trace.
No probes were connected to any channel. All i did was randomly selecting channels, turning them on/off, switching through the V/div settings randomly. Especially the last image shows a real problem: Am i to expect that i have about 20V p-p noise there, with a +10V offset, although nothing at all is connected?
They have a real problem with that offset/cal stuff there. And again, it's not static either, a single channel massively varies depending on what other channels where on/off/selected/etc. previously.
That just ain't right.
Greetings,
Chris
-
Those offset calibration shots at 24 hours are not bad at all considering the input frontend is discrete. You can hardly complain about what looks like maybe half or three-quarters of a millivolt...
Does a push of the V/div button set each to 0 V as in most other DSO's?
Does this zero them exactly?
You can push the Position knob to move the trace to the center graticule. It does not solve the problem because it is using the cal as a zero reference an it is off by a bit. Basically the cal is the issue. -
You can push the Position knob to move the trace to the center graticule. It does not solve the problem because it is using the cal as a zero reference an it is off by a bit. Basically the cal is the issue.
As it seems it's not only the cal, it seems to get confused what cal values to use for a given channel when using or having used other channels.
Greetings,
Chris -
You can push the Position knob to move the trace to the center graticule. It does not solve the problem because it is using the cal as a zero reference an it is off by a bit. Basically the cal is the issue.
As it seems it's not only the cal, it seems to get confused what cal values to use for a given channel when using or having used other channels.
Greetings,
Chris
I haven't noticed that but will keep an eye on it, I may have missed it. The position of the zero marker does change when a cal is done. Even if it comes out wrong, you'd expect it to be the same wrong every time. I've run the cal about 12 times on a well warmed up unit and the variations seem random. -
I would qualify extremely slow CSV export of full memory as a bug. It takes around half an hour! It's not that complex operation to take so long. It should be up to a few times longer than storing to WFM file to account for additional processing, not more.
-
- Be able to display a message from software on a PC. Ideally it would also have a Yes / No / Close button attached. I have a background in production testing and was often asked "Why can't I have a message on the scope screen to let me know?".
I've added these.
Seriously?
I have no doubt this would be useful for pickle, and probably others as well. But you're talking about something that no other scope I am aware of has ever had. And you're thinking that asking Rigol for this will have some benefit?
IMO, there's no point muddying the waters with things that have basically 0 chance of ever being considered. I mean, there are 'wishes', and there are 'blue sky fantasies'. And I can tell you an 'ancient Chinese secret'
that the longer your laundry list is, the greater the chance that the whole thing will get thrown away, and never looked at.
-
Hmm, two different people posted offset calibration images and on both of them, only ch4 is zeroed out correctly. Coincidence?
-
Seriously?
I have no doubt this would be useful for pickle, and probably others as well. But you're talking about something that no other scope I am aware of has ever had. And you're thinking that asking Rigol for this will have some benefit?
Most, if not all, HP/Agilent/Keysight DSOs seem to support displaying a message to the user via the :SYST:DSP command (it's listed in the programming manuals for the 54100A and DSOX2000 and also works on my old 1650B logic analyser); not sure how common this is with other manufacturers, as it isn't one of the commands required by SCPI as far as I can tell. Some pre-SCPI HP gear also supports similar functionality, so it could just be something HP like to throw in. Don't think I've seen a version with support for response buttons, though...
Although that doesn't take away from your point that the more you ask for, the less likely you are to see even the big things taken care of! -
Some pre-SCPI HP gear also supports similar functionality, so it could just be something HP like to throw in. Don't think I've seen a version with support for response buttons, though...
Yeah, I know for a fact the 3468A multimeter can do this. You can get a response too:Code: [Select]send ("D2HELLO WORLD\r\n");
send ("D2SOME QUESTION\r\n");
send ("D2ANSWR:PRES SRQ\r\n");
send ("D2IN 5 SECONDS\r\n");
pause (5);
if (had_srq ()) ...
send ("D1\r\n");
I suppose you'd have to insert some delay between the lines, or perhaps "press SRQ to scroll"
-
Channel 4 is the only one that looks close to normal on yours.
I don't have a major issue with this, I have other gear. That said will voltage measurements match between channels? My guess would be no not exactly. Could be out by a couple mV.
I'm baffled. In all four screen shots -- from my scope -- all four channels are ON, I took these shots by simply highlighting each channel in turn and hitting PRINT. So if channel 4 looks OK to you it's directly on top of 1,2,3 and hiding those traces. It looks like the firmware turns off the markers if they peak out from underneath another marker by less than a few pixels.
However, I do see what you all are referring too as far as the offset of the channel markers. That looks to only be off by about 1 pixel, maybe 2. That's close enough for me on something with a vertical gain accuracy specified as +/- 4% (below 10mv, +/- 3% otherwise) and an offset accuracy of 1% (which translates to 4.8 pixels). I'd say it more than meets its spec -- on my scope -- other units might not meet the spec, which is why I noted this in the BUGs section at the top of this thread.
-
I'd say it more than meets its spec -- on my scope -- other units might not meet the spec, which is why I noted this in the BUGs section at the top of this thread.
I would say it is not so much an issue of "meeting the spec" as it is an issue of there being no excuses for it to exist in the first place: compute the average (DC) value of no-input noise and subtract it from future ADC input or adjust the analog bias to reduce the ADC input offset and then apply the remainder of the bias error digitally. The visible offset error should be less than 1LSB. -
I haven't noticed that but will keep an eye on it, I may have missed it. The position of the zero marker does change when a cal is done. Even if it comes out wrong, you'd expect it to be the same wrong every time. I've run the cal about 12 times on a well warmed up unit and the variations seem random.
I have a DS2072 that initially did the same thing.
Now I've found that I get the best and most consistent calibration result by running the self cal in an electrically quiet environment (away from computers, LED lamps, etc.) and also tightly covering all of the input BNC connectors with a single piece of aluminum foil (implements a low impedance common ground plane and shield).
-
I would qualify extremely slow CSV export of full memory as a bug. It takes around half an hour! It's not that complex operation to take so long. It should be up to a few times longer than storing to WFM file to account for additional processing, not more.
It is slow to a stick, does work though. -
(...)extremely slow CSV export (...)
It is slow to a stick, does work though.
It sure does, though it's not very useful if you can save two-three files (of 24MSa) per hour. -
- Be able to display a message from software on a PC. Ideally it would also have a Yes / No / Close button attached. I have a background in production testing and was often asked "Why can't I have a message on the scope screen to let me know?".
I've added these.
Seriously? I have no doubt this would be useful for pickle, and probably others as well. But you're talking about something that no other scope I am aware of has ever had. And you're thinking that asking Rigol for this will have some benefit?
IMO, there's no point muddying the waters with things that have basically 0 chance of ever being considered. I mean, there are 'wishes', and there are 'blue sky fantasies'. And I can tell you an 'ancient Chinese secret' that the longer your laundry list is, the greater the chance that the whole thing will get thrown away, and never looked at.
It's unusual but if this scope is targeted at education, new users or training then it's probably worth it. It's a minor change software wise, they will have most of the code in place already.
Just being able to ask a user to wait for a process to complete is a good idea. If you are in a classroom situation you could do walk the student through basic operations. On a repair bench integrate a predefined setup load and include test points. Of course this can be done in software on a pc and force the operator to look at the pc.. Anyway, I do think it's a good idea and a minor effort. -
(...)extremely slow CSV export (...)
It is slow to a stick, does work though.
It sure does, though it's not very useful if you can save two-three files (of 24MSa) per hour.
I've never tried that before, but just did, it's horribly slow. Something around 45 minutes to write a 350MB file. That's around 1/10 of USB 1.1 speed, let alone about USB 2.0. I've added this to the "bugs" section.
-
Has no one mentioned the seemingly non-existent hi-res mode?
-
(...)extremely slow CSV export (...)
It is slow to a stick, does work though.
It sure does, though it's not very useful if you can save two-three files (of 24MSa) per hour.
I've never tried that before, but just did, it's horribly slow. Something around 45 minutes to write a 350MB file. That's around 1/10 of USB 1.1 speed, let alone about USB 2.0. I've added this to the "bugs" section.
To be fair I've seen this before, the large waveform memory exaggerates the issue. -
Most, if not all, HP/Agilent/Keysight DSOs seem to support displaying a message to the user via the :SYST:DSP command (it's listed in the programming manuals for the 54100A and DSOX2000 and also works on my old 1650B logic analyser); not sure how common this is with other manufacturers, as it isn't one of the commands required by SCPI as far as I can tell.
Thanks for the correction.
I was unaware of those capabilities, and it's good to know. It's not an illogical thing to have, and I can see how it would be useful to pickle9000. I've got an older HP logic analyzer I haven't unboxed after a move. I should check to see if it supports it, though I doubt it's something I'd ever use, not being in a production environment.
-
"Why can't I have a message on the scope screen to let me know?"
... Of course this can be done in software on a pc and force the operator to look at the pc.
And you've just identified the main reason not to go to the extra effort. If you're sending SCPI commands from a PC, you've got a PC there. Just put the message on that screen, which will be vastly superior as an interactive display medium, and user-interaction device. -
Top annoyances for me are: decoders working on screen not memory, measurement left on the screen after removal. Actually removal process is convoluted and takes too much time. Proposed On/Off for measurements would save ton of time.
But in addition to that I have something extra.
Flatten trigger menu.
Remove "Setting" option and bring items under that sub-menu to the front. They are all important and frequently used. Lack of any indication of trigger coupling requires unnecessary key press to verify that setting. Bring coupling and holdoff to the front, noise reject can occupy second page.
Scope has nice system of long menus with indicators of currently visible page, use that. This will make it more consistent with channel options that have "two pages" and the rest of the menus. -
Flatten trigger menu.
Remove "Setting" option and bring items under that sub-menu to the front. They are all important and frequently used. Lack of any indication of trigger coupling requires unnecessary key press to verify that setting. Bring coupling and holdoff to the front, noise reject can occupy second page.
Scope has nice system of long menus with indicators of currently visible page, use that. This will make it more consistent with channel options that have "two pages" and the rest of the menus.
These are good suggestions. We've got an on-screen indicator of trigger coupling on the wish list already, item (O) and moving the Coupling to the top level trigger menu as item (P). I've added Holdoff.
-
I had asked Rigol about the Decode working on screen only and was informed the DS1000Z series has very little FPGA space left.
I would assume if that is true they are keeping their Limited resources for bug fixes not features and I would assume they are looking across the whole product line which includes the MS01000Z as well. So while implementing the decode may work on a base DS1000Z the MSO1000Z would run out of space so that makes the feature something that can not be implemented.
From a support POV if this is true it would be a nightmare. If they implemented the better decode on the DS1000Z but did not on the MSO1000Z I know I would be upset because I paid more for scope with LA capabilities so to have the support in the DS but not MSO would upset users so Rigol would be in a bad position. Best stance as a company is to fix bugs but not add features that can not be supported across the whole line of the supported boards.
Thats mine opinion FWIW based on a simple reply from Rigol, take it for what it's worth.
I do say that the decode function is not worth buying if this is the case. -
I had asked Rigol about the Decode working on screen only and was informed the DS1000Z series has very little FPGA space left.
I would assume if that is true they are keeping their Limited resources for bug fixes not features and I would assume they are looking across the whole product line which includes the MS01000Z as well. So while implementing the decode may work on a base DS1000Z the MSO1000Z would run out of space so that makes the feature something that can not be implemented.
From a support POV if this is true it would be a nightmare. If they implemented the better decode on the DS1000Z but did not on the MSO1000Z I know I would be upset because I paid more for scope with LA capabilities so to have the support in the DS but not MSO would upset users so Rigol would be in a bad position. Best stance as a company is to fix bugs but not add features that can not be supported across the whole line of the supported boards.
Thats mine opinion FWIW based on a simple reply from Rigol, take it for what it's worth.
I do say that the decode function is not worth buying if this is the case.
Yikes! I wonder how bad is bad. -
....
I would assume if that is true they are keeping their Limited resources for bug fixes not features and I would assume they are looking across the whole product line which includes the MS01000Z as well. So while implementing the decode may work on a base DS1000Z the MSO1000Z would run out of space so that makes the feature something that can not be implemented.
.....
I do say that the decode function is not worth buying if this is the case.
I think it's fair to say that at least initially Rigol intended for the decode function to work on the entire memory contents as it's in the manual and they have a button for it. Assuming that what they told you is true, that they ran out of room to implement this, they just never got around to changing the manual and removing the button in the firmware. This has put them in a bad position as far as not meeting their advertised expectations. Unless they can find room for this in all models they're not looking too good on this point.
I agree that, as-is, the decode function is of minimum utility and not worth paying for -- it's almost as expensive as a Saleae Logic 8.