SDS800X HD Bug Reports + Firmware

[electronics hobbyist]

I learn from everyone on the forum in my spare time, and I am a Siglent fan.
I try to be objective and hope to discuss various technical issues with everyone.

This thread was created mainly for the following purposes:
- Avoiding a wrong perception of "too many bugs".
- makes sure that the real bugs get proper attention and are not lost in the noise.

As mentioned in another thread, Siglent is more concerned about bugs, and fixing bugs is Siglent's obligation.
There may be some discussions during the process, it's okay. If you're not sure if it's a bug, you can send me a private message and we'll try to avoid too much posts.

When a new version is released, I will put the link at the end, cross out the resolved bugs with a horizontal line after verification, and indicate which version has been modified.

In order to make the problem description clearer, based on everyone's suggestions, it is defined as the following format:

Version: 1.1.3.3

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

Test signal: (If it is not related to the signal, it can be written as "Null")
-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: (Expected behavior can be written below)
-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


The following is the list of bugs and versions:

Bugs:
1. After saving the reference waveform, clicking the save button will restore it to png type.The save/recall and save button functions interact with each other. -- Martin
https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/msg5383955/#msg5383955
Note:This bug should be a Wanted Feature and has been added to Wanted Feature No.26.

2. Some parameters have not been restored after selfcal, such as fft vertical gear, fft markers, and channel vertical settings. -- Martin
https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/msg5383955/#msg5383955

3. After rebooting, the vertical gear of FFT did not restored. -- Martin
https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/msg5396141/#msg5396141

4. There have been crashes when using CAN and IIC decoding.The probability of reproduction is relatively low. -- Mortymore
https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/msg5396960/#msg5396960

5. The universal knob can only set the history frame when opening the menu, and should be able to operate the list when closing the menu.  -- ebastler
https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/msg5424557/#msg5424557

6. When the menu disappears, the universal knob light is still on, and at this time, the universal knob is used to change the brightness of the waveform.  -- newbrain
https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/msg5401697/#msg5401697

7. Measuring with cursors on a history frame is impossible, since moving the cursor changes the history frame simultaneously. -- eTobey

8. Math Function dialog automatically closes after channel change. -- eTobey
https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/msg5426099/#msg5426099
https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/msg5414804/#msg5414804

9. Trigger holdoff fails. -- eTobey
https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/msg5424071/#msg5424071

10. SMB Client does not autoconnect when DHCP.  -- eTobey
https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/msg5417699/#msg5417699

11. History frame and intensity will change simultaneously.  -- eTobey
https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/msg5424257/#msg5424257

12. Sequence is restart when menus are opened and closed. -- eTobey
https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/msg5426579/#msg5426579

13. Scale number overlaying others.  -- eTobey
https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/msg5426687/#msg5426687

14. The setting of the trigger type edge(When edge slope is set to alternate) influences the qualified trigger.  -- eTobey
https://www.eevblog.com/forum/testgear/sds800x-hd-bug-reports-firmware/msg5467114/#msg5467114

15. When adjusting the level for source A in "trigger delay", and setting it below low level of signal, acquire stops. -- eTobey
https://www.eevblog.com/forum/testgear/sds800x-hd-bug-reports-firmware/msg5462833/#msg5462833
https://www.eevblog.com/forum/testgear/sds800x-hd-bug-reports-firmware/msg5466322/#msg5466322

16. Most trigger settings for the Delay trigger are lost upon reboot. -- ebastler
https://www.eevblog.com/forum/testgear/sds800x-hd-bug-reports-firmware/msg5466322/#msg5466322

17. Qualified and Delay triggers level indicator is wrong in zoom mode. -- eTobey
https://www.eevblog.com/forum/testgear/sds800x-hd-bug-reports-firmware/msg5469073/#msg5469073
https://www.eevblog.com/forum/testgear/sds800x-hd-bug-reports-firmware/msg5469121/#msg5469121

Version download:
https://siglentna.com/service-and-support/firmware-software/digital-oscilloscopes/#sds800x-hd-series
SDS800X HD Firmware_V1.1.3.3 (Release Date 03.04.24 )

Latest developments:
1.1.3.5 version in beta testing phase
https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/msg5452385/#msg5452385

[ebastler]

Just replying to "subscribe" to this thread.

Could you update your signature to point here and to the newly renamed "Features" thread? That might help others to get their bearings. It currently still points to your original bug/features summary post, in the thread which is now focused on feature suggestions.

[electronics hobbyist]

Could you update your signature to point here and to the newly renamed "Features" thread? That might help others to get their bearings. It currently still points to your original bug/features summary post, in the thread which is now focused on feature suggestions.

I have made modifications according to your suggestion, but due to the valid signature length, I had to reluctantly remove the review thread. If everyone need to know what this oscilloscope can do, you can refer to:
https://www.eevblog.com/forum/testgear/sds800x-hd-review-demonstration-thread/

Meanwhile, OP has added the Latest developments section.

[eTobey]

I found a bug:
When adjusting the level for source A in "trigger delay", and setting it below low level of signal, acquire stops. At 50% level it triggers kind of slow, but below the rate increases, but then eventually stops completely. The trigger does not restart after moving it back.

[2N3055]

I found a bug:
When adjusting the level for source A in "trigger delay", an setting it below low level of signal, acquire stops. At 50% level it triggers kind of slow, but below the rate increases, but then eventually stops completely.

Hi.
Can you try something?

If you go from Normal to Auto trigger mode (Auto button in trigger area) does it happen then?
Press Auto an go in Trigger and change that level same way.

[ebastler]

When adjusting the level for source A in "trigger delay", an setting it below low level of signal, acquire stops.

If you set the trigger level below the signal, the Source A state will never change. So it seems natural that the "<some time window> after a state change" condition is no longer met.   

At 50% level it triggers kind of slow, but below the rate increases, but then eventually stops completely.

You mean the trigger rate decreases as you go below 50%, right?

What is the timing condition you have set for the delay trigger? It looks like your CH1 and CH3 change at pretty much the same time, so there's a race condition. Changing the trigger threshold for CH3 might shift the starting point for the delay condition by just the tiny required amount needed to either meet or fail the timing condition? 

[eTobey]

I found a bug:
When adjusting the level for source A in "trigger delay", an setting it below low level of signal, acquire stops. At 50% level it triggers kind of slow, but below the rate increases, but then eventually stops completely.

Hi.
Can you try something?

If you go from Normal to Auto trigger mode (Auto button in trigger area) does it happen then?
Press Auto an go in Trigger and change that level same way.

I can not observe a freeze with auto trigger. But there is something else i observed:
There is only a stable trigger from 0V to 300mv (the signal is 3.3V).

[eTobey]

When adjusting the level for source A in "trigger delay", an setting it below low level of signal, acquire stops.

If you set the trigger level below the signal, the Source A state will never change. So it seems natural that the "<some time window> after a state change" condition is no longer met.   

At 50% level it triggers kind of slow, but below the rate increases, but then eventually stops completely.

You mean the trigger rate decreases as you go below 50%, right?

What is the timing condition you have set for the delay trigger? It looks like your CH1 and CH3 change at pretty much the same time, so there's a race condition. Changing the trigger threshold for CH3 might shift the starting point for the delay condition by just the tiny required amount needed to either meet or fail the timing condition?

I think my video will answer all your questions.

[ebastler]

I think my video will answer all your questions.

No, it did not. It left me with exactly those questions, which is why I asked them. How about you answering them now?

[rf-loop]

I found a bug:
When adjusting the level for source A in "trigger delay", and setting it below low level of signal, acquire stops. At 50% level it triggers kind of slow, but below the rate increases, but then eventually stops completely. The trigger does not restart after moving it back.

I would also like to remind of this in general:
Trigger: Accuracy (typical) CH1 ~ CH4: ±0.2 div
Sensitivity CH1 ~ CH4 : DC ~ Max BW : 0.6div

As can see in your images some signals are barely over 0.6 div from signal bottom to top.

It is also good to remember that the triggering has vertical hysteresis and it need meet this. It has to be there, it is mandatory for trigger.
Personally, I wouldn't use such a low relative sigal level if I wanted to make sure that the trigger is as sure as rock solid. You can try set bit more channel sensitivity. 

And note. I do not try claim this is poroblem there now.  But in general, take care, you are working near trigger system borderline.




If look rising edge based triggers.  It trig when signal cosses trig level (3) but only IF signal level have first crossed trigger hysteresis threshold level (2). If it crosses hysteresis and go back below hyst threshold it of course do not trig (1). Only it trig if it first crosses (upwards) Hyst Threshold level and then upwards Trigger level. There is no any visible sign about this trigger hysteresis threshold level. (amount of hysteresis (gap between hysteresis level threshold and trigger level) is not just one fixed value. Trigger noise reduction affect to this hysteresis.
It can also see with very low signal levels. It maybe do not trig if trigger level is set middle og signal p-p but but moving it near top it still may trig (unreliable) if sigal just cross hyst level and trig level barely. So it "looks like" trigger have offset. But no, it have not. This behavior is based to this hysteresis. naturally if we use falling edge based trig... this system (as in image) is  vertically flipped.
Experience with triggers can only be achieved when you know the functioning of the triggering system a little more deeply. Of course, ordinary simple use does not require it. But in problematic situations, "know your device" is a guide worth its weight in gold.

[eTobey]

I found a bug:
When adjusting the level for source A in "trigger delay", and setting it below low level of signal, acquire stops. At 50% level it triggers kind of slow, but below the rate increases, but then eventually stops completely. The trigger does not restart after moving it back.

I would also like to remind of this in general:
Trigger: Accuracy (typical) CH1 ~ CH4: ±0.2 div
Sensitivity CH1 ~ CH4 : DC ~ Max BW : 0.6div

I thought about the hysteresis too, but on rising edge it should not trigger where it actually triggered?

Where do you got these values from? The trigger accuracy seems to be much more accurate than your numbers.

[eTobey]

When adjusting the level for source A in "trigger delay", an setting it below low level of signal, acquire stops.

If you set the trigger level below the signal, the Source A state will never change. So it seems natural that the "<some time window> after a state change" condition is no longer met.   

At 50% level it triggers kind of slow, but below the rate increases, but then eventually stops completely.

You mean the trigger rate decreases as you go below 50%, right?

What is the timing condition you have set for the delay trigger? It looks like your CH1 and CH3 change at pretty much the same time, so there's a race condition. Changing the trigger threshold for CH3 might shift the starting point for the delay condition by just the tiny required amount needed to either meet or fail the timing condition?

It freezes: no more triggering what so ever.

No, i meant the trigger rate has risen. (Why do you think the other way around?)

There are more edges blue can have on the left side.

I just had it freeze without doing nothing, so i suspect it may be related to the trigger holdoff issue. Therefore i will not discuss this any further and ignore it for now.

[ebastler]

It freezes: no more triggering what so ever.

No, i meant the trigger rate has risen. (Why do you think the other way around?)

There are more edges blue can have on the left side.

I just had it freeze without doing nothing, so i suspect it may be related to the trigger holdoff issue. Therefore i will not discuss this any further and ignore it for now.

If you had a trigger holdoff dialed in, then I  agree, all bets are off for now.

Looking at your video and screenshots, I am still wondering about the timing condition you have set. It looks an awful lot like the rising and falling edges of CH1 and CH3 occur at more or less the same time, and due to the finite rise time the exact timing will be determined by the trigger level you set.  If that is indeed the case, it would be an ill-defined trigger condition and you should think about other edge relationships (timing) to trigger on.

[eTobey]

It freezes: no more triggering what so ever.

No, i meant the trigger rate has risen. (Why do you think the other way around?)

There are more edges blue can have on the left side.

I just had it freeze without doing nothing, so i suspect it may be related to the trigger holdoff issue. Therefore i will not discuss this any further and ignore it for now.

If you had a trigger holdoff dialed in, then I  agree, all bets are off for now.

Looking at your video and screenshots, I am still wondering about the timing condition you have set. It looks an awful lot like the rising and falling edges of CH1 and CH3 occur at more or less the same time, and due to the finite rise time the exact timing will be determined by the trigger level you set.  If that is indeed the case, it would be an ill-defined trigger condition and you should think about other edge relationships (timing) to trigger on.

I dont see no such thing as holdoff in delay trigger. It might still relate to the holdoff issue, as i had another issue with, i believe it was delay trigger too, when i have set alternating edge on edge trigger. That means settings of edge trigger influenced the behaviour of the delay trigger.

Good point about ill formed trigger, but then the problem should dissappear right after i put the levels back?

In the meantime i found another issue, maybe it is somehow related:

At about 0:02, you can see a falling egde of C3 on the left side of the screen. This should be a measure to the falling edge of C1 on the right side of the screen, but the measure count stays zero. Later on i go into history and scroll back to this very same frame, and at about 0:16 you can see that it was a valid condition for measurement, as it has been counted. It has been missed in the first place.

[KungFuJosh]

If you're going to capture the whole screen, click the button to expand the scope to fullscreen.

[rf-loop]

I found a bug:
When adjusting the level for source A in "trigger delay", and setting it below low level of signal, acquire stops. At 50% level it triggers kind of slow, but below the rate increases, but then eventually stops completely. The trigger does not restart after moving it back.

I would also like to remind of this in general:
Trigger: Accuracy (typical) CH1 ~ CH4: ±0.2 div
Sensitivity CH1 ~ CH4 : DC ~ Max BW : 0.6div

I thought about the hysteresis too, but on rising edge it should not trigger where it actually triggered?

Where do you got these values from? The trigger accuracy seems to be much more accurate than your numbers.

These are from data sheet (rev EN01C) .
Of course they are conservative limits. Individual scope may be better. Note also Sensitivity  DC to Max BW

[eTobey]

Which button?
Aaah that tiny almost colorless one down there. Jeez i was desperatly looking for it and thought you wanted to fool me. Something that could be improved  .
Funfact:
The manual does not say anything about this button.

[electronics hobbyist]

In the meantime i found another issue, maybe it is somehow related:

At about 0:02, you can see a falling egde of C3 on the left side of the screen. This should be a measure to the falling edge of C1 on the right side of the screen, but the measure count stays zero. Later on i go into history and scroll back to this very same frame, and at about 0:16 you can see that it was a valid condition for measurement, as it has been counted. It has been missed in the first place.

This is not a bug. Trigger and measurement are two separate parts. Trigger is implemented by hardware, while measurement is implemented by software. It is not possible to measure every captured frame. The signal you input frequency is 5k, and the run state measurement speed cannot reach 5k wf/s. You should modify the title of this video to avoid misunderstandings.

[electronics hobbyist]

I suggest everyone discuss in another thread or send me a private message first. If the bug is confirmed, I will write it to this thread in the standard format.
I'm not limiting everyone's opinions. Let's stick to this for a while and see the effect first.

It is more appropriate to discuss here:
https://www.eevblog.com/forum/testgear/sds800x-hd-featureimprovment-disscusions/

[eTobey]

This is not a bug. Trigger and measurement are two separate parts.

I have edited the title accordingly. I was pretty sure that it was a bug, because it really "looked" like one. 

[electronics hobbyist]

This is not a bug. Trigger and measurement are two separate parts.

I have edited the title accordingly. I was pretty sure that it was a bug, because it really "looked" like one. 

Yes, It just looks like, I also hope a manufacturer can achieve a measurement speed of 100k frames/s or even millions frames/s, currently no manufacturer can do it (if it capturing a frame and then measuring one frame, this will significantly decrease the capture rate), as long as the capture rate is greater than the measurement speed, this phenomenon will occur. 

[Martin72]

No picture possible in PM, so i put it here:

There are two possibilities.
Either you use a picture upload service and post the link to the person you had pm contact with.
Or you can explain the context to the rest of the public here, i.e. what the picture is about and the corresponding backstory.

[eTobey]

No picture possible in PM, so i put it here:

There are two possibilities.
Either you use a picture upload service and post the link to the person you had pm contact with.
Or you can explain the context to the rest of the public here, i.e. what the picture is about and the corresponding backstory.

What is a good upload service?

[ebastler]

I found a bug:
When adjusting the level for source A in "trigger delay", and setting it below low level of signal, acquire stops. At 50% level it triggers kind of slow, but below the rate increases, but then eventually stops completely. The trigger does not restart after moving it back.

I looked at this again, and can reproduce it with simplified signals (just two square waves). All I can see, in my experiments and in your video, is:

• If you drop the CH3 threshold below the CH3 signal swing, there are no valid transitions in Source A anymore. Hence no triggering; that's to be expected.

• As you raise the CH3 threshold higher and higher, the low-to-high transition in CH3 will be detected later and later. Eventually it will no longer occur before the CH1 transition, but afterwards. And the next transition in CH1 is well outside the time window you have set for the delay trigger condition. Hence no triggering; that seems correct too.
  

I don't observe the "trigger does not restart after moving the threshold back" in my setup. And I actually can't see it in your video. Did I overlook it or is it not captured? Are you sure it's a reproducible effect for you? If so, please document the exact conditions -- thanks!

In Normal triggering mode, when the CH3 threshold is adjusted either too high or too low, triggering does indeed not restart once the threshold is set back to a good value. Some other change to the trigger settings (e.g. a minor change to the other channels's threshold) is required to restart triggering. That's a bug -- in a rather special situation, but I can see how it can leave the user very puzzled why the trigger does not work.

Also, most trigger settings for the Delay trigger are lost upon reboot: Source A channel selection and thresholds,  delay time condition and value(s). Only the Source B channel seems to be remembered. That's another bug I would say.

[eTobey]

Another issue: i am pretty sure i could use the b-word:
The setting of the trigger type edge influences the qualified trigger. In the first part of the video the trigger is not exactly stable, only if the slope of edge trigger is changed, the qualified triggers works without issues.