GDS-1054B -- initial observations

[kcbrown]

I just recently acquired an Instek GDS-1054B.  At less than $300 with the EEVblog discount from tequipment.net, this was impossible for me to pass up.

While I already own a Siglent SDS-2104X+ and a Siglent SDS-1204X-E, I was immensely curious as to the responsiveness of the UI for this instrument, plus the way you set it up to display signals versus what it acquires is quite different from the Siglent.  At this price, I thought it would make for an excellent replacement of my hacked Rigol DS-1054Z.

And finally, I was curious about the vaunted quality of the firmware, primarily as claimed by @nctnico.


Well, it may be that all of the basic functions work properly.  I haven't managed to test all of that and probably won't be able to for quite some time.  My initial focus was on playing around with the scope and experiencing its responsiveness.

It is incredibly responsive ... immediately after powerup.  And if you leave it alone, or do minor things with it, it'll remain responsive.

But as you start twiddling things like the acquisition length, enabling and disabling the bus, enabling and disabling the FFT, etc., the UI will eventually get slower.  And slower.  And slower.  Until it gets to the point where it lags so badly that it will stop responding to button presses (e.g., the run/stop button).   At first, you'll see little pauses here and there in the display update.  And they'll get worse and worse as you continue to operate the UI to change things like what I mentioned.  It may be that this is specific to changes in the acquisition length.  I'll have to play with it some more to see if I can narrow down the source of the slowdowns to something specific like that.

This clearly isn't a hardware issue.  Hardware just doesn't behave this way, at least that I've ever experienced.  But software does.  The scope is behaving as if it's failing to properly manage its internal memory in such a way as to retain its responsiveness, or something like that.  If changing the acquisition length is the primary thing that is causing or providing an initial trigger for this behavior, then it would certainly be a memory management problem.  Languages that perform automatic garbage collection are known to cause behavior such as this, though they eventually stabilize.  This seems worse in that it gets progressively worse until it gets to the point where I'm better off restarting the scope.  When I do so, the scope comes back up exactly as I left it, but is suddenly enormously responsive.

When the scope is responsive in the way it tends to be when you first turn it on, it's a real joy to use.  Neither the Siglent line nor the Rigol line compare, at least that I've ever seen or experienced.  Even the SDS-1204X-E isn't this responsive.  Since the hardware in question is roughly the same as what is in use in Siglent's current line, it would appear that Siglent could learn a thing or two about UI responsiveness from Instek.   It proves my assertion that there is no excuse for a laggy UI when you've got a Zync processor/FPGA at your disposal.

But my initial experience also suggests that Instek's firmware is not the paragon of stability and quality that @nctnico claims it to be, even though this scope has been in production for several years (I'm using version 1.28 of the firmware, which is what came with the scope).  And note, too, that it's not just UI slowdowns that I've managed to cause in my brief time with this scope.  Within 15 minutes of playing with it, I managed to crash the scope hard, causing the screen to go blank and forcing a power cycle.  What did I do?  I had enabled the FFT, and then hit the "advanced math" button under the "math" menu.

I had already tried using "default" and had reproduced the lag issue after that.  I've since cleared the memory of the scope and hit the "default" button again, and will play with it some more.   It may that these latest actions are sufficient to make the issues I've seen disappear permanently, in which case it'd be hard to fault the firmware, since all software depends on starting from a known-good state.  And that would make this initial post a lesson to those who acquire this scope that the first thing they should do is clear the memory and hit the "defaults" button to put the scope into a known good state.

We'll see.  Meanwhile, I'm incredibly impressed with the responsiveness of this thing when it's behaving itself.

[kcbrown]

I've managed to reproduce the issue one more time.  This time, I did so by switching to advanced math from the FFT.  Rather than crashing the scope, the UI became unbearably slow.

But I haven't been able to reproduce it since.  So whatever's going on here, it's not obvious what steps are necessary to induce it.

I tend to leave my equipment running 24x7, and this scope will be no exception.  So it'll be interesting to see what the long-term stability of the UI is.

[tautech]

Would UI responsiveness between brands when using the same processor be related to vastly different waveform update rates ?
Design tradeoffs ?

[kcbrown]

Would UI responsiveness between brands when using the same processor be related to vastly different waveform update rates ?
Design tradeoffs ?

From a programming perspective, not as much as one might think.  It's more about how you interleave the two things and how you use the CPU in the first place.  There may be some design tradeoffs (in fact, I'm sure there are), and those can affect the outcome.  But from what I've seen, the general approach seems to be to avoid such tradeoffs in the first place.  See below.

How you use the FPGA greatly influences the end result, of course.  As a general rule, if you can do something faster in the FPGA, you should do it in the FPGA.  But beyond that, there's the question of whether you continue to perform captures while the UI is being manipulated.  If you do continue to perform captures while the UI is being manipulated, then absolutely you have tradeoffs unless you've got so much horsepower at your disposal that you just don't know what to do with it all.   

For the Siglent, at least, manipulating the UI does seem to cause the scope to temporarily suspend captures, which means that any tradeoffs that might otherwise have affected the UI responsiveness have just gone out the window.  That's why I say that for the Siglent, there's really no good reason for the UI to not be completely responsive -- it's not doing anything else to speak of, at least that the user can see, either while the UI is being manipulated or even afterwards.  This is evidence by the fact that it clears the history immediately upon re-starting acquisition, so in light of that, there's no good reason whatsoever for it to be doing anything while the UI is being manipulated (well, more precisely, while the user is manipulating the waveform, e.g. by moving it, changing the timebase, etc.), since manipulation of at least certain portions of the UI cause the scope to throw away everything until acquisition is restarted, which doesn't happen until it detects that the user has stopped manipulating the waveform/UI.  This means the entire power of the CPU can be used for the purpose of handling the UI and displaying the results of the changes being made therein, until the user has stopped for some amount of time (like, say, a tenth of a second -- getting that value right is crucial).  The UI should be BUTTER smooth in light of that.

When you manipulate the UI on the Instek, it also appears to suspend captures for at least some amount of time.  But this is based only on seeing what it does with the displayed waveform -- it might be continuing to perform captures behind the scenes.  The only way I'd know that is with the segmented memory feature enabled, but that's not yet present on my scope, and I don't intend to enable it until I've had the scope for at least 30 days, in case I have to perform a warranty exchange.  However, my bet is that it does in fact stop acquisition until the user has finished manipulating it.  Absent a hardware-based implementation like what the Keysight uses, and absent some very careful multithreaded programming, stopping all background processing so that the UI can be butter smooth is perhaps the only effective way to give the user a very pleasant experience.

The Zynq-7000 has a dual-core processor.  It might be possible, through careful use of that, to provide a butter-smooth UI without having to stop acquisition at all.  With all of the things the scope has to do, it would have to be managed carefully, with the work divided between the cores very carefully.  It's not an easy job at all.  But from what I've seen of computer user interfaces over the years, on hardware much less capable than what's in these scopes today, I have a hard time believing that it's not possible.

As usual, of course, I'm willing to be educated otherwise, and in fact would love to have that conversation, because I'm always looking to learn.

I will say this: while the Siglent isn't butter smooth when you're manipulating the UI, it is usable under at least most circumstances (this is especially true for the SDS-1000X-E series, but is also true of the 2000X+).  I fully expected that, after having used the Instek and it's instantly-responsive UI, I would find the Siglent unpleasant to use.  But that hasn't been the case at all, and that actually took me by surprise somewhat.   I do think Siglent should make the UI as responsive as possible, and given the fact that they're stopping all acquisition anyway, they may as well make it butter smooth.  But it's not necessarily the best place to put engineering effort.

Seems to me that what these scopes could use is a good GPU.  That could even be used to good effect for some of the background processing that the scope does, that is currently being performed by the CPU.  With that, combined with a dual-processor Zynq, it seems to me that it certainly should be possible to maintain full capture and processing while the UI is being manipulated, without any visual indication that there's any kind of slowdown at all.  Remember that the screen really just needs to be updated 30 times per second (of course, 60 times per second would be better).  For the hardware in these scope, and really for any kind of computing hardware in the last 20 years, 30 milliseconds is an eternity.

[nctnico]

I've managed to reproduce the issue one more time.  This time, I did so by switching to advanced math from the FFT.  Rather than crashing the scope, the UI became unbearably slow.

But I haven't been able to reproduce it since.  So whatever's going on here, it's not obvious what steps are necessary to induce it.

I recall having a few slow downs as well on my GDS-2204E (which runs more or less the same firmware) and IIRC these also had to do with switching between FFT and math modes but it hasn't bothered me to the point where I reported it to GW Instek.

[YurkshireLad]

Have these slowdown issues been fixed in a newer firmware version?

[kcbrown]

I haven't seen the issues I originally reported since.  While this isn't my primary scope (that role goes to my SDS-2104X+), I do manipulate it often enough that I'd have expected to see something if the issue I saw were pervasive.

At this point I'll have to chalk it up to an initialization issue.  Of course, in an ideal world, such things shouldn't be a problem.  But nobody's perfect, and I can understand how problems may arise if the initial state of the scope isn't something that was anticipated (how it got that way in the first place is anyone's guess).

I'm still on firmware version 1.28.  I see Instek has version 1.29 out now.  The release notes show only that they added a couple of languages.  There is no mention of any bug fixes.  So there's no compelling reason for me to upgrade.