Question about Streaming and Block transfer modes

First let me explain how I think it works.

My understanding is streaming works like this:
sample number: 1 2 3 4 5 6 7 8 9 10 11 ...

Every single sample is transferred over the USB port, as it is generated by the oscilloscope.


And that block transfer mode works like this:
Block 1 samples: 1 2 3 4 5
Block 2 samples: 6 7 8 9 10
Block 3 samples: 11 12 13 14 15
Block ...

The samples are gathered into "blocks" by the oscilloscope, and when each block is full it is sent over the USB port. This way, every sample that is generated by the oscilloscope gets sent to the computer, with the only difference being that they are sent in groups known as "blocks", rather than one sample at a time.

Is this correct? Or does block mode actually drop some samples, like this?

Block 1 samples: 1 2 3 4 5
(samples 6 and 7 are missing)
Block 2 samples: 8 9 10 11 12
(sample 13 is missing)
Block 3 samples: 14 15 16 17 18
Block ...


Please let me know. I am planning on buying a Picoscope, and would like to use it at a sample rate higher than allowed by Streaming mode, and am aware that Block Transfer mode can run much faster than streaming mode. However, in my application, the complete original signal must be able to transferred to the computer, and the signal will last longer than one block. Therefore, it is absolutely essential that Block Transfer mode does NOT drop any samples.

Please let me know if it is possible to make sure that Block Transfer mode doesn't drop any samples.

Hi Ben,

The description is close but hopefully the information below will provide some clarification.

In streaming mode, the oscilloscope begins to collect data and returns data in chunks (the driver manages this process, and the number of samples returned at a time will depend on the settings). If you are writing your own application, then you would need to ensure that you are retrieving data from the device at regular intervals to avoid potential data loss. The buffer memory on the PicoScope is used as a cache but if it becomes full, then this is where data loss could occur.

It is unlikely that you would get back 1 sample at a time from the device/driver unless downsampling is being used when writing your own application.

In block mode, the data is collected into the buffer memory of the device and then transferred to the PC when it is requested. The memory allocated for a single capture depends on the number of samples requested and the number of channels enabled (the memory should be divided by a power of 2, so a quarter per channel when 3 channels are enabled).

For example, on a PicoScope 3000 Series device you could request a capture of 1 million samples per channel with 2 channels enabled, and the device will collect a total of 2 million samples which are then transferred to the PC in one call to the driver.

If you are capturing multiple blocks of data (e.g. when capturing multiple waveforms with the PicoScope software), then the buffer memory on the device can be segmented with each segment of buffer memory sub-divided according to the number of channels enabled. There will be some dead-time between captures while the trigger is re-armed.

There is also a rapid block/rapid trigger mode where the memory is segmented and waveforms are captured with minimum re-arm time between triggers. The data is then transferred to the PC when the capture is complete.

You download the PicoScope 6 software free of charge from our Downloads page to try these modes of capture.

We do provide further explanation of the Block and Streaming capture modes via our Library A to Z of PC Oscilloscopes and Programmer's Guides (see here for one example).

I hope this helps but if you need further clarification, please post back here. It would be useful to know the number of channels you require, the sampling rate, the number of samples per channel and the number of waveform you would like to capture.

Regards,

Ben,

At what sample rate are you planning to do the sampling ?
If it is essential to NOT lose any samples between data chunks streaming mode is the only solution to go.

The key question here is the sample rate you are planning on (and the number of channels at the same time)

P.S. with the SDK the limit is USB transfer rate and not the scope.

Regards,
Benno

Hitesh wrote:I hope this helps but if you need further clarification, please post back here. It would be useful to know the number of channels you require, the sampling rate, the number of samples per channel and the number of waveform you would like to capture.

I need only one channel, and its bandwidth must be at least 6MHz, as that is the bandwidth of an NTSC composite video signal (the yellow plug on the A/V cable from a camcorder). According to the specs for the scope that I had wanted to buy (Picoscope 2204A, which has a 10MHz bandwidth) the maximum sample rate for USB streaming is 1MS/S (which gives a nyquist limit of only 500kHz, well below my required bandwidth of 6MHz). Is this streaming limitation only in the Picoscope 6 software? Or does this limitation also effect the Picoscope SDK? Missing any samples (if the lost samples were in the middle of the picture part of the signal) would mean losing pixels in the final decoded image.

Fast block mode MIGHT work, if it can be done so fast that it loses NO samples. However, streaming mode would be much better, because it would guaranty no lost samples, but I would need to be able to set the sample rate to 12MS/S (to get a 6MHz bandwidth), and not be limited to 1MS/S. So I strongly hope that that 1MS/S sample rate limit is only a limit of the Picoscope 6 software when interfacing with the Picoscope 2204A hardware, and not an inherent limit in the Picoscope 2204A hardware.

the 2204A has only 8kb buffer memory, have you calculated how short of a hick-up in USB streaming causes a buffer overflow, at that speed even a mouse click can cause a buffer overflow.

Go for a scope with enough memory to buffer at least 0.5 sec of data at your max streaming speed.

And USB3 is a lot faster at streaming with the SDK.

Benno

bennog wrote:the 2204A has only 8kb buffer memory, have you calculated how short of a hick-up in USB streaming causes a buffer overflow, at that speed even a mouse click can cause a buffer overflow.

Go for a scope with enough memory to buffer at least 0.5 sec of data at your max streaming speed.

And USB3 is a lot faster at streaming with the SDK.

Benno

I have an 8 core CPU. That means 8 processes (including detecting mouse clicks) can run simultaneously. My computer wouldn't be overloaded by a single mouse click, so it wouldn't have to stop processing USB streaming data to process a mouse click.

Also my computer has USB3, not USB2. Does Picoscope 2204A support USB3? Or does it only support USB2?

Also, does the Picoscope 2204A support USB streaming at rates faster than 1MS/S, if you use the Picoscope SDK (and write your own software) instead of using the Picoscope 6 software? Or is that 1MS/S a limit in the Picoscope 2204A hardware (or its firmware), and thus can't be overridden even by using the Picoscope SDK?

Then you need to write multithreaded software and know how to write it in a minimal or non blocking way.

But in the 2000 specifications under the section
'SDK / API details and specifications for customers writing their own software'

you can see the 2204A will only do 1MS with the SDK and only USB2
From the 2206 and up you can get about 31 MS/sec with the SDK and only USB2

If you want USB3 speeds you need a 3000 series scope.

Benno

Hi Ben,

Further to Bennog's comments, the PicoScope 2204A is limited to 1 MS/s as it is a low memory device and so there is likely to be data loss regardless of whether you use the PicoScope 6 software or the driver. The buffer memory can be used as a cache during data collection, so data must be retrieved regularly from the device in order to avoid data loss.

The PicoScopes are able to achieve a wide range of sampling rates which are governed by the on-board ADC(s). In the case of the PicoScope 2206B you should be able to achieve a rate of 12.5 MS/s. If you require exactly 12 MS/s then downsampling can be used but you would probably have to look at a USB 3.0 model due to the upper limit of around 31 MS/s on USB 2.0.

Regards,