Fastest way of capturing data

Post any questions you may have about our current range of oscilloscopes
Post Reply
User avatar
fabian
Newbie
Posts: 0
Joined: Thu Jul 02, 2015 12:22 pm

Fastest way of capturing data

Post by fabian »

Hello,

I use the Picoscope 6404D for capturing data using the SDK and Labview.
As my application needs a fast data aquisition I need to use the fastest timebase that's possible (200 ps).

When I use the block mode I can collect a block of data with a predefined number of samples, transfer the data to the PC and restart the data aquisition. The problem is that there's a time gap while transferring the data to the PC of about 10-20 ms. That is a really long time and does not suit for my application. Is there a way to reduce this time gap to let's say 1 ms or even less?

Beside the normal block mode there's also the rapid block mode which seems to reduce the gap. The programmer's guide says about this mode "It reduces the gap from milliseconds to less than 1 microsecond.". It would be nice, if that's true, but when I tried using it Labview says nevertheless that the transfer takes about 15 ms. Does someone has any experience with this issue?

Thanks.

Fabian
Remember why you started and make it work.

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

Re: Fastest way of capturing data

Post by Mark_O »

Hi, Fabian.
fabian wrote:I use the Picoscope 6404D for capturing data using the SDK and Labview.
As my application needs a fast data aquisition I need to use the fastest timebase that's possible (200 ps).
Congrats! That's a very powerful piece of kit. Super high acquisition speed (5 GSa/s) combined with super deep memory (2GSa).
When I use the block mode I can collect a block of data with a predefined number of samples, transfer the data to the PC and restart the data aquisition. The problem is that there's a time gap while transferring the data to the PC of about 10-20 ms. That is a really long time and does not suit for my application. Is there a way to reduce this time gap to let's say 1 ms or even less?
You didn't say if you were using USB2 or USB3. If the former, then you can speed transfers up substantially by using USB3 instead. You also didn't mention what sample size you were using in your captures. It's going to take some finite amount of time to transfer data from the internal buffer to the PC, via the USB link and the driver. The only way to reduce that gap is to reduce the size of the blocks being transferred. There is a limit to this though, because there is a fixed overhead for any transfer, that won't scale with smaller block sizes. (PicoTech would have to comment on what this lower-bound is.)
Beside the normal block mode there's also the rapid block mode which seems to reduce the gap. The programmer's guide says about this mode "It reduces the gap from milliseconds to less than 1 microsecond.". It would be nice, if that's true, but when I tried using it Labview says nevertheless that the transfer takes about 15 ms.
Rapid block mode does reduce the time between consecutive blocks in one acquisition, and the time between each burst is extremely small, as they claim. But this doesn't have any impact on how long it takes to then get that data out of the internal buffers and into the PC. If it's a large chunk, it's going to take just as long to transfer.

One other available method is streaming-mode, which sends data continuously, with no gaps at all. Using USB3, you may be able to achieve sampling rates in the range of 6-8 ns per sample. However, it sounds as if this is too slow for your purposes (200 ps). The physical reality is that you're never going to be able to get data out of the box faster than ~130-180 MS/second, under even optimal circumstances. If you really need to be sampling at 5,000 MS/sec (>30x faster)then you can see it's not going to be possible to do that for any longer time than the internal buffer will allow.

If you explained a bit about what you were trying to explore, it may be possible to suggest some alternatives. I.e., do you really need 2 G sample bursts of data continuously? Or can you limit captures to smaller bursts, based on a smart set of trigger conditions? Rapid block mode, with up to 2 million segments of 1k each (for example, or 1k segments of 2MS each), and carefully selected triggers, could boost capture density significantly, by skipping blocks of time that weren't "interesting". Then only transferring that data out after the fact.

- Mark

User avatar
fabian
Newbie
Posts: 0
Joined: Thu Jul 02, 2015 12:22 pm

Re: Fastest way of capuring data

Post by fabian »

Hi Mark,

thanks for your reply.
I want to specify my problem a little bit more.

I use USB 3 with the Picoscope 6404D. The block length isn't specified up to now and so I'm very variable with this. I tried very different ones starting from 100 to 1000000, while 100 has to me the minimum. The transmission time I've mentioned, was measured in Labview by capturing a timestamp before and after the transmission. This always returns around 15 ms with an amount of 10000 samples or lower. I'm not really sure if that's a good way for measuring the transmission time, but it seems like the 15 ms are a kind of needed time for the USB protocol.

I've also tried the rapid block mode. It seems to be the best mode for me, due to the documentation.
My only problem with this is specifying the time gap. I understood the mode in a way, that it's capturing data in different internal buffers that can be read out one by one. While reading one buffer the Picoscope captures data into another buffer. Is this right?
How long is the time gap between the last sample in buffer-block 1 and the first one in buffer-block 2? I don't know how to get this information.

-Fabian



As you mentioned, streaming mode is too slow for my application.
Remember why you started and make it work.

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

Re: Fastest way of capuring data

Post by Mark_O »

Hi, Fabian. Thanks for filling in the missing pieces, and confirming that you're already using USB3, and that Streaming is too slow.
The block length isn't specified up to now and so I'm very variable with this. I tried very different ones starting from 100 to 1000000, while 100 has to me the minimum. The transmission time I've mentioned, was measured in Labview by capturing a timestamp before and after the transmission.
That is a good range of sizes to have tested. And yes, measuring the timestamp in LabView before and after is a valid way of checking the interpacket latency.
This always returns around 15 ms with an amount of 10000 samples or lower. I'm not really sure if that's a good way for measuring the transmission time, but it seems like the 15 ms are a kind of needed time for the USB protocol.
Yes, and no. There are two components to that time. One is the actual transfer time. The other is Setup overhead. Over USB3, the speed can vary between 80-180 MB/sec, depending on a variety of conditions. Let's say it was 130 MB/sec. With a Blocksize as large as 1 MB, the actual transfer time would be ~8 millisecs. With just 100kSa, it would be less than 1 ms. And 10k Sa, only <0.1 ms.

What your testing has revealed is the second component of the time, which is Setup and overhead in the Driver. Basically, this suggests that almost the entire 15 ms is overhead, and not actual transfer time. Which sets a very hard lower bound, which you cannot get below. :( This time is actually so large that I believe it presents a real opportunity for Pico to optimize and reduce it, by dedicating some resources to the task.
I've also tried the rapid block mode. It seems to be the best mode for me, due to the documentation.
I think it could be, depending on your expectations. One major question would be, when you're capturing at 200 ps/sample, for how long a duration do you need to capture? That will affect how many segments you will have available, and thus the total time interval you can span.
My only problem with this is specifying the time gap. I understood the mode in a way, that it's capturing data in different internal buffers that can be read out one by one. While reading one buffer the Picoscope captures data into another buffer. Is this right?
Unfortunately, no. Although I can understand why you might have that impression. The PicoScopes can either be acquiring data, or transferring it to the PC. Not both at once. (This is because the same FPGA engine that handles captures, also aggregates and feeds data to the USB port. And it only operates in one mode at a time.)

So what Rapid Block mode does is partition the on-board memory space into segments, and capture bursts continuously, without transferring any of it to the PC. By deferring the transfer until later, that reduces the time between two consecutive captures to the smallest possible amount. As little as <1 us, in some cases, we have been told.
How long is the time gap between the last sample in buffer-block 1 and the first one in buffer-block 2? I don't know how to get this information.
That is a very good question! While PicoTech likes to brag often about how low it can be, they seem very shy about revealing how large it can be. Or any relationship between capture rates and inter-segment gaps. I have inquired here on several occasions, and I am still waiting for an answer to that same question. I'm not sure if they simply don't know, or prefer not to say.

However, I can say that your scenario, where you are capturing at the fastest possible rate, will also yield the smallest possible intervals. The relevant question for you will be how closely spaced do you expect two triggerable events might be? If it's >=1 us, I think you will be fine. If they could come closer than that, you may drop some.

E.g., on the 6404D, "Rearm time: Less than 1 µs on fastest timebase", and you're using the fastest timebase.

User avatar
fabian
Newbie
Posts: 0
Joined: Thu Jul 02, 2015 12:22 pm

Re: Fastest way of capuring data

Post by fabian »

Hi Mark,

thanks for your detailed response.
Mark_O wrote:Unfortunately, no. Although I can understand why you might have that impression. The PicoScopes can either be acquiring data, or transferring it to the PC. Not both at once. (This is because the same FPGA engine that handles captures, also aggregates and feeds data to the USB port. And it only operates in one mode at a time.)

So what Rapid Block mode does is partition the on-board memory space into segments, and capture bursts continuously, without transferring any of it to the PC. By deferring the transfer until later, that reduces the time between two consecutive captures to the smallest possible amount. As little as <1 us, in some cases, we have been told.
Is this really true? I have understand this in the other way, I already described. If you are right, what is the benefit of the rapid block mode then? It really doesn't matter, if I partition the memory and write it full or if I write it full as one big memory.
Mark_O wrote:That is a very good question! While PicoTech likes to brag often about how low it can be, they seem very shy about revealing how large it can be. Or any relationship between capture rates and inter-segment gaps. I have inquired here on several occasions, and I am still waiting for an answer to that same question. I'm not sure if they simply don't know, or prefer not to say.
I talked to Picotech yesterday and they told me that they really don't know how long the gaps are. I tried to measure the gap and find out an average value, but it seems to highly fluctuate around 1 µs.

-Fabian
Remember why you started and make it work.

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

Re: Fastest way of capuring data

Post by Mark_O »

Hi, Fabian.
Is this really true? I have understand this in the other way, I already described. If you are right, what is the benefit of the rapid block mode then? It really doesn't matter, if I partition the memory and write it full or if I write it full as one big memory.
The benefit is that if the data being sampled is sparse, then all the (potentially) large gaps get skipped. This can increase the acquisition window by many orders of magnitude. OTOH, if the data is NOT sparse, and all the gaps between segments are very small (your situation?), then you are right... it doesn't help at all.

One thing to take some comfort in is that even if I were wrong, and it could overlap sampling and transferring, it would make no difference! Why is that? Because of the mismatch in the two rates, in your case. If you're capturing at 5 GSa/s, while transferring captured blocks at ~130 MB/sec, then in fairly short order you will have filled all the segments, because they simply can't be emptied fast enough. I.e., regardless of the segment-size chosen, you'd be filling 40 segments in the time it takes to empty just one. That is an unsustainable situation.
I talked to Picotech yesterday and they told me that they really don't know how long the gaps are.
OK. Thanks for that information! Good to know.
I tried to measure the gap and find out an average value, but it seems to highly fluctuate around 1 µs.
Well, in your specific case (sampling at the max possible rate), they do indicate it is <=1 us. So you did confirm that, which is good.

Returning to your problem, you indicated a need to sample every 200 ps, but you didn't indicate how long each sample burst needed to be. You also haven't said how frequently you expect your trigger conditions to be met. With that information, it would be possible to determine if what you'd like to do is even possible with a ps6404D. It may not be.

Independent of your situation, I do wish that someone knowledgeable at Picotech could describe in more detail how their hardware-acceleration engine manages segmented captures. Right now it remains too much of a mystery, and that should be unacceptable to any engineer.

- Mark

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

Re: Fastest way of capuring data

Post by Martyn »

It is not true that we don't know the inter gap time, but it is true that it varies depending upon the setup of the scope, and also between the different scope ranges.

In simple terms it takes a fixed number of clock cycles to write the last sample to memory, change to a new block, rearm the trigger, and restart the capture; so in theory it would be possible to give figures. We have chosen not to publish this information, but to give a guideline figure, as it is not required for the the majority of customers and would just add confusion.

What you really need to do is look more closely at what you are trying to achieve with your data collection, what the exact nature of the data is, and then decide on the suitability of the device and appropriate mode of operation.

You ask the question Rapid Block or Single Block Capture ?

In your case Rapid Block would be the correct mode to select if you are interested in a specific number of data points, related to a point of interest (the trigger), but you have no interest in the data between these specific events. For this mode to work the trigger events must occur at intervals less frequently than the 1us re arm time of the 6404 if you are using the fastest timebase, unless you are not interested in every trigger event.

If the trigger events are occurring more frequently than 1us, and you need to see every one, then it would be necessary to capture the data as a single block, and then post process it.

Why not just use Single Block all the time ?

The memory on the scope is finite, if you are not interested in all the data that coming into the scope, using single capture would waste part of the device memory for this dead data. By using Rapid Block you can maximise the memory use, and therefore capture more events of interest in a single run.

Streaming Mode

When collecting data in streaming mode, the scope will sample at the appropriate rate, up to 156MS/s, temporarily buffering this in the scopes memory. The driver will read out this data, as and when it is allowed to by the operating system, at the USB line rate (~500MB/s). The buffering mechanism, and deep memory of the scope, means that data loss is unlikely when sampling at these speeds, even on a PC with other applications running.

It is also worth noting that timing program execution in LabVIEW, or any software development environment, will produce very variable results for successive runs. This is the nature of software running on systems that having multiple processes using the available system resources, many of which have a higher execution priority. However you can rely on the scope collecting the samples of data at the specified sample interval.

Hope this helps to clear things up.
Martyn
Technical Support Manager

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

Re: Fastest way of capuring data

Post by Mark_O »

Thanks for participating in the discussion, Martyn.
It is not true that we don't know the inter gap time,
OK. Even though Fabian reported yesterday that someone at Pico told him you didn't know. I'm glad to hear that you do.
but it is true that it varies depending upon the setup of the scope, and also between the different scope ranges.
OK. That is suitably vague.
In simple terms it takes a fixed number of clock cycles to write the last sample to memory, change to a new block, rearm the trigger, and restart the capture; so in theory it would be possible to give figures. We have chosen not to publish this information,
So I was correct then, when I hypothesized that you prefer not to say. :P

I think you're making this more complex and mysterious than it needs to be. But perhaps I am incorrect. We're not looking for a precise formula, that nails this down to the clock-cycle. We need some general guidelines and boundaries. I can tell you this though... as a current Pico customer, and potential purchaser of more expensive Pico gear, I want to know more than just what the dead-time is at 1 GSa/sec. I want to have some idea what it will be at 10x, 100x, and 1000x slower sampling rates.

This is an important consideration. Think a situation where you're capturing serial data streams, at 1-10 MSa/sec. Knowing (approximately!) what this dead-time between segments is in each case would be a pretty important factor, yet Pico is unwilling to divulge it.*

- Mark

[*I've been asking the same question of Pico support Tech staff (direct communications) for about 9 months now, and have never gotten a straight answer. Just, "it varies". Just like you stated above.]

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

Re: Fastest way of capuring data

Post by Martyn »

We don't actually have the figures available, because the development team have not published them, they have only provided the fastest re arm time. To ask the them to provide additional figures to cover all timebases, and all scope models, would take them away from more important work, and with very little gain for either ourselves, or our customers.

If you are concerned that you are going to miss data due to the rearming of the trigger, then it would be better to reconfigure the scope to capture more data in the given block, or even to capture just one block of data using all of the memory in the scope. In most situations it is just a case of understanding the data and setting the scope up appropriately.

With the 2105 and ADC-216 devices you have, rapid triggering is not available, therefore I suggest you contact our US office and get hold of a deep memory MSO scope on sale or return, you may then find that this is not an issue for you at all.

If this is not an option then you can always look at our competitors for a solution that more accurately meets your requirements.
Martyn
Technical Support Manager

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

Re: Fastest way of capuring data

Post by Mark_O »

To ask the them to provide additional figures to cover all timebases, and all scope models, would take them away from more important work...
Thanks for setting up a straw man. Did you enjoy knocking him down? :lol:

I haven't seen anyone asking for "all timebases, and all scope models". That may indeed be a chore. I asked for much less (3, in fact), but let's narrow it down to just one: 10 MSa/s, on a ps3000D unit. Is that also an unanswerable question? :?
If you are concerned that you are going to miss data due to the rearming of the trigger...
Ah, what engineer would NOT be concerned about such a thing? Is that not a pivotal question for using segmented acquisitions in the first place?
then it would be better to reconfigure the scope to capture more data in the given block, or even to capture just one block of data using all of the memory in the scope.
In other words, don't even bother using one of the more powerful (and much advertised) capabilities? :roll: That doesn't make any sense to me.
In most situations it is just a case of understanding the data and setting the scope up appropriately.
I understand the data perfectly. What I don't understand is the capabilities and limitations of the test instrument. Which is why I came here, in search of technical information. Is this the wrong place to ask questions? Because that is the impression you are conveying.
...you can always look at our competitors for a solution that more accurately meets your requirements.
:shock: I think you need to remind me... what company do you work for? PicoTech may be interested in the answer to that.

An engineer comes here asking very reasonable and polite questions. And your response is to effectively say, "Get one and try it for yourself, or bugger off"? That is very strange indeed. I think you've insulted me enough that's what I probably should do. :( Perhaps I'm not the only one who should heed your sage advice?

- Mark

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

Re: Fastest way of capuring data

Post by Martyn »

I don't have the details of the data streams you are thinking of looking at but will give some thoughts on how to decide whether a PicoScope 3000D would be suitable for your needs.

A sample rate of 10MS/s would suggest that you are looking at 1MHz clocked data, possibly 2MHz, to give a good representation of the signal.

Now consider how many samples it would take to cover your bit stream, and you are likely to still be in the low KS, even with 64 bit data. If you change the sampling to 100MS/s, this would still only mean mid KS, but you are now looking at re arm times of around 1us, or close to the clock rate of the data stream. Unless there is data collision going on, for which I would suggest using single block capture for analysis, you should not be missing any data blocks, and therefore re arm time is no longer an issue.

With the deep memory buffer, 64MS for the entry level 3000D, you would be able to collect a few thousand blocks of data per run.

When I said to look at competitors it was because we are confident in our products going up against them on a price and performance basis.

If you would like to email us on support@picotech.com, with your contact details, I can see if our US office has an old MSO unit they could loan you for evaluation.
Martyn
Technical Support Manager

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

Re: Fastest way of capturing data

Post by Mark_O »

Martyn,

thanks for the informative response.
Martyn wrote:A sample rate of 10MS/s would suggest that you are looking at 1MHz clocked data, possibly 2MHz, to give a good representation of the signal.

Now consider how many samples it would take to cover your bit stream, and you are likely to still be in the low KS, even with 64 bit data. If you change the sampling to 100MS/s, this would still only mean mid KS, but you are now looking at re arm times of around 1us, or close to the clock rate of the data stream. Unless there is data collision going on, for which I would suggest using single block capture for analysis, you should not be missing any data blocks, and therefore re arm time is no longer an issue.
My actual use cases involve data streams that I sample at rates varying from 1 MS/s to 16 MS/s. Which is why I picked 10 MS/s as a representative intermediate value. At the high end of that range, a re-arm time up to 2 us worst case would probably be acceptable. At the low end, things are looser, and up to 8 us would likely be tolerable.

While I am mildly disappointed that you shifted the requested test case from 10 MS to 100 MS, the fact that the rearm time is still close to 1 us tells me a lot. It really implies that the rearm time degrades slowly, as sample rate drops. This is critical information to know.

Why? Because citing nothing more than a single, best-case spec, is inadequate. I've never seen any engineer on any piece of test gear whose focus was on what the best-case performance was. That's not how engineers work. We need to know worst-case performance as well. Or at the very least, some information on how performance degrades under various conditions. That's what professional engineering is all about... dealing with boundary conditions, and providing adequate margins.

Lacking any information at all (the situation from the beginning of time, up until your post), one might easily wonder if the re-arm time degraded proportionally? I.e., 1 us at 1 GS, so 10 us at 100 MS, 100 us at 10 MS, and so forth. That would certainly be one plausible projection, based on absolutely no information at all. Well, that's obviously not the case, but there has been no way to know that from anything PicoTech has ever published.

Thank you for shedding some light on a very important subject. I think this is also worthy of mention in your T&M News. As you did in the July issue with my previous inquiry about timebase limitations on Rapid Trigger Mode.

I hope you can see that the questions I am asking are not only helpful to me, but will help PicoTech as well. Because I am not the only engineer who is (or should be) questioning these issues, that Pico has failed to fully specify. Vagueness "works" for politicians, but it is potentially disastrous for engineers.

- Mark

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

Re: Fastest way of capuring data

Post by Martyn »

It wasn't a case of changing the test case, after all the data stream would still be the same, but just an example of using the full capabilities of the scope, and the software, to collect the required data. Something that is probably easier to do with an actual scope in front of you, rather than trying to imagine what is possible from written specifications.

In this case by changing the settings of the scope, because the extra memory depth allows you to do so, it is possible to overcome any perceived limitations in trigger re arm times.
Martyn
Technical Support Manager

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

Re: Fastest way of capuring data

Post by Mark_O »

Martyn wrote:In this case by changing the settings of the scope, because the extra memory depth allows you to do so, it is possible to overcome any perceived limitations in trigger re arm times.
Thanks. But there are two significant problems with those statements.

The first is that the limitations in trigger re-arm times are NOT "perceived". They are real. Whether those limitations are relevant or not is what my inquiries were intended to determine.

Secondly, the "extra memory depth" available on a Picoscope does NOT allow you to change the Settings, with no impact. The lower rates I had inquired about would allow 10,000 segments to be acquired. By increasing the sample rate by a factor of ten (as you did), that also decreased the number of segments by the same amount. Being able to acquire 1,000 segments is NOT the same as capturing 10,000. Especially since the Picoscopes have no protocol-level triggering capabilities, thus requiring ALL traffic to be captured. The window is therefore much narrower.

In some cases that 10k vs. 1k could make the difference between solving a problem, and not. In others, it might simply reduce productivity, and require more time and effort to accomplish the task. In either case, it's an important consideration.

- Mark

Post Reply