SDS800X HD Wanted Features

[2N3055]

And in measurements you also have CH Delay page... For inter-channel measurements.

Lots to play with. But for now, i stay a cursor fanboy. I like to see what i actually measure.

I have more good news for you.

You still use measurements, and enable cursors, but enable Measurement cursors.
Those follow automatic measurements and show where is measurement performed at...

It is basically reverse direction.. Instead of numbers following cursors position, this is cursor position showing you where it is measured. This is what you use to verify measurement is done where you like it to be...

[ebastler]

I have more good news for you.

You still use measurements, and enable cursors, but enable Measurement cursors.
Those follow automatic measurements and show where is measurement performed at...

Maybe we should rename the thread into "Bugs/Wanted/Available Features".

But yes, those advanced cursor options might be the improvement I enjoy most, compared to my old DS1000Z. Distances and positions shown right next to the manual cursors (and the UI is pretty smart in choosing the location); cursors to gate the measurement window; cursors showing me where automatic measurements are taken -- maybe these are not the most fundamental improvements, but they actually make me smile when I use them.

[eTobey]

Yes, that should work. Note that setting up a measurement in advanced mode is a bit finicky:

I really do like my cursors 

Edit: That actually appears to be a little glitch in the UI. There are nice explanatory texts for each measurement item. But there is no way to see them without actually selecting that item (before you see its explanation) and auto-closing the dialog. Well, you can re-open the dialog afterwards, to see explained what you just did...

Go into the menu, hit "type" and it wont close it. I guess selecting the "+" and then having the menu closed is expected behaviour, as it speeds up things.

[eTobey]

I have more good news for you.

That is awesome.

I stumbled upon an issue:
Switching from percent to count in the histogram window is sometimes quite unresponsive. First i thought i had to really hit the dot, but its not the case. It works for a few seconds, then it wont, then it works again. Without doing anything to it.

Find attached the setupfile.

The checkbox for percent and count in the histogram window are to small, and easily missed. Not just once in a while, but sometimes you miss them 2 times in a row. At least i do, and i am not drunk, nor do i have fat fingers. 

[2N3055]

I have more good news for you.

That is awesome.

I stumbled upon an issue:
Switching from percent to count in the histogram window is sometimes quite unresponsive. First i thought i had to really hit the dot, but its not the case. It works for a few seconds, then it wont, then it works again. Without doing anything to it.

Find attached the setupfile.

I will check but  it might not be unresponsive but recalculating......
But will check and if something is fishy will be reported...

[eTobey]

I will check but  it might not be unresponsive but recalculating......
But will check and if something is fishy will be reported...

Save your time:
I just found out, that it is just hard to hit! That needs a bit of tweaking id say. Because i am not drunk, und i dont have big fingers. Still i fail quite a lot in hitting those.

[eTobey]

Suggestion:
Restart/continue mask test when hitting run/stop.
An inactive operation is easily missed after it has been stopped from a fail. Hitting the run/stop button alone does not restart the fail test. No indication visible.

[2N3055]

I will check but  it might not be unresponsive but recalculating......
But will check and if something is fishy will be reported...

Save your time:
I just found out, that it is just hard to hit! That needs a bit of tweaking id say. Because i am not drunk, und i dont have big fingers. Still i fail quite a lot in hitting those.

Yeah they are kinda hard to hit right.  If I put my hand on top of scope and press them with a thumb then it works every time...

I will report that maybe target area is small.. Maybe an artefact of scaling down to small screen. On my bigger screen scopes it is flawless.

[2N3055]

Suggestion:
Restart/continue mask test when hitting run/stop.
An inactive operation is easily missed after it has been stopped from a fail. Hitting the run/stop button alone does not restart the fail test. No indication visible.

In mask test you have option Display info.
When that is enabled you see pass/fail info.
When I STOP/START it restarts from 0.

[Performa01]

Edit: That actually appears to be a little glitch in the UI. There are nice explanatory texts for each measurement item. But there is no way to see them without actually selecting that item (before you see its explanation) and auto-closing the dialog. Well, you can re-open the dialog afterwards, to see explained what you just did...

It's actually a very well thought-out behavior:

If you call the measurements dialog via the empty measurement slot ("+" symbol), then it will behave like you've described it and selecting a measurement actually acts as "OK" and closes the dialog, assuming you wanted to just add that one particular measurement.

If you want to add several measurements at a time, or just read the help text, then you click the "Type"button in the MEASURE menu. Now clicking on a mesurement displays the help text and adds it to the active mesurements, but doesn't close the dialog. So you can click that measurement again to de-select it (if ou only wanted to read the help text) or select more items, also from different categories. Once you're done, you close the dialog manually.

EDIT: oh, I've missed the progress in this thread, so this was old news

[eTobey]

When I STOP/START it restarts from 0.

Not if it has stopped from a failure, or its operation has not been activated in the first place. I have written this in my post: "An inactive operation is easily missed after it has been stopped from a fail."

[2N3055]

When I STOP/START it restarts from 0.

Not if it has stopped from a failure, or its operation has not been activated in the first place. I have written this in my post: "An inactive operation is easily missed after it has been stopped from a fail."

Ahh, that.
That is by design.

Why start stop would auto enable mask test? How scope would know when it should and when it shouldn't?
Expectations of auto this and auto that presumes only simple scenarios of use.

Mask test is used a lot from testing scripts. In a testing script you go from step to step.
Sometimes you are accumulating results, sometimes you want to stop until operator reacts....
Etc.

Coupling two functions with some auto type of reaction is not welcome here.

[eTobey]

While trying out this really nice feature, i stumpled yet again over something:
When in measure menu -> config, it is not possible to scroll the menu, if you try to scroll with (touch) the Gate on/off button, or with text fields.

[eTobey]

Coupling two functions with some auto type of reaction is not welcome here.

I am OK with that, but then it should be clearly visible, that it is currently not activated.

[2N3055]

Coupling two functions with some auto type of reaction is not welcome here.

I am OK with that, but then it should be clearly visible, that it is currently not activated.

With many analysis packages there is enabled or disabled. Like decoding for instance.

For some analysis packages you have two separate states: analysis package activated and separate testing progress on/off. 

That is like that for Bode plot, Power analysis etc.
This is so for Mask test also.

If you enable Show statistics, it shows it is not counting.  If you enable [Stop on fail] it will not exit Mask mode but only stop testing.

We might have some additional message somewhere that would mean "testing in progress".
But in reality it is counting up the number tests performed as it works, as an indicator it is working.
We might ask for something obvious in addition to Info lines (something like "Collecting/Paused"), but basic indicators are already there.
I also keep side menu folded out all the time when doing Mask test, so I see it there.

[tautech]

Coupling two functions with some auto type of reaction is not welcome here.

I am OK with that, but then it should be clearly visible, that it is currently not activated.

With many analysis packages there is enabled or disabled. Like decoding for instance.

For some analysis packages you have two separate states: analysis package activated and separate testing progress on/off. 

That is like that for Bode plot, Power analysis etc.
This is so for Mask test also.

If you enable Show statistics, it shows it is not counting.  If you enable [Stop on fail] it will not exit Mask mode but only stop testing.

We might have some additional message somewhere that would mean "testing in progress".
But in reality it is counting up the number tests performed as it works, as an indicator it is working.
We might ask for something obvious in addition to Info lines (something like "Collecting/Paused"), but basic indicators are already there.
I also keep side menu folded out all the time when doing Mask test, so I see it there.

That can be remedied by using the other menu setting and compressing the active display and grid so to not hide anything under the dropdown menu bar.

[eTobey]

If you enable Show statistics, it shows it is not counting.  If you enable [Stop on fail] it will not exit Mask mode but only stop testing.

It shows counting, but what if an event takes a dozend of seconds to appear? Than you wait that long?
Efficient would be you just beeing able to tell with a quick glimpse, if it is activated.

[2N3055]

If you enable Show statistics, it shows it is not counting.  If you enable [Stop on fail] it will not exit Mask mode but only stop testing.

It shows counting, but what if an event takes a dozend of seconds to appear? Than you wait that long?
Efficient would be you just beeing able to tell with a quick glimpse, if it is activated.

Like I said, if that is important, just keep the menu open then. But as I said, I'm not against another line in info that would signal current state. It cannot hurt.

[electronics hobbyist]

I have more good news for you.

You still use measurements, and enable cursors, but enable Measurement cursors.
Those follow automatic measurements and show where is measurement performed at...

Maybe we should rename the thread into "Bugs/Wanted/Available Features".

Actually, I have an idea to split this thread into two threads, one is bugs+firmwares, and the other is wanted features(Current thread),
if this thread is too long, which may give people the illusion that there are many product problems.

Firstly, siglent is more concerned about bugs, and it is Siglent's obligation to modify them,
Then another wanted features thread(Current thread) can provide good ideas for all manufacturers, allowing everyone to speak freely and leverage their professional advantages.
Although manufacturers are not obligated to implement features that are not included in the datasheet, when ideas that are beneficial to all products appear, manufacturers will prioritize their implementation.

In the bugs+firmwares thread, can standardize the problem description, mainly referring to the form of ebastler. Everyone can also supplement it to see if there is any missing information:

Version: 1.1.3.3

Problem description: Trigger holdoff fails (or When holdoff is turned on, waveform acquisition stops)

Test signal:
-SDG2042X, connected via BNC into 50 Ohm terminator
-Square wave, 1 Vpp
-Frequency sweep 10 kHz 100 kHz over 100 ms

Scope settings: (If the settings are more complex, the current oscilloscope setup.xml can be attached, Try to start from "Default" as much as possible)
-Start from Default settings
-Connect signal to CH1
-Edge trigger, positive edge, 3 ms holdoff
-Leave timebase at default 1 µ s/div (but 5, 10, 50 µ s/div also show the problem)
-Leave memory at default 10 MPt (but other settings also show the problem)

Observed behavior:
-Leave scope in RUN mode, wait up to a minute or so (but some of the problem occurrences within seconds)
-In AUTO trigger mode, the scope will stop rendering new waveforms entirely Trigger status shows READY, trigger frequency counter is still updated, waveform is frozen Operation restarts after any user interaction
-In NORMAL trigger mode, the error seeds puller, but occurrence events Before it does, I noticed sporadic "hickups", where the trigger status switches to "Arm" and the waveform is not updated for a few months of a second

What do you think? We can discuss it. 

[eTobey]

Firstly, siglent is more concerned about bugs, and it is Siglent's obligation to modify them,

I would be quite a bit sad, if a few of the feature/improvement suggestions would not be implemented in the next 6-12 months. But at the same time i am glad that they actually going to fix those bugs.

I like the idea of a clear separation of things. But then i like the idea, to slip in a few suggestions in between in the bugs. 

[ebastler]

Actually, I have an idea to split this thread into two threads, one is bugs+firmwares, and the other is wanted features (Current thread),
if this thread is too long, which may give people the illusion that there are many product problems.

Firstly, siglent is more concerned about bugs, and it is Siglent's obligation to modify them,
Then another wanted features thread(Current thread) can provide good ideas for all manufacturers, allowing everyone to speak freely and leverage their professional advantages.

I can see the benefits of having a more focused bugs-only thread. Besides avoiding a wrong perception of "too many bugs", it also makes sure that the real bugs get proper attention and are not lost in the noise.

But we can probably not make a very clear cut. I recall several instances where a presumed bug was reported, then it was explained that there is a reason for this behaviour and that it is "right" in many situations, but the desire for a modified behaviour  still remained as a feature request. So we should still be prepared to see some discussions in the bug thread which eventually turn out to be about a feature request.

A lot of the feature requests will be specific to a particular manufacturer or even a particular scope model -- in particular most of the UI-related ideas. So the feature request thread should definitely remain Siglent-specific in my opinion. Then we can benefit from the comments of other users who know the scope well. (Who may either support a request, or explain why they problems with it, or explain already existing solutions.)

In the bugs+firmwares thread, can standardize the problem description, mainly referring to the form of ebastler. Everyone can also supplement it to see if there is any missing information:

Glad that you found my format useful! I would be happy to see it adopted as a general structure for bug reports, but think we should not put the bar too high:

Sometimes the test signal will not be as easily described (if it comes from a complex device under test and the person reporting the bug has not been able to reproduce the problem with a simple signal yet). Sometimes the person reporting the bug may not have found out yet which exact combination of settings is required (starting from Default), but has only noticed one particular setting change which prompted the bug. 

We should "allow" such partial reports and not reject posts which don't include fully reproducible steps. Otherwise some critical observations may not get reported at all, because the hurdle is too high. I think the general structure -- test signal, scope settings, observed bevaviour -- is still useful then. It also makes it clear where information is still incomplete and needs to be filled in (by the OP or others).

By the way -- in bug report templates I have sometimes seen an "expected behaviour" section before the "observed behaviour". Adding this may be useful when describing complex, non-obvious issues. But I don't think it is always required as a separate section; it could also be a comment in the "observed behaviour" part which explains why the observed behaviour is considered wrong or unexpected.

[tautech]

Coupling two functions with some auto type of reaction is not welcome here.

I am OK with that, but then it should be clearly visible, that it is currently not activated.

With many analysis packages there is enabled or disabled. Like decoding for instance.

For some analysis packages you have two separate states: analysis package activated and separate testing progress on/off. 

That is like that for Bode plot, Power analysis etc.
This is so for Mask test also.

If you enable Show statistics, it shows it is not counting.  If you enable [Stop on fail] it will not exit Mask mode but only stop testing.

We might have some additional message somewhere that would mean "testing in progress".
But in reality it is counting up the number tests performed as it works, as an indicator it is working.
We might ask for something obvious in addition to Info lines (something like "Collecting/Paused"), but basic indicators are already there.
I also keep side menu folded out all the time when doing Mask test, so I see it there.

That can be remedied by using the other menu setting and compressing the active display and grid so to not hide anything under the dropdown menu bar.

I had a PM from a member asking what my reply meant.

The 2 attached screenshots reveal these menu setting changes and how they impact on the display.

[2N3055]

I have more good news for you.

You still use measurements, and enable cursors, but enable Measurement cursors.
Those follow automatic measurements and show where is measurement performed at...

Maybe we should rename the thread into "Bugs/Wanted/Available Features".

Actually, I have an idea to split this thread into two threads, one is bugs+firmwares, and the other is wanted features(Current thread),
if this thread is too long, which may give people the illusion that there are many product problems.

Firstly, siglent is more concerned about bugs, and it is Siglent's obligation to modify them,
Then another wanted features thread(Current thread) can provide good ideas for all manufacturers, allowing everyone to speak freely and leverage their professional advantages.
Although manufacturers are not obligated to implement features that are not included in the datasheet, when ideas that are beneficial to all products appear, manufacturers will prioritize their implementation.

In the bugs+firmwares thread, can standardize the problem description, mainly referring to the form of ebastler. Everyone can also supplement it to see if there is any missing information:

Version: 1.1.3.3

Problem description: Trigger holdoff fails (or When holdoff is turned on, waveform acquisition stops)

Test signal:
-SDG2042X, connected via BNC into 50 Ohm terminator
-Square wave, 1 Vpp
-Frequency sweep 10 kHz 100 kHz over 100 ms

Scope settings: (If the settings are more complex, the current oscilloscope setup.xml can be attached, Try to start from "Default" as much as possible)
-Start from Default settings
-Connect signal to CH1
-Edge trigger, positive edge, 3 ms holdoff
-Leave timebase at default 1 µ s/div (but 5, 10, 50 µ s/div also show the problem)
-Leave memory at default 10 MPt (but other settings also show the problem)

Observed behavior:
-Leave scope in RUN mode, wait up to a minute or so (but some of the problem occurrences within seconds)
-In AUTO trigger mode, the scope will stop rendering new waveforms entirely Trigger status shows READY, trigger frequency counter is still updated, waveform is frozen Operation restarts after any user interaction
-In NORMAL trigger mode, the error seeds puller, but occurrence events Before it does, I noticed sporadic "hickups", where the trigger status switches to "Arm" and the waveform is not updated for a few months of a second

What do you think? We can discuss it. 

That is excellent idea, I think!

[eTobey]

...
We should "allow" such partial reports and not reject posts which don't include fully reproducible steps.
...

I totally agree to all that you have said.

The freeze (mosquito) bug would not have been found until i would have made a complete description, and that would have taken me hours. But it would have never been found, as it got fixed with that holdoff bug.  I am glad, that we actually have found this in a teamwork effort. Otherwise i would have been seen as an idiot not knowing of how to use a scope. 

[rf-loop]

Actually, I have an idea to split this thread into two threads, one is bugs+firmwares, and the other is wanted features (Current thread),
if this thread is too long, which may give people the illusion that there are many product problems.

Firstly, siglent is more concerned about bugs, and it is Siglent's obligation to modify them,
Then another wanted features thread(Current thread) can provide good ideas for all manufacturers, allowing everyone to speak freely and leverage their professional advantages.

I can see the benefits of having a more focused bugs-only thread. Besides avoiding a wrong perception of "too many bugs", it also makes sure that the real bugs get proper attention and are not lost in the noise.

This is important. Even when there is sometimes somewhat fuzzy line between bugs and then  and other problems or "features", or these "I like - I do not like" - things. 
Also there are different class of bugs. And different clas of other things what can make UX (user experiance about UI) better or worse but what are not bugs.