Picoscope 5243A Complex Triggering

[Howdie91]

I am using a picoscope 5243A to capture Mass Spectrometry data from an instrument in our lab.The problem that I'm running into is that the MS scan takes somewhere on the order of 250 ms, and the timebase needed for the pico to not miss triggers is at least 100. This leads to a loss of data because enough datapoints aren't being taken.

The attached image are the two triggers I have at my disposal. The blue trace ("Scan") goes high when an MS scan is initiated and stays high for the duration of the MS scan, and the red trace ("Trigger") goes high every time ions hit the detector. How I am currently operating this, is to use the "Scan" as ext and triggering on that, feeding the "Trigger" to channel B, and the raw output of the detector to Channel A. I set up a for loop that bins all of the ADC count each time the trigger goes high. This works okay, but not great.

What I would like to do is not use the "Scan", instead triggering the picoscope on the "Trigger", taking a series of captures every time "Trigger" goes high, and only for the duration that "Trigger" goes high. In the attached example, there are about 36 captures (though eventually there would be at least 1000). The problem is as you can see, "Trigger" does not stay high or low for a set duration of time. It instead goes high and low as a set number of periods of the corresponding frequencies.

So my question is: Is there a way to trigger to pico to take a capture when a channel goes high, and only for as long as it is high? And to do that repeatedly until it stays low for some set amount of time? If I can get that, I'm pretty sure I can stitch all of the captures together and put them in a queue to actually see what I'm looking for.

I'm currently using the RapidBlock mode of the picoscope in LabView. I've seen some people mention Streaming mode to work for longer acquisition times, but I can't for the life of me understand the example or how to use it. The .vi I'm using is kind of robust as it does the acquisition and data analysis, but I can upload a portion of it if needed. I'm really just using the pre-mad PS5000 Settings and Block in a while loop so I'm not currently doing anything crazy in my program as far as the picoscope is concerned.


Any help would be greatly appreciated .

[Martyn]

To assist we will need to know the sample rate (sample interval) that you need for your data collection and on how many channels, as this will define what options are available.

[Howdie91]

Sorry Martyn I just now saw this.

For number of channels I'm currently using A for "Signal," B for "Trigger" and Ext for "Scan." If I can break up the long capture into several small ones, I can eliminate the need for "Scan" and instead use A for "Signal" and Ext for "Trigger." I do not have access to a four channel device.

By sample rate do you mean how long each "Trigger" pulse is? That is a frequency dependent, at a given frequency (highest is 500 kHz) the trigger stays high for say 100 periods. As the "Sweep" progresses, the frequency is lowered, making the "Trigger" pulses longer. You can see this in the attached photo of the original post.

Or do you mean the sample rate as how long is the "Scan" channel? That is anywhere from 50 ms to 1 second depending on several factors.

Or do you mean how frequently do I need to take data on my main acquisition channel? That number ideally should be as fast as possible. In say a 100 us "Trigger" pulse, it'd be nice to have a timebase of say 6, but towards the end of "Scan" when the "Trigger" pulse is closer to 1 ms, I'd need a higher timebase. The way that I currently use the pico I take say a 150 ms capture and optimize the timebase so the total number of samples is less than the PS5243A's maximum buffer, though I admittedly do this by hand, turning up the timebase until a timed loop is the correct time.

I've attached three photos of how I'm currently using the Picoscope. It should be noted that for data analysis I use LabView instead of picoscope 6, and that to I bin the "Signal" to when each "Trigger" pulse goes high. The problem with this system is that it requires me to take data for long periods of time (this "Scan" was about 150 ms).The reason that's a problem is as you can see in the zoomed in and zoomed in 2 photos, I'm losing a lot of signal because higher time windows requires high timebases (more time between points).

The question I'm posing is this: Instead of taking one 150 ms long acquisition, can I instead take X number of traces (where X is the number of "Trigger" pulses), then stitch them together once they're on my computer?

[Martyn]

Unfortunately it is not possible to change the settings dynamically without introducing significant gaps due to re configuring and restarting the scope.

However you setup the scope you need to ensure each block of data you collect has sufficient time for your slowest trigger pulse, and has as many samples so that you can see the detail for the fastest trigger pulse, whilst still fitting in to the on board memory.

[Howdie91]

That is what I was afraid of. Would the streaming mode be useful here? I've tried the example code in LabView, but can never get it to work in an understandable fashion. Also I could not find this information easily, but if instead of using a dynamic window, I used a specified lower capture window, then take several "bins" of the "Signal" and "Trigger" channels, then stitch them together in post.

I guess what I'm asking is how you recommend taking a 250 ms capture window while minimizing the time in between points?

Also thanks for the help so far, it has saved me a lot of time and a large headache from trying to figure this our programatically.

[Martyn]

Using PicoScope 6 software for this kind of task will always prove difficult, the software is designed to set up the scope up based around the fixed parameter of the time across the screen, which isn't actually used in setting up the hardware.

Using the SDK, for example with LabVIEW, will offer greater flexibility as you can concentrate on collecting the data you need.

To be able to work this out would you be able to sketch out a typical data collection scenario, showing the number of sample and sample interval you need to to collect in each single continuous block of data, and how much time is allowed between blocks to reset the scope for the next capture.

[Howdie91]

Martyn,

I'm sorry I'm just now seeing this.I captured this data on Picoscope 6 because it was easy to convey, but I do have a working LabView code for the rapid block mode. My current methodology involved feeding the pico a time to take data, and an adjustable timebase to capture the data that I want, through a subVi calculation, it sends the total number of samples to the PS5000Settings subVi. I'd upload the code, but it is incorporated into a complex architecture to average and process the data.

About the information you asked for. Each mass scan takes about 250-500 ms total. Of that, I only need to be taking data for about half that time (125-250 ms). I have a pulse that goes high when I need to start taking data (Scan channel) and stays high for the duration that I need to be taking data. The current LabView program I have, I provide the pico with a time length (125-250 ms) and a timebase (currently set to 60, but is tunable based on the block length). The problem that I'm having is that to take 250ms of data, I need a very high timebase (over 100), and am losing data due to the time between points. Each ion hitting the detector causes very quick (ns timescale) pulses. For taking long time length blocks with low timebases, would the streaming mode be more applicable than the rapidblock? From initial testing it seems as if the problem is that I keep maxing out the internal buffer of the picoscope, so would bypassing it through streaming work better for this application?

I unfortunately don't have any more sample data to send at this time, but if you take the pictures from the original post, and extent that out to 125-250 ms, that's basically what my data collection scenario is. I can try to make a stylized diagram if my description was not illustrative enough.

[AndrewA]

Hi,

This looks like a good application to use streaming with a trigger.
Triggering in streaming mode is different to block modes.
The API/dll will tell you where it has triggered ie the sample number in the block of returned samples.
The Wrapper function called IsTriggerReady returns a flag which is set when triggered and the trigger sample point.
You find this code already in the PicoScope5000aGetStreamingValues.vi.
If you open the PicoScope5000aExampleStreaming.vi you see the trigger flag is latched on the front panel.
I have a setup and tested out triggering on a 500kHz square wave.

The maximum sampling rate in streaming for our devices is limited to the USB throughput and processing on data on the PC.
The maximum rate is shared between scope channels. So for the 5000A/B which are USB 2 devices-
no of chs Sample frequency Hz (sample rate)
1 39.063MHz (25.6E-9)
2 19.531MHz (51.2E-9)
3
4 9.766MHz (102.4E-9)

This is for 8-bit on the 5000A/B, for 12 to 16 bit you will need to half these numbers.

So for 2 channels enabled I have chosen 52ns which the driver actually reports back with 56ns.
Disable the 'Autotrigger' by setting this 0.
Enable the 'Auto Stop'. This will stop the scope sampling once triggered and all the requested samples have been captured.
I have set the trigger point to be in the first sample with 'post-trigger' set 0.
Therefore the 'overview buffer size' and 'post-trigger' to the number of samples you need after the trigger point.
So this will be-
500ms capture / 56ns sample rate = 8.928MS
So just round this up to 10MS
You also need to adjust the trigger level to within range of your signal. ie 0.5V

You should be able add some more code to just save the samples you want using your 'trigger signal' when high. You could just create an array, for each time the this signal go's high.

[Howdie91]

Hey Andrew,

This is almost exactly what I'm looking for! I've tried in the past to get the streaming mode working, but never really understood the settings. I've set up my pico with a 500kHz burst wave that triggers on the same "Scan" channel in the OP. This Scan is also being sent to the Pico's Ext Channel for streaming triggering. Attached is a screenshot showing the Channel A (Blue) and Ext (Red) channels I'm using for the example streaming code.

If I understand correctly the trigger channel is to provide a reference point to the streaming data? The data from Channel A is also coming in as long as the connection is opened, but the trigger indicator is telling me when to break up the data, either in refreshing the waveform chart, or starting a new array. Basically Channel A is a continuous data stream, and the trigger is telling me where it repeats?

There are two immediate problems I'm hoping you can help address.

1) I'm having a hard time actually looking at the output array. Attached is a screenshot of the example code with the 500kHz burst data. I've changed the Chart history length so that I can see the entire 10M samples, but it seems as if every time I run the code it is just starting at an arbitrary point in the cycle instead of when Ext goes high. The "Triggered" indicator goes high when the next cycle starts, so I don't think this is too much of an issue. The real problem is that when Auto-Stop is off, Triggered never goes low again. I dug around in the code, and I really don't understand the Triggered feedback loop and what its doing, because it looks like its set-up so that once Triggered goes high, it will stay high until the innermost loop is ended. but when I end that look by hitting Apply Settings, it stays high.

2) I'm still unsure if it is a Pico problem is a Labview problem, but when Auto-Stop is off and I hit Apply Settings to reset the stream, the data looks like I expect it to for a few cycles, but then it starts truncating the dead time (when Channel A isn't bursting a sinewave). I've included this in the labview screenshot.

I think once I can view the output correctly, and get an array output for each cycle, I can do all of the post processing fanciness with my original Trigger setting and setting up and averaged queue, which is my end goal for this project. Thanks for the detailed post about streaming, it has saved me a lot of time trying to understand the example code .

[AndrewA]

Hi,

Could you email me at support@picotech.com I have new example for you try.

[Howdie91]

I emailed you 8/16. I look forward to your email!

[Howdie91]

Hey Andrew, just as a follow up, did you ever get a chance to respond to my email? Just want to make sure it didn't get marked as spam.

[AndrewA]

Hi Casey,

I sent you an email (from support@picotech.com) on the 17th of Aug, did you get it? can you check your spam folder.