SDS800X HD Wanted Features

[electronics hobbyist]

#5 and #6 are attributed to me, but I don't recall reporting these, and am not sure what they relate to in detail.

I have found one issue around history + cursors which can be easily reproduced.

It's okay, I remember the problem description. 

It is somewhat related to #7 and #11, in that is decribes a mode where the universal knob gets assigned to two functions at once, but is a separate issue I think:

- Firmware 1.1.3.3, start from Default setup
- Activate manual measurement cursors
- Run a regular acquisition
- Press Stop
- Select Navigate, Type: History Frame
> The universal knob now controls both, cursor(s) and frame selection.

Yes, I also reproduced the problem in this step.

[ebastler]

#5 and #6 are attributed to me, but I don't recall reporting these, and am not sure what they relate to in detail.

It's okay, I remember the problem description. 

Ah, I think I have figured it out now. Neither of these are bugs; they are feature wishes (usability improvements). I actually have three of them, all related to scrolling:

(a) Relevant to any type of list (history list, decode results -- are there any others?): It should be possible to assign the universal knob to scrolling lists when the list is shown on-screen and the respective menu is closed. E.g. by tapping the list's title bar. [currently #5 in the bug list.]

(b) Relevant to any type of list: When using the mouse, the scroll wheel should scroll a list when the mouse pointer is hovering anywhere over the list. (Not only when the mouse pointer is over the scroll bar on the screen.) This behaviour is consistent with all major operating systems, I believe.

(c) Specific to the History list: When scrolling the History list, the blue selector should not move with the list (and out of sight). Rather, the list items should move relative to the selector, and the displayed frame should actually change. [The behaviour is fine when the Navigate menu is also open, and one the History list scrolls via the universal button. But the behaviour is different, and worse, when one scrolls via the scroll bar or mouse scroll whell of the History list itself.]

[rf-loop]

Not a B**, but a potential for improvement:

Bad units:
Units are not the same and will cause confusion. In this picture, the 100ns are easly to see as a different unit, but that is not the case, if it would be below 87.1.
It should only have the same unit, or those units can be displayed with different colors. Show "ns" in blue, "us" in yellow and so forth.

Those that might now be urged to reply with "you just need to read" or similar, i wish to be quiet. I post this, because its always good to be able to work efficiently.

When you said "...if it would be below 87.1....."

In this image what you have attached there can not be below 100ns. Next step is 0
There is 10MSa/s decimated sampling speed. Decimated, and used for decode, Sample interval is 0.1 us.
(Sidenote: And even more for thinking... there is Peak Detekt in use. What means that one displayed (and used for decode) sample point can be originally from what ever position inside this 100ns interval (Perhaps all know how peak detect works).


About displayed time units in this image. For better UX

Least in just this particular case, displayed in your image.
Naturally it is better if it display 0.1 us instead of 100.000 ns, then all values can use same unit (because its timing resolution in this your image is 0.100 us and nothing more because sample rate is 10MSa/s

[eTobey]

When you said "...if it would be below 87.1....."

In this image what you have attached there can not be below 100ns. Next step is 0
There is 10MSa/s decimated sampling speed. Decimated, and used for decode, Sample interval is 0.1 us.
(Sidenote: And even more for thinking... there is Peak Detekt in use. What means that one displayed (and used for decode) sample point can be originally from what ever position inside this 100ns interval (Perhaps all know how peak detect works).

I did not use the unit "ns" intentionally. All those units can be the next bigger one. And then, there would be a big difference between 82us and 82ms for example. The units can be missed easily! Yes, maybe not between us and ms, but just take the example on the picture with different numbers.

BTW:
Having the same unit throughout the list is a requirement, if you want to export it to spreadsheet.

I would really love to have those units the same, or just colored differently, so my eyes can fly over it easily. (I like efficiency!)

[eTobey]

Room for improvement:
When using decode, i thought "oh there is binary too, that is awesome", then switched to binary. Saw that it also changed the first hex that i needed to read in hex, to binary too. 
So much empty space in those rows...

Edit:
Setting up SPI decode:
When choosing the channel for signals, activate channel automatically. Channel can not be choosen, if channel is not activated. Needs a lot of clicks for that.

[ebastler]

Thought "oh there is binary too, that is awesome", then switched to binary. Saw that it also changed the first hex that i needed to read in hex, to binary too. 
So much empty space in those rows...

We really need a bit more context: This is still referring to decoding, I guess? Which protocol? Is that first byte different from the others (an ID?), or just the first byte in the data field?

I could imagine a format selection by field, i.e. separate for IDs or commands vs. data. But I am not sure I'm in favor of it -- is it worth the added complexity in the UI, given how often (or not) it would get used? I would certainly not be in favor of different formats for different data bytes.

As a more general theme, I don't think Siglent should provide option switches for every imaginable aspect of UI behaviour. It seems fine to me to let users adjust to the software for rarely used or not-so-impactful aspects of the software. Otherwise one ends up with a jungle of switches. Limit user-selectable switches to aspects which really impact the handling of the software on a tangible and regular basis, like e.g. the menu auto-hiding behaviour.

Edit:
Setting up SPI decode:
When choosing the channel for signals, activate channel automatically. Channel can not be choosen, is channel is not activated. Needs a lot of clicks for that.

Edit: You seem to plan ahead much more than I do! 

I would always connect the signals, activate the channels and set them to make the signals visible first -- then proceed to set up the decoder and (if needed) protocol-specific trigger. Which probably shows that I am not good at abstract thinking or planning; I need to see what I am doing. 

[eTobey]

I added the picture i forgot.

Yes a user format. That would be an idea. I already using the uart for debugging too, so it would be awesome to have a column for hex, ascii and decimal. But there was a feature suggested, that would write a whole packet of bytes in one line. But in this case, functionality could be adopted differently.

The automatically turning on channels was just a suggestion, since one can adopt. I wonder if others run into this problem of not beeing able to choose a channel, because it is not activated.

[electronics hobbyist]

I added the picture i forgot.

Yes a user format. That would be an idea. I already using the uart for debugging too, so it would be awesome to have a column for hex, ascii and decimal. But there was a feature suggested, that would write a whole packet of bytes in one line. But in this case, functionality could be adopted differently.

The automatically turning on channels was just a suggestion, since one can adopt. I wonder if others run into this problem of not beeing able to choose a channel, because it is not activated.

Your idea is good, and the best solution is to have multiple formats to choose from. Users can choose from 1, 2, 3, or N display formats on the same line, such as 01000001 | 0x41 | 'A' | ...  If it cannot be displayed properly, it is the user's responsibility,
It can also be displayed in one column, such as
UART    Time      Rx
1          0us       01000001
1          0us       0x41
1          0us       'A'

I haven't seen any manufacturers doing this yet, when implemented, the workload looks very heavy, and all protocols need to consider supporting various display formats, Also, need to consider whether the decode bus supports multiple display formats.Some protocols have a relatively large amount of data, When the display cannot fit, users will be dissatisfied. Therefore, manufacturers still need to consider whether the display area is sufficient.

Add to Wanted Features No.27

[electronics hobbyist]

Bug:
SMB Client does not autoconnect. My setup includes a TP-Link TL-WR802N N300 WLAN Nano Router.
It does work when i connecting manually.

I did not reproduce this issue. I connected through an Ethernet cable and after a power outage and restart, I was able to directly open the remote mounting path directory.
It may be due to differences in the network environment.

[eTobey]

It can also be displayed in one column, such as...

Another idea:
Make quick button cycle through hex, dec, binary.

[ebastler]

The description of bug #8 should be re-worded for clarity and reproducibility, I think:

Math > Function dialog automatically closes after channel change.
- Set Display > Hide Menu to 10 seconds
- Open Math > Function dialog
- Normal behaviour is that this dialog (like all dialogs) never closes automatically. Auto-hiding only applies to menus and is disabled whenever a dialog is open.
- In the Math > Function dialog, change the channel(s) for the active Math function
- The dialog and menu will automatically close 10 seconds later -- even if the user stays active and changes other entries in the dialog.

[electronics hobbyist]

It can also be displayed in one column, such as...

Another idea:
Make quick button cycle through hex, dec, binary.

This solution looks easy to implement, I added it to the description.

[electronics hobbyist]

The description of bug #8 should be re-worded for clarity and reproducibility, I think:

Math > Function dialog automatically closes after channel change.
- Set Display > Hide Menu to 10 seconds
- Open Math > Function dialog
- Normal behaviour is that this dialog (like all dialogs) never closes automatically. Auto-hiding only applies to menus and is disabled whenever a dialog is open.
- In the Math > Function dialog, change the channel(s) for the active Math function
- The dialog and menu will automatically close 10 seconds later -- even if the user stays active and changes other entries in the dialog.

Great, you perfectly reproduced this problem, and I have added this link to bug No.8. 

[2N3055]

I added the picture i forgot.

Yes a user format. That would be an idea. I already using the uart for debugging too, so it would be awesome to have a column for hex, ascii and decimal. But there was a feature suggested, that would write a whole packet of bytes in one line. But in this case, functionality could be adopted differently.

The automatically turning on channels was just a suggestion, since one can adopt. I wonder if others run into this problem of not beeing able to choose a channel, because it is not activated.

Your idea is good, and the best solution is to have multiple formats to choose from. Users can choose from 1, 2, 3, or N display formats on the same line, such as 01000001 | 0x41 | 'A' | ...  If it cannot be displayed properly, it is the user's responsibility,
It can also be displayed in one column, such as
UART    Time      Rx
1          0us       01000001
1          0us       0x41
1          0us       'A'

I haven't seen any manufacturers doing this yet, when implemented, the workload looks very heavy, and all protocols need to consider supporting various display formats, Also, need to consider whether the decode bus supports multiple display formats.Some protocols have a relatively large amount of data, When the display cannot fit, users will be dissatisfied. Therefore, manufacturers still need to consider whether the display area is sufficient.

Add to Wanted Features No.27

UART protocol on electrical level is defined as sending single ASCII characters/single byte (or 7bits sometimes, not even a full byte).

Creating complex messages and/or binary transfer is left to application level.
There are protocols like Xmodem/Zmodem/Kermit, AT command set for modems, Modbus, and literally millions of custom data exchange protocols. Some send fixed length data, some are delimited at the end of a message with a character sequence. Protocol is asynchronous so Rx/Tx can happen at any time, intermixed..

So how do you group messages for all that?

As for coding, available space on screen limits what can be done. When showing characters, do we do only original ASCII or ANSI?
How do we deal with control characters? Are control characters used as control characters at all in this particular protocol? Do we show only "readable" characters and some symbol for the rest or we do mixed display where we show ASCII(or ANSI) for "readable" and hex for the rest ? Or decimal, or binary? Do we decode VT100 ?
And on and on...

There is whole world of terminal applications (standalone programs) for PCs for this purpose. Paid applications, where companies live from selling terminal/serial/modbus etc, serial protocol software for this purpose. Software made for sole purpose to be able to look at serial stream data.
That is a testament how easy it is.

This kind of higher level decoding of data is called "symbolic decoding" in scope world.  Like when you are decoding CAN on a car, and then you load symbolic data for your specific car (you need special symbolic database for that) and then on a screen of a scope you can directly see that message came from throttle position sensor and that throttle is pressed 50% instead of seeing a message from ID 3345 with value 2024. These things exist. But on scopes that cost as much as your car.

[RAPo]

...
UART protocol on electrical level is defined as sending single ASCII characters/single byte (or 7bits sometimes, not even a full byte).

Creating complex messages and/or binary transfer is left to application level.
There are protocols like Xmodem/Zmodem/Kermit, AT command set for modems, Modbus, and literally millions of custom data exchange protocols. Some send fixed length data, some are delimited at the end of a message with a character sequence. Protocol is asynchronous so Rx/Tx can happen at any time, intermixed..

So how do you group messages for all that?

As for coding, available space on screen limits what can be done. When showing characters, do we do only original ASCII or ANSI?
How do we deal with control characters? Are control characters used as control characters at all in this particular protocol? Do we show only "readable" characters and some symbol for the rest or we do mixed display where we show ASCII(or ANSI) for "readable" and hex for the rest ? Or decimal, or binary? Do we decode VT100 ?
And on and on...

There is whole world of terminal applications (standalone programs) for PCs for this purpose. Paid applications, where companies live from selling terminal/serial/modbus etc, serial protocol software for this purpose. Software made for sole purpose to be able to look at serial stream data.
That is a testament how easy it is.

This kind of higher level decoding of data is called "symbolic decoding" in scope world.  Like when you are decoding CAN on a car, and then you load symbolic data for your specific car (you need special symbolic database for that) and then on a screen of a scope you can directly see that message came from throttle position sensor and that throttle is pressed 50% instead of seeing a message from ID 3345 with value 2024. These things exist. But on scopes that cost as much as your car.

Indeed, as long as I can get the data in raw-hex format in a file, I'm happy. There are enough utilities to do conversion and/or making your own interpretation of the data so this is best done outside the oscilloscope context.

[ebastler]

Indeed, as long as I can get the data in raw-hex format in a file, I'm happy. There are enough utilities to do conversion and/or making your own interpretation of the data so this is best done outside the oscilloscope context.

I tend to agree: Let's not overload the decoders with options and attempts to deal with large datasets on the small screen. At some point this is best left to a PC with a large screen, full-blown GUI and specialised applications for data analysis.

But can you get the data in a file? To my knowledge, the file Save operation does not have the option to store decoder results, or did I overlook anything? And the SCPI command to pull decoder results to the PC seems broken -- see eTobey's post below. (Note that the problem illustrated in that post is not the strange diamond characters at the end. Rather, the data blocks before are incomplete, with random (?) bytes missing. I have seen the same with I²C results, it does not seem CAN-specific.)

https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/msg5417735/?topicseen#msg5417735

[electronics hobbyist]

UART protocol on electrical level is defined as sending single ASCII characters/single byte (or 7bits sometimes, not even a full byte).

Creating complex messages and/or binary transfer is left to application level.
There are protocols like Xmodem/Zmodem/Kermit, AT command set for modems, Modbus, and literally millions of custom data exchange protocols. Some send fixed length data, some are delimited at the end of a message with a character sequence. Protocol is asynchronous so Rx/Tx can happen at any time, intermixed..

So how do you group messages for all that?

As for coding, available space on screen limits what can be done. When showing characters, do we do only original ASCII or ANSI?
How do we deal with control characters? Are control characters used as control characters at all in this particular protocol? Do we show only "readable" characters and some symbol for the rest or we do mixed display where we show ASCII(or ANSI) for "readable" and hex for the rest ? Or decimal, or binary? Do we decode VT100 ?
And on and on...

There is whole world of terminal applications (standalone programs) for PCs for this purpose. Paid applications, where companies live from selling terminal/serial/modbus etc, serial protocol software for this purpose. Software made for sole purpose to be able to look at serial stream data.
That is a testament how easy it is.

This kind of higher level decoding of data is called "symbolic decoding" in scope world.  Like when you are decoding CAN on a car, and then you load symbolic data for your specific car (you need special symbolic database for that) and then on a screen of a scope you can directly see that message came from throttle position sensor and that throttle is pressed 50% instead of seeing a message from ID 3345 with value 2024. These things exist. But on scopes that cost as much as your car.

Yes, scope are mainly used for the analysis of electrical level problems. The application protocols are ever-changing, and there are many things to consider. Therefore, it is more appropriate to use Quick Action to switch display formats in this Wanted Feature.

[electronics hobbyist]

Indeed, as long as I can get the data in raw-hex format in a file, I'm happy. There are enough utilities to do conversion and/or making your own interpretation of the data so this is best done outside the oscilloscope context.

I tend to agree: Let's not overload the decoders with options and attempts to deal with large datasets on the small screen. At some point this is best left to a PC with a large screen, full-blown GUI and specialised applications for data analysis.

But can you get the data in a file? To my knowledge, the file Save operation does not have the option to store decoder results, or did I overlook anything? And the SCPI command to pull decoder results to the PC seems broken -- see eTobey's post below. (Note that the problem illustrated in that post is not the strange diamond characters at the end. Rather, the data blocks before are incomplete, with random (?) bytes missing. I have seen the same with I²C results, it does not seem CAN-specific.)

https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/msg5417735/?topicseen#msg5417735

I have no problem using NI MAX to send commands through the LAN to obtain decoding results.
Sending commands through the web will truncate the data. It seems that the data returned through the web cannot exceed 512 bytes, so I suggest using Python script to obtain the decoding results, this can specify the data length.
There is a "Save" button under the "Decode" -> "Result list" menu, which can save the decoding results to a U disk or remote computer.

[eTobey]

Sending commands through the web will truncate the data. It seems that the data returned through the web cannot exceed 512 bytes,...

The data is not truncated at all! Just take a closer look, that the data is corrupted at the first few field. Also if i remember right, it was a html response on the network, which is not really limited (at least not under a few Mb i would guess).

[electronics hobbyist]

Sending commands through the web will truncate the data. It seems that the data returned through the web cannot exceed 512 bytes,...

The data is not truncated at all! Just take a closer look, that the data is corrupted at the first few field. Also if i remember right, it was a html response on the network, which is not really limited (at least not under a few Mb i would guess).

I just tested it with UART. I will try your settings again when I come back from vacation.I checked the previous part of the web return data and did not find issues.

[2N3055]

There is a "Save" button under the "Decode" -> "Result list" menu, which can save the decoding results to a U disk or remote computer.

This something very often overlooked: you can map a folder on your PC to a Scope and you save directly into that share.
Data, screen captures, decoded data etc.

I use that all the time, it is very useful.

[eTobey]

It would be sufficient, to just have the quick button change format. But one thing that would really be helpful, is, having a complete packet of values/characters shown on one line UART I2C or else it would apply (less columns that would mean - for this option).

[eTobey]

I just tested it with UART. I will try your settings again when I come back from vacation.I checked the previous part of the web return data and did not find issues.

This export is wrong too. It has 3 column heads but prints only 2 on each line (mind the ',').
Have a great vacation.

[2N3055]

It would be sufficient, to just have the quick button change format. But one thing that would really be helpful, is, having a complete packet of values/characters shown on one line UART I2C or else it would apply (less columns that would mean - for this option).

Read my post on this.
What is full line to you? How it is defined?

"message" as you call it is application level concept. Scope looks at electrical level there is no application protocol parser in it.

[ebastler]

There is a "Save" button under the "Decode" -> "Result list" menu, which can save the decoding results to a U disk or remote computer.

Thank you, I had indeed overlooked that! I was looking in the Utility > Save/Recall menu, where the Type options do not include decoder results.

Sending commands through the web will truncate the data. It seems that the data returned through the web cannot exceed 512 bytes, so I suggest using Python script to obtain the decoding results, this can specify the data length.

As another data point, please see my trivial I²C example attached. Each packet sent by the master consists of just a slave address (because the slave does not respond), and there are only 6 entries in the results list. The on-screen list is fine, but SCPI delivers incomplete and inconsistent results: The actual address byte is only inlcuded 2 times out of the 6. Not an issue of data size, given the minimal size of this example.