Timespan of Rapid Captures

Forum for discussing PicoScope version 6 (non-automotive version)
Post Reply
Posts: 1
Joined: Sat Jan 23, 2010 1:33 pm

Timespan of Rapid Captures

Post by Gustav » Mon Jun 01, 2015 8:55 am

I am using the rapid capture mode on my 5244B. This is really a great new feature that has been added to PicoScope 6.

I have one issue with the rapid capture, and that is that the maximum time span seems to be 10ms. Why is it so low? And is it any higher on for example 3205D MSO? This is a scope that I am thinking of buying.

Advanced User
Advanced User
Posts: 2856
Joined: Tue May 31, 2011 3:43 pm
Location: St. Neots, Cambridgeshire

Re: Timespan of Rapid Captures

Post by Hitesh » Thu Jun 04, 2015 1:13 pm

Hi Gustav,

This is a limitation set by the PicoScope 6 software of enabling rapid block captures at a timebase of 1ms/div or faster.

If slower timebases were possible, it would take longer to complete data collection.

With the Software Development Kit, you can select the desired sampling interval and number of samples to collect per segment (subject to the limitation of the buffer memory).


Software Dev. Engineer

Posts: 0
Joined: Fri Oct 03, 2014 5:58 am

Re: Timespan of Rapid Captures

Post by Mark_O » Mon Aug 03, 2015 12:56 am

This is a limitation set by the PicoScope 6 software...
I've heard this explanation quite often, in this Forum. An artificial limitation, set by the software. To protect the users from themselves. Engineers and scientists, who should be able to make such choices for ourselves.
If slower timebases were possible, it would take longer to complete data collection.
This could be true, but doesn't have to be. I.e., one could decide to use fewer segments, of longer durations. Which would not take longer at all. But even if it DID take longer, why is that a decision that Pico gets to make, and not the person who paid for their gear?
With the Software Development Kit, you can select the desired sampling interval and number of samples to collect per segment...
I think it's great that the SDK gives owners (that subset who are also programmers) a way around the roadblocks Pico has put in place. However, even those of us who ARE also programmers don't always have the time to re-invent the wheel. Telling customers to discard the software that Pico cites as a major product advantage, and start over from scratch nullifies one of the greatest assets of a PicoScope! I may be alone, but that doesn't make much sense to me.

And to be clear, I'm not referring to legitimate limitations that all software will have. There will always be things it can and can't do. And capabilities that Pico would like to add, but hasn't had time to get to yet. This is just about those things (time frames, buffer sizes, etc.) that Pico has decided to restrict artificially, based on their opinion that some users may have some problems dealing with or understanding the ramifications?

Considering the large number of times these questions have kept coming up, over and over across the years, it would be wonderful if Pico re-examined the reasons why the limitations were established in the first place. And eliminate the unnecessary constraints that keep Owners from getting their work done (or cause them to select a different product).

- Mark

[revised to tone down the rhetoric, and remove unappreciated attempts at really amusing humor.]
Last edited by Mark_O on Mon Aug 03, 2015 9:28 pm, edited 2 times in total.

Site Admin
Site Admin
Posts: 3802
Joined: Fri Jun 10, 2011 8:15 am
Location: St. Neots

Re: Timespan of Rapid Captures

Post by Martyn » Mon Aug 03, 2015 8:00 pm

The triangular conundrum, when setting up the scope using PicoScope 6, requires that the following three values are defined

Display Time
Number of Samples
Sample Interval

In our software the "Display Time" is the primary option selected by the user, the "Number of Samples" they wish to collect is the secondary option, and with both of these pieces of information, and knowing the possible sample intervals supported by the device, the software selects the "Sample Interval" to achieve as close to the "Number of Samples" as possible.

The final part of the picture is the memory depth of the scope which will then give a possible number of buffers to collect, either in block or rapid block mode.

The SDK works from a different perspective in that it is only the number of samples, and the sample interval, that matter, the collection time is just a result of these settings. It is by trying to look like a traditional scope with 10 divisions across the screen that a number of limitations in PicoScope 6 exist.

Going back to the original point of the thread concerning the screen time for rapid block, for the mode to be effective you are looking to capture a single event per buffer, and rearm the scope ready to collect the next event. The longer the screen time the higher the probability that the next event is going to occur during the current capture, which may result in the loss of data if this is towards the end of the buffer.
Technical Support Manager

Post Reply