SDS800X HD Wanted Features

[eTobey]

Anyways I thank you for being a decent human being that wants to "sort it out". I think you took upon yourself a large burden of herding cats here....

Seemingly a useless effort, as some will never change...

[eTobey]

I suggest a better layout for the Input pad:
The enter button is so far away... And the other buttons can be closer too, and even bigger. All buttons can be bigger too, in my opinion. Clear is not really needed, as the number is already selected, and you just type in the new value ( I am thankful, that this little feature is already implemented!).


If you think this is too much, then please just move the enter button! It is quite annoying to move over there. But hitting max by accident will make your day even harder.

[tautech]

I suggest a better layout for the Input pad:
The enter button is so far away...

Rarely used as after selecting a unit denominator the virtual keypad is auto exited.

[eTobey]

Rarely used as after selecting a unit denominator the virtual keypad is auto exited.

Yes, you're right. But when changing only a few digits and then hitting the wrong unit is not so pleasant to work with, especially if you do not notice your little mistake. I would use that enter button when i would just change a few digits.

Bigger buttons overall would help a lot.

[Omega Glory]

[Bug With SCPI Trigger and Wave Capture Commands]

When issuing SCPI commands via USB to an SDS814X, I am running into what appears to be a firmware issue involving single capture triggering, and retrieving the waveform data.

I can set the scope to single capture by issuing: "TRIG:MODE SING", but then when it comes time to retrieve the data by issuing "WAV:DATA?", while I'm able to capture data, it puts the scope back into RUN mode. This worries me because sometimes waveforms have to be transferred over with multiple calls to "WAV:DATA?" depending on how many sample points there are, and I worry that since the scope gets flipped into run mode, I might actually be retrieving chunks from different captures. Even if it is all coming from one capture, it doesn't seem like issuing "WAV:DATA?" should put the scope back into run mode.

Has anyone else encountered this problem?

[electronics hobbyist]

I suggest a better layout for the Input pad:
The enter button is so far away... And the other buttons can be closer too, and even bigger. All buttons can be bigger too, in my opinion. Clear is not really needed, as the number is already selected, and you just type in the new value ( I am thankful, that this little feature is already implemented!).


If you think this is too much, then please just move the enter button! It is quite annoying to move over there. But hitting max by accident will make your day even harder.

From the perspective of reducing movement distance and minimizing accidental clicks on "Max", this suggestion is reasonable.
For example, if I input 10V, I would click on 1, 0, and "Enter". If "Enter" is closer, it would be more efficient.

Added to Wanted Feature No.29

[electronics hobbyist]

[Bug With SCPI Trigger and Wave Capture Commands]

When issuing SCPI commands via USB to an SDS814X, I am running into what appears to be a firmware issue involving single capture triggering, and retrieving the waveform data.

I can set the scope to single capture by issuing: "TRIG:MODE SING", but then when it comes time to retrieve the data by issuing "WAV:DATA?", while I'm able to capture data, it puts the scope back into RUN mode. This worries me because sometimes waveforms have to be transferred over with multiple calls to "WAV:DATA?" depending on how many sample points there are, and I worry that since the scope gets flipped into run mode, I might actually be retrieving chunks from different captures. Even if it is all coming from one capture, it doesn't seem like issuing "WAV:DATA?" should put the scope back into run mode.

Has anyone else encountered this problem?

If you send a "TRIG:MODE SING", it will stop if triggered. After stopping, sending the "WAV: DATA?" command will not back into run mode. My software version is 1.1.3.3;
Can you describe the order of commands you execute and the settings of the oscilloscope?

[eTobey]

Good morning!

From the perspective of reducing movement distance and minimizing accidental clicks on "Max", this suggestion is reasonable.
For example, if I input 10V, I would click on 1, 0, and "Enter". If "Enter" is closer, it would be more efficient.

Added to Wanted Feature No.29

You may want to change the text to "optimize input pad", as moving the enter button is not the only thing that can be optimized. Bigger buttens will help a lot. Also a margin is needed (see picture). Column A and Columns B could be switched too, as the units would probaby be  more frequently used.

This suggestion can be combined with the keyboard suggestion of "optimization".

[eTobey]

Pushing horizontal knob in zoom mode causes double push?

It might be a physical issue, but worth to test if others have the same problem:
- When in zoom modus, pushing the horizontal knob causes a switch from one window to the other (as is excpected), but then (quite often) immediately back to the original window.
There is a 128us pwm 50% duty signal on CH4!

Bug debouncing issue:
The two big knobs have a bouncing issue. I could confirm this with the hardware self test.  The small knobs also have a debouncing issue, but this is not as bad as the big ones.

The issue apears about every 3 to 8 pushes!

[ebastler]

Bug debouncing issue:
The two big knobs have a bouncing issue. I could confirm this with the hardware self test.  Havent tested the other knobs, but they seem to not bounce as bad at least.

That occurs on my unit too: Both knobs (horizontal and vertical scale) do occasionally bounce when pushed. Not very often, but when it does happen it's irritating, since you don't land in the mode you expected to. It would be good if Siglent can improve the debouncing algorithm for those knobs in an upcoming firmware release.

Interestingly, the universal knob -- the only other one which can have toggle functionality, e.g. when controlling the cursors -- does not bounce at all. Maybe I got lucky with that encoder; maybe it's a different encoder type (no detents on this one); or maybe it uses a different debouncing algorithm?

[eTobey]

... - the only other one which can have toggle functionality, e.g. when controlling the cursors -- does not bounce at all. Maybe I got lucky with that encoder; maybe it's a different encoder type (no detents on this one); or maybe it uses a different debouncing algorithm?

Nope, it has the same issue (i edited my post). Physical differences i guess. Needs a tweak for sure!

[eTobey]

Suggestion:
- When in zoom modus:
- having the big window ativated for horizontal scrolling:
Horizontal scrolling a long way takes a lot of turns. There is some kind of acceleration algorithm in place, but that needs to be increased.

As an alternative, that i think is even better:
The little zoomwindow that shows the extends of the big window needs a invisible, minmum size, drag button, so you would not miss it when trying to drag it. (see picture)

[ebastler]

Horizontal scrolling a long way takes a lot of turns. There is some kind of acceleration algorithm in place, but that needs to be increased.

You can use the mouse to drag the little "you are here" frame in the upper window directly to the desired position. That's very quick, and I find it more convenient becaue it gives me absolute positioning vs. the relative movement provided by the encoder knob. You can still use the encoder for fine adjustments afterwards, of course.

(Using the touch screen instead of the mouse also works. But it is easier to miss the little frame and end up dragging the upper trace sideways instead. Also, for some reason the frame does not follow in real time when I drag it with my finger -- it does when I do the same with the mouse, giving better feedback and faster positioning.)

[Performa01]

This would also be a perfect occasion to explore the Navigate (time) feature...

The SDS800X HD even has the physical buttons for navigating, derived from its non-touch ancestor.

[eTobey]

(Using the touch screen instead of the mouse also works. But it is easier to miss the little frame and end up dragging the upper trace sideways instead. Also, for some reason the frame does not follow in real time when I drag it with my finger -- it does when I do the same with the mouse, giving better feedback and faster positioning.)

Yes i have discoverd that feature, but you found the issues with this workaround... Also i dont really want to use the mouse. There is enough stuff on the table already. But i have just another idea (solution): If that window is small, there can be a minum (invisible) drag button size, so you wont miss that window.

I have edited my original post with your input.

This would also be a perfect occasion to explore the Navigate (time) feature...

I made a quick exploration. You could play a little game here, quick scroll, and try to land on the spot with the stop button. 

[ebastler]

(Using the touch screen instead of the mouse also works. But it is easier to miss the little frame and end up dragging the upper trace sideways instead. Also, for some reason the frame does not follow in real time when I drag it with my finger -- it does when I do the same with the mouse, giving better feedback and faster positioning.)

Yes i have discoverd that feature, but you found the issues with this workaround... Also i dont really want to use the mouse. There is enough stuff on the table already.

Just discovered yet another way to quickly get around: In the upper trace, double-tap at the desired time point, and the magnified view will be positioned there right away! 

Edit: That trick is actually described in the user manual, section 14. I am wondering whether there are any further double-tap actions in the UI? The manual does not mention any others; at least a seach for "double" finds only the one hit. I'll have to play around some...

[ebastler]

This would also be a perfect occasion to explore the Navigate (time) feature...
The SDS800X HD even has the physical buttons for navigating, derived from its non-touch ancestor.

I'm not sure I "get" time-based navigation:

• If I open the navigation dialog and control the time via the universal knob, that's identical to using the horizontal position encoder, right? And the horizontal position knob is always there and has a dedicated function, so I much prefer using that.

• When I use the front panel buttons, the only mode of operation seems to be "continuous movement until stopped". There may be uses for this to replay a captured trace in a kind of roll mode, but I have not come across a need for that yet. For my taste the ability to step back and forth in discrete steps, one step ber button push as offered in History Frame mode, would be more useful. But that seems unavailable in time-based mode?

Is there yet another way of using time-based navigation which I have missed?

[eTobey]

Just discovered yet another way to quickly get around: In the upper trace, double-tap at the desired time point, and the magnified view will be positioned there right away! 

That is a kinda nice feature. But it has its drawbacks:
- You have to aim very good
- if you want to fine adjust, you have to switch back to the big window, otherwise you would move the trigger point.

I find that speed-up algorithm from those knobs very good, it just has to be adjusted for this function.

[eTobey]

Wrong and redundant numbers:
See pictures....

[eTobey]

It might be a less important issue, but i post this anyway for future analysis...

Slow response in zoom modus:
When moving the little zoom window in the upper zoom window, there is a lagging. When moving it a lot, i accumulates to a few seconds. Other functions (menu presses on screen) are delayed because of it.

Restarting the scope did not help.

[Performa01]

Is there yet another way of using time-based navigation which I have missed?

You are right: we don’t need Navigate anymore, because there are multiple methods to position the zoom window – some of them you’ve already discovered. Yet it cannot hurt to recall the methods without touch:

Back when we didn't have touch screens - and encoder acceleration generally didn't work so well on top of that, twiddling the time base knob absolutely wasn't an option when positioning a zoom window at high zoom factors. It would have taken forever - and it still does today. So, navigation was one of only two feasible ways to position the zoom window:

1.) start with a low zoom factor, do a coarse positioning and then increase the zoom factor, do a fine(r) positioning, repeat the last two steps if required.

2.) Use time navigate. The direction buttons act as automatic knob twiddlers with three different speeds, where the highest speed is very suitable for coarse positioning, because even with a very high zoom factor like one million, it takes only some 12 seconds to go from one end of the record to the other.

That was our best bet without touch interface.

Nowadays we can quickly enter the required delay in the time field of the Navigate function, which was a tedious task with the old instruments, where the numeric input field had to be operated by the universal control.

Yet as mentioned right at the start, with the touch-UI we don’t need Time Navigate anymore because now we have the zoom tab which we can touch and set the delay directly.

Yes, there are several occasions where we want to enter numerical values directly, namely:

1. When we need high precision and the desired value cannot be reached via the encoder. This usually isn’t an issue with vertical gain and horizontal time base settings, but might happen for FFT or Bode Plot applications.

2. When we need a big jump to set a completely different value – for parameters that cover an exceptional wide range with very high resolution. Setting the time base delay is an example, even more so for the zoom time base, where we can have 10 million zoom factor (20 ms and 2 ns per division), and the delay can be anything from 20 ps up to 200 ms with 20 ps resolution. Twiddling a knob certainly isn’t the method of choice in such situations.

[eTobey]

enter the required delay in the time field of the Navigate function

But how often do we actually know the required delay? I guess not so often?

That lagging in the zoom function currently renders it kinda usless (its pretty bad sometimes). Have you encountered this behaviour?

[eTobey]

Issue:
Moving the waveform to a desired position does not work.
It can only be moved, until the triggerposition leaves the right side of the screen. This issue it not observed when moving it to other side.

Edit: Found out, that this is only the case, when it is in run state. It does not exist when in stop mode.
If it is a valid acquire limit issue or similar, then it should read like "Can not go beyond this point in run mode".

[ebastler]

Issue:
Moving the waveform to a desired position does not work.
It can only be moved, until the triggerposition leaves the right side of the screen. This issue it not observed when moving it to other side.

I believe there is a technical reason for that. To show you that part of the waveform before the trigger actually occurs, the scope will have to fill a pre-trigger buffer -- speculatively, since it does not know whether and when a trigger will actually follow. The size of that pre-trigger buffer is limited, and hence the amount by which you can shift the waveform to the right is limited too.

[hallkbrdz]

Bug (IMHO): A user setting of a probe multiplier is not restored between sessions. It does remember what you used last when you select user, but then the vertical scaling is off until you change that.

I'd really like it to just remember and restore the setting between sessions as it's a pain to keep setting it for the hvdp channel.