semiconductive
Hazard to Others
Posts: 311
Registered: 12-2-2017
Location: Scappoose Oregon, USA.
Member Is Offline
Mood: Explorative
|
|
K type thermocouple, data acqisition and calibration with Owon B41T+ ohm meter
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:
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]
|
|
|