In our setup, we have a set of 5 magnetometers (our device) set up connected to a Labjack T7 Pro with a MUX80 multiplex board. Each Magnetometers reads 1 set of data for each axis, so there are 15 total channels. Every second, our data acquisition program, requests data from the Labjack. This renders it an externally clocked system, since the requests for data aren't being timed by the Labjack. ScanRate and ScansPerRead are both set to 500, so our program does a few simple calculations by calculating the mean and standard deviation of the samples before returning those two values for our DAQ program to record.
The problem arises with the values we're getting. As can be seen in Fig. 1, most values fall within reasonable ranges of less than |B|<300uT, but there are some seemingly random spikes that are far above anything physically possible. To try and debug this issue, we looked at some of the individual values that Labjack was giving before being averaged. By logging them, we found that there would be random pauses of ~5-10s wherein no data would be recorded, and after that there would be a couple seconds where most of the data was simply -9999. This was causing these massive spikes, since even a few of these values would throw the calculated average off by a huge factor. After looking into this issue, we found this page in the documentation that says that "when the device buffer overflows, LJM inserts a dummy sample (with the value -9999.0) in place of each skipped sample": https://labjack.com/support/datasheets/t-series/communication/stream-mode . However, when we did some debugging and looked the device buffer (using the eStreamRead DeviceBufferOverflow), we saw that the device buffer was always empty following each read. In contrast, the LJM buffer was consistently getting fuller after each read (see Fig. 2). We're not sure if that's causing the problem, but it's definitely a possibility.
We also tried following the advice from https://labjack.com/support/software/api/ljm/streaming-lots-of-9999-values , but none of it seemed applicable/seemed to help. We currently have the program set up to simply ignore all the spikes and not report them to our DAQ software, but this results in missing data points and obviously isn't ideal. If you have any advice for this our problem, it would be greatly appreciated.
.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")
It actually sounds to me like you are using stream mode with the normal internal stream clock. You tell the T7-Pro to stream 15 channels at 500 scans/second, and it does so until you tell it to stop. The LJM library is then transferring this data from T7 to computer in the background, and it is up to your computer to pull this data out of the LJM buffer.
15 * 500 scans/second = 7500 samples/second, which is no problem as long as ResolutionIndex<=4 and Range of all channels is 10.
Try replicating your test with LJStreamM.exe to see if it has the same problem.
If LJStreamM works fine, try the basic stream example in whatever language making the minimum changes so it does your 15 channels.
Thank for your advice, we'll try that soon. On a seperate note, we were testing the Labjack with a voltage generator on Kipling and we noticed that the channels seemed to "mix". Even when nothing was plugged in to AIN2, for example, there would be a voltage change with similar amplitude to AIN0. This might just be our inexperience with the program and unrelated to the spikes issue, but do you have any knowledge about this problem?
Just to follow up, we started using LJstreamM, and we've included a screenshot of some of the results below (the data was generated using a function generator). We applied only a sine function to only one of the channels (in this case AIN0), but all of the channels respond to a lesser extent as well.
Readings from floating channels are meaningless:
https://labjack.com/support/app-notes/floatingunconnected-inputs