PicoScope 7 Software
Available on Windows, Mac and Linux
Obtaining continuous triggered data
Obtaining continuous triggered data
Hello,
I have a project in which I need to stream blocks of triggered data using the 6404C picoscope.
The trigger arrives at 100kHz, and I need 1000 samples each trigger, which gives a window of 10us for each trigger. I am using the 6.4ns time division, and taking 1000 samples per trigger yields 6.4us of data out of the 10us window.
The problem is that when I try to use a revision of the "PicoScope6000ExampleRapidBlock.vi" the communication with the scope takes too long, and I "miss out" a lot of the information. The project requires a continuous measurement of the data synced with the trigger. It also requires a real-time display of the data, so it is possible for example to obtain 1000 blocks of 10us, giving a 10ms update to the screen. However, the measurement needs to be over 10s of seconds, and no data can be lost.
What is the best way to achieve such a measurement? Obviously it is possible to stream both the trigger and the data, but the communication for both channels as well as the post-processing to crop the data is highly non-efficient.
Thanks in advance
Or
I have a project in which I need to stream blocks of triggered data using the 6404C picoscope.
The trigger arrives at 100kHz, and I need 1000 samples each trigger, which gives a window of 10us for each trigger. I am using the 6.4ns time division, and taking 1000 samples per trigger yields 6.4us of data out of the 10us window.
The problem is that when I try to use a revision of the "PicoScope6000ExampleRapidBlock.vi" the communication with the scope takes too long, and I "miss out" a lot of the information. The project requires a continuous measurement of the data synced with the trigger. It also requires a real-time display of the data, so it is possible for example to obtain 1000 blocks of 10us, giving a 10ms update to the screen. However, the measurement needs to be over 10s of seconds, and no data can be lost.
What is the best way to achieve such a measurement? Obviously it is possible to stream both the trigger and the data, but the communication for both channels as well as the post-processing to crop the data is highly non-efficient.
Thanks in advance
Or
Re: Obtaining continuous triggered data
The issue is going to be the transferring of data over the USB bus and where in the process this happens. There are three different approaches that you can take :-
1. Streaming data but only saving out what you need
You can stream continuously with a 6.4nsec sample interval for a single channel (or 12.8nsec interval on two channels) and sustain this for long periods without worry of data loss. The driver may allow you to set 6.4nsec for 2 channels but not guaranteed for long periods although I don't have a device to check this with due to Covid-19 restrictions and no access to devices. As the data is passed to the PC and requested by the application you could write out the required 1000 samples to memory covering the 6.4usecs of interest, and then ignore the data samples from the next 3.6usecs, before repeating the cycle continuously.
2. Capture individual blocks of 1000 samples in response to trigger events
The problem here will be the time it takes to rearm the scope after downloading the previous block of data so it will not be possible to guarantee every event is capture. So we can probably rule this approach out.
3. Rapid Block capture of 512000 trigger events
Segment the memory of the scope into 512000 segments of 1000 samples for 1 channel or 256000 segments for two channels. Capture these events to the memory of the device at the required trigger rate and sampling interval and then download the data as a block to the PC. If you need more events then there will be a significant delay whilst the data is downloaded to the PC and before the scope can be rearmed to capture new events. It will not be possible to collect long term without missing trigger events.
If none of these approaches will work for you then unfortunately they 6404C is not suitable for your application.
1. Streaming data but only saving out what you need
You can stream continuously with a 6.4nsec sample interval for a single channel (or 12.8nsec interval on two channels) and sustain this for long periods without worry of data loss. The driver may allow you to set 6.4nsec for 2 channels but not guaranteed for long periods although I don't have a device to check this with due to Covid-19 restrictions and no access to devices. As the data is passed to the PC and requested by the application you could write out the required 1000 samples to memory covering the 6.4usecs of interest, and then ignore the data samples from the next 3.6usecs, before repeating the cycle continuously.
2. Capture individual blocks of 1000 samples in response to trigger events
The problem here will be the time it takes to rearm the scope after downloading the previous block of data so it will not be possible to guarantee every event is capture. So we can probably rule this approach out.
3. Rapid Block capture of 512000 trigger events
Segment the memory of the scope into 512000 segments of 1000 samples for 1 channel or 256000 segments for two channels. Capture these events to the memory of the device at the required trigger rate and sampling interval and then download the data as a block to the PC. If you need more events then there will be a significant delay whilst the data is downloaded to the PC and before the scope can be rearmed to capture new events. It will not be possible to collect long term without missing trigger events.
If none of these approaches will work for you then unfortunately they 6404C is not suitable for your application.
Martyn
Technical Support Manager
Technical Support Manager
Re: Obtaining continuous triggered data
Martyn and orpeleg7
The option 3 of this discussion: 'Rapid Block capture of events...' uses a method that I need to perform on a 4224 with 240 segment capture for a single channel. And I presume that the continuous trigger can have a delay. Is there any example code available to be sure I order the method correctly?
SMac
The option 3 of this discussion: 'Rapid Block capture of events...' uses a method that I need to perform on a 4224 with 240 segment capture for a single channel. And I presume that the continuous trigger can have a delay. Is there any example code available to be sure I order the method correctly?
SMac
Re: Obtaining continuous triggered data
For a Rapid Block capture where you need to data download all the segment blocks use the PicoScopeXXXXExampleRapidBlockBulk.vi examples-
For your 6404C use-
32-bit-
https://github.com/picotech/picosdk-ni- ... ockBulk.vi
64-bit-
https://github.com/picotech/picosdk-ni- ... ockBulk.vi
For a 4224 (non A model)
There is no PicoScopeXXXXExampleRapidBlockBulk.vi example.
So you need to change the code to match functionality of the 6000 RapidBlockBulk.vi examples above.
Yes you set the trigger with delay option by calling ps4000SetTriggerDelay() function.
You need to look at the C header to create this function which have been installed with SDK here-
C:\Program Files\Pico Technology\SDK\inc
Or 32-bit on 64-bit OS here-C:\Program Files (x86)\Pico Technology\SDK\inc
Please follow the LabVIEW instructions here-
https://github.com/picotech/picosdk-ni- ... /README.md
For your 6404C use-
32-bit-
https://github.com/picotech/picosdk-ni- ... ockBulk.vi
64-bit-
https://github.com/picotech/picosdk-ni- ... ockBulk.vi
For a 4224 (non A model)
There is no PicoScopeXXXXExampleRapidBlockBulk.vi example.
So you need to change the code to match functionality of the 6000 RapidBlockBulk.vi examples above.
Yes you set the trigger with delay option by calling ps4000SetTriggerDelay() function.
You need to look at the C header to create this function which have been installed with SDK here-
C:\Program Files\Pico Technology\SDK\inc
Or 32-bit on 64-bit OS here-C:\Program Files (x86)\Pico Technology\SDK\inc
Please follow the LabVIEW instructions here-
https://github.com/picotech/picosdk-ni- ... /README.md
Regards Andrew
Technical Specialist
Technical Specialist