data collection/save rate

[weschang]

Hi,
So I'm using a Picoscope 2000 series to collect ultrasound wave data. I'm controlling it with custom code on a Linux computer. It generally works well, but I notice that it's not able to collect more than one waveform per second. If I set to collect every 5 sec, it's quite accurate. Every 1 sec, still accurate. Every 0.1 sec, it only outputs one set of data every second. Each waveform contains about 3000 values. Does anyone have any idea as to the limitations of data saving rates, and whether it can go any faster? I would think that it should be able to collect much faster. (Or do I need to just use a better oscilloscope?)

[Gerry]

Hi weschang,

Are you using PicoScope 6, or the SDK and your own code? In PicoScope 6 if you want a fast waveform repetition rate you can use Rapid Triger Mode for the fastest sample rates, while in the SDK this would be Rapid Block Mode. But a lot depends upon which 2000 series PicoScope you have, and the exact implementation of what you are trying to do, including capture time etc. So could you tell us what the model is, and post some kind of data file and details of how you have set up the capture (if using the SDK, otherwise just the psdata file do).

Regards,

Gerry

[weschang]

Hi Gerry,

Thanks for the response. I am using the Picoscope 2206B. I am not using the Picoscope 6 software, but rather my own code in a docker container. I then use Python to tell the Picoscope when to collect a waveform and save it on the computer. The waveform is generally only 10 us long, including a delay of 26-27 us followed by a range of 10 us. It can only collect about 1 wave every 1 second. If I tell it to collect once every 0.1 sec, it seems like it maxes out around 1 wave / 1 second. I have the Python code readily available, but I suspect it's more so the backend, or maybe there is just an inherent limitation here? How fast would you expect this Picoscope model to be able to transfer data from the described wave to a Linux computer?

[Gerry]

Hi weschang,

Sorry for the delay in responding, and actually, you did mention your own application.

I don't have any figures for what the waveform update rate should be in Linux, but back when Windows 8 was around, the PicoScopes of the time were able to achieve these rates: https://www.picotech.com/library/oscill ... date-rates. Our specifications state that the Maximum waveforms per second are 80,000.

So, the only reasons that I can think of, as to why you can't achieve a rate better than 1 per second when capturing blocks in Linux, would be if either: the USB handling that you're using is less efficient, the overall effect of multithreaded processing and processing power is significantly reduced on your platform, your code needs significant optimisation, or some combination of those conditions. So, I have to ask, what platform are you running it on, what distro are you using, and are you able to benchmark or find out the performance of any of these factors?

As a means of overcoming the limitation with little effort, you can switch from using Block Mode to using Rapid Block Mode (which is supported in the 2000A driver) which will capture and store 10,000 of your waveforms in the 32MS Waveform buffer of your PicoScope before having to go through the exaggerated delay in transferring all of the waveforms over USB. Using this mode of capture the delay between the end of one waveform and the start of another should be microseconds.

Regards,

Gerry

[weschang]

Hi Gerry,

Yes it does look like the specifications are much higher than what I'm getting. I think it might be the overall effect of multithreaded processing, etc. We are already using the Rapid Block Mode.

The Picoscope is being used together with an ultrasonic pulser. The pulser sends out an impulse voltage very frequently, which then gets triggered by the Picoscope so that the Picoscope knows when to measure the wave. We're using the Picoscope Linux drivers from some Python code being run inside a docker container..(this is all also interfacing with code that connects to the ultrasonic pulser from another docker container).

Given that we are already using Rapid Block Mode, are there other solutions? Or we just need to poke around the drivers to see if anything can be further optimized..let me know if you have other thoughts. thanks!

[Gerry]

Hi weschang,

Sorry, I overlooked the Docker container that you mentioned, which is certainly a potential cause of the problem, as any virtualization utilizes an extra interface layer between guest and host systems, which could easily contribute to any slow down in communication with hardware.

So could you tell us what docker service are you using (and is what type, e.g. free/premium.....)?
Could you also tell us what computer platform are you running on, and what Linux Distribution are you using?

Could you tell us what sample rate you are using, how many waveforms you are capturing in Rapid Block Mode, and post example code of the key elements of your data retrieval (preferably with comments where necessary, as my Python is a bit rusty).

Regards,

Gerry

[weschang]

Hi Gerry,

This is a late reply, but the issue below was resolved after digging into my Python scripting more carefully and removing any timing delays. I've able to grab a waveform every ~0.2 seconds using the Docker setup I have, which is sufficient for my application.

Another question came up today: I now have both the 2208B and the 2207B, and I'm noticing there is slightly more noise waveform to waveform with the 2207B. Do you think this would be expected?

[Gerry]

Hi weschang,

That depends upon quantifying what you mean by "slightly". The noise levels even on any 2 same model Scopes can be slightly different, but still within spec, (especially where they are from 2 different batches) because the characteristics of components will vary slightly (but within tolerance) in different devices.

If you post data files for captures of the same signal on both Scopes, we can give you a yes or no answer.

Regards,

Gerry

[weschang]

Hi Gerry,

Please see attached for screenshots of sample waveforms collected by the 2207B vs the 2208B (all collection parameters are the same). As you can see, the actual waves look pretty similar, but by zooming in (the second plot shows the "total amplitude" which is the dot product of the wave just to see changes more clearly) one can see these intermittent blips in the amplitude. the second plot includes a bunch of waves that are collected over the course of a few minutes to note noise/stability. any thoughts as to where the increase in noise comes from?

[Gerry]

Hi weschang,

All I can say from what I can see on the left is that there appears to be no significant difference between the noise for the 2 Scopes. However, without knowing the absolute scaling that you're using, i.e. what proportion of the full-scale Input Range the amplitudes on the left represent, it's impossible to make any valid quantitative comment on accuracy.

Regarding the values on the right, I'm not exactly sure what you're doing or what you mean by 'total amplitude'. Could you explain in more detail?
(My understanding of a 'dot product' is that it includes another parameter associated with the amplitude, e.g. phase, turning it into a vector multiplication. So then, if you are multiplying amplitudes, as the units seem to suggest, then any minor differences between the amplitudes shown on the left are going to be exaggerated way out of proportion by the values shown on the right).

Regards,

Gerry

[weschang]

Yes, that's right, I'm multiplying each value in the wave with itself in order to exaggerate the differences. This is to see subtle changes more clearly rather than just looking at peak to peak differences. So yes, the two Picoscopes are quite similar, but one seems to be very slightly noisier than the other, as observed by the longer intermittent 'jumps' in the signal.

[Gerry]

Hi weschang,

The only way to conclusively answer your original question would be for you to paste the data files for a capture on both Scopes, with the Channel A of both Scopes set to the Input Range of ±20 mV, and nothing connected to the Channel A inputs apart from a 50Ω termination (e.g. in the form of 50Ω feed-through terminators, see here: https://www.picotech.com/accessories/bn ... inator-bnc).

Regards,

Gerry