Have you tried it with more wide slope steep. Example 1ms / 2ms. Do it change situation.
Have you tried same with analog side BW reject.
So far this issue has *not* reproduced with the 20MHz bandwidth limiter enabled on the probe. Looks to me like whatever's causing this, it's very high frequency noise that somehow doesn't appear in the capture.
I'll try some of the other things next.
This is very strange if it do not appear in capture or captured raw ADC data. It must be there, infinitely. Without it, it do not trig. But all is possible. Also some bug in FW what cause this reason is hiding.
Do you have FULL .CSV or Binary data.
Screen shot png and paired with this full saved sample data. Example 3 set of these pairs so that these pairs are somehow marked so that can not mix and with perfectly explained trigger setting and scope other settings (norm/Auto, possible trigger coupling filters and, trigger setup exactly and so on. (display dots/interpolatin line or sinc do not affect any thing, they are post processed.)
Because if there is really no raw ADC data what explain wrong/failed trig, it need solve what make it. These can bit look and forward to Siglent for further analysis. It is not lottery machine and it do not have its own mind what some times do irrationally something like human..
Quote from: rf-loop
Have you tried same with analog side BW reject.
Limiting the bandwidth helps. I'm running a test now to see if the issue reproduces at all with a 20 MHz bandwidth limit on the input. But limiting the bandwidth shouldn't be necessary. What if you're trying to find high-frequency noise in the signal? The point here is that if noise causes the trigger to fire and the trigger mechanism exclusively uses ADC output, that noise should be present in the capture! But it wasn't, and isn't.
This is very strange if it do not appear in capture or captured raw ADC data. It must be there, infinitely. Without it, it do not trig. But all is possible. Also some bug in FW what cause this reason is hiding.
Do you have FULL .CSV or Binary data.
Yes. Well, I *had* it but had to reboot my computer, and didn't have them stored in a location that would survive the reboot. But seeing how I can reproduce this essentially at will, getting the data isn't a problem at all.QuoteScreen shot png and paired with this full saved sample data. Example 3 set of these pairs so that these pairs are somehow marked so that can not mix and with perfectly explained trigger setting and scope other settings (norm/Auto, possible trigger coupling filters and, trigger setup exactly and so on. (display dots/interpolatin line or sinc do not affect any thing, they are post processed.)
Sinc versus dots versus linear doesn't affect triggering??
OK, that raises a question: does the triggering mechanism *always* use sinc? Or straight point-to-point? Or something else? It has to somehow detect that a transition has happened between acquired points, clearly, so it has to be doing some kind of interpolation for that, no?QuoteBecause if there is really no raw ADC data what explain wrong/failed trig, it need solve what make it. These can bit look and forward to Siglent for further analysis. It is not lottery machine and it do not have its own mind what some times do irrationally something like human..
Agreed. OK, so the question then is: how do you want me to upload the data? To where? The resulting 7-zip archive of 14Mpoints of CSV data is far too large for uploads to this forum.
It need think. Also it need take account that what if... and so on.. Do you have binary data also from same acquisition what you have CSV and I do not mean small part of acq. but of course every byte from start to end.
How big your zips are for both separately.
It need think. Also it need take account that what if... and so on.. Do you have binary data also from same acquisition what you have CSV and I do not mean small part of acq. but of course every byte from start to end.
How big your zips are for both separately.
Well, "zip" and "7-zip" are actually two different things. "7-zip" does a *much* better job of compressing. While "zip" of the 14Mpoint CSV gets me a 30 megabyte zip file, "7-zip" gets me a roughly 9 megabyte "7z" file. Both are archive formats that can store multiple files within the archive, so they're both good for the same thing. You can get "7-zip" from https://www.7-zip.org.
I don't know how much space an archive containing the binary format file will take. I'll let you know.
Right now I'm running the test with the trigger bandwidth limiter enabled, and it hasn't reproduced yet (it's been running for about 30 minutes so far, with about 15K frames analyzed -- I'm using the mask function to detect a violation). I'll let that run a bit longer before reverting back to full bandwidth on everything for the purpose of gathering the data.
The real question is where I should upload the resulting (rather large) archive files to. Any suggestions?
It is explained bit more but unfortunately "scrambled by natural enigma". Our "enigma" is our Finnish language what is said is second difficult after Chinese in world.
In some images there is some english/finglish explanations. But more deep text explanations just with Finnish.
https://siglent.fi/oskilloskooppi-tietoa-sds1004x-e--wfm-speed.html
I am slowly reading through this with help from Google translate. It's very helpful, thank you for writing it!
PS: there is a typo in the second (all yellow) table shown in Figure 1, in the line with t/div= 1ms. Column 6 contains 1G sa/s. It should read 1M sa/s.
I know this all may be bit frustrating. If I have here now this scope I can try repeat this error using noises etc... but I do not have.
In this image there is 1GSa/s 1ms/div 14M memory.
There was some other image where was 500MSa/s and 2ms/div
Both show this error.
But I have not seen any test (or my far over best before date eyes have not hit) test where is native 500MSa/s sampling speed.
In this 2ms 500MSa image it is decimated samplerate.
So, can you do also test just like this image:
But change one thing. Turn just this ADC from interleaved mode to non interleaved mode so it have real 500MSa/s.
This you can do more easy than easy.
Keep 1ms and this channel. Turn Ch1 ON. Now you see samplerate is 500MSa/s now ADC is not inteerleaved mode but normal 2 channel 500MSa mode.
As told some previous image also have 500MSa/s but is is decimated from 1GSa interleaved sampling.
It may have some difference depending how trigger engine listen these 4 x 250MHz 8 bit bus from ADC or 2 x 250MHz bus in non interleaved mode...
If it give real big difference.. it is very extremely important finding, together with this previous finding about BW reject (and case is that before BW reject in ADC data can not see any reason for wrong trig. )
Imho, both are important finding, it this change affect or if not. These can imagine are like road crosses and how to go forward, right or left or straight.
Have you tried same with analog side BW reject.
So far this issue has *not* reproduced with the 20MHz bandwidth limiter enabled on the probe. Looks to me like whatever's causing this, it's very high frequency noise that somehow doesn't appear in the capture.
I'll try some of the other things next.
This is very strange if it do not appear in capture or captured raw ADC data. It must be there, infinitely. Without it, it do not trig. But all is possible. Also some bug in FW what cause this reason is hiding.
Do you have FULL .CSV or Binary data. Screen shot png and paired with this full saved sample data. Example 3 set of these pairs so that these pairs are somehow marked so that can not mix and with perfectly explained trigger setting and scope other settings (norm/Auto, possible trigger coupling filters and, trigger setup exactly and so on. (display dots/interpolatin line or sinc do not affect any thing, they are post processed.)
Because if there is really no raw ADC data what explain wrong/failed trig, it need solve what make it. These can bit look and forward to Siglent for further analysis. It is not lottery machine and it do not have its own mind what some times do irrationally something like human..
Have you tried same with analog side BW reject.
So far this issue has *not* reproduced with the 20MHz bandwidth limiter enabled on the probe. Looks to me like whatever's causing this, it's very high frequency noise that somehow doesn't appear in the capture.
I'll try some of the other things next.
This is very strange if it do not appear in capture or captured raw ADC data. It must be there, infinitely. Without it, it do not trig. But all is possible. Also some bug in FW what cause this reason is hiding.
Do you have FULL .CSV or Binary data. Screen shot png and paired with this full saved sample data. Example 3 set of these pairs so that these pairs are somehow marked so that can not mix and with perfectly explained trigger setting and scope other settings (norm/Auto, possible trigger coupling filters and, trigger setup exactly and so on. (display dots/interpolatin line or sinc do not affect any thing, they are post processed.)
Because if there is really no raw ADC data what explain wrong/failed trig, it need solve what make it. These can bit look and forward to Siglent for further analysis. It is not lottery machine and it do not have its own mind what some times do irrationally something like human..Are we absolutely sure the trigger voltages are converted to adc values, and not let's say analog comparators? The strange thing is that when using scpi those voltages are attributes of each channel. In a complete digital situation, it would be more logical for them to be attributes of the trigger.
It could explain the behavior if they where analog...
Truth or fact is not about how many times one says something..
I don't say its likely, but seeing the scope's behavior..
Also there could be benefits to analog triggers, for example when using slow "time div's", but very fast signals. At the moment I'm experimenting with that, to see how the scope responds.
Its stil running but it managed to capture a pulse of 32 ns each 700s using only 10 Samples/s (100 s/div thus 23 min/screen). That's amazing if it where only digital...
Maybe it sampling faster under water than it says?
If thats true than we have another possible explanation..(I see that the faulty trigger examples are at max sample rate, so probably not)
Truth or fact is not about how many times one says something..
I don't say its likely, but seeing the scope's behavior..
Also there could be benefits to analog triggers, for example when using slow "time div's", but very fast signals. At the moment I'm experimenting with that, to see how the scope responds.
Its stil running but it managed to capture a pulse of 32 ns each 700s using only 10 Samples/s (100 s/div thus 23 min/screen). That's amazing if it where only digital...
Maybe it sampling faster under water than it says?
If thats true than we have another possible explanation..(I see that the faulty trigger examples are at max sample rate, so probably not)
On a slow time base it is very possible to have it trigger on a pulse (2.5V, 32 nS) without seeing it happen on screen. Using a very simple edge trigger.
It probably doesn't prove much, because it is propably sampling faster under water.
It probably doesn't prove much, because it is propably sampling faster under water.
On a slow time base it is very possible to have it trigger on a pulse (2.5V, 32 nS) without seeing it happen on screen. Using a very simple edge trigger.
It probably doesn't prove much, because it is propably sampling faster under water.That is why there exists peak detect mode. It will show those peaks..
On a slow time base it is very possible to have it trigger on a pulse (2.5V, 32 nS) without seeing it happen on screen. Using a very simple edge trigger.
It probably doesn't prove much, because it is propably sampling faster under water.That is why there exists peak detect mode. It will show those peaks..I just figured that one out by myself as well
Just before I thought it was only a way of displaying underlying data. Now I know why the aquisition needs to be redone.
Now I wonder, does it need twice the memory..? Will look it up, because it is not relevant to the issue.
B.t.w. I know I'm lacking technical knowledge regarding this scope, I see myself more like a user. But the question is how much knowledge will be needed to pinpoint the issue some more. I think experiments are propably more important. I'm also not yet fully engaged in this issue (yet), but I don't dislike to finding "thruth" with very little information. For instance I know now why going on a "slower sampling speed" will not induce comparable behavior. Which might together with the non analog trigger already be enough technical info.
Okay so no negative peaks, like minimals..
About the facts. I might have skipped the digital trigger (vs analog) trigger post.. Got some brain damage, so reading and processing information is a bit impaired.
So my remark:
Truth or fact is not about how many times one says something..
Was more a general remark, not a disbelief in what was said (which I didn't read).
But either way: in this situation that fact should be traced to its roots. If rf-loop is that root of knowledge than .
There's more to say but I'll leave it like this.