Setting sampling frequency in PicoScope 5442D

[vgeno]

I am collecting data by using a PicoScope 5442D connected to my Pc (OS: Windows 10).
A special software was developed in C Microsoft Visual Studio 2019 by means of the PicoSDK_64_10.6.16.113.

The program allows to change the some parameters configuring the PicoScope 5442D such as the resolution.
By analyzing the data collected in streaming mode I have estimated the current USB data rate adopted by the system: 1MHz.

The issue:
is it possible to change programmatically the USB data rate (I need to lower it) ?
I know that such the USB data rate does not match with the internal sampling rate of the oscilloscope
but for my application the sampling rate corresponds to USB data rate.
I have checked the PicoScope 5000 Series (A API) Programmer's Guide and an easy solution (a specific command) seems to be not available.

Best Regards
Vincenzo

[Gerry]

Hi Vincenzo,


It is possible to lower the data rate in your code.

For Streaming Mode, the USB 3 transfer rate for PicoScopes entirely depends upon the rate that you are sampling the data. There is a practical Maximum of 125MS/s for 8-bit, or 62.5 MS/s for 12 to 16 bit modes, in order to be able to guarantee working with the data on the PC, without any data loss. So, you can't change the data rate of your application by making any changes to USB and therefore you won't find any commands related to the USB data rate in the Programmers Guide.

If you want to change the data rate you will need to change the Timebase value in either the ps5000aGetTimebase function or the ps5000aGetTimebase2 function (depending upon which one has been used in your application). However, if either (a) you run into difficulties, or (b) you want to change more of your Application code, and the code is too complicated/convoluted to work through and isn't documented well, I would recommend downloading the example code for using 'C' in the SDK which we provide here: https://github.com/picotech/picosdk-c-examples. The downloaded zip provides examples of basic functionality that you can work through and experiment with to gain an understanding of how to control the PicoScope with a custom Application.

Regards,

Gerry

[vgeno]

Hi Gerry,

thank you for the prompt reply.
By modifying one sample code (ps5000aCExamples.sln) contained in picosdk-c-examples-master (GitHub repository) I am currently able to
change the sampling frequency in streaming mode. The function involved is: ps5000aRunStreaming. This function allows to set the sampling time and consequently the data rate over the USB.

A new question.
I noticed that the data collected by means of the function ps5000aGetStreamingLatestValues are returned in packets containing more than one sample at a time (it is not clear if these packets are originated by the Pico 5442D or by the drivers running on my Pc). My application have to process each sample in real time and of course the packet destroys the timing integrity).
Therefore what I need is to force the system to provide sample by sample (something like a function ps5000aGetStreamingLastValue).

Best regards
Vincenzo

[Gerry]

Hi Vincenzo,

Yes, ps5000aRunStreaming is the correct function to use. I was thinking that you wanted to have the sample rate editable in your user setup (and forgetting that you only need to set the Timebase in Block Mode - too many coding cobwebs in my head from being on furlough ).

Regarding your second question, once you have initiated streaming with ps5000aRunStreaming, the data is sent, over USB continually, until you call ps5000aStop, or until the number of post trigger sample values have been sent (depending upon the choice you have made for the autostop value in ps5000aRunStreaming). So, to answer your question, the driver requests the start of the streaming and the hardware then originates sending packets of data to the PC. The Driver places the received data in the Overview Buffer, which is a circular buffer that you define the size of in ps5000aSetDataBuffer or ps5000aSetDataBuffers. The way the data is transferred and stored in the Overview Buffer means that the call to ps5000aGetStreamingLatestValues will return varying numbers of values each time. Once it reaches the end of the Overview Buffer the write pointer will just wrap around so that it continues storing new data from the start of the buffer. So, in order to avoid the driver overwriting valid old data with new data, you need to be emptying the Overview Buffer by calling ps5000aGetStreamingLatestValues, often enough (so that the Overview Buffer is being emptied faster than the rate that it is being filled).

So, you shouldn't be using the Overview Buffer as an application store for your data, you should have your own additional Application Buffer to store your data in. I will explain why using an analogy (because for some people visualisation makes this clearer). So, think of the USB data transfer as a courier delivering food to you, in varying amounts. You can't pick individual items from him, otherwise he'll leave everything on the floor outside and go. So, you have to take the whole lot from him (which represents the driver) and place it on the kitchen table (which represents your Overview Buffer). You would like to just take food off of the table and go away and eat it (which represents your Application making use of the data), but you have many deliveries coming, at regular intervals, and you don't want the kitchen table (Overview Buffer) to be filled up, otherwise you would have to start putting food on the floor which means it would get dirty and need to be thrown away (which represents data being overwritten). So, you start putting individual items away in cupboards, fridge, etc, (which represent your Application buffer) except when you have to stop to get the next delivery from the door. Now, what you can do is put away the food away while you are eating it, and occasionally putting more food on the table from the next courier.

So, the key to making the system work, without having to throw away food, is (a) making sure that you have a big enough table to accommodate the first few deliveries, and then most importantly (b) making sure that the couriers are not arriving to quickly, i.e. are only arriving at a rate that guarantees that the table will always have enough space on it for the next delivery, based upon how quickly you are putting away the food and freeing up the space in your cupboards, fridge, etc. by eating it. Or, analogy aside, the key to making the streaming work without data being overwritten, is (a) making sure you have a large enough Overview Buffer to accommodate the first few calls to GetStreamingLatest Values(), and, more importantly (b) making sure that you are not using a sampling rate that is too fast, i.e. using a sampling rate that guarantees that the Overview buffer will always have enough space in it for the next GSLV() call, based upon how quickly you are transferring the data to your application buffer and using the data up in your application (freeing up the space in your application buffer).

Bear in mind that, in the analogy, if you were to just eat the food off of the table you would be filling up the table much quicker because eating the food is much slower than putting it away, which is true outside of the analogy, i.e. you would be over-writing data in the Overview Buffer much sooner because processing the data in your application is much slower than transferring it to an Application Buffer.

Ultimately though, and most importantly of all, if your original application was running close to the maximum possible, without over-writing streamed data, and you are reducing the transfer rate because you wanted to add more functionality (processing of the data) to the application, then you would have to lower the transfer rate enough to compensate for how much longer you are taking to process the data, if you want to avoid over-writing the data (so, just for completeness , in the analogy, if you wanted to heat the food in the microwave before eating it, you would have to slow down the deliveries, to compensate for the time the microwave is running, in order to avoid having to throw away food when the table gets full).

Regards,

Gerry

[vgeno]

Hi Gerry,

thank you!!!!

Your explanation is clear and confirms what I could get from the A API manual.

Just a remark about the timing:
regardless my code speed, there is no way to be sure that the USB data packet coming from the device contains just one sample a time. Therefore a 100% correct timing (useful for real time control) is not reachable.
Is it right?


Best regards
Vincenzo

[Gerry]

Hi Vincenzo,

You can't use a PicoScope for real-time control of a closed loop system based upon the timing of streamed sample collection. This is because no timing information is sent with the data to the PC, so there is no way of knowing exactly when each sample was collected.

In Block Mode some of our PicoScopes can send timing of blocks of samples relative to the Trigger used to start the capture. However, as streaming is a method that doesn't fill a buffer and then send that as a block of data, it has no associated absolute or relative to the trigger timing.

Regards,

Gerry