Streaming mode loses data

[sjlongland]

Hi,

We recently purchased a DSLogic Plus based on the fact that it can stream the data out at 100MHz.

Our use case is simple… we want to determine how much CPU time is being devoted between two different tasks on a micro-controller. We've modified the code so that it turns a GPIO pin ON for one task, and turns it OFF for the other. We want to measure the width of each "1" and "0" pulse of this GPIO pin. For this we just need a single channel, and so the 100MHz streaming mode should be perfect for the job.

Workstation running the DSLogic is a Core i5-2410 laptop with 6GB RAM running Debian 10. I have also tried with Ubuntu 18.04 LTS on a Rysen 7 desktop with 16GB RAM.

In both cases, I configure the probe (under Options) for stream mode, select 3-channel mode, and turn off all channels but channel 0.

I then set the sample rate as high as it will go (100MHz), put DSView into Repetitive mode, set the smallest interval I can (it won't let me select less than 1 second… this is "streamed" is it not?), then hit Start.

I start the test running on the microcontroller, go get lunch. 10 minutes later I return.

Upon return, I should have 10 minutes of data. DSView only shows 2 minutes worth. How do I retrieve the previous 8 minutes as well as the 2 minutes displayed?

[DreamSourceLab]

@sjlongland This is not the case of data lose. It seems you have a misunderstanding about the repetitive mode. It just repeats your caputure under your settings (capture duration & capture sample). If you want to capture a long time, just change the capture duration. For detail explain on different modes, pelease refer to our user guide: https://www.dreamsourcelab.com/doc/DSView_User_Guide.pdf

[sjlongland]

So where do I get the previous 8 minutes that are allegedly "not lost"?

[DreamSourceLab]

If you set 2 minutes on Sample Duration, only 2 minutes data will be captured. If you want to capture 10 minutes, just set 10 minutes on Sample Duration.

[sjlongland]

When 100MHz is selected as the sample rate (which is the maximum supported for "streamed" mode), 2.86 minutes is the maximum duration that it allows for selection. It doesn't give a 10 minute option.

This is a bug. "Stream" mode means the sample duration should stop when I click the stop button, i.e. it's "streamed", not "buffered".

[DreamSourceLab]

Of cause there will be a limitation on sample duration. Memory space is limited for any program. Is there any software can capture and store data forever? let alone with 100MHz sample rate. And we already declare the max sample depth for stream mode is 16G. at 100MHz, the max sample duration is 16G/100M about 160s. (2.86 minutes), which explained clearly in our user guide. Issues are used to discuss software, not technicial specification.

[sjlongland]

So it isn't streaming at all, it's buffering, like I asked it not to in the software? If I wanted buffered mode, I'd have selected buffered mode. I selected streaming mode, I expected streaming mode.

Buffer size in the device is irrelevant at this point because it should be the host PC that's storing the samples, a machine with many gigabytes of RAM and even more of disk.

The scope and its software was obtained on the promise it could "stream" samples at 100MHz, implied in that is that since it is streaming the samples, minimal buffering if any is occurring and thus the limitation in buffer size is on the host computer.

The software is not fulfilling this promise.

[zhanglongqi]

I have the same issue. The stream mode has no difference from the buffered mode.

[olovskos]

Same here... Streaming Mode seems to be a lie...

[jgressmann]

I am experiencing the same problem w.r.t. streaming mode. Seems to be the same as buffered. Build on Ubuntu 21.10 from today's sources. Same behavior on Windows (pre-built binary). For my use case, that's pretty much a showstopper.

[andsmedeiros]

I also don't get your "streaming" mode. What we expect from a real streaming mode is to be able to see the signal in real time, as it is sampled, with no time limit on the capture. Right now, using the streaming mode results in a time limited capture that gets displayed all at once when the counter reaches its limit. This is virtually the same as buffered mode, doesn't matter if you transfer the buffered data during or after the capture. I bought my DSLogic to work on digital communications, and the signals I want to sample are often small and very spaced in time (e.g. digital messages sent in response to button presses). Not having an actual real time streaming mode burdens me with much preparation and timing that would be simply unnecessary. Saleae does this and it is the normative solution out there these days.

[c0d3z3r0]

It seems the issue regarding streaming mode being the same as buffered mode is resolved. I can see the signal in real time. However, I'm unhappy with that time limitation as well. I opened issue #725 for this.