Expected time to set up & start streams? | LabJack
 

Expected time to set up & start streams?

3 posts / 0 new
Last post
mikelwrnc
mikelwrnc's picture
Expected time to set up & start streams?

I need to use the T7 in streaming mode to capture a high frequency input (an emitter-detector scenario using lock-in amplifcation), but am cycling through signals that are expected to have very different signal ranges, so I'd to switch the adc range to match the expected signal range. I don't think it's possible to change the adc range once a stream has started, so presumably I'll have to stop the stream, reconfigure it for the next signal's expected range, and re-start it (possibly using burst stream to avoid having to manually stop?). Any idea what I might expect in terms of time it'll take to configure and start the stream each time? I need to be switching between signals at a minimum rate and if it's going to take seconds to configure and start the stream each time, I won't even bother with this avenue.

LabJack Support
labjack support's picture
Summary: a quick test via a

Summary: a quick test via a USB connection suggests that the time from stop to start is less than ~15 milliseconds.

More details: I modified stream_basic.c to have the following code replace the original stream stop code:

    printf("Stopping stream\n");

    unsigned int t0 = GetCurrentTimeMS();

    err = LJM_eStreamStop(handle);
    ErrorCheck(err, "Stopping stream");

    HardcodedConfigureStream(handle);

    err = LJM_eStreamStart(handle, scansPerRead, numChannels, aScanList,
        &scanRate);
    unsigned int t1 = GetCurrentTimeMS();

    printf("from before LJM_eStreamStop to after LJM_eStreamStart: %ld milliseconds\n", t1 - t0);
    ErrorCheck(err, "LJM_eStreamStart");
 

This gave results of ~15 milliseconds. Notes:

  1. HardcodedConfigureStream could be faster. It currently writes configurations one at a time (for readability sake). To improve this, you could write your stream configurations all at once using eNames.
  2. This test measures time from before stream is stopped until after it is re-started.
  3. This test was done with LJM version >1.1405, which reduces stream restart time.
  4. Network-based connection types may take longer due to the nature of networks. (For example, exponential backoff can occasionally cause delays which are a magnitude(s) greater. USB is a more reliable transport mechanism.)
  5. This test was done on macOS, but results should be similar for other OSes.
mikelwrnc
mikelwrnc's picture
Perfect. I coded up my own

Perfect. I coded up my own test using a burst stream and I'm able to set up a new burst every 8ms or so.