I have been using the streaming mode on the CW1200 with UFO board and different targets without problems, but I recently had to face one problem and one question:
I have recently had the need to capture large traces. It appears that capturing 15,000,000 samples in a trace provokes an error, where 14,000,000 works fine. Is there such a limit in trace size when using the streaming mode? Also, setting an offset of 14,000,000 with a trace of 14,000,000 samples provokes the error as well.
When using the streaming mode, only one sample per cycle can be captured. Is it possible to choose which one of the four “usual” samples (i.e. with 4 samples per cycle when not using the streaming mode) is taken? Or is the one sample per cycle a kind of “average” of all four?
The Pro is rated to 10MS/s, but there’s a lot of variables that determine whether that rate can be achieved in practice (for example, activity from other USB devices).
When streaming, incoming samples are buffered in the CW1200’s relatively small internal sample storage and sent along the USB interface while the capture is in progress. So it’s possible for a shorter capture to succeed, but as you keep increasing the capture size, you may run into a situation where the link overflows before the end of the capture, which is what seems to have happened to you here.
So to answer your first question, there is no absolute limit to the capture size, unless the capture rate exceeds the rate that we can push samples over USB. This limit depends on a lot of variables so we can’t put a number to it.
The good news is that setting a large offset can definitely be made to work. What you’ve likely run into is that with a large offset, the capture is timing out before it’s done, and so you simply need to increase that timeout value with scope.adc.timeout.
For your second question: no, you can’t choose which sample, and no averaging is done. Sampling is done synchronously, on the sampling clock rising edge, so compared to clkgen_x4 you’re getting samples 0, 4, 8, …
You can however play with scope.clock.adc_phase to shift the sampling clock around.
In fact, when looking at the value of scope.adc.timeout and seeing the value 2, I suspected that this was also the reason why the capture of 15M samples failed (14M < 2 * 7.37M < 15M).
This was actually the case, and by increasing the timeout value, I could successfully capture a trace comprising more than 500M samples.
Just one more question: what is the unit / range of values for the scope.clock.adc_phase parameter?