Test and Measurement Forum

Hello,

we have been using the C sample code to obtain streaming in non-aggregated mode with PicoScope 5204.
We want to stream data to file with:
sample interval: 104ns
down sample ratio: (1 (no aggregation)
10MB buffer for channel A
a sleep time of 10 ms

Extracted code:
// Register the data buffer 10MB.
unsigned long bufferSize = 10000000;
short *buffer = (short*) malloc(bufferSize * sizeof(short));
ps5000SetDataBuffer(unit->handle, PS5000_CHANNEL_A, buffer, bufferSize);

// start the scope, sampe interval is 104
ps5000RunStreaming(unit->handle,
&g_sampleInterval,
PS5000_NS,
0,
bufferSize,
FALSE,
1,
bufferSize);

// Grab the data
while (!_kbhit())
{
Sleep(10);
g_ready = FALSE;
status = ps5000GetStreamingLatestValues(unit->handle, CallBackStreaming, NULL);

if (g_ready && g_sampleCount > 0)
{
fprintf(fp, "Collected %i samples, index = %i\n", g_sampleCount, g_startIndex);
for (unsigned long i = g_startIndex; i < (unsigned long)(g_startIndex + g_sampleCount); ++i)
{
// adc_to_mv
fprintf(fp, "%2lu: %d\n", i, ((buffer[i]* range ) / PS5000_MAX_VALUE) );
}
}
}


The data seems to be ok (we'we looked at in it MatLAB)
until the buffer wraps around, then we loose data.
We have a fairly new laptop Intel Core 2 Duo, 2.4GHz, 2GB RAM.
What could cause us to loose data (only happens when buffer wraps around, when g_startIndex = 0)?

Regards,
jan

Hello it's me again:

We use ps5000SetDataBuffer to register the buffer to the driver.
The problem is that when the buffer (size 10MB) wraps around
with cont streaming, no-triggers, non-aggregation mode in a sample interval of 104 ns.

When calling ps5000RunStreaming with autostop= 0,
then (since we do not use triggers) maxPreTriggerSamples is ignored.
But what about maxPostTriggerSamples (max no of samples)?
Is this parameter ignored too (since autoStop is 0). If it's used then what could be a suitable value?

Jan

Hi Jan

I just want to make sure I understand the problem that you are seeing.

Are you saying that the driver is returning samples correctly until it has returned a number of samples equal to the buffer length? If so, what data do you get from the driver once this has happened? Is it the same data repeated?

Thanks

Robin

Hi Robin,

I'm working with Jan. So I'll try to help with your question.

We try to stream data to the PC but it when we open up the saved file we can see that there are data missing.

When checking the file I can see where new data is collected (collected samples and index position). Here is an example:

Settings:
Sample interval 104 ns
Number of iteration 10
Sleep time 10 ms

iteration 1: Collected 32689 samples, index = 0
iteration 2: Collected 655360 samples, index = 32689
iteration 3: Collected 7864320 samples, index = 688049
iteration 4: Collected 8546609 samples, index = 0
iteration 5: Collected 8540849 samples, index = 0

The buffer size is 10 MB.
From the above we can see that after iteration 4 a wrap-around occurs (we have rached the maximum buffer size). This is as expected BUT when I check the sampled data I can see that there is a gap. We loose data when the wrap-around occurs.

I have tried different settings for sleep time, sample interval and buffer size but all results in the problem that I loose data when we return to index=0 (wraparound).

Hope this clears your answers a little bit Robin,

Best regards,
Mikael

Hi Mikael

Which sample rates have you tried? Have you tried a low sampling rate?

The maximum rate at which you can stream will depend on both your hardware and software (writing the data to a file will add overhead, for example).

I would be suprised if the example code can stream at the rate you require.

The driver indicates lost data by setting the sample value to:

#define PS5000_LOST_DATA -32768

Robin

Hi,

I've tried with different sample rate (the lowest 200 kS/s) but the only difference is that it takes a little bit longer before the buffer is full. We still loose data.

I thought that the streaming would be continuously if the sample rate was not to big. But maybe it's not possible?

/Mikael

Hi

We have found the cause. The driver was calling the callback function twice when the buffer overflowed.

The attached DLL should work correctly with the example.

I hope this helps

Robin

Hi,

Thanks, now it looks better. When it starts again at index=0 we don't loose any samples as before.
But I can see that something strange occurs sometimes. We have a buffer size at the moment of 12 MB. When analysing the data I can see that almost all of the 12 MB is read each iteration. But sometimes it looks like this:
(this is cut out from the resulting data-file)

11999929: -377
11999930: -377
11999931: -377
11999932: -377
11999933: -377
11999934: -377
11999935: -377
Collected 64 samples, index = 11999936
11999936: 330 <- this is not correct, garbage?
11999937: 330 <- this is not correct, garbage?
11999938: 330 <- this is not correct, garbage?
11999939: -377
11999940: -377
11999941: -377
11999942: -377
11999943: -377
11999944: -377

It almost always when 11999936 samples have been collected and the remaining 64 samples shall be collected that there is some wrong bits (in this case 3 samples).

Another example:

11999929: -39
11999930: -39
11999931: -39
11999932: -39
11999933: -39
11999934: -39
11999935: -39
Collected 64 samples, index = 11999936
11999936: 141 <- this is not correct, garbage?
11999937: 149 <- this is not correct, garbage?
11999938: 141 <- this is not correct, garbage?
11999939: 149 <- this is not correct, garbage?
11999940: 149 <- this is not correct, garbage?
11999941: 149 <- this is not correct, garbage?
11999942: 149 <- this is not correct, garbage?
11999943: 149 <- this is not correct, garbage?
11999944: 141 <- this is not correct, garbage?
11999945: 149 <- this is not correct, garbage?
11999946: 149 <- this is not correct, garbage?
11999947: 149 <- this is not correct, garbage?
11999948: 149 <- this is not correct, garbage?
11999949: 149 <- this is not correct, garbage?
11999950: 149 <- this is not correct, garbage?
11999951: 149 <- this is not correct, garbage?
11999952: 149 <- this is not correct, garbage?
11999953: 149 <- this is not correct, garbage?
11999954: 149 <- this is not correct, garbage?
11999955: 149 <- this is not correct, garbage?
11999956: 149 <- this is not correct, garbage?
11999957: 149 <- this is not correct, garbage?
11999958: -39
11999959: -39
11999960: -39
11999961: -39
11999962: -39
11999963: -39
11999964: -39

22 samples are not correct.
The sample rate in this example is 104 ns (~10 MS/s)
Don't know if the buffer size is causing the trouble?

Best,
Mikael

Hi Mikael

Are those raw or scaled values?

At such a high sampling rate, I wouldn't be suprised if you are loosing samples. However, the driver should return

#define PS5000_LOST_DATA -32768

for these lost sample values.

Have you tried lower sampling rates?

Robin