AnsweredAssumed Answered

A couple of firmware tweak requests for 6000-series scopes

Question asked by JohnMiles on Oct 26, 2009
Latest reply on Oct 30, 2009 by dnt
I've owned an MSO6054A since earlier this year, and have really appreciated the various feature enhancements that you guys have made available via firmware updates.  The overall experience has been reminiscent of the iPhone... while it wasn't perfect at first, the thing just keeps getting better on its own, often in ways that were never promised up front.  Every time that happens, it reinforces the idea in the customer's mind that he picked the right horse.

So, in that spirit, I've got a couple of hopefully minor enhancements to suggest:

1) Add a Startup message option to Utility->Options->Preferences->More.  This would be on by default to maintain current behavior.  If turned off by the user, the scope will return immediately to its power-down state at bootup, without displaying the "Press and hold Quick Help for help with any key / Available languages / Copyright " message that obscures the trace and forces the user to either wait 30 seconds or touch a control unnecessarily to make it go away. 

If the copyright notice at startup is important, perhaps it could be rendered transparently in a single line near the bottom of the trace window for 30 seconds instead?

2) Roll mode is something I use all the time, and it's one of those (few) features that Tektronix scopes seem to implement more thoughtfully, going all the way back to the 2430A I replaced with this MSO.  A common use case is to run the scope in roll mode for a few minutes waiting for a glitch to appear on some trace(s), then hit the Stop button and use the horizontal timebase and position controls to zoom in on the glitch, without bothering to enter the separate Zoom mode.  This is awkward on the MSO6000s because the Time Ref button on the horizontal menu is hardwired to Right in roll mode, while the user's intuition is to center the glitch before expanding the timebase around it.  Instead, you have to remember to position the glitch at the far right edge of the screen before spanning down. 

It'd be nice if you could allow the user to select Center and Left reference positions in roll mode, just as you do in normal mode.  An easy way to implement this might be to adjust the reference position by either (0|5|10x the previous time/division setting) + (0|5|10x the new one) whenever the user adjusts the time/division setting in roll mode.  The choice of 0, 5, or 10x would depend on whether the reference position is set to Right, Center, or Left, respectively.

That would preserve the current behavior exactly when the reference position is set to Right, and take advantage of the existing position-adjustment and clamping logic in the other modes.  Seems like a reasonable way to implement Tek-style roll mode functionality without requiring too much thinking or regression testing. 

One downside would be that to do it right, you'd need to unpeg the roll-mode trace from the right end of the display, so that any point on it could be brought to center- or left-screen with the Position control even if the trace isn't long enough to fill the screen.  (This seems to happen anyway if you select Zoom mode on a trace that was acquired in Roll mode and then return to Roll mode, although I can't always reproduce it.)  I'd be fine, though, if the scope only made a best effort to automate the scroll-right/change scale/scroll-left activity based on the selected reference position.   The awkwardness of the current behavior is mainly apparent once the user has already zoomed in several levels anyway.

3) In the manual, you might clarify that you lose antialiasing filtering when switching to High Resolution acquisition mode... or in general specify exactly what happens in the acquisition pipeline when this mode is selected.  Aliasing behavior has bitten me a couple of times in High Resolution mode, to the extent that I don't use it much anymore.  Fortunately the Normal mode works really well by itself in most cases.

Thanks for considering these suggestions, and (again) for the great firmware support in general!