SDS800X HD Bug Reports + Firmware

[eTobey]

I actually only wanted to document this issue here, but since i could not proceed to to work with it, i got a little more into it.
You are welcome to spend some time investigating this issue.

The two pictures show the exact setup, and are only like 5 seconds apart. The difference is just, that the vertical position has been moved, and then the mask test fails to detect fail conditions...


I also tried for solving the issue:
- pulling the plug (when turned off)
- Factory reset (funny: after activating the mask mode, a mask was already loaded...)

Cant think of what else could be the cause. Never had such persisting problems with mask editor

Edit:
Would you believe it? After creating a mask without the mask editor, it now seemingly works as it should!!!

Worked for a few minutes.... 

[tautech]

Some info on using Masks here:
https://www.eevblog.com/forum/testgear/siglent-sds3034x-mask-testing/

[eTobey]

Some info on using Masks here:
https://www.eevblog.com/forum/testgear/siglent-sds3034x-mask-testing/

Why would you think, that this information would help?


I found another issue, that may stem from the same rootcause:
https://youtu.be/lDr_-nYgddQ

Edit:
I think i found pretty much the cause:
In the mask file, there are settings of the channel and timebase saved. (I guess this is how every scope does it, so this is why it isnt mentioned in the manual?)
The wrong channel is saved (CH3 was used, but CH1 saved). Interestingly, CH3 is loaded though.
Oh boy... 

I may have a workaround:
Starting the mask test with the run/stop button seems to work fine. Problem though: "Capture on fail" is always set to off... 

[eTobey]

Dear siglent,

would you please fix the bugs? Especially this one should be an easy fix.


2 Useless digits (the last ones, that do not change anyway), but then important digits are hard to read.

[awakephd]

I am very hesitant to bring this into the conversation, because thus far I have not been able to reproduce it ... and I am not at all sure that the problem was not in my cheap FY6900 AWG instead of in the SDS804X, or in the defective user operating both. But just in case this is something that anyone else has seen, or has an explanation for ...

Siglent SDS804X-HD, Firmware 1.1.3.8, U-boot version 3.8.12, FPGA version 2024-04-11, Hardware version 00.
Codes entered to boost this to an 824.

I was looking at the input and output of a single-transistor Class A amplifier, feeding in a 0.04Vpp sine wave from an FY6900 AWG. I was entering various frequencies to the FY6900 via the serial interface and observing the results on the web interface of the Siglent. I changed the frequency from 100kHz to 10kHz, and then changed the timebase on the oscilloscope ... and got the results shown below. Changed the timebase again, and still showing the odd result (3rd picture). When I changed the FY6900 back to 100kHz, however, the results were normal / as expected, and thereafter remained normal when I changed back and forth between 10kHz and 100kHz and changed timebase of oscilloscope accordingly.

Again, could easily be something going on with the FY6900, especially since my "serial connection" is actually being made via an ESP-01 telnet interface. Could easily be user error, since I am still such a newbie. But if anyone happens to be able to tell me what I did wrong ... I would be most appreciative!

[2N3055]

I am very hesitant to bring this into the conversation, because thus far I have not been able to reproduce it ... and I am not at all sure that the problem was not in my cheap FY6900 AWG instead of in the SDS804X, or in the defective user operating both. But just in case this is something that anyone else has seen, or has an explanation for ...

Siglent SDS804X-HD, Firmware 1.1.3.8, U-boot version 3.8.12, FPGA version 2024-04-11, Hardware version 00.
Codes entered to boost this to an 824.

I was looking at the input and output of a single-transistor Class A amplifier, feeding in a 0.04Vpp sine wave from an FY6900 AWG. I was entering various frequencies to the FY6900 via the serial interface and observing the results on the web interface of the Siglent. I changed the frequency from 100kHz to 10kHz, and then changed the timebase on the oscilloscope ... and got the results shown below. Changed the timebase again, and still showing the odd result (3rd picture). When I changed the FY6900 back to 100kHz, however, the results were normal / as expected, and thereafter remained normal when I changed back and forth between 10kHz and 100kHz and changed timebase of oscilloscope accordingly.

Again, could easily be something going on with the FY6900, especially since my "serial connection" is actually being made via an ESP-01 telnet interface. Could easily be user error, since I am still such a newbie. But if anyone happens to be able to tell me what I did wrong ... I would be most appreciative!

What you show looks like FSK modulation between 2 frequencies was set on generator..

[awakephd]

What you show looks like FSK modulation between 2 frequencies was set on generator..

I wondered about that. There shouldn't have been any way to switch over to that, since all I did was issue a WMF command to change the frequency. (This is the FY6900 command format, nothing like scpi!) That said ... this is a budget/cheap AWG ... being operated by a newbie ... using self-written software to send the commands via an ESP-01 ... so anything is possible!

[Aldo22]

I wondered about that. There shouldn't have been any way to switch over to that, since all I did was issue a WMF command to change the frequency. (This is the FY6900 command format, nothing like scpi!) That said ... this is a budget/cheap AWG ... being operated by a newbie ... using self-written software to send the commands via an ESP-01 ... so anything is possible!

Don't you have physical access to the FY6900?
That should be displayed with the MOD button?

[eTobey]

Cursor shows nans - make it usable again:

Hit value and push knob.

[awakephd]

Don't you have physical access to the FY6900?
That should be displayed with the MOD button?

Yes, but at the time I was accessing both scope and FY6900 remotely - web interface for the former and telnet / serial access for the latter - so I was not able to observe the FY6900 directly.

[awakephd]

Guys, seriously...! This topic is messed up enough, now you add other device too? 

Please delete these posts!

As I said, I was not sure I should even ask the question. Fine with me if the mods want to delete it. I don't think I can go back and delete, can I?

[BillyO]

Can some just take this scope away from him?  He does not seem to use it at all, just spends endless hours finding things to complain about.
 

[awakephd]

BillyO, I hope that wasn't directed towards me - ? Lots of newbie questions to be sure, and I'm not always sure I'm following the right protocols and customs for the forum, but I don't think I've complained about the scope at all.

[BillyO]

BillyO, I hope that wasn't directed towards me - ? Lots of newbie questions to be sure, and I'm not always sure I'm following the right protocols and customs for the forum, but I don't think I've complained about the scope at all.

No worries, not you.   

You ended up getting in a couple of posts before I hit return.

[eTobey]

Be aware, that you might work all in vain:

Saved a row of screenshots with the webinterface, and only verfied, that they have been saved. But they were all the same, as seemingly the connection dropped without notice. 

[tautech]

Be aware, that you might work all in vain:

Saved a row of screenshots, and only verfied, that they have been saved. But they were all the same, as seemingly the connection dropped without notice. 

Webserver ?
Most browsers give some indication of a download to use as confirmation of a successful Save.....or weren't you taking notice ? 

This is where Fade Tips for local saves are useful and to also have confirmation of the Save path.

[eTobey]

Most browsers give some indication of a download to use as confirmation of a successful Save.....or weren't you taking notice ? 

Saved a row of screenshots, and only verfied, that they have been saved. But they were all the same, as seemingly the connection dropped without notice. 

Most posts give some information, on what has been done...

(Yes another rude answer, from a noob that does not know anything... )

BTW:
I am still waiting for an answer in this post:
https://www.eevblog.com/forum/testgear/sds800x-hd-bug-reports-firmware/msg5674679/#msg5674679

[tautech]

Most browsers give some indication of a download to use as confirmation of a successful Save.....or weren't you taking notice ? 

Saved a row of screenshots, and only verfied, that they have been saved. But they were all the same, as seemingly the connection dropped without notice. 

Most posts give some information, on what has been done...

Thanks, wasn't clear.

So have you changed the LAN cable to confirm that was the problem ?

[chr1s]

I have found a problem when using the UART decoded data trigger.


Version: Software 1.1.3.8, Uboot-OS 3.8.12, FPGA 2024-04-11, Hardware 00

Problem description: UART not triggering on the specified value

Test signal:
- 6 Mbaud UART with inverted active level (idle = 0 V, start = 2.1 V, stop = 0 V), 8 data bits, no parity, 1.5 stop bits
- Continuous stream with no pause between the data bytes

Scope settings:
- Start from Default settings
- Set decoder to UART with RX threshold 1 V, Baud 6 Mbit/s, Parity None, 1.5 Stop Bits, Idle Level Low
- Use Protocol Copy: Copy To Trigger. Verify if the settings have been copied to the trigger.
- Set the trigger condition to Data = 0x71 (this is the data byte I'm interested in for this application)
- Start signal acquisition using the Auto trigger
- Connect the UART stream to CH1. Use a continuous stream with the same frame specifications as the decoder settings.

Observed behavior:
When connecting the UART stream to CH1, the oscilloscope will sometimes not trigger on the data byte, and keep not triggering as long as the signal is connected. To get the trigger to work again, the channel must be disconnected and reconnected. It does not matter if it is physically disconnected, or disabled using the channel switch on the oscilloscope. Trigger fails to start at about 20 % of the connection events.
The interesting thing is that the data byte of interest is decoded with no problems at all. If I stop the Acquisition, I can find the 0x71 byte in the data history. It seems that it is just the trigger not seeing the successfully decoded byte. I have tried with every 20th byte, as well as every 1000th byte being a 0x71 byte.
It also seems that, even when the trigger is catching the byte after a connection event, it sometimes fails to trigger for up to a second.

[2N3055]

I have found a problem when using the UART decoded data trigger.


Version: Software 1.1.3.8, Uboot-OS 3.8.12, FPGA 2024-04-11, Hardware 00

Problem description: UART not triggering on the specified value

Test signal:
- 6 Mbaud UART with inverted active level (idle = 0 V, start = 2.1 V, stop = 0 V), 8 data bits, no parity, 1.5 stop bits
- Continuous stream with no pause between the data bytes

Scope settings:
- Start from Default settings
- Set decoder to UART with RX threshold 1 V, Baud 6 Mbit/s, Parity None, 1.5 Stop Bits, Idle Level Low
- Use Protocol Copy: Copy To Trigger. Verify if the settings have been copied to the trigger.
- Set the trigger condition to Data = 0x71 (this is the data byte I'm interested in for this application)
- Start signal acquisition using the Auto trigger
- Connect the UART stream to CH1. Use a continuous stream with the same frame specifications as the decoder settings.

Observed behavior:
When connecting the UART stream to CH1, the oscilloscope will sometimes not trigger on the data byte, and keep not triggering as long as the signal is connected. To get the trigger to work again, the channel must be disconnected and reconnected. It does not matter if it is physically disconnected, or disabled using the channel switch on the oscilloscope. Trigger fails to start at about 20 % of the connection events.
The interesting thing is that the data byte of interest is decoded with no problems at all. If I stop the Acquisition, I can find the 0x71 byte in the data history. It seems that it is just the trigger not seeing the successfully decoded byte. I have tried with every 20th byte, as well as every 1000th byte being a 0x71 byte.
It also seems that, even when the trigger is catching the byte after a connection event, it sometimes fails to trigger for up to a second.

So there are no pauses between characters in data stream? Ever?
You are relying solely on 0,5 of bit width in stop bit to distinguish it from standard data bit?
It is easy to have framing errors that way...
I 'we seen such serial data streams but synchronous...

Did you try different speeds?
What you use to create signal? Some microcontroller?

I would need to put something together or create signal on AWG to try to create test vector for this...
I won't be able to work on this till the end of the week..

[tautech]

I have found a problem when using the UART decoded data trigger.


Version: Software 1.1.3.8, Uboot-OS 3.8.12, FPGA 2024-04-11, Hardware 00

Problem description: UART not triggering on the specified value

Test signal:
- 6 Mbaud UART with inverted active level (idle = 0 V, start = 2.1 V, stop = 0 V), 8 data bits, no parity, 1.5 stop bits
- Continuous stream with no pause between the data bytes

Scope settings:
- Start from Default settings
- Set decoder to UART with RX threshold 1 V, Baud 6 Mbit/s, Parity None, 1.5 Stop Bits, Idle Level Low
- Use Protocol Copy: Copy To Trigger. Verify if the settings have been copied to the trigger.
- Set the trigger condition to Data = 0x71 (this is the data byte I'm interested in for this application)
- Start signal acquisition using the Auto trigger
- Connect the UART stream to CH1. Use a continuous stream with the same frame specifications as the decoder settings.

Observed behavior:
When connecting the UART stream to CH1, the oscilloscope will sometimes not trigger on the data byte, and keep not triggering as long as the signal is connected. To get the trigger to work again, the channel must be disconnected and reconnected. It does not matter if it is physically disconnected, or disabled using the channel switch on the oscilloscope. Trigger fails to start at about 20 % of the connection events.
The interesting thing is that the data byte of interest is decoded with no problems at all. If I stop the Acquisition, I can find the 0x71 byte in the data history. It seems that it is just the trigger not seeing the successfully decoded byte. I have tried with every 20th byte, as well as every 1000th byte being a 0x71 byte.
It also seems that, even when the trigger is catching the byte after a connection event, it sometimes fails to trigger for up to a second.

Welcome to the forum.

Nice write up. 

Question
Do you have a Threshold level set within the amplitude of the waveform ?

[chr1s]

Welcome to the forum.

Nice write up. 

Question
Do you have a Threshold level set within the amplitude of the waveform ?

Hello, and thank you for the nice welcome

The threshold was set at the correct level for the decoder, then copied to the trigger. I also verified that the threshold is correct in the trigger setup menu. And I tried varying the threshold level, with the expected result of no trigger when the threshould is outside the signal boundaries.

So there are no pauses between characters in data stream? Ever?
You are relying solely on 0,5 of bit width in stop bit to distinguish it from standard data bit?
It is easy to have framing errors that way...
I 'we seen such serial data streams but synchronous...

Did you try different speeds?
What you use to create signal? Some microcontroller?

I would need to put something together or create signal on AWG to try to create test vector for this...
I won't be able to work on this till the end of the week..

Yes that is correct, there is no pause between the bytes. In my application, the data is conveyed across signal transformers for which I have minimized the magnetics to just reliably carry my signal. That is why I chose to use manchester encoding and employ a 0x71 byte, which is in no case valid manchester encoded data, to signal the beginning of the dataset within the stream. My STM32 microcontroller has no problems synchronizing with the data stream.

I just tried using 2 stop bits, which did not improve the trigger quality. One thing that is interesting here is the need to set the trigger to 1 stop bit, instead of 2. It will not fire on 2 stop bit UART data when using the 1.5 stop bit or 2 stop bit decoder setting. When the UART configuration is 1.5 stop bit, the trigger setting must be 1.5 stop bit to fire. I did not try lower data rates as the microcontroller is hard wired to the transformer which is just tuned to carry the manchester encoded data over a 6 Mbaud UART. I hope I can try it later using another data source.

At the moment, the data stream is generated on a STM32 microcontroller on a custom board. I have a STM Nucleo-F429ZI here, for which I could adapt the transmitter code. If you are proficient with that, could send you a program which transmits the continuous data stream. I could also provide a wave file from the oscilloscope.

[eTobey]

Working with the decode function is still frustrating:
- Moving the scrollbar of the decode list wont move it simulataneously
- When there are only 5 items, the first 4 are hidden, if the last choosen item was > 10 (or so) and then the timebase had changed to view only the first 5.
- SCPI export does not work at all!!!

Really dissapointing. Even more so after i got scolded over and over again for revealing issues. 

Maybe i should get another hobby that is less complicated, or does not rely on other parties/devices... 

[BillyO]

Maybe i should get another hobby that is less complicated, or does not rely on other parties/devices... 

Maybe knitting.  Although the bugs rampant in knitting needles might drive you nuts.

[BillyO]

- SCPI export does not work at all!!!

Which command are you talking about here?  There is no reference to the word "export" in the programming manual.