I have a PS2203 and I'm using the PS2000.dll and ctypes in Python. I have it working with no auto stop and my call back function collects the data nicely. I've set up a data buffer of length 20,000 and set the overview_buffer_size to 20,000, I have the timebase set to 1us. I was hoping to be able to only transfer the overview buffer data to my buffer once they were full so I guessed this is very much dependent on the speed of the computer as the number of values collected on the first call to ps2000_get_streaming_last_values(handle,stream_ready)gives me 20,000 values but subsequent calls give me:199991068210682etc etc13671367I tried placing a sleep in the code after the call to ps2000_get_streaming_last_values(handle,stream_ready) but this doesn't effect the number of values captured diminishing over time. I'm assuming that this all to do with how much data is available at the time of the call to get the values but I was wondering if there's a way that I can wait until the buffer is full before transferring to my buffer?

It would not make sense to wait for the buffer to be full before returning data as you would then be risking buffer overruns if some other windows service came along at a higher priority level.

I would expect the number a values to settle to a steady state value over time which reflects the actual streaming rate. There would be occasional variations as other windows services kick in, therefore the overview buffer size needs to be able to cope with this.

You could always set up a fixed buffer size approach in your application if you need to as part of data presentation or manipulation.

Ok so I've finally got back around to this and implemented some python code to manage the stream of data coming back from the buffers. In the mean time I've been working with and analysing the data using block mode which produces a nice waveform. The overall goal was always to eventually use the fast streaming mode and do some data analysis on the fly. I've just realised though that the data coming back in fast streaming mode is incorrect (it looks like random noise, and should be a high pass filtered mains signal with an attenuated 50Hz sinusoid and the associated noise - this is what I get in block mode), but what I get with fast streaming just looks like random noise. I've spent quite a bit of time trying to get the datatypes right: