Maximum error bound of linear interpolation - Page 1
Forum section: electronics / projects

author: thexeno
author_rank: Regular Contributor
timestamp: September 25, 2015, 12:45:37 pm
content: Hi! I'm trying to build an NTC based thermal sensor. The only condition is to made it with a good known tolerance on the final measure, it doesn't matter, for now, if it is small or big error.And actually I'm stucked in understand the maximum error bound of a linear interpolation that I will apply on a LUT in microcontroller, when I read data between two entry of the table. Can I have some suggestions?

author: JimRemington
author_rank: Regular Contributor
timestamp: September 26, 2015, 02:30:07 am
content: Start by telling us how the LUT was derived. What are the errors in the individual table entries?Given the expected errors in any two table entries, it is straightforward to use error propagation to define the expected error of any function of those two entries. See among othershttps://en.wikipedia.org/wiki/Propagation_of_uncertainty

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 26, 2015, 01:41:04 pm
content: If this is in regards to the other thread, I'd suggest using polynomial -- it's faster on most platforms (a few more multiplications, no divisions) and uses far less memory (a table of < 8 coefficients, versus a table of 20+ values for the same accuracy).When I tested methods, I evaluated three approaches: piecewise-continuous was the worst for the above mentioned reasons; a sum-of-reciprocals method is the simplest mathematically, but performs poorly on most platforms (again, division sucks); and the polynomial method was the best compromise (saving on code as well as the fairly small table).Downside for calibration is, you need to solve for a lot of coefficients, which might not be so easy to do on a live platform (I just solved them using an Excel spreadsheet!).Tim

author: KerryW
author_rank: Regular Contributor
timestamp: September 26, 2015, 02:59:47 pm
content: I;m no mathematician, but this seemed like an interesting problem, so I gave it some thought, and this is what I think:Let us assume a table of sines in 1 degree increnebts.What would be our error if we linearly interpolsted the sine of 60 degrees from the sine of 59 degrees and the sine of 61 degrees, instead of using the table entry for 60 degrees?59 0.857167360 0,86602540361 0.874619707Interpolated sine of 60 = 0.865893503Error vs table entry = 0.0152328%%Using every table entry instead of every other entry should cut that error by at least half. If we linearly interpolate the sine of 59.5 degrees and compare it to our calculator value, the error should be no more than half the error of using half the table entries, or 0.0076164% Max.Interpolated sine of 59.5 = 0.861496352Error vs calculator = 0.003807839Which is 1/4 of the error of using 1/2 of the table entries.So, if N is the nearest table entry, Max_error = ( ( (2*LUT) / (LUT{N-1}+LUT[N+1]) ) -1)/4Doubling the table size increases accuracy by a factor of 4.

author: bson
author_rank: Unknown
timestamp: September 26, 2015, 11:11:58 pm
content: Make a series of finely granular measurements, an order of magnitude more than you think you'll want for calibration points.Make a least-squares polynomial fit. (scipy/numpy's polyfit() is very handy.)Calculate the maximum error for a linear interpolation of N points, for a range of N.If the polynomial function for the entire set is a(x) and for two points with linear interpolation is b(x), then the error e = a(x)-b(x), and its max/min is at x for d(a(x)-b(x))/dx = 0. Since both a(x) and b(x) can be symbolic expressions it can be solved symbolically (by e.g. sympy's symbolic solver).Also plot the least-squares fit to eyeball it and get a sense of measurement noise. You'll want the degree high enough to capture the general shape, but not so high you model the measurement noise. It might be worthwhile taking a large number of measurements and averaging or smoothing before fitting. If you can't tell the difference between signal and noise you don't have enough data.

author: mikerj
author_rank: Super Contributor
timestamp: September 27, 2015, 07:59:48 am
content: Quote from: T3sl4co1l on September 26, 2015, 01:41:04 pmIME the problem with polynomials is coping with the range of intermediate values produced when using fixed point math, and if speed is a concern then floating point is a non-starter on most small micros. No so bad on a 32 bit micro where an int64 isn't much of an overhead but potentially a hefty overhead on an 8 bit micro.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 27, 2015, 02:00:59 pm
content: My computation was 16 bit fixed point on AVR (2 cycle 8x8 mult), something like 250 cycles for the entire calculation.Tim

author: thexeno
author_rank: Regular Contributor
timestamp: September 27, 2015, 02:30:55 pm
content: Quote from: mikerj on September 27, 2015, 07:59:48 amActually I can use the S-H formula (with no re evaluation, since I don't have a FAR more precise thermometer capable to do that), with one division and the natural logarithm (up to the power ofthe order of the SH). By multiplying the constants with a fixed value, I can work on 32bit variables, unsigned.The problems are:1- how can I estimate the additional error if I loose one least significant decimal value on a coefficient ofthe higher grade in the SH equation?2- my micro will have a good machine precision? How can evaluate this if it is not provided AND how to use it to evaluate the freshly introduced error?I'm not expect that someone can answer to these questions, because is a tough topic (at least for me) and could be difficult to discuss this in a forum (at least for you that are giving the help to me). So, if someone knows the answer, I'd happy enough to see even just a link to a resource.

author: zapta
author_rank: Super Contributor
timestamp: September 27, 2015, 02:45:05 pm
content: Quote from: thexeno on September 25, 2015, 12:45:37 pmShouldn't be to difficult if you have the formula of the ideal function you are trying to approximate. The error can come from two source, up to the a/d conversion and after the a/d conversion. I understand that your question is about the second part.Since the number of finite and relative small (e.g. 2^14), write a program (C, Java, Python, etc) that iterates over these numbers and compares the digital result to the target function. This will give you the exact digital error for each possible input. Then just compute the min and max of those values.

author: thexeno
author_rank: Regular Contributor
timestamp: September 27, 2015, 05:33:07 pm
content: Quote from: zapta on September 27, 2015, 02:45:05 pmInteresting. What should I iterate? I tried quickly by putting some of these values as double in my uC and I've observed a difference between a scientific calculator (can be also the calc of windows, that have more numbers, like an Excel sheet). Only 7 numbers at right of decimal point are correct. How can I find this by using a more general method? I've understand only the vague idea of the iteration that you intend to find the "quantum" error and finally how this influence the final temperature reading.After this, I think that I will be stuck in understand on how apply this error on a SH equation. And without this final step, all the previous work is useless

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 28, 2015, 03:49:00 am
content: SH?Error propagation is a subject unto itself, but the general idea is it goes as the derivative with respect to each parameter, and to each calculation step that involves rounding. The initial distribution is flat (quantization noise, corresponding to +/- 1/2 the truncated decimal point or digit or bit), though after a lengthy computation it might be expected to spread out roughly Gaussian (as with the central limit theorem).0.4% is about 8 bits, so you wouldn't expect massive loss of accuracy for a 1% thermistor, uncalibrated. This corresponds to about 2.5 digits, or over the working range of the thermistor, perhaps a (biased) -100 to +156 degC range, no decimal part.A 12 bit ADC is good to 0.024% or 244 ppm, more than good enough for fairly precise measurements and calculations (e.g., a 3.5 digit multimeter or what have you). By calculations, I mean, including doing all the intermediate math on that level.If you cast all the computations to 16 bit fixed point, placing the fixed point in a suitable position, you will have essentially zero loss of accuracy due to rounding.For example, my spreadsheet illustrates a total true rounding error that is a small fraction (+/- 1/2 LSB, no more than the best case ADC measurement can provide) of the total approximation error (which is more like +/- 8 LSB, out of 12 bits, IIRC), which is in turn a small fraction of the actual tolerance of the part used (which is some 40 LSBs).And yes, I verified (theoretically and experimentally) that my code produces precisely the same rounding errors as the spreadsheet code. The code used for the final result is, in fact, an absolutely identical simulation of the real live computation on the target platform, including edge cases (i.e., one should never expect 0x000 or 0xfff from the ADC, but the formula still produces a reasonable, extrapolated, answer for both cases).If you're talking about 32 bit floating point, or int64's, for a computation like this, I'm sorry but your mind iswaayyyout in outer space here. There are some cases where those are nice, and worth the computational effort (even on integer CPUs), but this is such a computationally easy problem -- a single, stateless function, with a single, well defined input domain and a well defined output range -- any suggestion of those is, at best, mathematically lazy, and and worst, liable to be utterly wrong and produce bad numbers, or no result at all (division by zero?).This isn't very hard -- of course I'd say so because I know the math -- but the rounding amount is simply the ratio of a digit you've truncated versus the number you cut it off of, and the method of fixed point is just how you write out numbers longhand, but doing it with bits or bytes instead of decimal. It sounds scarier than it is, and once you get your head around it, it's pretty cool.Tim

author: thexeno
author_rank: Regular Contributor
timestamp: September 28, 2015, 08:35:32 am
content: Just to clarify, when I talk about SH coefficients, I'm referring to Steinhart-Hart equation, with a coefficient of order of magnitude in 1E-14. I can handle this by multiplying them by a facto of 1E12, but the natural logarithm still require precision.I will analyse what you wrote, as soon as I have spare time

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 28, 2015, 01:07:16 pm
content: Logs can be evaluated in fixed point using a shift-and-accumulate algorithm that repeats squaring (thus, each iteration raising the operand by a power of 2, which is also the base -- handy, no?). Lg(x) can be used directly and adjusted with a constant, or Lg(e) can be used as a stored constant.Or they can be approximated over a small range using rational curves (1/x or polynomials, or combinations), or difference equations (by definition, ln(x) is the integration of 1/x dx).Note that bit shifts represent multiplication/division by base^N. They can be done implicitly by lining up the addend with the respective bytes in the output term, or smaller shifts have to be done with bit shifts.An excellent way to divide by a constant is to precompute the quotient (which will be fractional 0.8 or what have you), multiply with the input, and implicitly shift the output (which is 8.8 but the integral half is zero, so you only need the low byte).Tim

author: thexeno
author_rank: Regular Contributor
timestamp: September 28, 2015, 06:04:24 pm
content: Ok, let's start with clarificationsMaybe it is only a language misunderstanding issue.Quote from: T3sl4co1l on September 28, 2015, 03:49:00 am0.4% of what?QuoteIntermediate math in between where? Analog/ADC ADC/Resistance Resistance/Steinhart Steinhart/Temperature?QuoteI may fall in the category of the mathematically lazy one, but are you sure? MAybe the answer in in your spreadsheet that I will look better...Quoteis mathematically ignorance... and I use "double" variables. Maybe this approach is conceptually the same of using 384 CUDA cores to read a f*cking temperature.QuoteThis is the definition of the relative error. But since the S-H equation have several terms (here R, and roundings, that ok are very small), I have some problems in conceive how the relative error of the various data combine toghether in a fraction with the logarithms. Even in a voltage divider it is not so trivial to combine the two errors of the resistors. Assuming to use two resistors of 5%, I know by "brute forcing" that the worst case is 5%+5% and when the resistors are approaching the same value, it returns to 5%, but I didn't devise a mathematical formula. I was trying to do the same for the SH equation, since at least I can devise the error of thesingevariable, but not how this combine with each other.Here is the SH that assure an absolute error of 0.015°C using coefficients already reversed, where the smallest one is D1 = 6.383091E-08If I will not reach such precision, I'd like to quantify what is the newest one.The ADC conversion and the subsequent R extrapolation from the voltage divider and its errors are all of them already inserted in the R term. I just stucked in this precision issue. One reason is to learn, the other is for quantify errors w/out being a butcher.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 29, 2015, 01:31:21 am
content: Quote from: thexeno on September 28, 2015, 06:04:24 pmOf VREF (full scale), for an 8 bit converter (just as an example).Of course, the thermistor won't go from 0V to VREF over its temperature range, so you won't be using the full range. And the relative error over the temperature range will therefore be larger.So, the 0.4% accuracy being better than a 1% part will be valuable; another bit or two (giving 0.2 or 0.1% reading error, out of full scale) might be best. More will not be necessary, but might come for free, anyway (12 bit converters are cheap and plentiful!).QuoteIncluding all of these.QuoteThat's a few orders of magnitude excess of "flogging a dead horse", but that's kind of the right idea..QuoteAlright, cool. Let's look at the equation. Just very roughly: orders of magnitude. (You can do this yourself for the other coefficients, if you have them.)We know T is roughly 300 K. It's actually more like 200-500 K for the craziest possible values of any thermistor, and 250-400 K would be very reasonable.So as orders of magnitude go, we can say T is in the range of 10^2 to 10^3. Good enough!Of course, the whole equation is for T^-1 (it's actually shown for T^1, which inverts the right-hand side: same thing), so the equation is for T^-1 in the 10^-2 to 10^-3 range.This is equated to A, B * ln(R/Rref), C * ln^2(R/Rref) and D*ln^3(R/Rref).Of course, R/Rref is just a ratio, and we expect that to be in the range of 10^-3 to 10^3 or thereabouts (i.e., at -100C, maybe it's 1000 times larger than R(25), and at 200C, it's 1/1000th). And probably even less than that, for commercial temperature ranges as mentioned earlier.So we also know the range of ln(R/Rref), which is -3 to 3 if it were the base-10 log. But it's base-e, so it's actually about triple that, or -10 to 10. Or 10^-1 to 10^1.Each power of ln(R/Rref) multiplies those exponents, so the B term has a 10^-1 to 10^1 multiplier; the C term has 10^-2 to 10^2, and the D term has 10^-3 to 10^3!Now for the coefficients. We know T^-1 is in the 10^-2 range (max), so for a temperature accuracy of, say, 0.1% (i.e., 10^-3), we need to account for anything that contributes a number of 10^-5 or higher.If D is around 10^-8, and multiplied by 10^3 in the worst case (largest R/Rref), then it will *just barely* twitch into the range of needing to calculate it. It might be tolerable to leave it alone (don't need as much accuracy at very low temperatures?), or just a few bits of it can be approximated (maybe using a best-fit curve, or Newton's Method, or a Taylor series).(By the way, if you use the SH equation at all, you're probably already calculating the log, so you can rewrite it as:1 / T = A + B * x + c * x^2 + d ^ x^3= (((D * x + C) * x + B) * x + Awhere x = ln(R/Rref)Which brings us back to the simple polynomial, saving a little more computation.)As for fixed-point computation, since we're interested in T as xxx.xx digits, perhaps -- we must use a representation that provides more than enough bits to print such a number.Three integral digits requires ten bits (because ten bits spans a range of 2^10 = 1024 > 999), and two fractional digits requires seven bits (2^7 = 128 > 99). A 17-bit calculation just barely gives enough space, but because it won't be well used (we have an available range of, say, -512 to +511 for the integral part, and 0 to 127/128ths for the fractional part), we'll need a couple extra bits in the fractional part to maintain good accuracy. That comes to 18 or 19 bits.We might as well use a whole byte extra, so a 24 bit calculation could be done.This will also give us some even more accuracy, which will conserve those small errors (even from the D term), in case they produce carries into our final number. Alternately, we could report the temperature to xxx.xxx maximum digits, though the accuracy of the equation, and the components, and the calibration itself (this is standards-grade temperature, now!), are all called into question -- how can you even justify displaying an extra digit when you don't know its accuracy?On something like AVR, I would guess a complete 24 bit SH calculation would need on the order of 2000 clock cycles (taking around 100us to complete, at typical clock speeds). Pretty involved, but if you demand the absolute best numerical accuracy, and want to save some time (floating point will probably take milliseconds to finish!), it's a worthy price to pay.A higher order polynomial approximation will probably achieve the required accuracy (i.e., 5 digits worth of true numerical accuracy) with a 10th order polynomial, and will save space on code size (the computation is much simpler: only a multiply-accumulate process), and take around 800 cycles to complete. Solving for calibration (adjusting 10 abstract coefficients!) is probably harder than for the SH equation, which would be worth considering in a self-calibrating system. (And of course -- if development is the dominant cost, and speed isn't an issue -- just go ahead and use single precision, it's easy!)But at least, I hope I've given you some insight, and shown that more than single precision (24 bits worth of mantissa -- as much numerical accuracy as the fixed-point example above, plus exponent) isn't necessary. Double or more certainly is wasted CPU time!Tim

author: mikerj
author_rank: Super Contributor
timestamp: September 30, 2015, 10:57:32 am
content: Quote from: T3sl4co1l on September 27, 2015, 02:00:59 pmI just simulated a piecewise linear function I wrote many years ago for thermistor linearisation and it takes 165 cycles to convert a 12 bit ADC value to temperature in units of 0.01 Celsius. This is using an old version of gcc-avr which doesn't give great optimisation, I suspect that could probably be reduced by 20-30 cycles without a huge amount of pain. Admittedly it's not the most space efficient (LUT=58*16 bit values).

author: bson
author_rank: Unknown
timestamp: October 01, 2015, 01:35:07 am
content: If it's just 12 bits and the processor doesn't have to do anything else, for a 16-bit result that's only an 8kB table. I'd just precompute it in a program that spits out a table that can be included in the code. Then add a build step to produce it.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: October 01, 2015, 06:23:07 am
content: Oh, and here's the code,So as you can see, it's almost as little code + data as the table alone in the lookup-heavy method (which I'm guessing used an addressing shortcut rather than a general binary search?). A pretty fair space-time tradeoff, considering.TimCode:.macro ldptrzpgmldi zh, HIGH(@0 << 1)ldi zl, LOW(@0 << 1).endm;; countToTemp;; Converts a 12 bit ratiometric ADC count into a; temperature (in 12.4 fixed point format, °C),; using a 7th order polynomial approximation.;; 74 words, approximately 310 cycles.;; Input:; r17:r16: 12 bit ADC count to convert; Returns:; r1:r0: 12.4 fixed point, temperature in °C;countToTemp:push zh; Register use:push zl; Z --> tmprtablepush r20; r20 = temp (in MAC)push r19push r18; r19:r18 = additive constant (from lpm), temppush r5; r17:r16 = input operandpush r4push r3; r5:r4:r3 = MAC accumulator (bytes 1, 2, 3; byte 0 unused); input conditioningldi r20, high(0x0800)add r17, r20; signed offset (r17:r16 + 0x0800)ldi r20, 4tmprshift:lsl r16rol r17dec r20; left-alignbrne tmprshift; initialize MAC chainldptrzpgm tmprtable; load pointer to coefficientsclr r5clr r4rcall tmprmac; r5:r4 <= ((r5:r4 + [z+]:[z+]) * r17:r16) >> 16rcall tmprmacrcall tmprmac; the first two MACs are normal...ldi r19, 4tmprsloop:lsl r3; but the third needs a correctionrol r4; (note: r3 is still MAC accumulator byte 1,rol r5; get that in the shift too)dec r19brne tmprslooprcall tmprmac; the rest are normalrcall tmprmacrcall tmprmacrcall tmprmaclpm r18, z+lpm r19, z+add r4, r18adc r5, r19tmprstempleave:movw r0, r4; add the final offset, move, and we're donepop r3pop r4pop r5pop r18pop r19pop r20pop zlpop zhrettmprtable:;; Coefficients for EPCOS thermistor;.dw -7762; coeff 0;.dw -255; 1;.dw 1004; 2;.dw 5599; 3;.dw -4454; 4;.dw 315; 5;.dw -1877; 6;.dw 738; 7; Coefficients for Murata thermistor.dw -14285; coeff 0.dw 1850; 1.dw 2802; 2.dw -1640; 3.dw -6812; 4.dw 676; 5.dw -1829; 6.dw 735; 7; Calculate r5:r4 <= ((r5:r4 + [z+]:[z+]) * r17:r16) >> 16.; Takes 29 cycles (not counting rcall).tmprmac:lpm r18, z+lpm r19, z+add r18, r4; r19:r18 = multiplicand,adc r19, r5; r17:r16 = multiplier (input operand); Using r5:r4:r3 = accumulator (bytes 1-3, byte 0 not needed), r20 = zeroclr r20muls r17, r19; high * high (only high bytes are signed)movw r4, r0mul r16, r18; low * low = byte 1:byte 0mov r3, r1; only need byte 1mulsu r19, r16; high * lowsbc r5, r20; sign extend hackadd r3, r0adc r4, r1adc r5, r20mulsu r17, r18; low * highsbc r5, r20; sign extend hackadd r3, r0adc r4, r1adc r5, r20ret; END PROC countToTemp

author: thexeno
author_rank: Regular Contributor
timestamp: October 01, 2015, 09:30:26 pm
content: Quote from: T3sl4co1l on September 29, 2015, 01:31:21 amThanks a lot, very very clear!Just I don't understand how, when talking about the ln(0.001) is somewhere around -10, this -10 became = 10^-1 ...surely my misunderstanding somewhereDespite your explanation, I have a thing that was not so very well explained from me, and the key is contained in the quote. When I'm using C (and not assembly) I must use the standard declarations, like LONG and FLOAT. Reading around, I discovered that the fixed point in C is hidden under the trick of multiplication by a constant, to represent the value using an integer, high number like xxxxx and just printing out the dot -> xxx.xxI was applying this since seems reasonable without 32bit floating usage (which can represent numbers something like from 10^-100 to 10^100). To do this, I must multiply by 10^9 (representable in 32bits, (even signed) integer). This is not sufficient to have all integers, because D = 6.383091E-8 and C=2.620131E-6. So I must repeat the multiplication by another 10^3. And the only affected value will be D (truncating out the last 91, but this can be avoided using another 100 factor applied only to D).Maybe in the logarithms, which can have some decimal part, should use the float, but note that this float is at minimum 24bit to be standard, and I don't want use non standard numerical manipulation. So now I almost understood how much numerical precision can be cut out if using floats, up to 10^-5 is useful, under you previous example. But somthing strange about fixed point.........and I will firstly apologize for my mistakes that you will read................This is the important question, to see if I've understand well. I'm going to use a list since it is better to split the problem and the eventual answers:1. Using your 10^-5 as maximum precision requirements just roughly devised to make the concept, if I loose the last one or two digits of C=2.620131E-6, because the multiplication of 10^9 (without the subsequent 10^3 multipl), I will obtain from the number 2620.131, the integer 2620. Which cuts the precision of this coefficient to 10^-3. Making this will reduce the precision of the whole temperature of the same amount.2. As a consequence, implementing the multiplication by another 10^3 (to keep 10^-5 precision would suffice a multiplication by 10 only) I will save the C coeff precision. This is not the same for D, which became (integer) 6.383091E-8*10^9*10^3=63830, cutting out .91 fractional part. So the final precision due to the D coefficient will be 10^(-8+2)=10^-6. So theoretically the multiplication with 10^12 provides enough precision even cutting out some decimal numers of D. Of course, assuming the usage of floating logarithms with very low number of decimal parts. And this problem about float on logaritms, if what I said until now is correct, would be my final problem.I hope that I've considered all of yours explanations, but maybe reading them again tomorrow it will shows something else. For sure, now I know that 32bit floating is not useful. Maybe less than 24bits, but will be non-standard, as far as I know. The best (not a foundamental thing) would be not using floating at all.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: October 02, 2015, 05:04:59 am
content: Quote from: thexeno on October 01, 2015, 09:30:26 pmOops, scratch that one...QuoteYes! Precisely the intent! The teeny, tiny fractional parts of C and D cannot possibly contribute to the answer (within e.g. 5 digits precision), so you do not need the extra digits (for this purpose, C is equally as accurate whether it equals "2.620131E-6" or "2.62E-6").If they were all weighted equally, then their orders of magnitude, and multipliers, would all be equal. But clearly, they are not, and that allows us to shove everything into a fixed point register, and truncate things we don't need.As for doing this in C, you can still save plenty of time over floating point. Back in the days when I played with QBasic, typically I'd have, say, a graphics demo, running at 20 FPS with floating point. Fixed point (using built-in integers) about tripled that, to a reasonable 50-60 FPS. Writing the core routine in ASM improved it more still, and running the whole thing in ASM topped out around 500 FPS (which goes to show how much dreadful overhead QB has; fortunately C doesn't have this problem).Tim

author: thexeno
author_rank: Regular Contributor
timestamp: October 03, 2015, 08:53:27 am
content: Under the conclusions just made about precision,I discovered that 24bit (float or double, experimentally, does not change the result!!) reduces the precision of the coefficients UNDER the 10^-2! Moreover, screws up completely the higher coefficient, A.In the picture shown here, thetempdvariable should be 0. I don't understand anything of what I see. What you see is not a result of any arithmetical operation, but it is just an assignment (that ok, could be comparable to an operation...).EDIT: my mistake. But it still worth a reasoning.Here the variable list, for 24bit double, withwrongright values:"Ad" is not screwed, was just shown with the wrong interpretation (32bit instead of 24). Moving to the right interpretation, the value is reasonable, but does not provide precision because change the value of 3.354016E-3 to 3.354013E-3. Keeping the example of the required 10^-5, this CAN BE acceptable. My argumentation is that if I need 10^-5 and Ad is multiplied by 10 as an extreme condition, I need its 5th decimal number plus one, therefore if Ad is still right at 10^-6 I can consider it correct.Ad = 0.003354|016 -> the 016 can be wrong without reducing precision.Proportionally, all the others coefficients follows the same rule.So, if let's say Cd is multiplied by a maximum of 10, I can even use Cd=2.6 (2.6 means that is already multiplied by a constant of 10^6) without any problem!For completeness, here the 32bit list.Using the 32bit precision everything is shown (uselessly) correctly:Under these considerations, I will need to use the multiplied value by the constant 10^12 as I said in the previous post. But with the 24bit behavior, I don't trust anything which brings a decimal result. With 24bit, this multiplication must be made by hand, since the starting value of the coefficient is always wrong.Hope to have understood correctly.EDIT1: Must be also keep in consideration that my NTC have 5% error, and also the B parameter have it. Assuming no error on resistance on the voltage divider (not a realistic condition), my error reading goes over 1°C