New Rigol DS1054Z oscilloscope

[tautech]

Acceleration would be great for trying to get those large value changes though.

That's one of the reasons I think the DS2000 is so nice = acceleration via the navigation knob.  When I was reviewing the Siglent SDS2000 recently, it was driving me crazy every time I had to get through a large selection of numbers via the multifunction knob.... sooo slow... but on the DS2000, just zip right to the end 

Re Multifunction knob, could this be improved with a different unit ie. with a much softer "push to select"?
It seems many DSO's suffer this problem, maybe it is a symptom of just what hardware is available?
The programmed code is another matter, the Chinese are improving and the SDS2000 improvements during the early firmware updates are proof of this.
Hopefully more refinements to come.

[olewales]

Acceleration would be great for trying to get those large value changes though.

"Editor" you get by pressing the knob while adjusting numerical value helps a little, but yeah, adjusting things like holdoff could be way easier.

[marmad]

Re Multifunction knob, could this be improved with a different unit ie. with a much softer "push to select"?

That could make matters worse.

It seems many DSO's suffer this problem, maybe it is a symptom of just what hardware is available?

Having written a lot of code for movement of cursors and selecting, it's definitely something that can be a bit tricky - especially if you want the same knob to be able to move through selections reasonably fast (it's much easier if the movement is always slow). I'm not sure it's possible to get it 100% right for 100% of the people, but it would help matters if the companies allowed you to set the lower sensitivity of the knob to your own taste with a persistent variable (plus acceleration).

Also, as Fungus mentioned, it would be handy if there were more than one way to move the cursor and select.

[ziq8tsi]

When I open up a menu with a lot of selections, scroll down to the one I want... it quite often jumps the the next selection when I press the knob to select it. So annoying.

If I remember correctly, Connor Wolf mentioned exactly that issue in one of his youtube videos about the 1000Z series.

I wonder if Rigol could fix it in software by slightly delaying the response to rotation, and ignoring it when followed immediately by a click.

As an aside, I have a Microsoft Comfort Mouse with exactly the opposite workaround.  It delays reporting clicks of the scroll wheel by 50ms, presumably so software can more easily ignore accidental clicks during scrolling.  This firmware feature badly broke my workflow, because in X11 the scroll wheel click is just the middle button, and it is not uncommon to click or drag with it.  The delay meant I was often clicking or dragging the wrong screen item.  Luckily the PCB had unpopulated footprints for the side buttons of a different model, and the firmware happily reported them, so I was able to bodgewire the scoll click to an undelayed button and then remap it in software.

[rolycat]

I think I hate the multifunction knob.

When I open up a menu with a lot of selections, scroll down to the one I want... it quite often jumps the the next selection when I press the knob to select it. So annoying.

It would be so much nicer if there was a separate "Enter" button, or even if I could just press the same button that opened the menu to close the menu again (selecting the new value, obviously).

Pressing a menu button multiple times should just repeatedly open/close the menu without changing the value.

If you want to go up/down to a new value in the menu by pressing buttons instead of using the multifunction knob you could use the blue up/down arrows, not the button that opened the menu.

There is a way to select menu values without touching the multifunction knob. As you noted, pressing the menu button changes the value. Having done this, pressing either of the light blue up/down buttons selects the new value permanently.

Doing this can have an advantage over using the multifunction knob in that the value takes effect on screen as soon as the menu button is pressed.

For the longer menus you can also spin the multifunction knob to the value above the one you want, press the menu button to select it, and then press an up/down button to implement it permanently. It doesn't work the other way around - if you use the knob after the menu button the up/down button selection jumps back to the value chosen by the menu button.

[Mark_O]

I just remeasured my "upgraded" DS1054Z bandwidth points. I used the amplitude of a 10 MHz sinewave input as my reference level, as I've observed that the amplitude drops by about 1.5 dB at 100 MHz as compared to the level at 10 MHz. I set my Agilent E4436B to deliver a signal that measured 0 dBm at the 50 ohm terminated scope input. I had only Channel 1 active so the scope would sample at 1 GSa/s to ensure the best waveform fidelity. Here are my results:

Frequency      Amplitude
  10 MHz          0.0 dBm
100 MHz         -1.5 dBm
150 MHz         -3.0 dBm
393 MHz        -10.0 dBm
447 MHz        -20.0 dBm

Thanks for taking the time to run the additional tests.  It's much appreciated.   

[Mark_O]

Yes, selecting things with the multifunction knobs on Rigols (and some Siglents also) can be a pain in the ass.

...it helps if you can develop a specific way of holding and turning it when selecting things...

Hey!  I thought Apple had a patent on "You're holding it wrong".

Less facetiously, this is a serious usability problem, that scope manufacturers could solve easily in their firmware. 

[Mark_O]

Frequency      Amplitude
  10 MHz          0.0 dBm
100 MHz         -1.5 dBm
150 MHz         -3.0 dBm
393 MHz        -10.0 dBm
447 MHz        -20.0 dBm

As would be expected, the waveform above 400 MHz became quite distorted (it looked like an amplitude modulated carrier) because of undersampling, but surprisingly, the triggering was rock-solid all the way up. The frequency measurement by the scope was reasonably accurate as well, except that at frequencies above 400 MHz the displayed value jumped around quite a bit.

Not bad performance at all, for a "50 MHz" economy scope.  [emphasis added]

[marmad]

More seriously, this is a serious usability problem, that scope manufacturers could solve easily in their firmware.

I don't agree that it can be 'easily' solved in firmware - or at least, not easily solved for all users all of the time. Every single device I own that is a complex combination of hardware/software buttons has UI mistakes that crop up from time to time (the iPhone jumps selections and misses presses, etc.) - although, granted, perhaps not as often as this; I certainly would agree that it could be better than it is.

[Mark_O]

More seriously, this is a serious usability problem, that scope manufacturers could solve easily in their firmware.

I don't agree that it can be 'easily' solved in firmware - or at least, not easily solved for all users all of the time. Every single device I own that is a complex combination of hardware/software buttons has UI mistakes that crop up from time to time (the iPhone jumps selections and misses presses, etc.) - although, granted, perhaps not as often as this; I certainly would agree that it could be better than it is.

Well, I never said (or meant) for ALL users ALL the time.  I agree that would be a difficult challenge.  (Can you ever please everybody?)  OTOH, I do believe it could be resolved for ALL users MOST of the time.  And even perhaps MOST users ALL the time.      

But we're on the same page as far as potential for radical improvements, that would not be all that hard to achieve.

[marmad]

But we're on the same page as far as potential for radical improvements, that would not be all that hard to achieve.

Radical? I wonder. The fact that it works about exactly the same as it did on the Rigol DS1052E that I used (released in 2008?) and on the newest Siglent seems to indicate that either the Chinese push knobs in a much different fashion than Westerners do - or that they're having problems getting it to work much better than it does.

Personally, I think the idea of pushing a rotating knob to select something which has been highlighted by the rotation is a bad idea to begin with - in a number of different ways. It's both non-intuitive, more physically wearing on the encoder, and harder to code correctly. I'd much rather have a selection button right next to the knob, but it's simply done as a cost/real estate-saving measure.

[rolycat]

Personally, I think the idea of pushing a rotating knob to select something which has been highlighted by the rotation is a bad idea to begin with - in a number of different ways. It's both non-intuitive, more physically wearing on the encoder, and harder to code correctly. I'd much rather have a selection button right next to the knob, but it's simply done as a cost/real estate-saving measure.

At least Rigol offer an alternative selection mechanism on the DS1000Z series.

[Fungus]

Is the issue that it moves when pressing the button, or that it has a delay before reaching its final location.

It moves when you press the knob.

If I wait for it to stop on a selection, then carefully press the button straight on with no rotation, it usually works fine.

"Usually" is not "always". It should be "always".

I'm guessing the problem is that sometimes you stop turning it very close to a threshold point and the tiniest movement can make it jump to the next option.

This is because it's not a knob with indents, yes, but putting in a clicky knob wouldn't totally 'fix' it, it's a broken paradigm (IMHO). It needs a separate button. The most intuitive choice (to me) is to push the same button that opened the menu.

PS: Some people have shaky hands...it must be almost unusable for them.

[Fungus]

Personally, I think the idea of pushing a rotating knob to select something which has been highlighted by the rotation is a bad idea to begin with - in a number of different ways. It's both non-intuitive, more physically wearing on the encoder, and harder to code correctly.

Yep.

I'd much rather have a selection button right next to the knob, but it's simply done as a cost/real estate-saving measure.

I've already mentioned ways to do it better... but how about that great big "Clear" button right above the multifunction knob? It would make a great "Enter" button with no extra hardware cost (just a firmware change - make it act as "Enter" whenever a menu is open).

FWIW: I don't think I've actually pushed the "clear" button yet. Is the "Clear" function really useful enough to be chosen for the 'first' (ie. top-left) button on the device? The waveform already clears when you press "Single" and I'm sure the "clear" function could be moved into each channel's soft menu with no loss of function (Just press the channel button then "Clear" in the side menu).

[rolycat]

The most intuitive choice (to me) is to push the same button that opened the menu.

I agree, but the Rigol UI designer(s) may have thought that that clashed with the toggle effect when a menu item has only two options.

Thus they chose pressing the menu button to change the setting and pressing the up/down buttons to select it permanently. It's back to front, but at least it works and avoids using the knob.

[Fungus]

Thus they chose pressing the menu button to change the setting and pressing the up/down buttons to select it permanently. It's back to front, but at least it works and avoids using the knob.

"Chose"?

I don't think that method is intentional ... I think they made a crap design and you just figured out a way to beat the system.

[tautech]

Is the issue that it moves when pressing the button, or that it has a delay before reaching its final location.

It moves when you press the knob.

If I wait for it to stop on a selection, then carefully press the button straight on with no rotation, it usually works fine.

"Usually" is not "always". It should be "always".

I'm guessing the problem is that sometimes you stop turning it very close to a threshold point and the tiniest movement can make it jump to the next option.

This is because it's not a knob with indents, yes, but putting in a clicky knob wouldn't totally 'fix' it, it's a broken paradigm (IMHO). It needs a separate button. The most intuitive choice (to me) is to push the same button that opened the menu.

PS: Some people have shaky hands...it must be almost unusable for them.

Sounds like a detented encoder like in the Siglent SDS2000 is needed.
While they are not the perfect fix, with good code they are quite usable.
Just don't expect perfection and manufacturers should not attempt to do EVERYTHING with one.
Surprising that detented type was not included with all the frustration that multifunction knobs create and is vented in this forum.

So does the famous Rigol knob swap still survive? 
Some Siglent models use it too. 

[poida_pie]

Fungus: ". but how about that great big "Clear" button right above the multifunction knob? It would make a great "Enter" button with no extra hardware cost (just a firmware change - make it act as "Enter" whenever a menu is open)."

YES! THIS PLEASE.
It must be simple to change the firmware to permit this function to be enabled/disabled via some system setting
in a future firmware update.
Please Rigol, can you do this?

The multi-function knob on my DS2072 works in accordance to specifications but there are times when you want to pick up
the DSO and throw it against a wall when it tediously continues to pick the next option - not the selected one.
Marmad's technique is not a complete fix, it merely reduces the annoyance to some degree. Not still tolerable by my measure.
With an <enter> button there will be no mistaking the user's intent.


 

[Fungus]

Fungus: ". but how about that great big "Clear" button right above the multifunction knob? It would make a great "Enter" button with no extra hardware cost (just a firmware change - make it act as "Enter" whenever a menu is open)."

YES! THIS PLEASE.
It must be simple to change the firmware to permit this function to be enabled/disabled via some system setting
in a future firmware update.
Please Rigol, can you do this?

There's no excuse:

The multifunction knob already acts differently when a menu is open so a function to test if a menu is open already exists in the firmware.

I bet this change could be done in five minutes + half a dozen lines of code.

[ragerino]

Be aware that the Meilhaus availability status is not correct!

Meilhaus contacted me this morning to let me know that they are on backorder and i will receive my Oszilloscope at begin of November. I checked on their homepage and they are still showing the status as green icon.

The place I got mine from is already posting ">21 days" delivery time on their front page.

http://www.batronix.com/shop/oscilloscopes/Rigol-DS1054Z.html

Meilhaus has them on stock: http://www.meilhaus.de/en/rigol+ds1054z.htm

[DanielS]

Sounds like a detented encoder like in the Siglent SDS2000 is needed.

It is not really needed: you simply need to code a dead-zone in the software to ignore movement below a certain speed or require a minimum amount of movement after the last stop before accepting movement again.

[godFather89]

Dave hasn't got his scope yet?

[David Hess]

Sounds like a detented encoder like in the Siglent SDS2000 is needed.

It is not really needed: you simply need to code a dead-zone in the software to ignore movement below a certain speed or require a minimum amount of movement after the last stop before accepting movement again.

I have seen other instruments which apparently did something like this because they do not suffer from this problem even without detents.  The ancient Tektronix 2232 has a momentary push rotary control and uses variable programmed hysteresis in the rotation which is both very simple and very effective.  If I try, I cannot even make it glitch.

[Fungus]

Sounds like a detented encoder like in the Siglent SDS2000 is needed.

It is not really needed: you simply need to code a dead-zone in the software to ignore movement below a certain speed or require a minimum amount of movement after the last stop before accepting movement again.

Much better to fix the underlying problem than fiddle around fine tuning the percentage of times it happens to people.

It's not as if there's a shortage of buttons to choose from...

[marmad]

Sounds like a detented encoder like in the Siglent SDS2000 is needed.

@tautech - I'm not sure what you're referring to. Unless Siglent has changed their production of the SDS series since my recent review, the universal (multifunction) knob is NON-indented, and suffers from the same problem as the Rigol. In fact, it might be a little worse on the Siglent because of the wobble in the encoder shaft, which is lacking on the Rigol.

It is not really needed: you simply need to code a dead-zone in the software to ignore movement below a certain speed or require a minimum amount of movement after the last stop before accepting movement again.

This introduces a stutter or lag in the movement when moving slowly, slowing down, speeding up, etc. - perhaps better, but also not an ideal solution.

The ancient Tektronix 2232 has a momentary push rotary control and uses variable programmed hysteresis in the rotation which is both very simple and very effective.  If I try, I cannot even make it glitch.

Well, we'll just have to accept your claim that the Tek knob is impossible to glitch, with smooth movement over all speeds it can possibly be turned at. Nevertheless, from a UI point of view, having to push something which rotates (except for the simplest toggling - e.g. coarse/fine) is a stupid idea on many levels and should be dropped completely from design.