stop stream acquisition but transfer data afterwards? | LabJack
 

stop stream acquisition but transfer data afterwards?

4 posts / 0 new
Last post
George McBane
GMcBane's picture
stop stream acquisition but transfer data afterwards?

I am using externally clocked stream, and watching for a non-T7-related event to decide when the interesting part of my data set has concluded.  Once that has happened, I would like to tell the T7 to stop collecting stream data, but still be able to retrieve the data it has collected so far.  That doesn't currently seem possible.  I can call eStreamRead only while the stream is running.  Once I know all the interesting data have been collected, I can call eStreamStop - but then any data collected between my last eStreamRead and my eStreamStop are inaccessible. If I continue to call eStreamRead, I keep collecting packets, but the T7 carries on acquiring more data that I don't want.  Is there a way to pause stream acquisition that permits me to continue reading until the onboard buffer is empty?

Thanks,

G.

LabJack Support
labjack support's picture
How big is the LJMScanBacklog

How big is the LJMScanBacklog parameter when you stop stream? You should be able to keep it low, where "low" means about equal to or less than the ScansPerRead parameter that was passed to eStreamStart. In that case, you shouldn't have much excess stream data and you can stream for perhaps ScanPerRead / ScanRate seconds to collect one more eStreamRead call worth of data.

Alternately, you can ignore the LJME_STREAM_NOT_RUNNING error when reading eStreamRead after calling eStreamStop. You'll notice that the LJMScanBacklog decreases each time. Be sure to not call eStreamRead when LJMScanBacklog is less than ScansPerRead. There currently isn't a way to retrieve less than ScansPerRead scans from eStreamRead.

Edit: LJMScanBacklog less than ScansPerRead, not greater than

George McBane
GMcBane's picture
> How big is the

> How big is the LJMScanBacklog parameter when you stop stream? You should be able to keep it low, where "low" means about equal to or less than the ScansPerRead parameter that was passed to eStreamStart. 

Yes, that's what's happening.  The backlog is usually single digits.

> In that case, you shouldn't have much excess stream data and you can stream for perhaps ScanPerRead / ScanRate seconds to collect one more eStreamRead call worth of data.

That is what I am currently doing: once my external event has occured, I make one more eStreamRead call, stop the stream, then decide in software how many of the final points need discarding.  I would just prefer to be able to swap the stop and the final read.

> Alternately, you can ignore the LJME_STREAM_NOT_RUNNING error when reading eStreamRead after calling eStreamStop. 

Ah.  If that works, then maybe I have what I want.

> You'll notice that the LJMScanBacklog decreases each time. Be sure to not call eStreamRead when LJMScanBacklog is greater than ScansPerRead. There currently isn't a way to retrieve less than ScansPerRead scans from eStreamRead.

That statement was confusing; should it have said "when LJMScanBacklog is less than ScansPerRead"?  If my interpretation is correct, then data are only retrievable in chunks of ScansPerRead, and any "leftover" data (if ScansPerRead>1) are lost. 

Thanks,

G.

 

LabJack Support
labjack support's picture
Yes, it should have said "Be

Yes, it should have said "Be sure to not call eStreamRead when LJMScanBacklog is less than ScansPerRead." I've edited my post. Sorry about that.

On a related note, you can use low-latency stream (a small number of ScansPerRead) to ensure that you collect a small(er) number of scans after your external event:

https://labjack.com/support/software/api/ljm/function-reference/ljmestre...

If you use a low-latency stream, you may want to try out LJM 1.1803, which has improved stream throughput. (1.1803 is currently in the Beta installers for Windows/macOS/Linux64-bit.)