PicoScope 7 Software
Available on Windows, Mac and Linux
Pre-trigger samples from ps2000_run_streaming_ns
Pre-trigger samples from ps2000_run_streaming_ns
Hello,
I am finding that the function ps2000_run_streaming_ns adds unwanted pre-trigger samples to the output stream. If I call the function with triggering disabled, and ask for a million samples, I receive exactly a million samples, which is fine. But if I enable simple triggering with the ps2000_set_trigger2 call, I receive a million + N samples, where N is variable, and if I examine a waveform manually I find that the trigger point would have been N samples into the received waveform.
Another example: suppose I enable triggering with ps2000_set_trigger2, setting the trigger level so high that it is above the peak waveform voltage, and also setting the auto_trigger delay parameter to 3 seconds. If I then call ps2000_run_streaming_ns, requesting a second's worth of data, what I receive is a 4 second long data stream.
The delay variable (parameter 5 of 6) passed to ps2000_set_trigger2 seems to have no effect on this behaviour.
My test setup is a program written in C# running on a 64-bit Windows 10 PC, interfacing with the 64-bit ps2000.dll from your current SDK (driver 2.3.0.6), and communicating with a 2205A scope.
I am finding that the function ps2000_run_streaming_ns adds unwanted pre-trigger samples to the output stream. If I call the function with triggering disabled, and ask for a million samples, I receive exactly a million samples, which is fine. But if I enable simple triggering with the ps2000_set_trigger2 call, I receive a million + N samples, where N is variable, and if I examine a waveform manually I find that the trigger point would have been N samples into the received waveform.
Another example: suppose I enable triggering with ps2000_set_trigger2, setting the trigger level so high that it is above the peak waveform voltage, and also setting the auto_trigger delay parameter to 3 seconds. If I then call ps2000_run_streaming_ns, requesting a second's worth of data, what I receive is a 4 second long data stream.
The delay variable (parameter 5 of 6) passed to ps2000_set_trigger2 seems to have no effect on this behaviour.
My test setup is a program written in C# running on a 64-bit Windows 10 PC, interfacing with the 64-bit ps2000.dll from your current SDK (driver 2.3.0.6), and communicating with a 2205A scope.
Re: Pre-trigger samples from ps2000_run_streaming_ns
Hi imgreen,
I've been looking through the posts, and I noticed that yours hasn't been answered. So, in case you still need the answer here it is:
Regarding the additional pre-trigger samples, when you are streaming the data, the data is being sent to the PC regardless of what you are doing with the Trigger. If you set a Trigger then, if the trigger fires, the trigger point is captured relative to the data that you are already collecting. So, it is then up to you to locate the trigger point, and discard any samples that were also captured before the trigger point. As you get all of the samples that you ask for, from the trigger point to the end of the capture, this should not give you any cause for concern.
Regarding your second example, what you are observing is what you would expect to see. To quote from the Programmers Guide, auto_trigger_ms is "the delay in milliseconds after which the oscilloscope will collect samples if no trigger event occurs". The PicoScope needs to capture your seconds worth of data without a trigger occurring (because you have set it too high), but only after waiting 3 seconds, so it also needs to capture the 3 seconds worth of data delay in order to get to the 1 second of data that you want.
The "delay" parameter that you're referring to (parameter 5 of 6) will have no effect on the above scenario because it is a delay from when an actual trigger (that is triggering correctly) occurs and not a delay from when the auto trigger occurs. So, if you were to lower the trigger point so that it now does trigger the capture, a 3 second value for this parameter should also give you 4 seconds of data captured.
Regards,
Gerry
I've been looking through the posts, and I noticed that yours hasn't been answered. So, in case you still need the answer here it is:
Regarding the additional pre-trigger samples, when you are streaming the data, the data is being sent to the PC regardless of what you are doing with the Trigger. If you set a Trigger then, if the trigger fires, the trigger point is captured relative to the data that you are already collecting. So, it is then up to you to locate the trigger point, and discard any samples that were also captured before the trigger point. As you get all of the samples that you ask for, from the trigger point to the end of the capture, this should not give you any cause for concern.
Regarding your second example, what you are observing is what you would expect to see. To quote from the Programmers Guide, auto_trigger_ms is "the delay in milliseconds after which the oscilloscope will collect samples if no trigger event occurs". The PicoScope needs to capture your seconds worth of data without a trigger occurring (because you have set it too high), but only after waiting 3 seconds, so it also needs to capture the 3 seconds worth of data delay in order to get to the 1 second of data that you want.
The "delay" parameter that you're referring to (parameter 5 of 6) will have no effect on the above scenario because it is a delay from when an actual trigger (that is triggering correctly) occurs and not a delay from when the auto trigger occurs. So, if you were to lower the trigger point so that it now does trigger the capture, a 3 second value for this parameter should also give you 4 seconds of data captured.
Regards,
Gerry
Gerry
Technical Specialist
Technical Specialist