Products > Test Equipment

REVIEW - Rigol DS2072 - First Impressions of the DS2000 series from Rigol

<< < (396/566) > >>

Mark_O:

--- Quote from: PA0PBZ on December 22, 2013, 09:27:15 am ---
--- Quote from: Teneyes on December 22, 2013, 06:43:21 am ---I am suggesting the amount of rotation to jump to the next selection be a bit larger...

--- End quote ---

No matter how large they make the amount of rotation it can always be just on the edge when you press the button, so I think it would make more sense to solve this in the software, like ignoring a turn when it happens less than 100ms before a push or something like that.

--- End quote ---

Since it has no way to see into the future (needs faster FPGAs for that :) ) to determine that a push is about to occur, that means it will delay all turn reactions for that same interval.  Aka, "is this a real turn, or an accidental turn while clicking?"

The response from users will then be... "Why is this d@mn thing so laggy?  The responsiveness to the knobs is poor."

JDubU:

--- Quote from: Mark_O on December 24, 2013, 12:51:35 am ---Since it has no way to see into the future (needs faster FPGAs for that :) ) to determine that a push is about to occur, that means it will delay all turn reactions for that same interval.  Aka, "is this a real turn, or an accidental turn while clicking?"

The response from users will then be... "Why is this d@mn thing so laggy?  The responsiveness to the knobs is poor."

--- End quote ---

You don't need to delay the response to the knob rotation.
Keep a short FIFO buffer of knob position, sampled every tenth of a second or so while the menu selection is exposed.
When the push occurs, use the position sample that was first stored a half a second ago.
This would ignore any movement of the knob that occurred in the previous half second but the knob rotation would continuously highlight the appropriate menu item without any lag.

Jason:

--- Quote from: Mark_O on December 24, 2013, 12:51:35 am ---
--- Quote from: PA0PBZ on December 22, 2013, 09:27:15 am ---No matter how large they make the amount of rotation it can always be just on the edge when you press the button, so I think it would make more sense to solve this in the software, like ignoring a turn when it happens less than 100ms before a push or something like that.

--- End quote ---

Since it has no way to see into the future (needs faster FPGAs for that :) ) to determine that a push is about to occur, that means it will delay all turn reactions for that same interval.  Aka, "is this a real turn, or an accidental turn while clicking?"

The response from users will then be... "Why is this d@mn thing so laggy?  The responsiveness to the knobs is poor."

--- End quote ---

Here's a better algorithm:  Reset the hysteresis if the knob has stopped moving for 50ms.  In other words, when you pause for a moment it sets a small dead zone and it ignores the spin until you turn 3 degrees in either direction.  This means that after you pause and see that you're on the the correct menu item it won't be right on the edge; clicks are registered instantly; and there's no perceptible spin lag (it starts moving within 3 degrees of rotation and stops immediately).

I desperately wish they'd fix the stupid knobs.  I can't tell you how many times I've tried to spin the horizontal offset to 6.0000ms, going as slow as possible and watching it go:  5.900, 5.9200, 5.9400, 5.9600, 5.9800, 6.2400.  20% of my menu selections miss no matter how careful I am.  This is by far the biggest usability problem I've had with my scope.

Wim13:
Did some testing with the new FW, and updated my Bandwidth chart.

There is not much more bandwidth on a 2072 with option 300 Mhz, the entry
of the 2072 , the non A models, dont get 300 Mhz, mine goes to 280 Mhz.
The lack of a internal 50 ohm terminator...

Also got more noise, see picture with only 1 channel, and then enable channel 2,
the difference is clear, on 1 nS the sample rate is to low for two channels.
The performance is worse on 1 nS then on 2 nS.

I did the test with the DSGH key, see option picture.

So the advantage of the new bandwidth option is not big for the non A models.
You are better off with the 200 Mhz version. So use the DSEZ key for better performance.

Edit 25/12: the key for CAN and 2202, is DSEZ, E for Can and Z for options + 200 Mhz.

Picture of the FFT i added, because i notice better function of the FFT after upgrading to version 2
The FFT function are much better to operate with the new FW.

So my DS2000, is just on the edge of 300 Mhz, on the post pictures below of EV, you an see the
litttle differences between two models, just a few dB, can also be the tolerances in the signal generators.
Normaly a tolerance off 1 dB is normal.

Marmad already stated a few posts back, the non A models where not good enough for 300 Mhz.
they had to modify the entry in the A models.


All measurements are done with the same 2072 and hardware version 1.0.1.0.0

Kobus:
Maybe I am missing something obvious. Is there some quick way to remove measurements from the bottom of the screen.
There are dedicated buttons for adding measurements but I cant find a quick way to clear them.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod