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....
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...
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.
RTFM they said...
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?
Contradictory findings:
Either the manual is wrong or the scope shows wrong values. I can only count like a few dozent of points.
You are dead wrong!
This is not meant to be rude: but i really get frustrated
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.
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.
...
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.
How am i supposed to set up a level and edge at the same time?
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?
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.)
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.
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...
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.
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?
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.
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.