SDS800X HD - Issue disscusions - is it me, or the scope?

[eTobey]

It might be a good idea, to discuss issues that user have, firstly here, instead of the bug and feature topics, as they may not belong there.

Features topic:
https://www.eevblog.com/forum/testgear/sds800x-hd-bugswanted-features/

Bugs topic:
https://www.eevblog.com/forum/testgear/sds800x-hd-bug-reports-firmware/msg5455364/#msg5455364

The first few posts may not seem to fit to the title of the topic, as it was changed later on!

[eTobey]

Suggestion:
When choosing a new measurement (clicking on an existing one) there is one selected, that is already used. One would think that you actually could deselect this, or changing the sources would affect this very measurement. (see picuture).

It can be activated, if you select the one that you actually opened.

Suggested solution:
Differentiate between measurments that are used for the particular channel/s, and the measurement that will be currently changed/activated.

[eTobey]

Minor measurement issue:
In more or less extreme circumstances, the measurements become unreliable. How could one know, that he has gone to far?

As the gate cursors do really stick to the curve, it is quite confusing that they dont, when zooming pretty far in.

The measurements become wrong too, when zoomed out a fair bit!

[ebastler]

As mentioned in the bug thread, I'm afraid the video is not helping me to understand the problem. It is also very blurry; I can't really see anything beyond the fact that you appear to be changing the timebase. 

Could you please elaborate?
- What are you trying to measure?
- What settings are you changing?
- Which traces/cursors/values should I be looking at, at which timestamp?
- How is the behaviour of that trace/cursor/value different from what you expect?

A still screenshot or two are probably better to illustrate the issue, together with the above information. In those you can show the relevant time points (only), and the quality will be much better.

Thanks!

[ebastler]

Thanks for the sharper video. I may still misunderstand what you are concerned about, but I believe it is about two separate issues:

(a) The position of the gate cursors is obviously limited to the time window shown on the screen. So when you zoom far in (100 µs/div and faster in your example), the cursor positions get "clipped" to the screen boundaries. This makes sense to me -- after all, you set the cursors because you want to measure in specific sections of the signal, based on your visual observation of the signal. So why should they be set somewhere out of sight?

(b)  When you zoom far out (50 ms/div and slower), the "green" measurement values, i.e. the inter-channel delays, are no longer correct. At 50 ms/div they are not measured at all; at 100 and 200 ms/div they come back, but are incorrect. I find that unexpected too, since the scope supposedly makes all measurements in its full-resolution data buffer, so they should not change. (And the CH2 width measurements in fact don't change.)

In summary, I see no issue with (a), and an unexpected behaviour -- although not highly relevant in practice -- with (b). And I would love if you could describe such issues similar to what I tried for (b), rather than letting me stare at a video and take my best guess... 

[eTobey]

...

I have now 2 issues in my head. It might get confusing...
- I try to measure the last falling edge from the red to the last rising edge of the blue. There is no LFFR measurement. I though id be smart and use FRLF, and switch the sources, but that dont work.
- I dont change settings? How would you think?
- Video description: Measurements are wrong at zooming out (Keep your eye on value of FRLF), and gates do not stay as they appear otherwise, if you zoom in. Quite easy to miss.

(a) Because i might measure stuff, and look at details.

Your summary:
If one would assume, that those gates will not change, then he would get wrong values if this little detail gets missed. Yes its a case not many would experience, at least not those that are creative. 
I do not really understand what you want me to describe.

[eTobey]

New issue:
How can i measure last rising edge of blue to last falling edge of red?

[ebastler]

New issue:
How can i measure last rising edge of blue to last falling edge of red?

Looking inside your gate window only: After the last rising edge of the blue trace, there is no more falling edge of the red, right? So what do you want to measure?

In general, since there are no delay measurements which start with a last edge, I think you need to work with the trigger to grab the starting edge of interest for such measurements. Then position your measurement gate cursors relativ to the trigger point, such that the starting edge becomes the first edge within the gate window.

(Pulse or Dropout triggers should work well with those signals which have short PWM pulses overlaid on the slower low/high transisitions. Set a ">=" time which lets the trigger ignore the short pulses, that will let you get hold of the longer-period transitions.)

[markone]

Dunno if discussed earlier in other threads, i post my potential desires here :

1) There is a way to "embed" the small floating measure track window in the main display like a math trace ?
2) There is a way to export measure track window data ?

The  track function works surprisingly good for the intrument price segment, but without above mentioned features its potential is heavily limited.

[electronics hobbyist]

Suggestion:
When choosing a new measurement (clicking on an existing one) there is one selected, that is already used. One would think that you actually could deselect this, or changing the sources would affect this very measurement. (see picuture).

It can be activated, if you select the one that you actually opened.

Suggested solution:
Differentiate between measurments that are used for the particular channel/s, and the measurement that will be currently changed/activated.

When clicking "+", there is no need to display the previously all added measurement items.

Edit: I try to understand the current strategy by clicking on an existing measurement item, Pop up measurement selection box will display all the measurement items for all channel. One benefit is to know which measurement items have been added.
The benefit of your suggestion is that it allows for modifications to the current measurement items.

[electronics hobbyist]

1) There is a way to "embed" the small floating measure track window in the main display like a math trace ?

If displayed in full screen, the coordinate system needs to be modified, which is a good feature and the implementation looks a bit complicated. Added Wanted Feature No.32

2) There is a way to export measure track window data ?

Exporting data is a reasonable feature.  Added Wanted Feature No.33

[eTobey]

I think you need to work with the trigger to grab the starting edge of interest for such measurements. Then position your measurement gate cursors relativ to the trigger point, such that the starting edge becomes the first edge within the gate window.

The starting edge can not be measured, as there is no LFXX function. It is then of no matter how you would set up the trigger, is it?

Now i understand...
Yes, the dropout would somehow work. But i dont know how well with those small pulses there. As in another post of mine, there are some measurement issues in some extreme cases. I think just changing the program would be the proper way to handle this.

Edit:
But now i want to measure the same thing on other channels at the same time... what can i do now? (see pciture - yellow last falling edge to green first rising edge)

[eTobey]

This is actually the "range" ?

[ebastler]

This is actually the "range" ?

If the Min and Max values are correct, then yes, that appears to be their difference. Is there reason to assume it is incoprrect?

[ebastler]

But now i want to measure the same thing on other channels at the same time... what can i do now? (see pciture - yellow last falling edge to green first rising edge)

Maybe you would be better off if you use a Math low-pass filter to get rid of the high-frequency PWM pulses, then measure the relative timings of the simplified signals? That's a more straightforward set of measurements which should be possible with a more generous gate window, or without any gating at all.

If the absolute time delays between edges are relevant (and not just relative fluctuations or glitches), you should probably run all channels through low-pass filters with the same settings, to make sure they all see the same filter delay.

[eTobey]

If the Min and Max values are correct, then yes, that appears to be their difference. Is there reason to assume it is incoprrect?

In statistics google told me, that "range" would be the adequate term.

I dont see  how i could measure "last rising edge". I can not set the gate differently, because i need to measure them at the same time. Why is there just no LFxx or LRxx measurement?

[ebastler]

In statistics google told me, that "range" would be the adequate term.

Ah, your concern was about the terminology -- I thought you were wondering about the suspiciously round value. Personally I  would have called the entry "Max-Min", but it does not really matter, does it?

I dont see  how i could measure "last rising edge". I can not set the gate differently, because i need to measure them at the same time. Why is there just no LFxx or LRxx measurement?

Have you tried the low-pass filter, and checked what the FFxx measures on the filtered signals give you? I think you should be alright.

[eTobey]

Have you tried the low-pass filter, and checked what the FFxx measures on the filtered signals give you? I think you should be alright.

I have changed my program to test it. Still i dont know how i should capture that last falling edge, since i cant not move the gate there, wenn i want to measure both delays at the same time.

[ebastler]

Still i dont know how i should capture that last falling edge, since i cant not move the gate there, wenn i want to measure both delays at the same time.

But why do you still need the gate cursors at all now?

With the fast PWM pulses gone, you can now measure the time between any CH1 falling edge and the next CH4 rising edge which follows that, right? And likewise for the other timing measurements you want to take in parallel. I think you can just disable the gating function entirely.

[eTobey]

But why do you still need the gate cursors at all now?

With the fast PWM pulses gone, you can now measure the time between any CH1 falling edge and the next CH4 rising edge which follows that, right? And likewise for the other timing measurements you want to take in parallel. I think you can just disable the gating function entirely.

Didnt you tell me to use the gate to grasp the last falling edge? Yes it now works without some extendes setup.

Still i need the gate, or else it would just grasp the wrong edges, unless you would zoom right. But with the gate i can zoom all i want (to some extend).

See my setup in the pictures, with, and without gate.

[ebastler]

Oh -- I did not realize that these delay measurements can also go backwards in time. I only played with them briefly and had not run into this situation.

Then the manual is wrong: "FRFF: The time between the first rising edge of source A and the following first falling edge of
source B", etc. for the other modes, see section 18.3.4.


Edit: Having thought this over a bit, I would actually prefer if the scope behaved as described in the manual.

In most use cases I can think of, it is clear which edge (in which channel) comes first, e.g. because there is a causal relationship between the signals in both channels. So I can always assign the channels such that a positive delay is to be measured. The scope should then only measure positive delays -- i.e. look for an edge in channel B which follows the edge in channel A. False measurements caused by the scope unintentionally "going back in time" when looking for the nearest edge would be avoided.

So I could argue that the present scope behaviour is a bug -- it's not what the manual says. What do others think? Which behaviour is more useful to you?

[eTobey]

Oh -- I did not realize that these delay measurements can also go backwards in time. I only played with them briefly and had not run into this situation.

Yes, it is a complicated topic. There are many use cases.

Measuring to the following edge would be undesired, if you would measure a delay that swing around the first edge. Then, the current behaviour would be desired.

What do others say?

[tautech]

What do others say?

There are so many changes coming that will impact on many things....I say you should wait until we have the new firmware.
The beta FW Release notes are a substantial list now and also added to a couple days back. 

Only patience will reveal what is to be delivered. 

[eTobey]

I cant wait...   

[eTobey]

I have another issue:
I set up a qualified trigger, but the edge trigger is not stable.
The deviation gets worse, if i set the trigger level lower.

[electronics hobbyist]

I have another issue:
I set up a qualified trigger, but the edge trigger is not stable.
The deviation gets worse, if i set the trigger level lower.

Can you explain your input signal? If you adjust the C4 vertical gear down, will there be a problem? I did not reproduce this problem; You can attach setup.xml. If the configuration is the same, it should be related to the input signal.

[eTobey]

I tried edge trigger to test, and went back to qualified trigger. Now the problem dissappeared, and i have not saved a setup file  .

Tought it was a lack of knowledge, but seemingly it wasnt...

Edit:
found the culprit:
When "alternating edge" is selected on any channel on trigger type edge, then the qualified trigger has this issue.

see setupfile attached.

[gitm]

Has anyone else turned on their SDS800X to find a fixed DC offset (~700 mV) on CH1 and CH1 only?

This has happened twice to mine immediately at power-on on two different days.  CH2, CH3, and CH4 all had no offset (i.e. 0) as expected.  Nothing was connected to any of the inputs.  Selecting the vertical position rotor and pushing to return CH1 trace to 0 had no effect and in the CH1 “box” (bottom left of screen) showed, IIRC, 0 mV.  Scrolling the position down to place the trace on 0 would then show a negative offset.  Setting the vertical position explicitly in the CH1 position entry box to 0 would position the trace to 0+~700mV. 

Shutdown, disconnect power, reboot, and set to default had no effect (something bad stored?). In each case to get the scope back to powering on with DC offset of 0, I set the scope to default and then ran selfcal after warming up for 30 minutes.  Once the selfcal completed the offset was now at 0.   I rebooted the scope and the offset was still gone.  Rebooting a few more times and the offset did not reappear.  So I continued my actual testing for the day.

After a couple of days not being used, I turned on the scope yesterday and the offset returned for a second time.  Same investigation and results as the above paragraph.  I then again continued my actual testing for the day.

I turned the SDS800X on today and the offset remains at 0.   

I will say that “testing for the day” was looking at a 5V/12V rail-splitter with DC coupling and using the vertical position offsets at -2.5V and -6.0V to see what ripple, noise, and droop were present under differing loads, 10X attenuation and 10mV/, and running FFTs.  Maybe this is related.  But then it didn’t reappear this morning. 

Anyone else seen this?

[eTobey]

Pictures! You have to take pictures, because some will never believe you. And you may consider, that some aspects of it a very confusing, so you take your time and try to figure out if its a problem with the setup.

[Martin72]

Has anyone else turned on their SDS800X to find a fixed DC offset (~700 mV) on CH1 and CH1 only?

I didn't have it with my 800X HD, but I had something similar with my 2000X HD at the time.
There, too, the spook disappeared after one or two self-calibrations.

[gitm]

Pictures! You have to take pictures, because some will never believe you. And you may consider, that some aspects of it a very confusing, so you take your time and try to figure out if its a problem with the setup.

Thanks for the response.  But it is irrelevant whether “some believe me” or not.  The question was "whether anyone else has observed this same phenomenon?”  If others have, then they will reply stating such and, implicitly, believe me, not that it matters.  Others that have not, may not reply or might nit pick because “the internet”.  I’m a big boy and my delicate psyche might not break after all.

Regarding “taking my time”, I spent the better part of two days “figuring out if its a problem with the setup” — it’s not.  My first reactions were, "okay what’s happening here?” and “what did I do wrong?”

Regarding “pictures”, I’m fairly certain that a static picture of a trace with an offset of ~700 mV and a CH1 box saying “0.00V” doesn’t help with explaining the issue (or my incompetence) more so than my words?  It’s pretty straight forward and nothing I’ve experienced with my 4 other scopes.

I appreciate the reply/advice and I am not in any way being sarcastic — really, honestly, and truly.

[electronics hobbyist]

Anyone else seen this?

Believe you have encountered this problem. So far, I haven't seen this phenomenon in SDS800XHD. If it appears next time, you can save the setup and let's see if we can duplicate it.

[tautech]

Has anyone else turned on their SDS800X to find a fixed DC offset (~700 mV) on CH1 and CH1 only?

Anyone else seen this?

Not.
There is mention of offset issues in beta FW release notes but not this exact issue it seems.

It is customary when reporting an issue to state the FW version in use.

[gitm]

Not.
There is mention of offset issues in beta FW release notes but not this exact issue it seems.

It is customary when reporting an issue to state the FW version in use.

Point taken.

Software Version 1.1.3.1
UBOOT-OS Version 2.8.10
FPGA Version 2023-12-29
HW Version 00

[tautech]

Not.
There is mention of offset issues in beta FW release notes but not this exact issue it seems.

It is customary when reporting an issue to state the FW version in use.

Point taken.

Software Version 1.1.3.1
UBOOT-OS Version 2.8.10
FPGA Version 2023-12-29
HW Version 00

https://int.siglent.com/upload_file/zip/firmware/Oscilloscope/SDS800X_HD_V1.1.3.3_EN.zip

[gitm]

Thank you.  While the release notes don’t mention offset issues, it does mention "Solve the problem that Bode Plot cannot control sdg1000”.  I do have a SDG1062X, so I’m up for a firmware update. 

[tautech]

Thank you.  While the release notes don’t mention offset issues, it does mention "Solve the problem that Bode Plot cannot control sdg1000”.  I do have a SDG1062X, so I’m up for a firmware update. 

No problem.
I think you will find this means the earlier SDG1k series, not your later 1kX model.

In Bode plot mode all Siglent AWGs are intended to be supported for the FRA stimulus, regardless of their vintage.

[eTobey]

Contradictory findings:
Either the manual is wrong or the scope shows wrong values. I can only count like a few dozent of points.

The timebase also does not show all the time 50Mpts if you zoom out  its sometimes 20 or 40 Mpts.

[eTobey]

Another thing in the manual that does not add up:
Again... 

The X2 is whereever you set it up. So it can also be on the left side. The same problem is with the Y1/2.

[ebastler]

Another thing in the manual that does not add up:
Again... 

The X2 is whereever you set it up. So it can also be on the left side. The same problem is with the Y1/2.

I take "left (default)" to mean that by default -- i.e. before you set it up differently -- X1 is on the left. Makes sense to me?

[ebastler]

Contradictory findings:
Either the manual is wrong or the scope shows wrong values. I can only count like a few dozent of points.

The timebase also does not show all the time 50Mpts if you zoom out  its sometimes 20 or 40 Mpts.

Should be exactly 20 points, right? 200 ns total sweep time, 100 MSa/s, so 20 Samples in 200 ns. You can see the individual data points when you switch the display mode to "Dot".

Did you acquire that data with a much slower time base, then stop and zoom in? In that case, the number of number of samples indicated in the info box might be the number of samples acquired in the sweep, rather than the number of samples shown on-screen at the moment? (I don't have access to my scope at the moment.) The manual would be incorrect in that case.

If the above hypothesis is right, I would probably prefer the scope to behave like stated in the manual, i.e. always tell me how many data points are behind the trace I see on-screen at the moment. In which case this would be a bug or improvement request.

[2N3055]

Another thing in the manual that does not add up:
Again... 

The X2 is whereever you set it up. So it can also be on the left side. The same problem is with the Y1/2.

I take "left (default)" to mean that by default -- i.e. before you set it up differently -- X1 is on the left. Makes sense to me?

It means left as being first on the time axis when doing subtraction.  Diff will be X1-X2.
If you set  X1 left and x2 right, diff will be 10 ns. If you set them the other way around then it will be -10ns.
X1-X2

[2N3055]

Contradictory findings:
Either the manual is wrong or the scope shows wrong values. I can only count like a few dozent of points.

The timebase also does not show all the time 50Mpts if you zoom out  its sometimes 20 or 40 Mpts.

Should be exactly 20 points, right? 200 ns total sweep time, 100 MSa/s, so 20 Samples in 200 ns. You can see the individual data points when you switch the display mode to "Dot".

Did you acquire that data with a much slower time base, then stop and zoom in? In that case, the number of number of samples indicated in the info box might be the number of samples acquired in the sweep, rather than the number of samples shown on-screen at the moment? (I don't have access to my scope at the moment.) The manual would be incorrect in that case.

If the above hypothesis is right, I would probably prefer the scope to behave like stated in the manual, i.e. always tell me how many data points are behind the trace I see on-screen at the moment. In which case this would be a bug or improvement request.

What you saying is not improvement or bug.
Scope shows sampled, acquired points, not current screen points.
What is purpose of useless metric of current screen?

And for other thing eTobey mentions:

In acquisition you set up Max point scope will capture but scope automatically sets points based on timebase.
And for instance, with 2 ch on as you go through timebases once you reach 50Mpts, it will start alternating between 40 and 50 MPts.

I'm guessing you know why but he doesn't understand that if you multiply time on screen with sampling rate you get what sample numbers are possible....

Best,

[tautech]

Contradictory findings:
Either the manual is wrong or the scope shows wrong values. I can only count like a few dozent of points.

The timebase also does not show all the time 50Mpts if you zoom out  its sometimes 20 or 40 Mpts.

The answer is staring you in the face...Peak Detect which is an entirely different acquisition mode and why this mode is always displayed when you select it.

Wanna see sample points, select Normal and Dot mode.

[eTobey]

It means left as being first on the time axis when doing subtraction.  Diff will be X1-X2.
If you set  X1 left and x2 right, diff will be 10 ns. If you set them the other way around then it will be 10ns.
X1-X2

You are dead wrong! It gives -10ns. Even more, when X1 is sometimes on the left, and sometimes on the right, there is a huge risk of confusion, which really bothers me, as electronics can be confusing enough already.

This is not meant to be rude: but i really get frustrated of people saying things that are wrong with an quite a high assurance (in general). Arent we all interested in having a good product?

[2N3055]

It means left as being first on the time axis when doing subtraction.  Diff will be X1-X2.
If you set  X1 left and x2 right, diff will be 10 ns. If you set them the other way around then it will be -10ns.
X1-X2

You are dead wrong! It gives -10ns. Even more, when X1 is sometimes on the left, and sometimes on the right, there is a huge risk of confusion, which really bothers me, as electronics can be confusing enough already.

This is not meant to be rude: but i really get frustrated of people saying things that are wrong with an quite a high assurance (in general). Arent we all interested in having a good product?

Off course it is meant to be rude...  The hint is in a tone and actual rude words you use...
Read occasionally your own signature...

Hint it was a typo... I wasn't wearing glases and didn't notice there is no minus sign.. Fixed now.

[eTobey]

And for instance, with 2 ch on as you go through timebases once you reach 50Mpts, it will start alternating between 40 and 50 MPts.

I'm guessing you know why but he doesn't understand that if you multiply time on screen with sampling rate you get what sample numbers are possible....

You are wrong:
at 20ms/div i got 20Mpts, but above and below i get 50Mpts... (see attached setup)

Are talking about me not understanding? I might miss some things, as i have a few projects ongoing, but if one is able to explain it, i will quickly grasp it.

[eTobey]

Off course it is meant to be rude...  The hint is in a tone and actual rude words you use...
Read occasionally your own signature...

Hint it was a typo... I wasn't wearing glases and didn't notice there is no minus sign.. Fixed now.

You may have gotten that tone wrong. But what is the actual "rude" word? I just expressed my feelings, and just why its is so.

If you have made a typo, it should be clear, that this sentence does not apply anymore, and there is no need of further discussion...

[2N3055]

And for instance, with 2 ch on as you go through timebases once you reach 50Mpts, it will start alternating between 40 and 50 MPts.

I'm guessing you know why but he doesn't understand that if you multiply time on screen with sampling rate you get what sample numbers are possible....

I can proove you wrong again:
at 20ms/div i got 20Mpts, but above and below i get 50Mpts... (see attached setup)

Are talking about me not understanding? I might miss some things, as i have a few projects ongoing, but if one is able to explain it, i will quickly grasp it.

We said and said repeatedly:  nobody is going to solve your puzzles.
Explain yourself better or you get what you get.
You could have explained that at 20ms/in particular you get this shorter length.
At 20ms/div it seems that scope organizes data as if all 4 channels are on even when they are not.
It might be necessary because of how internal data pump works at that sample rate or maybe it can be optimized.
Will ask.

But you still need to work on your communication....

[2N3055]

Off course it is meant to be rude...  The hint is in a tone and actual rude words you use...
Read occasionally your own signature...

Hint it was a typo... I wasn't wearing glases and didn't notice there is no minus sign.. Fixed now.

You may have gotten that tone wrong. But what is the actual "rude" word? I just expressed my feelings, and just why its is so.

If you have made a typo, it should be clear, that this sentence does not apply anymore, and there is no need of further discussion...

Let me try to explain, and now I ask you to not get offended.

To me it seems you can't hardly wait to see something that can used to argue to start arguing.

If someone corrects you and then writes same as you it is either a mistake or the other side didn't take their meds.
Both are good reason not to react with "AHAAAAA I have you now!!!!!!".

That kind of reaction is not truth seeking but an effort to embarrass somebody.

This is not a competition.
If in doubt, clarify...

[eTobey]

We said and said repeatedly:  nobody is going to solve your puzzles.
Explain yourself better or you get what you get.
You could have explained that at 20ms/in particular you get this shorter length.
At 20ms/div it seems that scope organizes data as if all 4 channels are on even when they are not.
It might be necessary because of how internal data pump works at that sample rate or maybe it can be optimized.
Will ask.

But you still need to work on your communication....

These are not my puzzles! These are my confusions that come from bugs, inconsistent behaviour of the scope at many places and confusing errors in the manual.

Can you just acknowledge, that you were wrong with "And for instance, with 2 ch on as you go through timebases once you reach 50Mpts, it will start alternating between 40 and 50 MPts."? It wont wont hurt, trust me, i did it myself.

[eTobey]

Off course it is meant to be rude...  The hint is in a tone and actual rude words you use...
Read occasionally your own signature...

Hint it was a typo... I wasn't wearing glases and didn't notice there is no minus sign.. Fixed now.

You may have gotten that tone wrong. But what is the actual "rude" word? I just expressed my feelings, and just why its is so.

If you have made a typo, it should be clear, that this sentence does not apply anymore, and there is no need of further discussion...

Let me try to explain, and now I ask you to not get offended.

To me it seems you can't hardly wait to see something that can used to argue to start arguing.

If someone corrects you and then writes same as you it is either a mistake or the other side didn't take their meds.
Both are good reason not to react with "AHAAAAA I have you now!!!!!!".

That kind of reaction is not truth seeking but an effort to embarrass somebody.

This is not a competition.
If in doubt, clarify...

Please try to forget what there was before, and answer my simple question.

[rf-loop]

Contradictory findings:
Either the manual is wrong or the scope shows wrong values. I can only count like a few dozent of points.

The timebase also does not show all the time 50Mpts if you zoom out  its sometimes 20 or 40 Mpts.

Should be exactly 20 points, right? 200 ns total sweep time, 100 MSa/s, so 20 Samples in 200 ns. You can see the individual data points when you switch the display mode to "Dot".

Did you acquire that data with a much slower time base, then stop and zoom in? In that case, the number of number of samples indicated in the info box might be the number of samples acquired in the sweep, rather than the number of samples shown on-screen at the moment? (I don't have access to my scope at the moment.) The manual would be incorrect in that case.

If the above hypothesis is right, I would probably prefer the scope to behave like stated in the manual, i.e. always tell me how many data points are behind the trace I see on-screen at the moment. In which case this would be a bug or improvement request.

User manual need some correction.

In this case it is ok for runtime. Runtime, info box bottom row tell acquisition sampling speed and length (points) what is also same as points "behind" one acquistion.
But what you see on screen. Runtime there also can be overlaid several, even thousends of acquisitions depending current wfm/s speed. So we can not tell how many data points are behind visible runtime trace what you see on display. (there is not good way to tell how many dots are behind visible DPO trace in runtime and also this kind of info is useless. )

After oscilloscope is stopped. Independent of stop mode zoom in/zoom out,  information box bottom row tell acquisition sampling speed and length (points) when it was captured in runtime and on stop mode it continue displaying it independent of current t/div.
But in stop mode, info box top row tell current displayed t/div and also time position, example when pan and zoom in when stop mode. So you know "where you are".

In this particular case @eTobey have made acquistion using 20ms/div, 20Mpts length and 100MSa/s.
Then he stop scope and zoomed in by  1/1000000. And also info box tell now his current displayed t/div is 20ns  and he have 100MSa/s sample rate so he have sample interval 1/100000000 s (10ns) and there is data points just with this interval, exactly (not just @eTobey red arrows pointed).   And he have there 20Mpts.  Original runtime display width was 200ms  and now when he have stop and zoom in... he have 20ns/div so his display width is 200ns, extremely narrov slice from whole acquisition length. And all data in info box is true. (after understand what is meaning of its bottom row. Just store it your mind and after then never need ask or wonder. This permanent burn to memory between ears take <1 second and it need do only once).


What need now improve. Least need fix this explanation in User Manual so that also Acquisition Stop state is included (or just tell that in Run time it display...).

[eTobey]

User manual need some correction.

Needs a lot more...

RTFM they said... 

[Martin72]

RTFM they said...

This is the first thing you should do.
Although for me the order of priority is more like this:
-try it out
-Does not work as expected
-Then read the manual first
 

[ebastler]

What you saying is not improvement or bug.
Scope shows sampled, acquired points, not current screen points.
What is purpose of useless metric of current screen?

I don't know about "useless". When showing interpolated traces (as I normally do), I appreciate the hint how many datapoints are actually used to generate the curve I see. Yes, I know I can calculate them by multiplying sample rate * sweep time, but an obvious number is helpful.

But I can also see the value in displaying the total number of acquired points, even if I have zoomed in and see just a fraction of them. Gives me a better idea about what to expect from measurements, for example.

In any case, either the firmware or the manual need to be changed. At the moment they are inconsistent, as the manual claims that the data points indicate the number of points shown on-screen. And that inconsistency is what eTobey had pointed out.

[eTobey]

I just want to write this, so others could self-reflect, and see how well this conversation went:
I made a statement, that something was contradictory in the manual:

This is a summary (drastically shortened, because i like it short):
User 1: Your observation is completely wrong.
Me: Dude, youre wrong.
User 1: You are rude! [User 1 made a mistake because he was not wearing his glasses]
User 2: The answer is staring you in the face... [no further clarification to my actual observation]
User 3: User manual need some correction. [some lengthy explaination followed - yes i am thankful for that, but i really like it short much more ;-)]
User 4: RTFM [i did, and it actually brought up this issue *facepalm*]

Again there was so much text and quotes. "A lot of noise".

[rf-loop]

Contradictory findings:
Either the manual is wrong or the scope shows wrong values. I can only count like a few dozent of points.

This manual is first version (EN01A)
It have many kind of things what can be better and it also have some detected errors and may have errors and inaccuracies what have not detected or noted. It need also know that manual updates are many times lot of behind oscilloscope FW updates, specially with products just launched.

This is not official but perhaps there can be something like this for just this case.

[KungFuJosh]

You are dead wrong!

Rude.

This is not meant to be rude: but i really get frustrated

It was rude, and your frustration is the result of your lack of understanding (in combination with some errors in the manual 😉). It doesn't matter that he made a typo. You don't need to be a dick about it. Your behavior here is quite abrasive. That's not acceptable, especially when you're seeking help and understanding from people that owe you nothing. Errors in the manual or not, makes no difference. Don't treat people that way.

[eTobey]

You are dead wrong!

Rude.

This is not meant to be rude: but i really get frustrated

It was rude, and your frustration is the result of your lack of understanding (in combination with some errors in the manual 😉). It doesn't matter that he made a typo. You don't need to be a dick about it. Your behavior here is quite abrasive.

I used google to translate, and i didnt find the translation rude at all.

Its quite easy to say someone has a lack of understanding, but i asked you in other posts why you would think that, but then there was just silence. No arguments... just insults.

[eTobey]

Contradictory findings:
Either the manual is wrong or the scope shows wrong values. I can only count like a few dozent of points.

The timebase also does not show all the time 50Mpts if you zoom out  its sometimes 20 or 40 Mpts.

Should be exactly 20 points, right? 200 ns total sweep time, 100 MSa/s, so 20 Samples in 200 ns. You can see the individual data points when you switch the display mode to "Dot".

Did you acquire that data with a much slower time base, then stop and zoom in? In that case, the number of number of samples indicated in the info box might be the number of samples acquired in the sweep, rather than the number of samples shown on-screen at the moment? (I don't have access to my scope at the moment.) The manual would be incorrect in that case.

If the above hypothesis is right, I would probably prefer the scope to behave like stated in the manual, i.e. always tell me how many data points are behind the trace I see on-screen at the moment. In which case this would be a bug or improvement request.

User manual need some correction.
...

Thank you for beeing professional.

[KungFuJosh]

You are dead wrong!

Rude.

This is not meant to be rude: but i really get frustrated

It was rude, and your frustration is the result of your lack of understanding (in combination with some errors in the manual 😉). It doesn't matter that he made a typo. You don't need to be a dick about it. Your behavior here is quite abrasive.

I used google to translate, and i didnt find the translation rude at all.

Its quite easy to say someone has a lack of understanding, but i asked you in other posts why you would think that, but then there was just silence. No arguments... just insults.

Fine, I'll bite.

Rude: "You are dead wrong!"
Not rude: "I don't agree with your answer..." or "That doesn't make sense to me."

You have a habit of pointing attacks at people, rather than asking appropriate questions to better help you understand what's happening.

[eTobey]

Fine, I'll bite.

Rude: "You are dead wrong!"
Not rude: "I don't agree with your answer..." or "That doesn't make sense to me."

You have a habit of pointing attacks at people, rather than asking appropriate questions to better help you understand what's happening.

After looking again at the translation, i found that it introduced other words too. 
Now i can not argue that what i wrote was not rude, the only thing i can say, that it was not my intention.

He was wrong in both of his statements after all.

[eTobey]

How am i supposed to set up a level and edge at the same time?

I got the trigger only to work when setting CH2 to high and edge to falling. I guess after high there is probably a falling edge following anyway?

[tautech]

How am i supposed to set up a level and edge at the same time?

Are you looking at the scope directly or the webserver control ?

There are 2 adjustment methods but only 1 can be used from the webserver.
Hint, one is a virtual keypad.

[ebastler]

How am i supposed to set up a level and edge at the same time?

I got the trigger only to work when setting CH2 to high and edge to falling. I guess after high there is probably a falling edge following anyway?

Sorry, I don't follow. What do your signals look like? (They seem to be hidden behind the trigger dialog). What do you want to achieve? What settings did you try? What happened, and how does it differ from what you expected to happen?

I find it confusing that the "Source A" setting for the Delay trigger comprises an edge polarity selection at all. I understood Source A to be purely state-dependent (and there is the dialog you show, which allows to set the state.) Then there is Source B, which is an edge trigger, so that one should have (and has) and edge polarity selection. But what does the edge selection for port A do? -- Is that what you were asking too, or is it something else? 

[eTobey]

I find it confusing that the "Source A" setting for the Delay trigger comprises an edge polarity selection at all. I understood Source A to be purely state-dependent (and there is the dialog you show, which allows to set the state.)

I am confused too. But i think it can be combined with states of other channels, but the manual just lacks this information?

[eTobey]

Are you looking at the scope directly or the webserver control ?

There are 2 adjustment methods but only 1 can be used from the webserver.
Hint, one is a virtual keypad.

It took me a while to get what you mean by that. It took so long, because i did not consider that you would actually think, that i would not know how to put in the numbers. 

[ebastler]

I find it confusing that the "Source A" setting for the Delay trigger comprises an edge polarity selection at all. I understood Source A to be purely state-dependent (and there is the dialog you show, which allows to set the state.)

I am confused too. But i think it can be combined with states of other channels, but the manual just lacks this information?

An Edge on the channel specified as "source B" will only be detected if one or more channels specified as "source A" are in a certain State (and have been in this state for a defined time). That is my understanding of the functionality.

There is no edge on source A involved, as far as I understand. And that's the part which confuses me, because I can set one in the UI. I am not ruling out the possibility that I misunderstand the UI; it's getting late here...

[eTobey]

An Edge on the channel specified as "source B" will only be detected if one or more channels specified as "source A" are in a certain State (and have been in this state for a defined time). That is my understanding of the functionality.

There is no edge on source A involved, as far as I understand. And that's the part which confuses me, because I can set one in the UI. I am not ruling out the possibility that I misunderstand the UI; it's getting late here...

The manual "shows" an edge of source A, and only one single source for source A.

[ebastler]

An Edge on the channel specified as "source B" will only be detected if one or more channels specified as "source A" are in a certain State (and have been in this state for a defined time). That is my understanding of the functionality.

There is no edge on source A involved, as far as I understand. And that's the part which confuses me, because I can set one in the UI. I am not ruling out the possibility that I misunderstand the UI; it's getting late here...

The manual "shows" an edge of source A, and only one single source for source A.

That "edge" is just where the existence of the required state begins (and hence the time over which the state needs to persist) -- again, my interpretation.

But source A can clearly comprise multiple channels; the manual only shows one for simplicity. The dialog you showed above illustrates the selection and state definition of those channels. The manual also refers to the pattern trigger for an explanation of that part.

[eTobey]

Pattern trigger....
From the manual i would translate: "triggers when the set conditions are gone".
Well that trigger would be kinda late then, wouldnt it?

[ebastler]

Pattern trigger....
From the manual i would translate: "triggers when the set conditions are gone".
Well that trigger would be kinda late then, wouldnt it?

I have not used this trigger type yet, but strongly expect that it behaves as described in the manual. After all, you can also set a timing requirement for the pattern, and that can include "time must be shorter than x" or "time must be between x and y". How would the scope know without having seen the full pulse?

You can always construct a trigger condition which occurs after a very short time, or you can invert the combined signal's polarity and hence get the trigger event on the opposite edge, right?

[electronics hobbyist]

What you saying is not improvement or bug.
Scope shows sampled, acquired points, not current screen points.
What is purpose of useless metric of current screen?

I don't know about "useless". When showing interpolated traces (as I normally do), I appreciate the hint how many datapoints are actually used to generate the curve I see. Yes, I know I can calculate them by multiplying sample rate * sweep time, but an obvious number is helpful.

But I can also see the value in displaying the total number of acquired points, even if I have zoomed in and see just a fraction of them. Gives me a better idea about what to expect from measurements, for example.

In any case, either the firmware or the manual need to be changed. At the moment they are inconsistent, as the manual claims that the data points indicate the number of points shown on-screen. And that inconsistency is what eTobey had pointed out.

I will try to answer this question based on my experience. If it is not correct, please correct me.

Let me first explain the conclusion: This information is useful, but whether it needs to be added to the UI requires discussing some details

Some machines from Keysight and Tektronix do not even display number of points, indicating that over 90% of people do not care about this information, What I mean is not that Siglent should not be ambitious, but rather that this priority is very low..

If Siglent wants to become one of the top few in the world, they need to consider these details. The current question is where are these information placed?

I think Yokogawa provides a good solution:
-The number of points in the stop state is displayed through a prompt message and disappears after a few seconds
-Yokogawa has Zoom 1 and Zoom 2. When opening Zoom, the number of points in the Zoom window is fixed on the screen. Of course, some people do not like to occupy screen space, so whether to display optional options is a solution

Additionally, the description in the manual that may be misleading should be revised.

[ebastler]

Let me first explain the conclusion: This information is useful, but whether it needs to be added to the UI requires discussing some details
[...]
Additionally, the description in the manual that may be misleading should be revised.

I didn't mean to suggest that another output should be added to the UI. The discussion was whether the existing number in the timebase information box is meant to show the number of data points in the whole capture, or the number of data points currently on the screen -- because the manual and current implementation are at odds here.

I had stated stated why my preference would the the number of data points on the screen, and was not too happy that 2N3055 disqualified it as "useless". But frankly I don't feel it's that important -- in RUN mode, while I set up the acquisition mode details, the two interpretations are the same anyway. So the main conclusion is that the manual should be corrected to reflect the actual scope behaviour; no need to change the UI.

Just out of curiosity and because I might be able to learn something: What do people use the "total data points in the acquisition" information for?

[electronics hobbyist]

Another thing in the manual that does not add up:
Again... 

The X2 is whereever you set it up. So it can also be on the left side. The same problem is with the Y1/2.

This description is easily misunderstood.It should be written in the following form:

1. The X1 vertical dotted line.
or 2.  The X1 vertical dotted line(On the Left by factory default).

[2N3055]

What you saying is not improvement or bug.
Scope shows sampled, acquired points, not current screen points.
What is purpose of useless metric of current screen?

I don't know about "useless". When showing interpolated traces (as I normally do), I appreciate the hint how many datapoints are actually used to generate the curve I see. Yes, I know I can calculate them by multiplying sample rate * sweep time, but an obvious number is helpful.

But I can also see the value in displaying the total number of acquired points, even if I have zoomed in and see just a fraction of them. Gives me a better idea about what to expect from measurements, for example.

In any case, either the firmware or the manual need to be changed. At the moment they are inconsistent, as the manual claims that the data points indicate the number of points shown on-screen. And that inconsistency is what eTobey had pointed out.

Sorry if it came out terse and harsh.

Like you say "I appreciate the hint", and "I like to know" is not necessary information, by it's very virtue of how we address it.
I personally like as much info as I can, but it is tiny 150x85mm screen.

When sitting on a desk next to 6000A this scope looks like "The little engine that could".

It literally is that. A small entry level scope that does what no other scope for that price could in history of scopes.
Of course there will be compromises.

OTOH, any bugs and document erratum should be fixed.
With note that user manual is reference document. It is not tutorial or introduction to scopes.

[electronics hobbyist]

You are dead wrong!

Rude.

This is not meant to be rude: but i really get frustrated

It was rude, and your frustration is the result of your lack of understanding (in combination with some errors in the manual 😉). It doesn't matter that he made a typo. You don't need to be a dick about it. Your behavior here is quite abrasive. That's not acceptable, especially when you're seeking help and understanding from people that owe you nothing. Errors in the manual or not, makes no difference. Don't treat people that way.

You are dead wrong!

Rude.

This is not meant to be rude: but i really get frustrated

It was rude, and your frustration is the result of your lack of understanding (in combination with some errors in the manual 😉). It doesn't matter that he made a typo. You don't need to be a dick about it. Your behavior here is quite abrasive. That's not acceptable, especially when you're seeking help and understanding from people that owe you nothing. Errors in the manual or not, makes no difference. Don't treat people that way.

The first time I read this, I thought war was about to break out . Yes, a different way of communication can solve these problems.

I know the point of departure of eTobey is good, and it would be much better if there were fewer emotional expressions.
For example, exclamation marks("!") should be avoided. People should not deny others first, and spend more time understanding the logic behind other people's discussions.

Language is a barrier. I translated it using Google and then modified the English. Before sending it, I thought about how others felt when they saw these words and whether they could understand.

[2N3055]

Language is a barrier. I translated it using Google and then modified the English. Before sending it, I thought about how others felt when they saw these words and whether they could understand.

 

[eTobey]

People should not deny others first, and spend more time understanding the logic behind other people's discussions.

I tried to communicate this in several posts too...

[eTobey]

With note that user manual is reference document. It is not tutorial or introduction to scopes.

Wanted feature No. 234:
A true user manual where i can RTFM all day long, without beeing more confused, than i would be, by just figuring it out all alone on the scope.

That trigger "pattern" and "delay" really takes time the get a hold of. It should not be like that.

[eTobey]

Here is my issue:
- Change the manual (red) so it is easier to understand.

- My actual issue (pink):
I would expect that when a condition (an edge happens, a delay has run out, ...) occures, the trigger triggers. But with pattern its inconsistent (again). Whats the point of triggering when a set up condition is not met anymore? Just think of it with a red light at a traffic light: i want to trigger the brake when the red light or yellow light is on. With the patter trigger logic, i would be braking when it is green. 

[electronics hobbyist]

Just out of curiosity and because I might be able to learn something: What do people use the "total data points in the acquisition" information for?

I have thought about removing the "total data points in the acquisition" and found that it doesn't seem to affect anything, I am more concerned about whether the sampling rate meets the requirements. If anyone else has an idea, could you explain it.

[2N3055]

Here is my issue:
- Change the manual (red) so it is easier to understand.

- My actual issue (pink):
I would expect that when a condition (an edge happens, a delay has run out, ...) occures, the trigger triggers. But with pattern its inconsistent (again). Whats the point of triggering when a set up condition is not met anymore? Just think of it with a red light at a traffic light: i want to trigger the brake when the red light or yellow light is on. With the patter trigger logic, i would be braking when it is green. 

Terminology true and false belong to Boolean algebra, a mathematical theory. And software engineering, that is based on it.

We are dealing with signals here, so HIGH/LOW.

Inside FPGA VHDL language it is True/False, on physical pin it is electrical quantity HIGH/LOW digital signal.
As far as electrical engineer is concerned any properly measured quantity is true....

We cannot expect a device/instrument to do abstraction/de abstraction of concepts or conceptual thinking for us.

[ebastler]

- My actual issue (pink):
I would expect that when a condition (an edge happens, a delay has run out, ...) occures, the trigger triggers. But with pattern its inconsistent (again). Whats the point of triggering when a set up condition is not met anymore? Just think of it with a red light at a traffic light: i want to trigger the brake when the red light or yellow light is on. With the patter trigger logic, i would be braking when it is green. 

Did you read my reply #72? I think the trigger can only work the way it does, and have explained my understanding why that is the case. I also described how, in my understanding, it's easy to get the scope to trigger at the time point you want to see.

[eTobey]

Terminology true and false belong to Boolean algebra, a mathematical theory. And software engineering, that is based on it.

We are dealing with signals here, so HIGH/LOW.

You missed the point: this is not about the signal itself, but the state of the signal one would setup with "high/low".
Showing the signal with a negation is not as easy to understand.

Inside FPGA VHDL language it is True/False, on physical pin it is electrical quantity HIGH/LOW digital signal.
As far as electrical engineer is concerned any properly measured quantity is true....

We cannot expect a device/instrument to do abstraction/de abstraction of concepts or conceptual thinking for us.

This is some information that i consider not helpful with my issue, and of course i already know.

[electronics hobbyist]

Here is my issue:
- Change the manual (red) so it is easier to understand.

- My actual issue (pink):
I would expect that when a condition (an edge happens, a delay has run out, ...) occures, the trigger triggers. But with pattern its inconsistent (again). Whats the point of triggering when a set up condition is not met anymore? Just think of it with a red light at a traffic light: i want to trigger the brake when the red light or yellow light is on. With the patter trigger logic, i would be braking when it is green. 

The image in the manual is an example. When Channel1 is set to High and Channel2 is set to Low, the “Trigger Position“ indications are triggered under different Logic, such as the Logic AND, trigger Position is in the time triggering from True to False. have you tested any inconsistencies with this image?

[eTobey]

The image in the manual is an example. When Channel1 is set to High and Channel2 is set to Low, the “Trigger Position“ indications are triggered under different Logic, such as the Logic AND, trigger Position is in the time triggering from True to False.

Yes, i think i already figured it out how it is meant to be. I just say, that this is a bad example.

Have you understand what i was trying to say with the traffic light?

[ebastler]

Have you understand what i was trying to say with the traffic light?

Have you read my post #72 in the meantime, where I think I explained why the Pattern trigger strikes at the end of the pattern's existence? It is a bit annoying at times that you hardly ever comment on attempts to answer a question, let alone confirm an answer. 

[eTobey]

Have you understand what i was trying to say with the traffic light?

Have you read my post #72 in the meantime, where I think I explained why the Pattern trigger strikes at the end of the pattern's existence? It is a bit annoying at times that you hardly ever comment on attempts to answer a question, let alone confirm an answer. 

I think i subconsciously ignored your answer, because you said: "I have not used this trigger type yet, but strongly expect that it behaves as described in the manual."
It seems, i have developed a behaviour, that i would ignore information that does not sound plausible or reliable  (to me) in the first few sentences. I have to change in this regard. My apologies. (I think i have developed this because of having to filter out google search results, or maybe i just need some time off)

Back to topic:
The manual does not explain anything about the time. All someone can do is guessing, and fiddling around with it.
If someone take a delay into consideration, then it absolutely makes sense, but this is a crucial information that is not there in the manual.

[eTobey]

Would you agree, that a better description would be like "Triggers after a pattern existed for the specified amount of time?

I just went to read about the pattern trigger, because the manual made me to! I just wanted to know the delay trigger. 

[rf-loop]

Would you agree, that a better description would be like "Triggers after a pattern existed for the specified amount of time?

I just went to read about the pattern trigger, because the manual made me to! I just wanted to know the delay trigger. 

Hmm...

I agree with you that the manual could be better made in this regard as well.
Here too (pattern trig), you can see the effect that it has been obvious to the Usr Manual author how it works, and of course the point in question is somewhat clear to him, as well as to me and all who have enough knowledge  and experience with these Siglent oscilloscope-multitools.
Because the background information that is missing from the manual is ready in the head.

In fact, it is difficult to notice the lack of it when the background information is already there when  read and look manual (or write it)..
But when a new user of the device is missing it, it can complicate matters quite a lot. Here it also helps if the user has used another model from the same manufacturer, because the basic implementation is almost the same.

In fact, it would be great if, for example, Pattern trig had its operation diagram with logic symbols on the oscilloscope's display screen (Pattern trig setup using diagram), which was then connected to the setting levers and parameters, so that the timer can be clearly seen if the user can read very simple logic diagrams. It could be very clear to use. No need to open the manual. However, the screen of that SDS800XHD is a bit small.

The problem is that someone should implement it, and the implementation should also be financially viable. There are other things to do with the resources that are available, which almost always get overlooked.

Read those old HP journals and one might start to get an idea of what is missing todays and which time will never come back. There will be nothing close to the perfect The Urser Reference Manual. Not even a really good regular User Manual. Because no one is buying it. The makers make what is bought or what is believed to be bought. If that belief is then wrong, it is terminated. Reality is like that, whether it's nice or not.

[Performa01]

Just out of curiosity and because I might be able to learn something: What do people use the "total data points in the acquisition" information for?

I have thought about removing the "total data points in the acquisition" and found that it doesn't seem to affect anything, I am more concerned about whether the sampling rate meets the requirements. If anyone else has an idea, could you explain it.

This information is called "Record Length". One would think it's quite obviously one vital parameter of any acquisition.

It allows me to know at a glance whether the current record can be used for signal analysis without any further (hidden) decimation (which would cause decoders to fail and measurements to give grossly wrong results; also whether it's still compatible (hence can be transferred) to a Memory trace (for scopes that support them).

When I plan to save the acquisition data, the record length will allow me to easily estimate the file size of a binary wavform file and whether I'll be able to send it per email or attach it in the forum.

For the scopes which support fixed memory, you cannot simply calculate the record length from time base and sample rate. Even though I strongly recommend to stay in Auto memory mode, exactly those persons who want to "improve" Siglent scopes all the time, would certainly ignore my advice and use fixed memory all the more (with waveform update rate dropping like a rock, intensity grading lost and segmented memory largely sacrificed for something pretty useless, wich LeCroy and Keysight Megazoom didn't have for a long time and Pico Tech still does not provide, just like the lower end Siglents - but I digress).

[ebastler]

Thanks, rf-loop.

I think an improved manual would be the most cost-effectivce way to sort this out. The fact that the Pattern trigger strikes when the defined pattern ends is not intuitive and should be spelled out. Likewise, operation of the Delay trigger needs significant clarification. Who can guess that the "edge polarity" for Source A essentially defines whether an AND or NAND condition of the defined source states must be met?

Frankly, if Siglent wants to be an "A brand", the manual is an area where there is work to do. Currently, the quality varies a lot between chapters -- there are some which I consider well-written, e.g. the FFT section, others which are ok, and then some which are just too terse and incomplete to make sense to someone who is new to this platform. The sections on Pattern and Delay triggers are examples of the latter category.

[eTobey]

It allows me to know at a glance whether the current record can be used for signal analysis without any further (hidden) decimation (which would cause decoders to fail and measurements to give grossly wrong results...

I would think, that this would depend on the Samples per second and not the total number of points acquired?

[eTobey]

It seems that not many have actually used the mask editor?
Or did no one care, that if you create a mask and load it straight away, its not really working flawlessly?

[ebastler]

I have indeed not used the mask editor at all yet. Could you describe what seems to be wrong? Ideally in a simple step-by-step sequence which we can try and reproduce.

[eTobey]

I have indeed not used the mask editor at all yet. Could you describe what seems to be wrong? Ideally in a simple step-by-step sequence which we can try and reproduce.

- create a mask
- save the mask
- load the mask
- observe how the steps above have changed vertial scale, vertical position, and

I can not reproduce this issue as yesterday, but it had changed vertial scale, vertical position and i belive the trigger level.


But instead i can deliver another issue:
I have setup a qualified trigger that triggers just fine with 200mv/div, but changing to 100mv/div it does not trigger does not trigger at all on a 100mv/div scale. The edge trigger does trigger on this signal down to 5mv. Signal is from ~0 - 2.7V

Edit: just noticed a freeze (no auto trigger what so ever), that was resolved by pushing "Clear sweeps" a few times... 

Edit 2:
Found the cause, Source "A" scale was to small, but interestingly that i only changed source "B"...

[ebastler]

I have setup a qualified trigger that does not trigger at all on a 100mv/div scale. The edge trigger does trigger on this signal down to 5mv. Signal is from ~0 - 2.7V

I will try to reproduce this later today. Could you please confirm one detail: I assume the critical (100 mV/div) scale applies to the channel which is the "edge trigger source", not the "qualified source" -- right?

[ebastler]

I just gave the Qualified trigger a quick try and cannot reproduce your issue so far.

Using 0V .. 3V pulses on both, the Qualified and Edge channel, I can happily overdrive the channels at 100 mV/div and higher sensitivity. Qualified trigger remains stable for me. Please provide further details on your setup and signals.

One caveat: In Qualified trigger mode, pushing the trigger threshold encoder has a different function than normally. It does not set a default (halfway) threshold, but toggles the threshold knob between controlling the Qualified and Edge channels. Did you possibly set unintended threshold values due to that?

[2N3055]

I have setup a qualified trigger that does not trigger at all on a 100mv/div scale. The edge trigger does trigger on this signal down to 5mv. Signal is from ~0 - 2.7V

Let's see, analyse and think:

At 100mv/div full scale is ± 400mV.
Signal is 2.7V P-P, but if it is not centered on the screen with offset it has 2.7 V peak value.

That means that signal is 3-6,5x larger than dynamic range of scope. You are overdriving inputs and ADC.
For scope functions to work properly signal has to fit on screen of the scope.
That is basic thing.

Since Edge trigger only looks for a slope in vicinity (close to) trigger level it usually works even in this situation of completely overdriven signal.

But other trigger types (or any other function of the scope to that matter) that relies on state, and previous states, it might not work.  If it has no valid data.
It might work but it doesn't have to.

That being said, on my scope, it seems to (miraculously) work.

I start wondering if my scope hase some issues itself, but then many other issues were confirmed by others...

What was also confirmed by many others are many false alarms and errors you made and then blamed scope . That is why we say a methodical approach is needed and good detailed explanations are needed.

For instance, you NEVER write what FW you are running at the time you encountered something that is suspicious behaviour or bug.

So in few weeks from now, when stuff is fixed nobody in the world will know if all the stuff you reported is still suspicious or that was some old initial FW that is not relevant anymore.

Like I said before but it fell on deaf ears.
You can stop writing about bugs, looking for them, or investigate them at this moment.
You are wasting your time (and ours if we decide to read).
There is imminent FW release being tested, as we speak.

Wait for a bit until new FW comes out.  Then start first with all the stuff that was reported in release notes that will come with it, then all the stuff that was reported and you don't see them in release notes.

This is my advice to you. You don't have to listen, of course.

[tautech]

Let's see, analyse and think: ............

Wait for a bit until new FW comes out.  Then start first with all the stuff that was reported in release notes that will come with it, then all the stuff that was reported and you don't see them in release notes.

This is my advice to you. You don't have to listen, of course.

We are blue in the face from telling such, so much so I think ears must be just painted on.

[ebastler]

What was also confirmed by many others are many false alarms and errors you made and then blamed scope . That is why we say a methodical approach is needed and good detailed explanations are needed.

For instance, you NEVER write what FW you are running at the time you encountered something that is suspicious behaviour or bug.

So in few weeks from now, when stuff is fixed nobody in the world will know if all the stuff you reported is still suspicious or that was some old initial FW that is not relevant anymore.

Like I said before but it fell on deaf ears.
You can stop writing about bugs, looking for them, or investigate them at this moment.
You are wasting your time (and ours if we decide to read).
There is imminent FW release being tested, as we speak.

Wait for a bit until new FW comes out.  Then start first with all the stuff that was reported in release notes that will come with it, then all the stuff that was reported and you don't see them in release notes.

This is my advice to you. You don't have to listen, of course.

You are too harsh with eTobey, I think. Yes, there have been "false alerts", but a surprising number of actual bug findings too. And this thread is titled "is it me or the scope?", so what's wrong about bringing up potential issues where one is confused and wants to ask others for help to clarify the situation?

Firmware version is 1.1.3.3. throughout -- what else would it be for mere mortal users?   But I do agree with you that a bit more detail about the signals and settings would be helpful in many reports.

Regarding the upcoming firmware, you are quite bullish in your advice that "it's likely to change everything, you can stop looking for bugs for the time being". Have you tried with the two three most recent bugs (#14 to #16) which eTobey found over the past two days, and which electronics hobbyist has added in the SDS800X HD bug thread?

[ebastler]

We are blue in the face from telling such, so much so I think ears must be just painted on.

How is this type of comment supposed to be helpful? It's only stoking up controversy. Please bite your tongue and refrain from posting such insults.

[electronics hobbyist]

Yes, we only discuss technical issues. If the problem is easy to reproduce, the manufacturer can solve the problem quickly. @eTobey You can attach two pictures, one picture where we can see the complete signal, and the other picture when there is a problem.  And explain the configuration of qualified, can also use pictures.

[2N3055]

What was also confirmed by many others are many false alarms and errors you made and then blamed scope . That is why we say a methodical approach is needed and good detailed explanations are needed.

For instance, you NEVER write what FW you are running at the time you encountered something that is suspicious behaviour or bug.

So in few weeks from now, when stuff is fixed nobody in the world will know if all the stuff you reported is still suspicious or that was some old initial FW that is not relevant anymore.

Like I said before but it fell on deaf ears.
You can stop writing about bugs, looking for them, or investigate them at this moment.
You are wasting your time (and ours if we decide to read).
There is imminent FW release being tested, as we speak.

Wait for a bit until new FW comes out.  Then start first with all the stuff that was reported in release notes that will come with it, then all the stuff that was reported and you don't see them in release notes.

This is my advice to you. You don't have to listen, of course.

You are too harsh with eTobey, I think. Yes, there have been "false alerts", but a surprising number of actual bug findings too. And this thread is titled "is it me or the scope?", so what's wrong about bringing up potential issues where one is confused and wants to ask others for help to clarify the situation?

Firmware version is 1.1.3.3. throughout -- what elese would it be for mere mortal users?   But I do agree with you that a bit more detail about the signals and settings would be helpful in many reports.

Regarding the upcoming firmware, you are quite bullish in your advice that "it's likely to change everything, you can stop looking for bugs for the time being". Have you tried with the two most recent bugs (#14 and #15) which eTobey found over the past two days, and which electronics hobbyist has added in the SDS800X HD bug thread?

I'm not to harsh with anybody. Just stating facts. 530+ posts and 4-5 bugs from him.
He had more repetitive reports and false alarms than real findings..
We have a proverb that loosely translated means "you have to bake bread before it is good to eat..".

I'm not saying all he says is wrong because he did find some real problems but he is very eager to write something so he's trigger happy. That is why I still read and answer to his posts. I took seriously (on probation) his apology post, so I approach him as someone a bit clumsy instead of malevolent.

But wrong is still wrong, facts are still facts.

As for being bullish, I'am not. Just saying.
Why waste time for detailed review of Golf8  2 weeks before Golf9 is released? It is a waste of time.

Yes, when new FW is released, list of all of reported bugs is formally invalid.

It remains as a reminder, a shortcut, what to check again in a new version.

In which case it is either not existent anymore (fixed), not fixed (not addressed, deferred for later), fixed partially (it was addressed but fix was only partially successful), or was fixed but new defects were introduced (it was addressed but by mistake some other error was introduced).

In addition to that maybe new defects could be introduced ( by regresion or in new functions added in meantime).

So any bug list lives only in that FW revision.

Any bugs in old FW found postmortem after new FW is available are either fixed already (sometimes one bug triggers a revision of part of design, that reveals some errors in common parts, so one fix fixes several bugs).  Bugs that were not fixed will be discovered in new one anyways.
So doing a work twice instead of once.

I'm not at liberty to discuss details, but can help friendly people with generalized advice not to waste their time.
As I said, not ordering anyone anything. A friendly notice.. If you don't care, your prerogative.

Best,

[ebastler]

530+ posts and 4-5 bugs from him.

Why distort the facts? The list of acknowledged bugs has 9 entries attributed to eTobey, and two more attributed to me (since I established the details) but originally found by him. It seems that these findings have provided useful input to Siglent for the upcoming firmware release.

I think we have a working set of threads now -- one for bugs, one for feature/improvement suggestions, and the present one for discussing unexpected observations which may or may not point to a bug. If we manage to use them as intended, I don't see a fundamental problem.

Any bugs in old FW found postmortem after new FW is available are either fixed already (sometimes one bug triggers a revision of part of design, that reveals some errors in common parts, so one fix fixes several bugs).  Bugs that were not fixed will be discovered in new one anyways.

So can we assume that the new firmware's scope is frozen, and that any bugs discovered now will not be addressed in the upcoming release?

That would be mixed news: It suggests that the new firmware release is imminent, after final beta testing. But it also suggests that further bugs might only be fixed significantly later -- I would guess that the Siglent software team needs to focus on other products for a while before they turn their attention back to the SDS800 series.

In any case, it's clear that a cut has to be made at some point. Siglent can't keep adding additional bug fixes and pushing out the firmware release date forever. I am looking forward to the new release!

[eTobey]

How about keeping the noise down, and trying to be professional? 
I dont see anything to discuss here at the moment. Except if you have found an issue that i have missed...

[eTobey]

Some new issue:
While the issue with the mask loading, that changes the settings of channels, is not a big problem (easy to undo - but still annoying), when triying to use the mask feature on the zoom window, i then was not able to get the zoom window back to the state where it was before setting up the mask (see picture - green signal). Also setting up the mask is very hard, since the zoomed view of the waveform dissappears then.

Its really nice to have many nice features, but i would have rather have "a few" features, that work flawless.

[ebastler]

when triying to use the mask feature on the zoom window, i then was not able to get the zoom window back to the state where it was before setting up the mask (see picture).

But what problem does the picture show?? 

The arrow in the picture points to the trigger threshold, which you were apparently setting at the time of taking the screenshot. That seems like normal behaviour? And what does the name of the picture ("would help to see channel") refer to? I see waveforms for CH1 and CH3, and I see the details in the respective info boxes -- so what is missing?

When posting such findings, please do take a step back before you click "Post", and review whether the description is sufficient for a reader who has not been sitting in front of your scope with you.

Edit: Did you attach the wrong picture maybe?

[eTobey]

when triying to use the mask feature on the zoom window, i then was not able to get the zoom window back to the state where it was before setting up the mask (see picture).

Edit: Did you attach the wrong picture maybe?

Yes it was indeed the wrong picture. Since i had the same issues again with a strong indication, that this is not just an issue, i moved over to the bug topic.

Yes, i have to take a step back and analyse more and not ton confuse others. But at the same time i would like to encourage others to be a bit more playful in trying things out that i wrote. Because some might find what i missed. As 2N3055 might have found nothing wrong, he could have tried other things too, like creating a mask by hand, which is probably the difference with this issue. (This sentence has truely only an objective meaning)

[2N3055]

when triying to use the mask feature on the zoom window, i then was not able to get the zoom window back to the state where it was before setting up the mask (see picture).

Edit: Did you attach the wrong picture maybe?

Yes it was indeed the wrong picture. Since i had the same issues again with a strong indication, that this is not just an issue, i moved over to the bug topic.

Yes, i have to take a step back and analyse more and not ton confuse others. But at the same time i would like to encourage others to be a bit more playful in trying things out that i wrote. Because some might find what i missed. As 2N3055 might have found nothing wrong, he could have tried other things too, like creating a mask by hand, which is probably the difference with this issue. (This sentence has truely only an objective meaning)

Can I ask why are you multiple posting same issues in several different topics?
You started now double spamming.

And as people already said to you multiple times: I'm not going to put in ANY work because you are too lazy to do proper write up.

With bugs you don't accuse and let other side defend themselves.

It is quite the opposite: Unless you can prove a repeatable method to replicate error and demonstrate it step by step,then probably you made a mistake or misunderstand grossly how things work.

[ebastler]

Can I ask why are you multiple posting same issues in several different topics?

That seems like the natural course of things if a topic starts in the "is it me or the scope" thread, and then is confirmed to be a bug. In that case it should be raised in the bug thread next, I'd say.

Whether we are at that stage regarding the mask & zoom issue is another matter. eTobey might have tried something "pathological" of no practical relevance -- although even in that case it would still be nice if the scope did not get confused regarding the time window it shows in zoom mode.

But in any case, I would have preferred to use the present thread to clarify whether "it's the scope or me", before potentially moving things over to the bug thread. It's not good style to ignore the request for clarification here, but post in another thread in parallel.

[eTobey]

when triying to use the mask feature on the zoom window, i then was not able to get the zoom window back to the state where it was before setting up the mask (see picture).

Edit: Did you attach the wrong picture maybe?

Yes it was indeed the wrong picture. Since i had the same issues again with a strong indication, that this is not just an issue, i moved over to the bug topic.

Yes, i have to take a step back and analyse more and not ton confuse others. But at the same time i would like to encourage others to be a bit more playful in trying things out that i wrote. Because some might find what i missed. As 2N3055 might have found nothing wrong, he could have tried other things too, like creating a mask by hand, which is probably the difference with this issue. (This sentence has truely only an objective meaning)

Can I ask why are you multiple posting same issues in several different topics?
You started now double spamming.

And as people already said to you multiple times: I'm not going to put in ANY work because you are too lazy to do proper write up.

With bugs you don't accuse and let other side defend themselves.

It is quite the opposite: Unless you can prove a repeatable method to replicate error and demonstrate it step by step,then probably you made a mistake or misunderstand grossly how things work.

This whole page is full of noise that contributes to nothing but aggravation. Would you please stop this? Get over it! I dont double post, i moved OVER. People suggested having different topics... 

BTW:
What we just did together was actually teamwork, as we discovered quite an important detail. Think about this!

[eTobey]

Another issue:
When missing the "+" or the button for resetting statistics, the measure menu opens. It is already too hard, to hit the resetting button. 
 

See picture.

[eTobey]

New issue:
Wrong measurement:
X2 of the measurement should be, where the arrow points to (last rising edge). When i move gate "B" just a tiny bit to the left, then the measurement is rendered invalid. The measurement is also rendered invalid, if i put the upper level of C3 above high level of C4 (slightly under it).

To me it looks like a bug.

[eTobey]

When loading the reference waveform, it does not scale, if i have a different timebase.
Is there a way to achieve this? The manual did not give details about this, only vertical adjustment.

[tautech]

Some hints of proper use of Reference waveforms are here:
https://www.eevblog.com/forum/testgear/probe-into-probes-whats-up/msg4678768/#msg4678768

[eTobey]

Some hints of proper use of Reference waveforms are here:
https://www.eevblog.com/forum/testgear/probe-into-probes-whats-up/msg4678768/#msg4678768

I cant find the hints that would help me. Maybe wrong link?