Confusion about how triggers work in streaming mode

bloer · Post by **bloer** » Thu Aug 16, 2018 4:42 pm

I am confused about a number of features of how the API works in streaming mode. From my reading the programmer's guide and example software, as soon as you call RunStreaming, the scope begins writing to the memory buffer(s) registered via SetDataBuffer. If autoStop is false, then it continues streaming until Stop is called.

Questions:
1) if autoStop is false, do the maxPreTriggerSamples and maxPostTriggerSamples have any meaning? If there is or is not a trigger defined?

2) If the scope reaches the end of the overview buffer, does it immediately begin overwriting samples at the beginning of the buffer even if I have not yet called GetStreamingLatestValues? If so, is there any indication that data has been lost?

3) When I call GetStreamingLatestValues, if there is not yet data available, does nothing happen, or is the callback called when data becomes available? Can/will it be called multiple times as new segments are available, or do I need to call GetStreamingLatestValues again first?

4) If I have set up a trigger in streaming, does this affect when the StreamingReady callback is called? E.g., will the callback not be called until a trigger is detected? Will the pre- and post- trigger samples be available in the single callback where the trigger sample happens, or do I need to make sure I keep track of possible pretrigger samples from previous calls in my application code?

5) In this post: topic35611.html?hilit=streaming%20trigger#p125801 I find the phrase

Once triggered the scope cannot re trigger without a restart.

. Is that true of streaming mode? We're looking to use streaming mode in an application to have a dead-time free acquisition, but that makes it sound like we would need to stop and restart streaming mode after every trigger. Is there any way to rearm the trigger without incurring deadtime?

Post by **Hitesh** » Mon Aug 20, 2018 9:08 am

Hi bloer,

Please find below responses to your questions:

1. If autoStop is set to 0 (false), then when you stop data collection, the driver will hold the sum of maxPreTriggerSamples and maxPostTriggerSamples in memory for each active channel. You can use the ps5000aGetValuesAsync() function to retrieve these samples.

2. The overview buffer should not be overwritten at the beginning. Data should be cached in the buffer memory of the device, but if the data is not retrieved and the buffer memory becomes full, data will be lost without indication. We recommend regularly retrieving data from the device, and ensuring that the overview buffer size is large enough to accommodate the number of samples collected in one iteration of your data collection loop.

3. The callback is only called when data is available (or if autoStop is true, when the device has completed data collection). I believe that the callback function is called once, so as per our examples, you should call ps5000aGetStreamingLatestValues() in a loop to check for new data.

4. When the ps5000aRunStreaming() function is called, data collection begins irrespective of whether a trigger is set or not and the callback will be called when data is available. You can check the triggered parameter in the callback to see if a trigger has occurred in the set of data that has been returned. You will need to keep track of pre-trigger samples being returned, and discard them if not needed.

As mentioned previously, you can call ps5000aGetValuesAsync() post capture in order to obtain just the specified number of pre- and post-trigger samples.

5. That is also true for streaming mode captures. The only mode that has a reduced deadtime between captures (depending on sampling rate) is rapid block mode, but is limited by the amount of buffer memory available on the device. What sampling rate are you using and how long do you need to capture data for?

Regards,

tonyzzr · Post by **tonyzzr** » Wed Sep 26, 2018 11:02 pm

Hi Hitesh,

Thank you for the very detailed explanation of the streaming mode! I have a very similar need to bloer. We are trying to capture a series of pulsed-wave ultrasonic signals in real-time via PicoScope 6403D. The pulse repetition frequency is in a range of 500 Hz to 5000 Hz and the sampling frequency is 40 MHz (a sample interval time of 25 ns). We only need the first 3000 samples after every pulse is fired (which can be indicated via a synchronized trigger). Can the triggerd streaming mode provide such function to meet our need? (We previously used rapidBlock mode to achieve the same goal but it can not be used in a real-time manner.)

bennog · Post by **bennog** » Thu Sep 27, 2018 3:04 pm

I would write a streaming app and do the segmentation in software. So evaluate the incoming data in a separate thread and as soon the trigger situation appears set a counter to put the next 3000 samples in a buffer and save them after they are captured.
If within these 3000 samples there is a chance of another trigger then you need some kind of fifo and fifo handler to fill the buffers and save them.

But that is because I like to do things in simple small blocks.

Benno

Post by **Hitesh** » Mon Oct 08, 2018 1:17 pm

Hi tonyzzr,

I would suggest an approach like Benno suggested in terms of processing the data after using a trigger for the first event.

Otherwise, you would have to stop and restart data collection which would lead to gaps of tens of milliseconds while the device rearms itself.

Regards,

Test & Measurement Forum

Confusion about how triggers work in streaming mode

Confusion about how triggers work in streaming mode

Re: Confusion about how triggers work in streaming mode

Re: Confusion about how triggers work in streaming mode

Re: Confusion about how triggers work in streaming mode

Re: Confusion about how triggers work in streaming mode