Hello Labjack,
I am streaming 79 channels at 1000Hz each. I am collecting data from strain sensors. 76 of them. 2 temperature channels and 1 labjack temperature channel AIN14. We notice that after 1 day of continous usage. There seems to be a high frequency noise spikes that appear about every 2 seconds(please see image). Our system is installed at the field. We notice that all our labjacks have the same problem. It doesnt appear at first. But the problem appears after a day or two. Could you please advise?
File Attachment:
.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")
At this time, my best guess is that the unit is entering auto-recover because the stream buffer has gotten too full. Are you monitoring the status of the device and LJM buffers?
It might be telling to see if the problem still occurs at a slightly reduced speed. Something like 800Hz.
Thank you for the response. could you please elaborate more on auto recover and how to be monitoring for the status of auto recovery? In my experience, when the stream buffer is full, i thought the values sent from the labjack are 99999 but this isnt the case. it just seems to be sending a high amplitude spikes of every two seconds.
Moreover, could you explain why the system is entering auto recover mode? we are currently using it under the specificatios range and it does not appear to functioning so. Our requirement is to be having it to work at 1000Hz for our application.
Could you also explain how to we mitigate this problem as it is vastly interfering with our data.
You are correct that auto recover will return 9999s value the data values. When the resulting data spike is high or low will depend on the conversion function being used. The images in your first post do not appear to be in volts, so I assume there is some sort of math being applied.
The system runs properly for 24 hours. Something must change at this point. My only guess is that the network or host computer is bottlenecking the read rate.
We have two options here. The first is to find and fix the actual problem. The second is to reset the stream once every 24 hours.
To find the real problem we need to start by monitoring the stream buffer status values returned by the StreamRead function. If one or both of the values start to climb when the spikes occur then we know we have a throughput issue. If they do not then we need to look elsewhere.
If we restart the stream every 24 hours then there will be a few seconds of missing data once per day.
Did you write your own streaming program or are you working with one of our examples?