MCC-134 temperature updating

[RobertNC]

Hello all,

 I am testing out the MCC-134 for a project. My aim is to read a continuously changing temperature every second. I can set the read interval to 1 Hz, which appears to work fine except that every so often I get the same temperature twice in a row. It appears that internally, the temperature is not update at 1Hz but a little bit less.

 I thought perhaps there was something funky with my code but even when I use the example code where I can set it to read every second, every so often I get the same reading two seconds in a row. For example, I use an emulator to emulate a temperature output that ramps continuously with 5 degrees per second. If I measure it with 1Hz using a different device, I do get a different temperature every time, but with the MCC-134, fairly often I will have the same temperature.

I have searched the forums but have not found any similar question yet. Does anyone have any input?

[DAQman]

The 1 Hz update rate is not precise because there's no circuitry on the board to pace the measurements accurately.  Instead, we use a thread running in the background responsible for returning the temperature.

[RobertNC]

Thank you for your prompt response. For the purpose I was hoping to use the board, it doesn't have to be perfectly precise at 1Hz but I think drastically closer. I tried a different way of logging the temperature at 1Hz and  I got a new temperature with a difference of 5 degrees +/- some percent, but here is an actual logging at 1Hz with MCC-134. This is the temperature difference from the previous second. It should be 5 degrees every second. If I take the average of the values it does come out to 5. But if I take the average of the non-zero values it comes out to about 7,3 degrees, which gives an actual update rate of about 0,68Hz.

For the purpose I was hoping to use it for, it's too far off. Is there a way to improve it, or would I be better off trying something else? I saw the voltagemeters 128 and 118 have a higher refresh rate, but I read about the difficulties achieving the accuracy with the CJC-compensation you had with the MC-134. The accuracy of the temperature reading itself appears to be very good and the libraries and everything are very easy to work with. If I could just improve the update rate, I would be home, but what would your advice be to me? Would I be better off not putting any more time in to it?

 

7,31185

0

7,263416

7,327612

0

7,351936

7,266413

0

7,307513

7,380631

7,307333

0

7,269447

7,396835

0

7,323546

7,274492

0

7,321396

7,386652

0

7,281096

7,298593

0

7,363915

7,333764

0

7,272853

7,333003

0

7,357105

7,167188

7,460817

0

7,360968

7,321905

0

5,393017

9,255339

0

7,331018

7,267101

0

5,367088

9,339923

0

7,282051

7,274998

0

6,095118

8,601788

7,268846

0

7,323588

6,541503

0

8,120406

7,286655

[DAQman]

My thermocouple simulator doesn't have a ramp feature, so I cannot duplicate the results. A rate of 0.68 Hz is a little disappointing.  If the requirement is for a single channel, our USB-2001-TC is better. I like its input isolation and low-pass filter. Use it with our UL for Linux driver. 

[RobertNC]

Thank you for your response. We do need the 4 channels so unfortunately, the USB-2001-TC would not be an option.

You don't think there's any way to get the MCC-134 to be closer to 1Hz then? What was the reason 1Hz was picked anyway? I was thinking if one made the thread update more often. I realize when you compare to the 118 and 128, we also need the CJC-value to get the temperature. But perhaps one could assume the internal temperature does not change much over one second, the CJC-check could be at one per second and the input channel a bit more often. Or will there be problems if trying to change the internal code?
 
What about the 118 or 128, or would an accuratce CJC be difficult to implement for them?

[DAQman]

I configured a test to see how fast my RPI 4 could read a single thermocouple. I used a function generator capable of putting out a millivolt signal at 10 Hz and used it as a simulated temperature. I used a 1000 uS delay in my read loop and counted the times I got an identical reading. The average was 915 times, which equates to a new reading every 0.915 seconds. The test program was written using C. The limiting factor is the conversion speed of the single A/D chip.

You need a board good at low-level measurements to measure a temperature with a thermocouple because one degree C change is about 40 microvolts. The 118 and 128 are not designed to measure microvolt changes.  

 

[RobertNC]

Thank you again for your input.

So I think we have ruled out the 134, 118 and 128.

If our requirements are as follows:

4 channels or more.
1Hz or faster frequency(for each channel)
Thermocouple type K and S compatibility.

Which product from your line would you recommend based on that?

[DAQman]

Consider the USB-TC or E-TC. Both work with our Linux driver:https://files.digilent.com/manuals/Linux-hw.pdf

https://digilent.com/shop/mcc-e-tc-thermocouple-measurement-ethernet-daq-device/

https://digilent.com/shop/mcc-usb-temp-and-tc-series-temperature-and-voltage-measurement-usb-daq-devices/