MLX90640 Thermal sensor - 64b Math question

[trastikata]

I've been playing with a 32x24 pixels thermal FIR sensor from Aliexpress and the first results are good for 25$ sensor.

Processing data is quite complex but I have written an Excel spreadsheet for pixel calculation, averaging from several pictures and thermal to RGB565 conversion. Result is displayed currently on a VB.NET application I've written to simulates a 320x240 RGB565 display. 

Interpolation and averaging from 32x24 yields good results, the screenshot further down is from my window and the heating radiator. The tubing in the wall is clearly visible as well as the window and cold spot on the wall. Calculated pixel temperatures are very accurate when compared to other measurement instruments.

The picture is inclined because I soldered the sensor the wrong way 

I managed to transfer all code and formulas from the Excel spreadsheet to Positron16 but I hit a wall at the end. Until now I was able to calculate and reduce mathematically most of the formulas to coefficients in few floating point arrays. However at the end of the formulae there's a Double variable or 64b floating point variable of a sum of about 9 billion from where I have to take 4th root (or two square roots) but the compiler doesn't support such big numbers. Any ideas?

[Wimax]

Hello Trastikata,

It seems another very interesting project !
The first two equations generate very big numbers that feed the final equation.
If you define normalized variables for Tak4 as(for example) Tak4n=((Ta+273.15)/10)^4 and for Tark as Tarkn=((Tr+273.15)/10)^4, rewriting Ta_r and the final equation in terms of the normalized vars... could help ?

[trastikata]

If you define normalized variables for Tak4 as(for example) Tak4n=((Ta+273.15)/10)^4 and for Tark as Tarkn=((Tr+273.15)/10)^4, rewriting Ta_r and the final equation in terms of the normalized vars... could help ?

Hi Wimax,

Tak4n=((Ta+273.15)/10)^4 and Tarkn=((Tr+273.15)/10)^4 are both over 8 billion, so it is not possible to store their values.

In the first equation where Sx(i;j) is calculated I can break down the 4th power and because a_comp(i;j) is about 0.0003 I get the 4th power of small numbers so it is OK and I can calculate Sx(i;j)

However the final result To(i;j) requires a 4th Root of the sum of a Double precision floating point, which is ok and T_a-r which is about 9 billion so there's no way to store that value and no way to break the root of a sum to smaller values.

[Wimax]

Hi Trastrikata,

I may have been mistaken because it was also quite late when I wrote  , but I see these numbers i.e. for Tak4:

Tak4=((Ta+273.15))^4=((39.184+273))^4=9498227415.25 that's a number over 9 billion

so

Tak4n=((Ta+273.15)/10)^4 =((39.184+273)/10)^4=((3.9184+27.3))^4=949822.741525 that's smaller than 1 million

I attach a small paper with some calculations, but if I started from wrong assumptions results are incorrect 

[trastikata]

I attach a small paper with some calculations, but if I started from wrong assumptions results are incorrect 

Hi Wimax,

by itself taking the 4th root of such a big number is not a problem because as you said I can decompose that number.

However in this instance that large number appears under the 4th root as part of a sum . Hence first you need to calculate the sum and then continue with the root.

[top204]

Looks excellent, but....  Wooooosh... Right over my head with all of a those calculations. The 16-bit compiler does have 64-bit floating point. i.e. Double variables, so you could try them.

Also, could you not divide the constants so they are smaller values, and then multiply the final result?

[John Drew]

I have used the 64 bit floats in a PIC24 very successfully. Lots of trig too and results are essentially the same with delphi running 64 bit variables. Great accuracy.
John

[trastikata]

Looks excellent, but....  Wooooosh... Right over my head with all of a those calculations. The 16-bit compiler does have 64-bit floating point. i.e. Double variables, so you could try them.

Hi Les, hi John,

I'm extensively using the 64-bit floating point as I need its extended accuracy with smaller numbers, however my understanding is that their maximum value is limited to about 2 billion whereas I need to store a floating point value of about 9 billion and process it further.

[Wimax]

owever in this instance that large number appears under the 4th root as part of a sum . Hence first you need to calculate the sum and then continue with the root.

Yes, the large number is Ta_r, but also the number I defined as "A" is also definitely large, around 6 billion. However, if you use only normalized auxiliary variables the final calculation always sees a sum under fourth root, but the addends are quite "small". Rather than calculating A+Ta-r (~ 6.1E9+9.51e9) and then performing the fourth root you calculate the sum of "A/N" (610142) and the normalized variable "T(a-r)N" (951650) and then the fourth root etc.

[trastikata]

Yes, the large number is Ta_r, but ...

My apologies Wimax, you are right ! I did not pay good attention to what you have written there and made an assumption without carefully reading your proof.

That's an excellent solution to the problem, many thanks for the help. Now I can continue with the code. Thanks again.

[Wimax]

It was a pleasure and I am glad to have been helpful !.
You have helped me so many times that I have only partially repaid the debt 

[Wimax]

just out of curiosity...you made me think of what we talked about a bit days ago on the forum about the new DsPIC33A series...I wonder if the revamped architecture of the CPU, memory, and the presence of a double precision FPU, would have allowed the computation to be performed without having to scale variables ?

[trastikata]

It is not a question of ALU or FPU architecture but a compiler support. Native 32b or 64b ALU or FPU units can, however greatly speed up the computations execution - for example 32b addition or 32b floating point multiplication can be done in only two clock cycles instead of few tens or hundreds for the same operation.

Even if the compiler doesn't  support it, one can implement a 64b or 128b variables and calculations with 8b architecture but it would require quite a lot of RAM and somebody knowledgeable enough to write the underlying assembler code  .