Problems reading temperature on USB-2408 at 20 Hz sampling rate

[MarkRivers]

I am having trouble with ulTIn on the USB-2408-2A0 with sampling times less than 60 Hz on for Linux. It works fine with cbTIn on UL for Windows.

I have written a test program to demonstrate the problem.

https://github.com/epics-modules/measComp/blob/UL_for_Linux_Direct/measCompApp/src/test_TIn_1.cpp

These are the comments at the beginning of the program that explain how to run it, and the problem I observe.

    This program reads the first temperature input on a device at 10 Hz.
    It prints the data for each point, and the mean and standard deviation for all readings.
    The program requires 3 arguments
    - The UnigueID of the device (serial number for USB, MAC address for Ethernet).
    - The Open Thermocouple Detect mode (0=disabled, 1=enabled)
    - The sampling rate in Hz
    - The number of readings

    The program runs on both Windows and Linux.
    It demonstates a problem with UL for Linux.  It works fine with sampling rate=60 Hz.
    However, at other sampling rates it occasionally returns spurious readings. This does not happen on Windows.

This is the output when running on Windows with sampleRate=60 Hz, OTD disabled, 20 readings. It works fine, the standard deviation of the readings is 0.004 degrees.

J:\epics\devel\measComp>bin\windows-x64-static\test_TIn_1.exe 1AAA83C 0 60 20
uniqueID=1AAA83C, ODTMode=Disabled, sampleRate=60, numPoints=20
Found 6 DAQ device(s)
Running on Windows
Connecting to device type=USB-2408-2AO serial number=1AAA83C
Reading: 0, T: 21.411213
Reading: 1, T: 21.406815
Reading: 2, T: 21.405659
Reading: 3, T: 21.413988
Reading: 4, T: 21.412600
Reading: 5, T: 21.411213
Reading: 6, T: 21.415146
Reading: 7, T: 21.409592
Reading: 8, T: 21.411674
Reading: 9, T: 21.407742
Reading: 10, T: 21.402418
Reading: 11, T: 21.407278
Reading: 12, T: 21.414221
Reading: 13, T: 21.407742
Reading: 14, T: 21.404734
Reading: 15, T: 21.411674
Reading: 16, T: 21.412832
Reading: 17, T: 21.410519
Reading: 18, T: 21.412832
Reading: 19, T: 21.415840
Mean=21.410287
Standard deviation=0.003580

This is the output when running on Windows with sampleRate=20Hz, OTD disabled, 20 readings. It works fine, the standard deviation of the readings is still 0.004 degrees.

J:\epics\devel\measComp>bin\windows-x64-static\test_TIn_1.exe 1AAA83C 0 20 20
uniqueID=1AAA83C, ODTMode=Disabled, sampleRate=20, numPoints=20
Found 6 DAQ device(s)
Running on Windows
Connecting to device type=USB-2408-2AO serial number=1AAA83C
Reading: 0, T: 21.398022
Reading: 1, T: 21.394089
Reading: 2, T: 21.397327
Reading: 3, T: 21.392469
Reading: 4, T: 21.393625
Reading: 5, T: 21.393394
Reading: 6, T: 21.397327
Reading: 7, T: 21.396402
Reading: 8, T: 21.392237
Reading: 9, T: 21.399643
Reading: 10, T: 21.401957
Reading: 11, T: 21.394089
Reading: 12, T: 21.401493
Reading: 13, T: 21.386452
Reading: 14, T: 21.390617
Reading: 15, T: 21.389460
Reading: 16, T: 21.389229
Reading: 17, T: 21.392931
Reading: 18, T: 21.393625
Reading: 19, T: 21.394089
Mean=21.394424
Standard deviation=0.003942

This is the output when running on Linux with sampleRate=60 Hz, OTD disabled, 20 readings. It works fine, the standard deviation of the readings is 0.006 degrees.

src> ../../bin/linux-x86_64-ub18/test_TIn_1 01AAA83C 0 60 20
uniqueID=01AAA83C, ODTMode=Disabled, sampleRate=60, numPoints=20
Found 7 DAQ device(s)
Running on Linux
Connecting to device type=USB-2408-2AO serial number=01AAA83C
Reading: 0, T: 21.717942
Reading: 1, T: 21.694114
Reading: 2, T: 21.693883
Reading: 3, T: 21.699435
Reading: 4, T: 21.696196
Reading: 5, T: 21.702211
Reading: 6, T: 21.703831
Reading: 7, T: 21.700129
Reading: 8, T: 21.697816
Reading: 9, T: 21.703831
Reading: 10, T: 21.690413
Reading: 11, T: 21.698047
Reading: 12, T: 21.691570
Reading: 13, T: 21.691570
Reading: 14, T: 21.701748
Reading: 15, T: 21.698047
Reading: 16, T: 21.694114
Reading: 17, T: 21.705219
Reading: 18, T: 21.698741
Reading: 19, T: 21.701517
Mean=21.699019
Standard deviation=0.006079

This is the output when running on Linux with sampleRate=20 Hz, OTD disabled, 20 readings. It does not work correctly. Most of the readings are OK, but 2 of the readings are -7.1 degrees, rather than 21 degrees.

src> ../../bin/linux-x86_64-ub18/test_TIn_1 01AAA83C 0 20 20
uniqueID=01AAA83C, ODTMode=Disabled, sampleRate=20, numPoints=20
Found 7 DAQ device(s)
Running on Linux
Connecting to device type=USB-2408-2AO serial number=01AAA83C
Reading: 0, T: 21.666584
Reading: 1, T: 21.667510
Reading: 2, T: 21.667741
Reading: 3, T: 21.662189
Reading: 4, T: -7.110869
Reading: 5, T: 21.667741
Reading: 6, T: 22.033967
Reading: 7, T: 21.662883
Reading: 8, T: -7.118032
Reading: 9, T: 21.664965
Reading: 10, T: 22.043911
Reading: 11, T: 21.667047
Reading: 12, T: 22.045530
Reading: 13, T: 21.666584
Reading: 14, T: 21.665890
Reading: 15, T: 22.040211
Reading: 16, T: 21.661726
Reading: 17, T: 21.663346
Reading: 18, T: 21.658719
Reading: 19, T: 22.038129
Mean=18.880789
Standard deviation=8.666549

There are some applications where I need to average for more than 1/60 second. This works on Windows but fails on Linux.

[jeffreyg3]

Attached is an all Linux example featuring the USB-2408-2AO, running ulTIn() in a 250 mS continuous loop (I have also run this at 500 mS and 100 mS sleep). Granted I am showing the data in degrees F. It does not show the aberration you are seeing. Note that since this function returns static values (not data returned in an array) there really is no sample rate supplied to the ulTIn function, that is a 'function' of the sleep() timer. There is a data RATE parameter but that is set for settling time for the 24 bit A/D converter. Not to be confused with Sample Rate. to be clear, Sample Rate is not the same as Data Rate. 2408_TIn.zip

[MarkRivers]

@jeffreyg3 I fully understand the difference between the rate at which I read the temperature (controlled by sleep) and the data rate, which is the averaging time in the 2408. It is controlled by this function call:

 err = ulAISetConfigDbl(devHandle, AI_CFG_CHAN_DATA_RATE, 0, dataRate);

This dataRate is what I was calling samplingRate, which may be the source of the confusion.

As you will recall from another recent issue I had on Linux it is necessary to set AI_CFG_CHAN_DATA_RATE because it is not read from the non-volatile memory (as it is on Windows) and defaults to a very short time which leads to very noisy temperature measurements.

My issue that that if I set dataRate to 60 it works fine. If I set it to 20 or less it works fine on Windows, but returns occasional spurious values on Linux. I have an application where I am seeing noise on the thermocouple with 60 Hz data rate, so I want to increase the averaging in the device by slowing down the data rate.

Please run the test program in the link in my original message and I am sure you will reproduce the problem.

[jeffreyg3]

@MarkRivers per our off github conversations, this issue has been resolved to your satisfaction. Please close this thread/topic.

[MarkRivers]

This problem is due to the cold junction compensation (CJC) value occasionally being read incorrectly from the device. This problem was observed on Ubuntu 18 and Centos 8.

The following is a workaround which adds a 100 microsecond sleep in AiUsb24xx::updateCjcValues().

corvette:~/devel/libuldaq-1.2.1>git diff
diff --git a/src/usb/ai/AiUsb24xx.cpp b/src/usb/ai/AiUsb24xx.cpp
index 38a3aa9..9341c71 100644
--- a/src/usb/ai/AiUsb24xx.cpp
+++ b/src/usb/ai/AiUsb24xx.cpp
@@ -534,6 +534,8 @@ void AiUsb24xx::updateCjcValues()
        if(daqDev().getDeviceType() == DaqDeviceId::USB_2416 || daqDev().getDeviceType() == DaqDeviceId::USB_2416_4AO)
                dataCount = 8;

+  // This usleep call is needed on Intel processors, otherwise occasionally the first 1 or 2 bytes of the CJC response are 0xFF so the value is
+  usleep(100);
        daqDev().queryCmd(CMD_CJC, 0, 0, (unsigned char*) &data, dataCount * sizeof(short));

Measurement Computing should decide if this is the correct fix, or whether some other change should be made.