SDS800X HD Wanted Features

[tautech]

Isnt the auto trigger supposed to trigger "all the time" even when there are no changes in the level, when there is no holdoff set up?

My auto trigger does not even trigger when there are pulses... It does for a few moments, then freezes. The frequency reading is reading something.

Just realized, that the normal trigger does this too!

Short pulses every 2.5us and some longer in between.

When i move the trigger, it starts to work again for a few seconds.

WTF? This scope starts to get annoying! Only started to use it this morning. 

Edit:
Issue confirmed on pulse trigger mode too! Does happen with 3ms holdoff.
It seems that there is a general holdoff bug, that is not only related to edge trigger???

Correct.
We are expecting a beta FW in a day or 3 to test.

FYI there are 4 trigger modes in the Trigger dropdown menu:
Auto
Normal
Single
Force

Each has their own usefulness and every one requires an appropriate level setting for correct results, that is the signal must meet the trigger setting to obtain a stable trigger/waveform/capture.

[2N3055]

Isnt the auto trigger supposed to trigger "all the time" even when there are no changes in the level, when there is no holdoff set up?

My auto trigger does not even trigger when there are pulses... It does for a few moments, then freezes. The frequency reading is reading something.

Just realized, that the normal trigger does this too!

Short pulses every 2.5us and some longer in between.

When i move the trigger, it starts to work again for a few seconds.

WTF? This scope starts to get annoying! Only started to use it this morning. 

Edit:
Issue confirmed on pulse trigger mode too! Does happen with 3ms holdoff.
It seems that there is a general holdoff bug, that is not only related to edge trigger???

Your reports are infuriatingly incomplete. After hundreds of explanations how it should be done so other people could understand what are you talking about.

What signal are you looking at? Is that complicated to make a screenshot and post it?

"this  is stupid, and WTF and today I was doing something and scope showed something and it didn't work and this scope is annoying."

Seriously.
Take a step back, read your own post and tell us what would you understand if someone else posted that? What actual information did you post that would help us help you?

You are using holdoff with pulse trigger? What is scenario? I told you before to not use Edge+Hold Off because Pulse trigger works perfectly for bursts like protocols and you don't need holdoff.

[eTobey]

FYI there are 4 trigger modes in the Trigger dropdown menu:
Auto
Normal
Single
Force

Each has their own usefulness and every one requires an appropriate level setting for correct results, that is the signal must meet the trigger setting to obtain a stable trigger/waveform/capture.

Is there something that makes you think i dont know these details?

[ebastler]

Isnt the auto trigger supposed to trigger "all the time" even when there are no changes in the level, when there is no holdoff set up?

My auto trigger does not even trigger when there are pulses... It does for a few moments, then freezes. The frequency reading is reading something.

Just realized, that the normal trigger does this too!

Short pulses every 2.5us and some longer in between.

When i move the trigger, it starts to work again for a few seconds.

WTF? This scope starts to get annoying! Only started to use it this morning. 

Edit:
Issue confirmed on pulse trigger mode too! Does happen with 3ms holdoff. The thresshold when it happens is about 885us holdoff.
It seems that there is a general holdoff bug, that is not only related to edge trigger???

It would be really helpful if you could provide more clarity and detail.

- Is trigger holdoff involved (as stated in your final paragraph) or not (first paragraph)?
- What's the exact timing of your "short" and "longer" pulses?
- What were your scope timebase and acquisition setttings, and your pulse trigger settings?

[eTobey]

- Is trigger holdoff involved (as stated in your final paragraph) or not (first paragraph)?
- What's the exact timing of your "short" and "longer" pulses?
- What were your scope timebase and acquisition setttings, and your pulse trigger settings?

It is, as stated in the last. That autotrigger might be a different issue, i dont know. I am already tired of investigating issues...

I can give you those anymore, but they are  about 1us pulses (10us the longer) i would guess. Interval would be like 80-150us.

I put the settings file in my original post.

[eTobey]

Improvement suggestion:
When observing a waveform at 50ms/div (window of 0.5s), it only gets updated every 1.8s in auto trigger mode. (no holdoff)
That would mean, that i will miss 72% of the signal.

Aqcuire mode fast, memory 10K (makes no difference).

Moving the trigger with the touchscreen is lagging a lot.
This is not a great performance...

No, roll mode is not an option...

See settings file attached.

[ebastler]

When observing a waveform at 50ms/div (window of 0.5s), it only gets updated every 1.8s in auto trigger mode. (no holdoff)

That 1.8 second interval only applies when there are no valid trigger events, right? (I actually measure 1.6 seconds then.) If valid trigger events occur regularly, I measure a capture period of 0.54 seconds.

That's expected behaviour: In Auto-trigger mode, the scope will wait "a while" for a valid trigger event, to show the waveform in sync with the trigger if possible. Only if no trigger event occurs during that timeout period, an un-synchronized capture will be triggered started. The duration of that timeout period is proportional to the total sweep time.

If Auto-trigger would restart a new capture right after the prior one, even without seeing a trigger event, you would have the scope in free-running mode, and even a valid recurring signal would not appear stable on the screen.

[ebastler]

- Is trigger holdoff involved (as stated in your final paragraph) or not (first paragraph)?
- What's the exact timing of your "short" and "longer" pulses?
- What were your scope timebase and acquisition setttings, and your pulse trigger settings?

It is, as stated in the last. That autotrigger might be a different issue, i dont know. I am already tired of investigating issues...
I can give you those anymore, but they are  about 1us pulses (10us the longer) i would guess. Interval would be like 80-150us.
I put the settings file in my original post.

I may try to reproduce this later today when I find some more time. To describe the conditions of a problem, I am not a big fan of sharing the settings XML (only). Essentially that means that you leave it to the readers to (a) mess up their scope settings by loading that XML, then (b) figure out which unusual hidden settings might be active, and (c) figure out which of these are relevant for the observed, unexpected scope behaviour.

You will find a much more receptive audience if you figure out the specific steps and settings needed to create the unexpected behaviour, and walk us through those in your report.

[eTobey]

When observing a waveform at 50ms/div (window of 0.5s), it only gets updated every 1.8s in auto trigger mode. (no holdoff)

That's expected behaviour: ....

It should be possible to capture the waveform continuesly and the draw it on the screen, aligned to a trigger event or not. I you would take 2 "screens" (to adjust for e potential trigger event) and show just the one screen, that would give you 50% miss...

To argue about this, its possible to do another topic. But i gues siglent would not care about this then.

[eTobey]

I may try to reproduce this later today when I find some more time. To describe the conditions of a problem, I am not a big fan of sharing the settings XML (only). Essentially that means that you leave it to the readers to (a) mess up their scope settings by loading that XML, then (b) figure out which unusual hidden settings might be active, and (c) figure out which of these are relevant for the observed, unexpected scope behaviour.

You will find a much more receptive audience if you figure out the specific steps and settings needed to create the unexpected behaviour, and walk us through those in your report.

I did so much research about bugs and other stuff, that is now time that other users can do a bit more work here too. Hit those scope buttons, not those keyboard buttons!

[2N3055]

- Is trigger holdoff involved (as stated in your final paragraph) or not (first paragraph)?
- What's the exact timing of your "short" and "longer" pulses?
- What were your scope timebase and acquisition setttings, and your pulse trigger settings?

It is, as stated in the last. That autotrigger might be a different issue, i dont know. I am already tired of investigating issues...
I can give you those anymore, but they are  about 1us pulses (10us the longer) i would guess. Interval would be like 80-150us.
I put the settings file in my original post.

I may try to reproduce this later today when I find some more time. To describe the conditions of a problem, I am not a big fan of sharing the settings XML (only). Essentially that means that you leave it to the readers to (a) mess up their scope settings by loading that XML, then (b) figure out which unusual hidden settings might be active, and (c) figure out which of these are relevant for the observed, unexpected scope behaviour.

You will find a much more receptive audience if you figure out the specific steps and settings needed to create the unexpected behaviour, and walk us through those in your report.

That has been explained more than dozen of times. This particular person is not here to cooperate and make a meaningful contribution to SDS800xHD owner's club.
What are the motives for this behaviour I don't know and won't speculate.

But look at the signature in best manner of Goebbels propaganda, shaped to a priory make any statement made by anybody contradicting him with any valid argument invalid. Sarcastic remarks and rude comebacks to people trying to teach him things (both about how scopes work, and his antisocial behaviour). Extremely histrionic literal style, egocentrism and narcissism together with Dunning Kruger that so often follow that combination. Nobody has any clue except him. "My way or highway" attitude and extreme sense of entitlement. Like all people are his servants and how dare they not obey...

I gave up.
I simply ignore answering to his posts, because less than 5% of them are useful. Rest is just raging Dunning Kruger on display... There are more than 150 posts in this topic alone by him and 6 bug findings that he actually contributed. Which several other people (including you) had to use pliers to extract from him useful data and actually formulate what the problem is.

Which is shame, because it doesn't have to be that way.
And don't worry, he will become increasingly rude to you too with time. As long as you don't nod "yes master" to everything he says.

[AndyC_772]

Since we're collecting wanted features...

Last week I had to spend some time debugging a product in which data is sent between a controller and a number of remote devices over an RS485 bus. I used my MSO-X3054A to perform serial decoding, which worked well, but as some of you have seen from my thread elsewhere, I'm considering retiring it in favour of a Siglent.

The product in question is slightly unusual in that it uses 9 bit UART characters, ie. 9 actual data bits, not 8 plus parity. This is an option supported in many STM32 UARTs, and in this case I used the MSB as an out-of-band signal to indicate the start of a data packet.

A quick RTFM suggests the Siglent can't decode 9 bit data, which means it couldn't have done the job. I also couldn't find a spec for the maximum UART rate that the 800X_HD or 2000X_HD are able to decode. I've developed products using UART interfaces up to 10 Mbps in the last few years, so that would be a realistic minimum for me.

Also - I had to connect a separate active differential probe across the A and B wires to extract a differential signal to decode. It would have been preferable to hook up two channels, set up A-B as a maths channel, then run the decoder on the result - but that wasn't possible, and it's not clear that the Siglent can do this either. This seems odd given that for CAN decoding it seems to expect both CANH and CANL, which is effectively the same problem electrically. (I presume it subtracts one from the other internally - right?)

So, feature requests please:

1) UART decoding of 9 bit data;
2) UART decoding of a differential signal, using 2 channels;
3) CAN decoding using just CANH or CANL (which is perfectly valid and possible if they're clean signals in a lab environment)

...and if anyone would be so kind, could you let me know the highest supported UART baud rate? Thanks!

[2N3055]

Since we're collecting wanted features...

Last week I had to spend some time debugging a product in which data is sent between a controller and a number of remote devices over an RS485 bus. I used my MSO-X3054A to perform serial decoding, which worked well, but as some of you have seen from my thread elsewhere, I'm considering retiring it in favour of a Siglent.

The product in question is slightly unusual in that it uses 9 bit UART characters, ie. 9 actual data bits, not 8 plus parity. This is an option supported in many STM32 UARTs, and in this case I used the MSB as an out-of-band signal to indicate the start of a data packet.

A quick RTFM suggests the Siglent can't decode 9 bit data, which means it couldn't have done the job. I also couldn't find a spec for the maximum UART rate that the 800X_HD or 2000X_HD are able to decode. I've developed products using UART interfaces up to 10 Mbps in the last few years, so that would be a realistic minimum for me.

Also - I had to connect a separate active differential probe across the A and B wires to extract a differential signal to decode. It would have been preferable to hook up two channels, set up A-B as a maths channel, then run the decoder on the result - but that wasn't possible, and it's not clear that the Siglent can do this either. This seems odd given that for CAN decoding it seems to expect both CANH and CANL, which is effectively the same problem electrically. (I presume it subtracts one from the other internally - right?)

So, feature requests please:

1) UART decoding of 9 bit data;
2) UART decoding of a differential signal, using 2 channels;
3) CAN decoding using just CANH or CANL (which is perfectly valid and possible if they're clean signals in a lab environment)

...and if anyone would be so kind, could you let me know the highest supported UART baud rate? Thanks!

1. That has been mentioned before. Would be good to have.
2. I don't think that can be trivially added.
3: Yes you can : [CAN Signal]->[Source] you can use CAN_H, CAN_L or CAN_H-L. 

Max UART speed I don't know. Would need to be tested.

Max speed in GUI that can be set is 20Mbit.
I just tested with 1Mbit and it is chugging along very nicely.

[Performa01]

I’m always really sorry to hear about the huge problems some folks are experiencing with Siglent instruments day after day.

Serious troubles, like a totally unusable “lagging” zoom function or a non-working trigger would bother me too – just like the awfully inefficient user interface.

What surprises me is the fact that highly knowledgeable and critical persons made the mistake to buy such an unusable instrument in the first place. All the top experts tell us over and over again that we cannot expect much from the cheap Chinese brands.

So the logical consequence would be to “scrap the toys and get a real oscilloscope”, right? why not follow that Keysight-slogan and get one of their real scopes – or a Tektronix maybe? All problems will be gone, all tasks will be easy and highly efficient – even those that oscilloscopes generally are not intended for, like high volume serial protocol analysis and debugging.

For those still sticking with Siglent, rest assured that real bug reports will always be taken seriously and realistic feature requests will be considered. Such input from serious people will always be welcome.

[ebastler]

I did so much research about bugs and other stuff, that is now time that other users can do a bit more work here too. Hit those scope buttons, not those keyboard buttons!

"Every time I drive from A-Town to B-Village, my car looses a hub cap! The car must be broken. Please find the full GPS track of my trip attached."

And now you expect others to make the same trip and look for something unusual along the road? Because you could not be bothered to keep an eye out and notice the big fat pothole halfway?? I'm afraid that is not how it normally works.

---

Nevertheless I just loaded your Setup file from the "auto trigger sometimes freezes" report. My test signal has 40 pulses of 1 µs duration at a 2.5 µs period, followed by 1 pulse of 10 µs duration, so the total cycle time is 110 µs. This should match what you described in response to my follow-up question. Whether in Auto or Normal triggering mode, I get a stable trigger period of 3.020 ms, which is dominated by the 3 ms holdoff time you have set. Seems fine to me.

[ebastler]

When observing a waveform at 50ms/div (window of 0.5s), it only gets updated every 1.8s in auto trigger mode. (no holdoff)

That's expected behaviour: ....

It should be possible to capture the waveform continuesly and the draw it on the screen, aligned to a trigger event or not. I you would take 2 "screens" (to adjust for e potential trigger event) and show just the one screen, that would give you 50% miss...

It would be really cool if you could acknowledge, every now and then, that what you considered a bug is not one, if someone explains the underlying cause to you. You might even consider thanking that someone for the explanation.

I can't figure out why you would need a free-running, capture-all-the-time mode. To my mind, Auto trigger mode is only there to help me get my bearings if I have not set the trigger condition properly, so my solution is to adjust that. If you have a signal which only appears sporadically (or which only takes a shape which meets the trigger condition sporadically), why would you be interested in capturing and rendering all the non-relevant parts inbetween?

And yes, please get rid of that signature.

[AndyC_772]

@2N3055 - thanks 

2. I don't think that can be trivially added.

Surely if it can decode (CANH - CANL), it should be able to do (A - B) as well? After all, it's the exact same data flow, and a differential UART interface is a very common thing indeed. (At least, in a world where UARTs are used at all...!)

3: Yes you can : [CAN Signal]->[Source] you can use CAN_H, CAN_L or CAN_H-L. 

Handy to know, it's just the manual that's unclear, then.

ps. I've just ordered an SDS804X-HD to play with 

[2N3055]

@2N3055 - thanks 

2. I don't think that can be trivially added.

Surely if it can decode (CANH - CANL), it should be able to do (A - B) as well? After all, it's the exact same data flow, and a differential UART interface is a very common thing indeed. (At least, in a world where UARTs are used at all...!)

3: Yes you can : [CAN Signal]->[Source] you can use CAN_H, CAN_L or CAN_H-L. 

Handy to know, it's just the manual that's unclear, then.

ps. I've just ordered an SDS804X-HD to play with 

To be honest UART is just that: UART single ended signal as it comes in TTL form from µC for instance.
RS232 or RS485 are electrical interface specification, single ended and differential.

I double checked on my MSOX3104T to make sure memory serves me right, and it is also absolutely same in that regard. Single signal, idle LOW/HIGH.

[mawyatt]

FYI there are 4 trigger modes in the Trigger dropdown menu:
Auto
Normal
Single
Force

Each has their own usefulness and every one requires an appropriate level setting for correct results, that is the signal must meet the trigger setting to obtain a stable trigger/waveform/capture.

Is there something that makes you think i dont know these details?

Yes, everything that you've posted   

Best,

[2N3055]

@2N3055 - thanks 

2. I don't think that can be trivially added.

Surely if it can decode (CANH - CANL), it should be able to do (A - B) as well? After all, it's the exact same data flow, and a differential UART interface is a very common thing indeed. (At least, in a world where UARTs are used at all...!)

3: Yes you can : [CAN Signal]->[Source] you can use CAN_H, CAN_L or CAN_H-L. 

Handy to know, it's just the manual that's unclear, then.

ps. I've just ordered an SDS804X-HD to play with 

While you are waiting, 20Mbit UART decoding:

[Performa01]

ps. I've just ordered an SDS804X-HD to play with 

I'm sorry to say that CAN_H-CAN_L did not work on the SDS800X HD with V1.1.3.3 firmware.

Among other things, this bug will be fixed with the next firmware release, yet unfortunatley the fix might not be what you expect: the CAN_H-CAN_L setting will just be deleted from the UI.

Some background information:

Serial decoders are closely related to serial triggers. We can copy settings from one to the other. Triggers are working in hardware on the trigger data stream, which is completely seperate to the record data. This should explain why a digital trigger can only work on physical input channels and not math results, and for some reasons we don't get the subtraction done in hardware on the basic SDS800X HD. And because of the before mentioned close relationship with the decoders, they also cannot accept any other data sources as the input channels.

[eTobey]

I did so much research about bugs and other stuff, that is now time that other users can do a bit more work here too. Hit those scope buttons, not those keyboard buttons!

"Every time I drive from A-Town to B-Village, my car looses a hub cap! The car must be broken. Please find the full GPS track of my trip attached."

And now you expect others to make the same trip and look for something unusual along the road? Because you could not be bothered to keep an eye out and notice the big fat pothole halfway?? I'm afraid that is not how it normally works.

---
Whether in Auto or Normal triggering mode, I get a stable trigger period of 3.020 ms, which is dominated by the 3 ms holdoff time you have set. Seems fine to me.

With this comparison, its like i gave you the GPS track with a presicion of 0.25meters. It should give some clues...

----
The second part is what i really wanted: its called "teamwork". Sad thing is, people today rather like to team up to bash others. 

I did not complain about a stable trigger... You may want to read my post again. (no, its not meant to be rude)

[eTobey]

It would be really cool if you could acknowledge, every now and then, that what you considered a bug is not one [...]

I can't figure out why you would need a free-running, capture-all-the-time mode. [...]

I did not say the B-Wort 


I actually tried to use the autotrigger, as the roll mode was useless in my case. (see following post/suggestion)

[eTobey]

Problem:
Different display mode for "roll mode".

On a rather fast running time setting, the waveform runs too fast through the screen, that it is not readable at all. Pulses of different widths can not be distinguished for example.

Suggestion:
Have a mode, that may be called "scan mode". The waveform (points in time) dont move, but are updated by a moving "scanline".

Imagine a printer that does not move the paper, but instead moves itself. The letters can easily be read, even while printing.

[ebastler]

I did not complain about a stable trigger... You may want to read my post again. (no, its not meant to be rude)

No, I will not read your post again. You had complained about the trigger "freezing", which I understand to meant that it no longer triggers. You did not even say whether it stops entirely or for a while; but as I wrote, I can reproduce neither. My scope keeps triggering stably every 3.020 ms.

From the problem description you gave so far, it seems to me that the most likely cause is that your signal had long dropouts or a bad connection. If you want to convince me otherwise, or want to convince me that I should do further experiments, I'm afraid you have some work to do.