Sciencemadness Discussion Board

K type thermocouple, data acqisition and calibration with Owon B41T+ ohm meter

semiconductive - 8-8-2024 at 13:18

I've been needing Thermal data acquisition capabilities for monitoring chemical reactions and processes; I'm not good at doing it manually and miss a lot of clues when not paying sufficient attention.

There's a reasonably low cost and attractive ohm meter for hobbiest/amateur use, which is capable of logging temperature, voltage, current, and resistance; It's called the Owon™ B41T+ meter (eg: Blue Tooth™ enabled).

This meter is meant to connect to Android™ phones using an app, but an open source library exists to operate it from Linux™ which many people may find more useful.

https://github.com/sercona/Owon-Multimeters

I have compiled and tested the Owon™ Blue Tooth™ reader on a Raspberry PI™-3 embedded computer. The PI is a low cost, educational Linux device that is sufficient to control/automate simple (non-critical) heating and monitoring of chemical processes.

The Linux™ based Owon™ library works, well! (from command line, at least).
However, the meter itself is not a very accurate device with some known flaws:

https://lygte-info.dk/review/DMMOwon%20B41T%20UK.html

But, since the meter works very well with Linux; I'm going to try and calibrate and work around the design defects.

I have bought four devices to get a sample of how production varies on these meters and what kind of precision can be expected. I bought two batches of two meters.

At 20 [°C], I measured the temperature offset of all four meters and collected them into a calibration text file:

calibration_owon.txt
Code:
#ALIAS MAC_ADDRESS Tcalib Toffset Tfreeze Tboil meter1 A0:6C:65:CA:89:56 20.0 6.1 NaN NaN meter2 A0:6C:65:CA:90:15 20.0 0.9 NaN NaN meter3 A0:6C:65:CA:58:ED 20.0 1.5 NaN NaN meter4 A0:6C:65:FD:46:EA 20.0 2.15 NaN NaN

Meters 1 and 4 came in the first order, Meters 2 and 3 came from the second order. The MAC addresses seem to indicate that these meters are already from mixed batches, and not sequential production.

Meter1's offset is out of specification for the K type thermocouple probe.
The probe itself states an accuracy of ±2.5 [°C], and the meter spec sheet states an overall accuracy of ±( 1% + 5 [°C] ).

I don't believe the error is primarily caused by K type thermocouple manufacturing variations. I've switched probes among meters and didn't see the temperature measurements affected by more than ±0.2 [°C]

However, using completely different probes I had laying around (unspecified) from other manufacturers did not agree well; so there may be an impedance sensitivity in the meter. I'm not entirely sure.

But: I think a major issue exists in the compensation electronics of the ohm meter, itself.

However; for completeness, I've ordered 3 Berkeley Glass type probes which ought to be more accurate, along with an adapter for standard K thermocouples; This will allow me (in the near future) to test the meters thoroughly and also have probes with chemical resistance (rather than the bare metal probes that comes with the Owon meter!).

For now: because K probe wire is prone to attack by acids, etc.
I have dipped the raw thermocouple wires that came with the meters, in Permatex™ Sensor Safe, High Temp Gasket Maker, (orange, #81422).
It needs to cure for at least 24 hours, and if you'd like a smoother finish, can be re-dipped in the same silicone thinned with EthylAcetate (MEK substitute).

Two of the sensors were twisted with multiple contact points, so I unwound them to make sure all four probes were identical with just a single weld point for measurement of temperature. These probes ought to behave identically, and I ordered five spares since they are low cost. They may be useful in sacrificial situations as a disposable probe.

A measurement made with Meter#1 and a silicone dipped probe, is shown here:

https://www.sciencemadness.org/whisper/viewthread.php?tid=15...

There was an unexpected drift in temperature overnight, and the temperatures measured were suspicious because they correlated with power line voltage fluctuations.

Since Meter#1 is out of specification, I also decided to short it with a thicker steel wire and not a thermocouple. This will allow me to use Meter#1 to track the temperature compensation electronics inside one Meter separate from any thermocouple interaction.

In the following plot, all four Owon meters were placed next to each other on a desk in very close proximity. There were three themocouple probes, all placed in open air roughly an inch apart and three feet away from the meters.

I used AA batteries in the meter, 2000[maH] NiMH's, and they are lasting for more than three continuous days without getting a low battery warning.

This is an ambient air test, so no power is applied and the traces associated with power do not show on the graph. ( They are 0. )

I have tracked all four meters, starting at 10PM local time, with the following result:

track.png - 46kB

I noticed during manual operation some problems with bad samples appearing.
I wrote a simple python (3) script to record data on the Raspberry™ PI, and to reduce the bad samples allowed in to the recording. The meters occasionally sample at the wrong time and inject about 1% false readings. This script is a strong rejector of repetitive data, AKA data that oscillates by ±0.1 [°C] along with false data jumps of more than 1.5 [°C]. Therefore, this software is NOT recommended for tracking fast temperature changes in industrial processes; it's far too simple with no error handling capability and is meant only to capture long term temperature trends without putting a lot of wear on the raspberry PI's SD card.

I am not affiliated with OWON™ in any way, nor are the people writing the drivers; so it is likely that the meters will change specification in the future and this code will be adversely affected.

However, open source code allows you access to fix problems, and gives an educational example that is hopefully, somewhat useful. This script is good enough for my desired initial tests of the meters.

But (for example) the script needs to be modified to include corrections in temperature scale, offset, and K type non-linearity, and safety/error handling for general usage. ( And whatever else you really need. :) ) It's not my purpose here to release production software; just alpha quality for educational/experimentation.

Code:
#!/bin/env python # Read a crude temperature from an Owon B41T+, and compensate it for fixed bias. # Written August, 2024 by Andrew Robinson of Scappoose. # Version 0.99.0 # This code is released under the GNU public license, 3.0 # https://www.gnu.org/licenses/gpl-3.0.en.html import sys from subprocess import Popen, PIPE import math if len(sys.argv) != 2 : print( "Command format is: %s meter_name", sys.argv[0], file=sys.stderr ) quit(1) meterID=sys.argv[1] alias,mac,Tc,To,Tz,Tb="","",0,0,0,0 f=open( "calibration_owon.txt", 'r' ) for calibration in f: alias, mac, Tc, To, Tz, Tb = calibration.split() if (alias==meterID or mac.upper()==meterID.upper() ): break else: print( "MeterID %s not found in calibration_owon.txt", meterID ) quit(1) Tc,To,Tz,Tb=float(Tc),float(To),float(Tz),float(Tb) f.close() f=open( "thermlog_"+alias+".dat",'w' ) print( "Thermal data log\n",file=f) f.flush() lastval,jitterval,count=0,0,0 with Popen(["stdbuf","-oL","owon_multi_cli","-a",mac,"-t","bt41"], stdout=PIPE) as p: while True: text=p.stdout.read1().decode("utf-8") sample=text.split(' ') if (sample[2]!='Deg'): print("Meter is in wrong mode") quit() time,val,units,x =sample val=float(val) count+=1 if (count<100) and (( val == lastval ) or ( val == jitterval )): continue count=0 if ( abs(val-lastval)>1.5 ): lastval=(val+lastval)/2. # Block spurious jumps jitterval=lastval continue jitterval=lastval lastval=val print( time,(" %6.2f"%(val-To))," ",units,x.strip(), file=f ) print( "\r\t%6.1f %s%s\t"%( val-To, units, x.strip()), end="" ) f.flush()



In the plot, there is significant variation from meter to meter both in the scale of the temperature changes and/or in the offset drift.

These meters were all turned on and allowed to sit for over an hour before being calibrated at the same room temperature; so, I expect they were all at nominal operating temperature and are not affected by initial warm up errors.

Random drift can't really be compensated for, but I'm hoping the meters are precision devices where I can correct repeatable errors.

Three of the plots, Meters 2,3,4, show more temperature fluctuation in reaction to air currents compared to Meter 1 (which has no external probe). Meter1 reacts much more slowly to ambient temperature changes since the case of the Meter shields the chip-set from actively moving air.

I am seeing a separation of temperatures by 1 [°C] over a three degree change in temperature between thermocouple probes.

This ~30% difference is a rather large error between thermocouples!

Presently, I am considering the following strategy to characterize the meters and allow calibration:

I plan to short all four meters' thermocouples out, and collect data on the temperature compensation circuits inside the meters to allow statistical characterization and correlation of the thermal compensation circuits.

Then, put three K probes into a test tube of silicone oil, and slowly warm it; while keeping Meter1 as a temperature compensation reference.

This, hopefully, will allow me to correlate the probe non-linearity of the probes to each-other.

Finally, test all three probes in an ice water bath; and then in a barely boiling water bath, to get reasonably complete calibration data for them over a wider temperature range and estimate how much random (uncorrected) drift the Owon meters have.

Then write a calibration function which attempts to do error correction and improve the accuracy of the recordings. Note: The number appearing on the meter can not be changed remotely, and will continue to display the meter's intrinsic error.

Only data recorded onto a Linux™ host is improved by my scripts.

More to come in posts below ...


[Edited on 9-8-2024 by semiconductive]