PicoScope 7 Software
Available on Windows, Mac and Linux
Data/triggers missed during rapid block mode capturing
Data/triggers missed during rapid block mode capturing
I've been using Pico 6404D recently for data acquisition and got stuck with trigger problem for sometime.
The situation is that I read output from a Thorlab photodiode using 6404D in Channel A with Labview2014.
In the meantime, I got a sync out signal from another device as a 20KHz standard TTL (5V), which I sampled in Channel C. Channel C is then set as a trigger to continuously triggering the data acquisition in Channel A.
The sampling rate is set at 1MS/s, meaning the timebase is 1us. I want to sample 30 points (blue data) after the trigger (green data) is active everytime. See the attached pic.
Now the problem I got is that when using Labview to do the data acquisition (in rapid block mode), the data I received is not continuous.
For example, I received 20000 captures with 30 samples per capture, I can tell these captures are not continuous because the data isn't fitting the actual signal (which I am sure of).
And the time to complete these 20000 captures is much longer than it should be (since the trigger is 20KHz, it should complete in 1 second, but I waited several minutes before it finished)
So there are several problems I hope you could help with:
1. What causes this problem? It seems to me the scope are missing out many triggers.
2. One year ago, I used Pico6407 to do exact the same data acquisition and it didn't have any problem (with 2.5GS/s sampling and 7KHz trigger TTL, and an old version of driver and SDK).
3. To achieve the data acquisition I want to, is rapid block mode the best way? or the streaming mode is the better one?
The situation is that I read output from a Thorlab photodiode using 6404D in Channel A with Labview2014.
In the meantime, I got a sync out signal from another device as a 20KHz standard TTL (5V), which I sampled in Channel C. Channel C is then set as a trigger to continuously triggering the data acquisition in Channel A.
The sampling rate is set at 1MS/s, meaning the timebase is 1us. I want to sample 30 points (blue data) after the trigger (green data) is active everytime. See the attached pic.
Now the problem I got is that when using Labview to do the data acquisition (in rapid block mode), the data I received is not continuous.
For example, I received 20000 captures with 30 samples per capture, I can tell these captures are not continuous because the data isn't fitting the actual signal (which I am sure of).
And the time to complete these 20000 captures is much longer than it should be (since the trigger is 20KHz, it should complete in 1 second, but I waited several minutes before it finished)
So there are several problems I hope you could help with:
1. What causes this problem? It seems to me the scope are missing out many triggers.
2. One year ago, I used Pico6407 to do exact the same data acquisition and it didn't have any problem (with 2.5GS/s sampling and 7KHz trigger TTL, and an old version of driver and SDK).
3. To achieve the data acquisition I want to, is rapid block mode the best way? or the streaming mode is the better one?
- Attachments
-
Re: Data/triggers missed during rapid block mode capturing
Rapid block will be the correct mode, you will need to set Memory Segments to something larger than 20000, say 1000000, and NoOfCaptures to 20000. Your sample interval is 1usec, time base is the wrong term, which means 50 samples could be taken across a single cycle of the ttl pulse. You only need 30, although I would suggest 40 and capture from the trigger point. This would leave 10usecs for the scope to rearm for the next block.
The whole capture process to the scopes memory should be 1 second, you then need to retrieve all the data from the scope, to the driver and then onto the application, and this will take time, particularly with LabVIEW.
If you are still having problems try increasing the sampling rate to 1GS/s and capture 40000 points per capture, and just down sample when retrieving data from the device. Trigger rearm time in rapid block will vary with sampling rate, I am not sure on the value when sampling at 1MS/s, at the fastest rates it is around 1usec.
Hope this helps.
The whole capture process to the scopes memory should be 1 second, you then need to retrieve all the data from the scope, to the driver and then onto the application, and this will take time, particularly with LabVIEW.
If you are still having problems try increasing the sampling rate to 1GS/s and capture 40000 points per capture, and just down sample when retrieving data from the device. Trigger rearm time in rapid block will vary with sampling rate, I am not sure on the value when sampling at 1MS/s, at the fastest rates it is around 1usec.
Hope this helps.
Martyn
Technical Support Manager
Technical Support Manager
Re: Data/triggers missed during rapid block mode capturing
Hi Martyn,
The problem is solved by increasing the sampling rate and then applying downsample.
Many thanks.
The problem is solved by increasing the sampling rate and then applying downsample.
Many thanks.
Martyn wrote:Rapid block will be the correct mode, you will need to set Memory Segments to something larger than 20000, say 1000000, and NoOfCaptures to 20000. Your sample interval is 1usec, time base is the wrong term, which means 50 samples could be taken across a single cycle of the ttl pulse. You only need 30, although I would suggest 40 and capture from the trigger point. This would leave 10usecs for the scope to rearm for the next block.
The whole capture process to the scopes memory should be 1 second, you then need to retrieve all the data from the scope, to the driver and then onto the application, and this will take time, particularly with LabVIEW.
If you are still having problems try increasing the sampling rate to 1GS/s and capture 40000 points per capture, and just down sample when retrieving data from the device. Trigger rearm time in rapid block will vary with sampling rate, I am not sure on the value when sampling at 1MS/s, at the fastest rates it is around 1usec.
Hope this helps.