Rapid block mode vs. memory depth

Post any questions you may have about our current range of oscilloscopes
Post Reply
IC_Larry
Newbie
Posts: 0
Joined: Tue May 07, 2019 9:21 am

Rapid block mode vs. memory depth

Post by IC_Larry »

Hello, I'd like to determine if the PicoScopes (in particular the family 6000) are suitable for our application.
We need to acquire signals with these characteristics:

* Four analog channels;
* Sampling rate between 1 GSPS and 2 GSPS;
* One trigger for all the channels with a frequency that may vary, let's say 10 kHz typical;
* Sampling of data delayed from the trigger (from some hundreds to some thousand of samples);
* About 256 samples acquired for each trigger and each channel.

We need to acquire as many events as possible, without gaps between the events. We cannot miss triggers.

Reading the Programmer's Guide, the ideal mode for this application appears to be the "rapid block mode": storing as much data as possible in the internal memory, then transfer it to PC when finished. I would like to understand the "real" limitations of this solution. Let's take for example the model 6404D, which has 2 GS sample memory. Ideally, the maximum time that we can acquire is given by the formula 2e9/4/256/10e3, which would give a time of about 195 seconds. Is this right or is it necessary to apply other limitation factors? Most of the APIs don't give any limit for the parameters, apart from the bit size itself (32 bits in most cases).

I have a similar question also for the transfer time to PC. The brochures indicate 150 MS/s as the typical USB transfer rate. This means that I can expect to transfer all the data in about 2000/150=13 seconds?

Thank you!

Cheers, L.

Gerry
PICO STAFF
PICO STAFF
Posts: 1145
Joined: Mon Aug 11, 2014 11:14 am

Re: Rapid block mode vs. memory depth

Post by Gerry »

Hi Larry,

You are correct in that the best mode for this would be Rapid trigger (which would avoid missing any triggers), but there are 2 issues with implementing your requirements in a 6000 series PicoScope.

The first is that, in our PicScope 6 software, you can delay the trigger by defining the number of samples that will be captured before the trigger, but there is no way to delay the trigger without actually capturing any samples.

The second is that, in our PicoScope 6 software, you can only capture a maximum of 1.5G samples with a single trigger (the available sample rate/Timebase combinations restrict the number of samples that can be captured to a specific set of values - Note that within our Software Development Kit no such restriction applies).

Your calculation would need to be corrected according to the 2 restrictions that I mentioned. So, your maximum acquisition time for your typical trigger frequency would be 1.5e9/4/256(+ pre-trigger samples)/10e3.

The Maximum transfer Time is indeed 150MS/s, and the time taken to transfer all of the data would therefore have to be adjusted according to the changes I mentioned.

Regards,

Gerry
Gerry
Technical Specialist

IC_Larry
Newbie
Posts: 0
Joined: Tue May 07, 2019 9:21 am

Re: Rapid block mode vs. memory depth

Post by IC_Larry »

Thank you Jerry. I will use a custom software, therefore I'm more interested in the "general" limitations rather than those of PicoScope 6 software.
Reading the documentation more thoroughly, I've also noticed a limit on the maximum number of memory segments, that for the 6404D model would be two millions. However this should be enough for me.

I'm more worried about what you say about the trigger delay. I'm not sure what you mean with "pre-trigger": I don't need to acquire samples before the trigger, but instead I need to skip samples after the trigger happens. Formally it should be a "post-trigger" delay, as it is called in the ps6000SetTriggerDelay() function described in the developer's manual. Just to be clear: a trigger happens, then I need to skip the following N samples, then to acquire the following M samples.

Are you saying that there is no way to skip the first N samples and therefore my calculation will be 2e9/4/(N+M)/10e3 instead of 2e9/4/M/10e3?

If this is the case, which is the purpose of the function ps6000SetTriggerDelay()? If I have to acquire all the samples anyway, it wouldn't make much sense to set a trigger delay. Or perhaps this function applies only for "single shot" acquisitions?

P.S. By the way, the ps6000SetTriggerDelay() documentation says that the delay range is 0 to MAX_DELAY_COUNT, and MAX_DELAY_COUNT should be defined in ps6000Api.h, but actually it isn't there. It is defined only in ps2000Api.h, ps4000Api.h and ps5000Api.h.

Thank you!

L.

Gerry
PICO STAFF
PICO STAFF
Posts: 1145
Joined: Mon Aug 11, 2014 11:14 am

Re: Rapid block mode vs. memory depth

Post by Gerry »

Hi Larry,

As your question is being answered by one of my colleagues via a help desk ticket that you sent in I will just let him respond to you on that ticket.

Regards,

Gerry
Gerry
Technical Specialist

IC_Larry
Newbie
Posts: 0
Joined: Tue May 07, 2019 9:21 am

Re: Rapid block mode vs. memory depth

Post by IC_Larry »

Thank you. Sorry for the duplication. When I've posted the question on the forum I wasn't aware of the e-mail support yet...

Cheers, L.

Post Reply