I'm trying to capture a window of data. I output a pulse that triggers a function generator, then stream in data. The time between when the output occurs and when the stream starts is about 150+/-100 ms. This huge variation in in the timing makes it difficult to capture what I want to. Is there any obvious solution on the labjack side of things that I can do? I think the variation is probably because of the time it takes the python code to get from the labjack output command to the stream command, which depends on what else the processor is doing at the same time.
I'm doing everything in python with the labjack python libraries, on a beaglebone connected to the labjack via ethernet.
.png%3Fitok=PHGBxf6M "EEV Blog Reviews LabJack T7-Pro & Software Tools")
.jpg%3Fitok=B1YcuDFK)
.png%3Fitok=Ybt-OlgU "LabJack + JEDI One Can Create a Powerful Distributed DAQ Ecosystem")
I feel like those numbers can be brought down to something like a few milliseconds (on normal computer at least), but before I hand this off to a coding expert I'll throw out that it usually makes sense to include your trigger signal with the stream inputs, start the stream right before you send the trigger signal, and then you get a data set that lets you see exactly when the trigger occurred relative to your other signals.
That would be first choice. Second choice would be "Triggered Stream" mentioned here:
https://labjack.com/support/software/api/ljm/function-reference/ljmestre...
Thirst choice would often be using a Lua script to start a stream based on fancy trigger logic.
The technique you describe would usually be after these.
First choice: this is what I'm currently doing, but I have to capture a window much larger than what I need to make sure I get the right data, this lowers the rate at which I'm able to repeat the whole thing, which is what I'm trying to optimize now.
Second choice: I couldn't get the triggered stream to work before because, I think, the sync pulse from my function generator was too short to be picked up by the labjack. Maybe I'll take a second look at this.
Third choice: this is what I was hoping to avoid, because I don't have time right now to invest in learning the Lua stuff, and trying to do my own custom solution - but I guess I might have to go that route.
Is there a possibility that it's the labjack causing the inconsistent timing because of something I'm doing wrong? Like maybe I need to clear a buffer before issuing the commands each time or something like that?
Here's the relevent part of my python code:
# Triggger scan
ljm.eWriteName(self.handle, 'DAC0', 5.0)
ljm.eWriteName(self.handle, 'DAC0', 0.0)
# Read in data
scanRateAct = ljm.eStreamStart(self.handle, self.scanN, self.Nchannels, self.channels , self.scanRate)
time.sleep(1e-3)
rawdata = ljm.eStreamRead(self.handle)
ljm.eStreamStop(self.handle)
And here's the labjack stream parameters I'm using:
1. Seems like all you need to do is rearrange your calls to:
scanRateAct = ljm.eStreamStart(self.handle, self.scanN, self.Nchannels, self.channels , self.scanRate)
ljm.eWriteNames(DAC0 high then low)
time.sleep(1e-3)
rawdata = ljm.eStreamRead(self.handle)
ljm.eStreamStop(self.handle)
In fact, if you doing repeat measurements you don't even need to start and stop the stream. Just read until you see what you want, then set DAC0 high-low, then repeat.
2. The trigger input uses hardware features and so is very fast. Maybe the signal is not going <0.5 and >2.64 volts?
3. I see no reason for Lua start stream unless you need a fancy trigger. Your trigger sounds very simple.
4. So you have:
ljm.eWriteName(self.handle, 'DAC0', 0.0)
scanRateAct = ljm.eStreamStart(self.handle, self.scanN, self.Nchannels, self.channels , self.scanRate)
I don't see anything wrong here. I would not expect 150+/-100 ms between when DAC0 goes low and the stream starts. How do you know this is happening?
Make sure you are using current LJM, as start stream was made faster some months ago.
Thanks, I'll try a couple of things. Definitely need to update, I guess, as I set up all the software earlier this year.
I have a function generator outputing a signal (basically just a ramp in this case), and I'm making measurements on other stuff responding to this. The labjack input is monitoring this waveform as well as 3 other signals. The function generator is triggered by the labjack output. I tune a delay on the function generator so that the output waveform pulse happens in the window of the data stream. I can see on an oscilloscope that the delay between the labjack trigger pulse and the function generator output waveform is very consistent - but the waveform shows up in a very different place in the labjack stream each time.
Your measurement sounds valid.
If you still see the long start delay and high jitter, let us know and someone here can make a simple example to quantify and demonstrate typical stream start timing.
I went back and tried triggered mode again and got that working this time (thanks to this comment, where I realized I was missing a couple things for triggering properly).
This is not as ideal, because now I have the function generator is just constantly outputing, so when the code is ready for the next dataset it starts a triggered stream, then has to wait around for the next cycle (rather than trigger the next cycle when ready as I was doing before). But, now the data is centered in the window exactly the same every time, which means the window doesn't have to be as big for software triggering.
I'll revisit the other method sometime. It may be more a limitation of the beaglebone processor than any real fault in the labjack or LJM libraries.