Thermistor Data (small update)

[T3sl4co1l]

https://www.seventransistorlabs.com/Calc/Thermistor.html

I added a modest selection (as opposed to none at all(!)), let me know if you'd like to see more parts.  Check the .js (same file name, s/html/js/) to see the format, pretty easily readable, send it like that and I can drop it in.

Or if you've some code to generate parts in a family, I can even toss that in.  (I know Vishay for example catalogs all their parts in a "locked" spreadsheet, which could be mined for data and formulas if one was keen to.)

I want to do an automation of the polynomial fit as well, but that will be a little bit more work.  At least it should be pretty straightforward -- polynomial regression is a surprisingly well-conditioned problem.  Will see how/if that changes under constraints (fixed point, quantization)...

Tim

[T3sl4co1l]

Bigger update!  Same link, new content.

I suppose I should add some discussion/disclaimer about the code example; it should be somewhat dismal in performance, noteworthy considering the rest of the page is concerned with performance.  The main problem is accum needs 32 bits, and the odd shifts up and down will be annoying on something like an AVR (but, effortless on others -- such as ARM and x86!).  I think I would recommend grabbing a set of coefficients and hard-coding the shifts, as I did for the earlier (ca. 2016, spreadsheet and asm) version, versus keeping the code/data perfectly tool-generated.

Tim

[bson]

I spent a fair bit of time trying to get reasonably accurate temperature measurements out of Murata NCP15xxx series divided with Susumi RR series, both 0402 - so low thermal mass.  Doesn't matter how I tried, it would never be more accurate than 1˚C and most of the time worse.  The reason of course is that the temperature calculated is in K, and even a 1% error at room temperature is ~3K = ~3˚C.  Even 1˚C is probably overly realistic with a divider without individual parts selection and/or careful calibration.  It's fine for monitoring board temperature, but wasn't workable for my purposes, in an HVAC thermostat (forming a multi-room mesh network).  So I changed tack and gave the ADT7311 (ADT7310 with SPI interface) a spin.  It only specs a 0.5˚C accuracy, but this is over a broad temperature range, and it agrees to about 0.1˚C with my 34465A and a type K thermocouple (which is spec'ed to 0.3˚C).  So good enough to use, and maybe calibrate using a reference thermometer.  (I just considered it good enough for my purpose while the divider wasn't.  My original goal of 0.25˚C was clearly overly ambitious and impossible using run of the mill parts and assembly.)

One problem with the Murata NCPxxx is they 1) have significant hysteresis (not sure why), and 2) don't document a C parameter, likely because there isn't one (it's a product of other ambient conditions).

[T3sl4co1l]

Nice Yeah, semiconductor sensors are nice when you don't need much range (like, ambient to internal-device levels), and are pretty linear AFAIK.

RTDs are also good, when you need somewhat better to high accuracy, or reliability, or range (with thermocouples left for the widest ranges).

All three [passive types] have curves (as opposed to perfect linearity), which... give or take the resistor divider in the case of the thermocouple, should just drop into my tool to get useful polynomial corrections.  Future opportunities?

Granted, the intended 16-bit format won't be quite applicable for the tightest applications.  Thermocouples are particularly well characterized, enough that 7th order or higher, I think, polynomials are published for them.  RTDs too probably (I haven't looked at them in great detail, think I recall seeing something like that too).


Most thermistors don't give good parameters, anyway; even at 3rd order, the log polynomial commonly discussed for them ("B, C, D" parameters), is a poor fit.  And you're lucky to find anything beyond B in the datasheet.  Which, being the only parameter then, thus varies considerably with the two intercepts it's calibrated at (B25/85 or etc.).  I always use raw (Temp, R) data, which I assume is characterized, not built from a model.  At which point, a cubic on the voltage divider I think does better already, and is far cheaper, computationally, than the log form.  And going to 5th order is hardly more work, for essentially perfect numerical results, so I don't mind.

Of course, they can't publish a datasheet with voltage divider information, so they don't; something more flexible is needed, to calculate calibration values for such a circuit.  Hence, this.

Good to know about the hysteresis, I'll have to see if I can observe that on anything I have.  Though I don't have much for temperature baths or references...

Tim

[mzzj]

I spent a fair bit of time trying to get reasonably accurate temperature measurements out of Murata NCP15xxx series divided with Susumi RR series, both 0402 - so low thermal mass.  Doesn't matter how I tried, it would never be more accurate than 1˚C and most of the time worse.  The reason of course is that the temperature calculated is in K, and even a 1% error at room temperature is ~3K = ~3˚C.  Even 1˚C is probably overly realistic with a divider without individual parts selection and/or careful calibration.  It's fine for monitoring board temperature, but wasn't workable for my purposes, in an HVAC thermostat (forming a multi-room mesh network).  So I changed tack and gave the ADT7311 (ADT7310 with SPI interface) a spin.  It only specs a 0.5˚C accuracy, but this is over a broad temperature range, and it agrees to about 0.1˚C with my 34465A and a type K thermocouple (which is spec'ed to 0.3˚C).  So good enough to use, and maybe calibrate using a reference thermometer.  (I just considered it good enough for my purpose while the divider wasn't.  My original goal of 0.25˚C was clearly overly ambitious and impossible using run of the mill parts and assembly.)

One problem with the Murata NCPxxx is they 1) have significant hysteresis (not sure why), and 2) don't document a C parameter, likely because there isn't one (it's a product of other ambient conditions).

Interchangeable is the magic keyword for thermistor.
These are +-0.1K and abt 3usd/pcs:
https://media.digikey.com/pdf/Data%20Sheets/Ametherm%20PDFs/ACC-103_Dwg.pdf

[floobydust]

I found even a 10k thermistor at 25˚C has significant self-heating at 5V with a 10k to Vcc. So for HVAC I switch power on/off to the thermistor to get an accurate reading, not influenced by the self-heating and convection currents.
I can't see the use for 470k thermistors, such high resistance I would never use, as a vanilla A/D needs a lower impedance source.

[mikerj]

I found even a 10k thermistor at 25˚C has significant self-heating at 5V with a 10k to Vcc. So for HVAC I switch power on/off to the thermistor to get an accurate reading, not influenced by the self-heating and convection currents.
I can't see the use for 470k thermistors, such high resistance I would never use, as a vanilla A/D needs a lower impedance source.

If you have something that runs at high temperature the higher resistance thermistors are more useful.  The errors introduced at low temperatures by driving the ADC from high impedance may be acceptable.  e.g. I have a heater that operates around 80C-90C during normal operation, a typical 10k thermistor could be well under 1k at that temperature. To get the best linearization the bias resistor needs to be comparable to the thermistor resistance at the working temperature, so I'd end up with high bias current and higher self heating as a result with a 10k part.

[T3sl4co1l]

Yup, good for higher temperatures, or low power (for which pulsed sensing is also a good idea).

Mind, most SAR ADCs have a quite high input impedance, some megs -- so, given the component tolerances, and the resistance at temperature (say, you're only interested in temps 25-125°C because it's on a heatsink or something), you're fine doing that.  You would want to buffer it to read the low temp range.

Tim

[Terry Bites]

I've found it hard in practice to get the polynomial fit to be accurate over more than few degrees.
Thermistor production spread of Beta is not tight enough.

[T3sl4co1l]

So this isn't bad, for fairly crude methods:

Code: [Select]

   Thermocouple     Thermistor (°C)
22.5 19.6
55.6 53.1
70.2 67.8
99.2 97.0
135 132.0

Thermocouple is just the whatever comes with the BM235.  So, within a few degrees I would think.  Thermistor is a bogey NTCS0805E3474JXT.  Fixture is as shown:



Both elements gooped (paste) into the crevice of a heatsink, waved with the hot air machine to get it to temperature.  There's a +/- fractional degree error between taking measurements, what with trying to hold the wand at the right distance (tongue in the right place, etc.).

This uses a 0-125°C range, 5th order polynomial, so it's not surprising it gives reasonable values slightly above that; it should diverge upwards there anyway, and is low over the whole range to begin with so that's not unexpected.  I didn't want to push it much higher, the spring clamp probably starts to melt by then...

Worst case tolerances, yeah, as mentioned above in this thread; but it's nice to see you can get surprisingly close results with typical parts.

Tim

[DrG]

So, I am having my morning coffee and stumbled over this thread and subsequently your site - there is a lot there and I have bookmarked it and will keep that as a reference.

I just went through my folder from about five years ago when I looked at polynomial fits and thermistors and. Forgive me if I have missed some points, but I did not see you breaking up the temp/resistance function to get a better fit. Since I still have those graphs, I am illustrating that below. I *think* this was a Vishay NTCLE100E3102GB0 1K@25 and the datasheet included an extensive spreadsheet which was used for the fits. My examples are all using cubic polynomials. Note the R² values and their reduction when breaking the function into sub-functions.

Full range


High portion


Mid portion


Low portion


Of course, you need software to determine which polynomial to use...e.g., this code fragment to illustrate.

Code: [Select]

  Ao=analogRead(ReadPin); 
  Vr=(Ao/A2Dres)* GalVout;
  Rt=((GalVout * Rf) / Vr)-Rf;
  if (Rt>7570) // 7570-23342 (-20 to -40 C)
    {
    TempC=y03 +(a3/Rt) + (b3/pow(Rt,2.0)) + (c3/pow(Rt,3.0));
    }
  else if (Rt>575) // 575-7569 ohms (-20 to 40 C)
    {
    startt=micros();
    TempC=y02 +(a2/Rt) + (b2/pow(Rt,2.0)) + (c2/pow(Rt,3.0));
    endt=micros();
    }
  else // 25.6-574 ohms (40 to 150 C)
    {
    TempC=y01 +(a1/Rt) + (b1/pow(Rt,2.0)) + (c1/pow(Rt,3.0));
    }

I'm not that bright and I am sure folks have been doing that, but I don't see this represented on your pages. A calculator that would automatically  take the full function (e.g., from a spreadsheet) and break that function into separate functions with the break points and resulting polynomials that minimize error would be nice.

On the other hand, I may have simply missed the point [it would not be the first time], if so, please forgive me....nice having coffee with ya

[mzzj]

So, I am having my morning coffee and stumbled over this thread and subsequently your site - there is a lot there and I have bookmarked it and will keep that as a reference.

I just went through my folder from about five years ago when I looked at polynomial fits and thermistors and. Forgive me if I have missed some points, but I did not see you breaking up the temp/resistance function to get a better fit. Since I still have those graphs, I am illustrating that below. I *think* this was a Vishay NTCLE100E3102GB0 1K@25 and the datasheet included an extensive spreadsheet which was used for the fits. My examples are all using cubic polynomials. Note the R² values and their reduction when breaking the function into sub-functions.

Or instead of splitting the equation use the Steinhart-Hart equation.
https://en.wikipedia.org/wiki/Steinhart%E2%80%93Hart_equation
It is a perfect fit for the data in the NTCLE100E3102GB0 vishay datasheet 
(resistance-temperature tables are calculated from Steinhart-Hart equation)

DKD has some further reading: Determination of thermometer characteristics
https://www.ptb.de/cms/fileadmin/internet/dienstleistungen/dkd/archiv/Publikationen/Richtlinien/DKD-R_5-6_2018-09_rev_1_en.pdf
As well BIPM Guide on Secondary Thermometry: Thermistor Thermometry
https://www.bipm.org/documents/20126/41773843/Guide-SecTh-Thermistor-Thermometry.pdf/87e2fdc8-14fc-e977-918e-b801752d06a0

Calculating full set of Steinhart-Hart coefficients takes at least 6 calibration points but you can then interpolate something like 0cel to 200cel range with exellent accuracy (limited by calibration uncertainty according to DKD guide so something like 1mK with proper equipment)

[DrG]

So, I am having my morning coffee and stumbled over this thread and subsequently your site - there is a lot there and I have bookmarked it and will keep that as a reference.

I just went through my folder from about five years ago when I looked at polynomial fits and thermistors and. Forgive me if I have missed some points, but I did not see you breaking up the temp/resistance function to get a better fit. Since I still have those graphs, I am illustrating that below. I *think* this was a Vishay NTCLE100E3102GB0 1K@25 and the datasheet included an extensive spreadsheet which was used for the fits. My examples are all using cubic polynomials. Note the R² values and their reduction when breaking the function into sub-functions.

Or instead of splitting the equation use the Steinhart-Hart equation.
https://en.wikipedia.org/wiki/Steinhart%E2%80%93Hart_equation
It is a perfect fit for the data in the NTCLE100E3102GB0 vishay datasheet 
(resistance-temperature tables are calculated from Steinhart-Hart equation)

DKD has some further reading: Determination of thermometer characteristics
https://www.ptb.de/cms/fileadmin/internet/dienstleistungen/dkd/archiv/Publikationen/Richtlinien/DKD-R_5-6_2018-09_rev_1_en.pdf
As well BIPM Guide on Secondary Thermometry: Thermistor Thermometry
https://www.bipm.org/documents/20126/41773843/Guide-SecTh-Thermistor-Thermometry.pdf/87e2fdc8-14fc-e977-918e-b801752d06a0

Yes, a whole lot has been written on this subject.

I was commenting particularly on using polynomials, which are not too difficult (for me) to use with embedded controllers, and which the site explores.

I wonder how one would go about calculating a systematic way to break the polynomial function into sub-functions where the subsequent polynomial for the sub-functions have a better fit? Could successively calculating the slope of adjacent points yield a measure (largest deviations) that would serve as the guideline?

For example, from the graphs I showed, I can visually (calibrated eyeball method) suspect that the high end sub-function could be broken up into two sub-functions, each with a better fit.

[T3sl4co1l]

I just went through my folder from about five years ago when I looked at polynomial fits and thermistors and. Forgive me if I have missed some points, but I did not see you breaking up the temp/resistance function to get a better fit. Since I still have those graphs, I am illustrating that below. I *think* this was a Vishay NTCLE100E3102GB0 1K@25 and the datasheet included an extensive spreadsheet which was used for the fits. My examples are all using cubic polynomials. Note the R² values and their reduction when breaking the function into sub-functions.

It's sort-of explained -- I only ever intend to use one in a divider, and, like, how do you propose to acquire the resistance directly and exactly, with that much dynamic range, right? -- so, concentrating on the divider transfer function is pretty reasonable.

Which, on that subject; a timer based method could do the range, I suppose?  But still, you aren't likely to have that kind of dynamic range on a low end MCU.  AVR's 16-bit timers, you'd have to implement auto-ranging to adjust the prescaler (or chain them, when such feature is available); with an, ARM or whatever, with 32-bit timers, you could do it fixed scale though.  So, more software work, more fiddling around, or bigger hardware, and gives variable update rates (very long time constant at low temp)...

The nice thing about the divider is, as a rational expression (goes as x/(1+x)), the asymptotic response of the thermistor is somewhat canceled out by same of the divider.  So it's a pretty well conditioned value to put into a SAR ADC.  Sure, suffers from error both numeric and analog at the extremes, but that's not at all unexpected.

Of course, you need software to determine which polynomial to use...e.g., this code fragment to illustrate.
...

I'm not that bright and I am sure folks have been doing that, but I don't see this represented on your pages. A calculator that would automatically  take the full function (e.g., from a spreadsheet) and break that function into separate functions with the break points and resulting polynomials that minimize error would be nice.

On the other hand, I may have simply missed the point [it would not be the first time], if so, please forgive me....nice having coffee with ya

It's not a bad method -- I think most generally one would apply Bezier curves, cubic splines.  And the segments and their breakpoints would be determined by, total curvature in the region, I think?  Or 2nd or higher order curvature, within some margin of error.  It's a tricky problem, and probably ill posed (as curve-fits go, nothing too surprising there, but not great), since, remember a spline is a parameterized plane curve, not a function, so it can represent vertical sections, and loops, just fine.  That's a degree of freedom we might not appreciate for these purposes.  But also some spacial awareness is welcome, in that we don't need such an accurate (ohm for ohm) fit at the high [resistance] end, and tracking temperature is more meaningful than resistance in that range (i.e., a small horizontal shift corresponds to a huge vertical shift).  Working with the error as blobs rather than vertical error bars, y'know?

I discuss a similar problem, I think; you can use piecewise curves, but you need the logic to split up the curve, and as soon as that logic (or the curves themselves) requires division, it's game over for so many platforms.

Or instead of splitting the equation use the Steinhart-Hart equation.
https://en.wikipedia.org/wiki/Steinhart%E2%80%93Hart_equation
It is a perfect fit for the data in the NTCLE100E3102GB0 vishay datasheet 
(resistance-temperature tables are calculated from Steinhart-Hart equation)

Yeah, looking at my extracted copy (Vishay datasheet) they have A, B, C, D and look to be calculating from them.  Interesting they do have different values above and below 25C.  Though not differentiated for the parts I looked at, but the NTCLE one does.

Huh, there's A1, B1, C1, D1 as well but they don't seem to be using them, they're just shown for flavor?  I wonder how they're supposed to be used...

Anyway, speaking of computation -- doing log/exp is even worse than division, you're off your nut if you're doing that on an embedded machine.

As for scientific purposes, I mean, anything goes, nothing wrong with that or even more esoteric things. Whatever makes your curve fit better.

Tim

[mzzj]

Huh, there's A1, B1, C1, D1 as well but they don't seem to be using them, they're just shown for flavor?  I wonder how they're supposed to be used...

Anyway, speaking of computation -- doing log/exp is even worse than division, you're off your nut if you're doing that on an embedded machine.

As for scientific purposes, I mean, anything goes, nothing wrong with that or even more esoteric things. Whatever makes your curve fit better.

Tim

A1 B1 C1 etc are just for the more usefull inverse function(resistance to temperature)

Someone already said I was nuts when I was doing 15-degree thermocouple polynomials on 8 bit arduino  so I had to try this also:

 temp=pow((a+b*log(res/r25)+c*pow(log(res/r25),2)+d*pow(log(res/r25),3)),-1);

Lo and behold, takes about 600 microsecond on arduino! and 8-bit! atmega168! 
Like 2 decades faster than I was expecting. 
Pretty much trivial on most temperature measurement setups.

[mag_therm]

Can you run python,  numpy libs on those things?
With  high temperature  production, multi input and multi output vars,
I had very good results with np.polyfit() ,  and for the cases where radiation dominates, np.polyfit(x, np.log(y), 1)
example snippet:

#!/usr/bin/python

#Main
import sys
import os
import csv
import numpy as np
import warnings

x = np.array([1.159,   1.079,   1.000,   0.921,   0.841])
y = np.array([0.898,   0.948,   1.000,   1.080,   1.172])



MR_z = np.polyfit(x, y, 3)
MR_z = np.asarray([MR_z])
#print(MR_z)
np.savetxt('MR_regressioncoef.csv',MR_z, delimiter=',' )
.
.

[T3sl4co1l]

Oh absolutely, no problem by itself -- even software floating point is not to be underestimated.  It's more than a few kFLOPs!

The problem is more, whether it can be done at all -- and you have the entirety of computer science practically at your fingertips to help figure that out.  (It's just that easy, right?!...)  You're primarily limited by how much RAM you have, and how much cleverness you want to apply to solve it (e.g. caching partial results in external RAM, emulating a much larger (flat address space? MMU?) system, etc.).  And as far as problems that still run "instantaneously" to a human (say < 100ms), that basically leaves out things mostly that require a lot of bandwidth or storage (over 1MB/s raw bandwidth is challenging at best, let alone with any thinking required), or those which are just pathological enough to run slow even for relatively small problem sizes (awful asymptotic complexity).

(Also, at some point you're limited on code space; particularly with a Harvard architecture and limited Flash lifetime, there's only so much complexity you can fit into there, even if you're willing to go to heroic lengths to try.)

I've seen, I think it was ZX Spectrum, doing actual real-time 3D animation, using crunchy 16-bit floating point or something like that -- real rough, HIGHLY optimized, as crude as possible while still being mostly correct -- but still, accurate enough given the low resolution, and it's capable of crunching the numbers for a good dozen, couple dozen even, vertices that way.  I forget what the claim was, a few kFLOPs, maybe even ~10?  AVR is much higher performance (albeit far more limited in RAM), so it should be no surprise to get comparable performance -- despite the much higher accuracy (that'd be 32-bit floats, right?).  To be sure, a welcome surprise, if you were unfamiliar with it.

But still, that's 600 microseconds you're out of the loop on something hard-real-time.  It depends -- thermistor bandwidth is likely single Hz, if that, so you can potentially afford to spend an enormous amount of time per sample.  Even if you need to leave like 90% CPU for something else, that's 10s of ms you could dedicate to it.  The trouble is more logistical -- if you have other things to do in the mean time (say, a power supply control loop at some KS/s), you need to be back on that, quite often -- you must split up tasks somehow.  Whether that's with interrupts vs. polled in main() vs. task switched RTOS vs. anything else, it's definitely a thing that has to be done; it's not like you'll get away with a fat main() loop alone (as you might on an rPi or something ).

Tim

[T3sl4co1l]

Which, speaking of complexity --

Can you run python,  numpy libs on those things?

Not quite -- seems to require a few hundred kB even for micropython.  STM32F4 and similar, is kind of the starting point for that I think.

I mean, you can certainly write an interpreter in less (BASIC is well known, I mean since the 70s on far less capable machines for that matter, but yeah, AVR too ), but the core functions, I have no idea.

Keep in mind, someone's booted linux on a ATMEGA168 -- you can emulate anything you want, given enough time and attached storage.  Emulating something usable, not so easy.  Perhaps there's a compromise with a thin, moderate-performing VM running Python, but that's a lot of work to figure out.

Tim

[mag_therm]

Well the upstairs computer can poll the dac and run the python etc.

And in my opinion we should not get too involved in trying to measure temperature accurately because we can't, yet.
Temperature is an intrinsic property, invented as partial derivative day_U/ day_S . But both of those properties are extrinsic.
They are unlikely to be in steady state or homogenious.
When doing FEM, we assign small cells assuming each are is steady state and homogenious for a small time.
It is an approximation, but I wonder if/whether more accurate than present invasive measurement technology.
( For example placing a thermocouple on a surface, or making an opening to aim an optical pyrometer.)