Different temperature values when using sensor via "dev board" vs this driver
quarcko opened this issue · comments
Hi,
So we started our development with your sensor, and really cannot get it to work normally.
We have a Melexis develoment board with Melexis original software for it, and let's say it produces
normal temperature readings, but this is not our goal to use this dev board.
We want it via our board and software, so this driver has been selected, and the only part that was modified
is I2C routines. Also we did verify they work OK by reading EEPROM to file with both develoment software of Melexis
and our own I2C driver. The files that were produced are identical, so I2C must be working OK.
Now about the temperatures: with this driver ALL pixels are WAAY too high.
The sensor points to the ceiling when measuring, and with DEV board it produces values in the range of 14-20C
(which is real for current environment).
And with this driver... from 27 till 80. (with some strange vertical artifacts...)
Reading sequence is as follows:
`uint16_t frameData[834];
std::cout << mlx0->MLX90640_GetFrameData(this, 0x33, frameData) << std::endl;
std::cout << "VDD: " << mlx0->MLX90640_GetVdd(frameData, ¶ms0) << std::endl;
float ta = mlx0->MLX90640_GetTa(frameData, ¶ms0) - 16.0f;
std::cout << "TA: " << ta << std::endl;
mlx0->MLX90640_CalculateTo(frameData, ¶ms0, 0.99, ta, result);
mlx0->MLX90640_BadPixelsCorrection((¶ms0)->brokenPixels, result, 1, ¶ms0);
mlx0->MLX90640_BadPixelsCorrection((¶ms0)->outlierPixels, result, 1, ¶ms0);`
This gives TA about 13.0
VDD is 3.3 (correct)
And image data:
29.2 29.7 29.7 28.6 27.9 29.2 29.8 28.2 27.5 28.9 28.6 27.9 27.6 28.5 28.2 27.6 26.8 27.5 28.1 27.1 26.8 28.2 28.1 26.7 27.3 28.9 28.0 27.9 27.7 29.2 29.5 29.8 30.6 29.5 29.3 29.8 30.1 29.2 28.0 28.1 29.3 28.3 28.1 28.5 29.1 28.2 27.7 27.3 28.0 28.2 26.9 27.5 28.5 27.5 27.0 28.3 28.3 28.2 27.7 28.7 29.7 28.2 29.0 29.1 30.0 29.9 28.5 27.9 28.9 29.8 28.7 27.2 28.2 28.4 28.4 27.6 27.6 27.8 28.6 27.5 27.7 28.4 28.3 27.8 27.1 27.8 28.6 28.1 27.5 28.0 28.4 27.2 28.1 29.0 28.7 29.3 30.5 29.2 28.6 29.1 29.5 28.7 28.1 28.4 29.2 27.8 28.1 28.4 28.4 27.8 27.9 27.5 29.1 27.7 27.6 27.4 28.3 27.4 28.0 28.3 27.9 27.6 28.0 28.1 29.1 28.0 28.6 29.7 28.8 29.4 29.6 27.9 28.6 28.8 28.7 28.2 28.4 28.8 28.8 27.5 27.6 28.8 27.6 27.3 26.8 28.5 28.3 27.0 26.9 28.9 28.2 27.4 26.8 28.7 28.2 27.9 27.8 28.6 29.2 29.3 31.2 29.4 29.5 29.1 29.8 29.1 28.6 28.5 29.4 28.0 28.3 28.6 28.5 28.2 27.7 28.2 28.5 27.7 27.6 28.1 28.2 27.4 27.7 27.6 29.0 27.0 28.4 28.3 28.9 27.9 29.2 29.7 29.1 30.2 28.9 28.5 28.7 29.0 28.6 27.6 28.4 28.6 28.7 27.9 27.7 28.3 28.5 27.1 27.1 28.6 27.7 26.8 27.6 28.1 28.1 27.5 27.9 28.3 28.6 27.5 28.1 29.1 28.9 28.4 30.8 29.4 29.1 29.6 29.5 28.5 28.2 29.0 29.4 27.7 27.7 27.9 29.2 27.7 27.5 27.5 28.2 27.1 27.2 27.5 28.0 27.1 27.6 27.7 28.2 28.2 28.6 28.5 28.7 27.8 28.5 28.8 28.7 30.0 29.7 28.7 28.9 29.1 29.2 27.6 27.7 28.8 28.8 28.0 27.4 28.9 28.1 28.0 27.3 27.8 28.0 26.9 27.4 28.4 28.1 27.7 27.2 28.2 28.4 27.6 27.7 28.9 28.7 28.8 30.5 29.5 29.2 29.2 29.7 28.8 28.3 28.8 29.2 28.7 27.1 28.3 28.4 28.2 28.5 28.5 28.3 27.7 28.2 27.9 28.9 27.6 27.9 27.9 28.7 27.4 28.4 28.4 29.1 28.3 29.0 30.2 29.0 30.2 29.2 29.1 28.3 29.0 28.9 28.4 28.6 29.3 28.8 27.9 27.6 27.8 28.3 27.6 27.8 28.6 28.1 27.4 27.2 28.1 28.2 27.5 28.0 28.6 28.5 27.2 27.5 28.8 29.2 28.4 30.9 29.4 29.6 28.8 29.5 28.6 28.7 28.8 28.7 28.1 28.2 27.6 29.6 28.1 28.0 28.2 29.0 28.3 27.5 28.4 28.2 28.1 28.3 28.2 29.2 28.2 28.3 28.4 29.3 27.8 28.6 28.9 28.8 30.5 30.3 28.2 28.4 29.1 29.0 27.7 28.1 28.5 28.8 28.3 28.0 28.5 28.0 27.7 27.9 28.9 28.8 27.0 27.0 28.1 29.0 27.7 27.2 27.8 28.3 27.4 27.8 28.4 29.4 28.5 30.9 29.3 28.8 28.5 29.7 28.4 28.6 29.2 29.8 28.2 28.1 28.6 29.1 28.1 28.1 28.1 28.8 28.5 27.7 28.2 29.0 27.9 28.7 28.2 27.9 28.4 27.7 28.0 29.6 27.7 28.7 29.6 29.8 31.1 31.1 29.9 30.0 30.2 30.1 29.0 29.2 29.8 29.7 28.9 28.5 29.6 29.4 28.8 29.3 29.6 29.4 28.0 28.1 29.0 29.2 29.0 28.7 29.5 29.7 28.6 28.5 29.7 30.4 29.6 31.4 28.9 29.0 28.7 29.5 28.5 28.8 28.7 29.4 29.0 27.9 28.0 29.2 27.6 28.0 28.5 28.9 28.1 27.5 27.8 28.3 28.3 28.1 28.2 29.2 28.2 28.1 28.1 28.2 27.4 28.2 29.3 29.4 29.9 30.4 28.6 28.7 29.6 28.3 28.8 28.2 28.7 28.6 27.7 28.1 28.0 28.6 28.4 28.1 27.5 28.3 28.9 28.0 27.8 28.3 28.7 27.9 28.3 28.4 28.8 28.5 28.6 29.2 30.2 29.9 29.9 30.0 29.8 29.3 29.4 29.9 28.6 29.0 28.5 29.2 28.3 29.3 28.7 29.4 28.2 28.5 28.7 29.2 28.3 28.5 28.1 28.9 28.6 28.5 28.2 29.6 28.7 28.7 28.7 30.5 30.1 30.7 30.3 31.0 30.7 29.8 30.2 30.4 30.1 29.2 29.7 30.1 30.9 29.6 29.0 29.2 29.5 29.0 28.7 29.3 29.4 29.0 28.7 29.6 30.1 28.9 28.9 29.6 30.1 29.0 28.9 31.0 31.2 29.9 29.3 31.5 28.9 29.5 29.2 30.5 29.3 29.4 28.5 30.0 29.4 28.6 28.2 28.5 28.6 28.3 28.9 29.8 28.2 27.8 28.2 29.3 28.5 28.2 29.3 28.9 28.7 28.6 29.0 30.0 30.1 30.4 31.2 31.0 30.8 29.7 30.3 30.9 30.8 29.4 29.6 29.9 30.2 29.2 29.2 30.3 29.9 29.3 28.6 30.1 30.0 29.1 29.1 30.3 29.3 29.5 29.8 29.9 31.0 29.4 29.6 31.5 31.9 27.9 27.0 28.6 26.7 27.2 26.4 28.0 26.2 26.7 26.8 27.4 26.7 26.6 26.1 27.4 26.1 26.0 26.7 28.0 26.1 26.8 26.0 26.4 26.6 26.8 26.7 27.4 26.8 26.5 26.3 28.0 27.0 31.1 30.9 32.4 32.5 30.2 30.1 30.2 31.1 29.6 30.0 30.0 30.2 29.7 29.4 29.9 30.4 29.0 29.6 30.1 30.5 29.0 29.6 29.5 30.4 29.9 29.5 30.6 30.4 30.2 29.8 31.8 32.7 74.9 74.1 76.6 24.9 25.1 24.7 70.1 70.2 24.8 66.3 67.3 66.0 25.0 24.7 64.5 65.1 23.7 64.0 65.1 64.6 24.4 64.2 25.7 65.4 24.6 24.6 69.4 68.5 71.1 24.9 25.6 75.8
What are we doing wrong?
As i menitoned driver code was unmodified in any way, maybe something is missing from reading / displaying sequence of function calls? What else?
This is just for better visual understanding... some strage artifacts at the bottom lines can be seen.
Also did not mention - human skin is abour 50C when presented into FOV.
With Melexis demo software it is showing aroung 34-35. (same sensor).
Are these measurements done with your own PCB?
The measurement deviation in the test seems typical for a configuration where the required power decoupling capacitors are either, not present, too far away from the sensor or broken. Can you please check that?
Yes, we are measuring with our own PCB, but as this is work in progress now
the sensor is connected via wires on breadboard, capacitors were not present, so i added them now.
And in terms of noise, and those several pixels that were "off" - it did wonders! Thank you!
The temperature readings are now much more stable but still far off.
30-38 for the ceiling it is pointed to.
around 40-45 when i near cover it with my hand.
So.. what else could cause this?
Power regulator in use on our PCB is LM1085 (3.3V version)
Yes, that is indeed too high.
What is the Ta that you get now?
Do you already see an image if you hold your had in front of the sensor (with a bit of distance).
Raw Ta calculated by MLX90640_GetTa -> 35.
But as your datasheet says i substract 8 from it, and it is 27. Which is as well too high.
(my code in First post substracted 16, that i was just playing around, really i use 8).
Also yes i can see my hand. As well tried a flame, which is seen even clearer.
Question about this function:
MLX90640_CalculateTo(uint16_t *frameData, const paramsMLX90640 *params, float emissivity, float tr, float *result)
What should i put into "tr" parameter? i put here currently my calculated Ta (with substracted 8C from it)
Is it correct, i've just seen someone doing it this way on github, but maybe it is incorrect?
Yeah, something is definitely not good. Here is image when i pointed camera to the surface of the window
which is much colder that surroundings, and artifacts got very bad...
It seems there is something going wrong with the synchronisation of the readout of the 2 sub pages.
What refresh rate and I2C speed are you using?
The tr parameter depends mainly on the package design and the measurement conditions. What you are using the ta-8.0 for what you are currently doing seems to be just fine. With emissivity set to 0.99, I would not expect such error coming from tr.
float tr – reflected temperature defined by the user. If the object emissivity is less than 1, there might be some
temperature reflected from the object. In order for this to be compensated the user should input this
reflected temperature. The sensor ambient temperature could be used, but some shift depending on the
enclosure might be needed. For a MLX90640 in the open air the shift is -8°C.
For the time being you could even set the emissivity to 1.0 to remove completely the tr from the equation.
Can you please share the EEPROM content (MLX90640_DumpEE), the extracted parameters(MLX90640_ExtractParameters), the frame data (MLX90640_GetFrameData) and the calculated temperatures (MLX90640_CalculateTo).
Best regards
Hello,
I found the problem, it was where reading from I2C combines 2 bytes into UINT16
originally code taken from your I2C driver:
*p++ = (uint16_t)i2cData[i]*256 + (uint16_t)i2cData[i+1];
As i am using Qt's QByteArray to store the data, i2cData[x] - is signed char!
So i rewrote it like this, and now temperature readings are same as with developer board:
*p++ = (uint16_t)((uint8_t)(answer.at(i)) << 8) + (uint8_t)(answer.at(i+1));
But during my experimets it seems that i have broken 2 bottom lines of my sensor...
Those lines are "broken" with both my software and melexis dev board as well, so issue is not in the code,
probably in the sensor, image attached:
Can it be saved?
eeprom-frame.zip
Zip file with binary eeprom and framedata files.
I think it is no point sending calculated parameters, as this issue persists as well on dev board with
melexis original software. So it is not software problem. Can you check maybe i owerwrote eeprom cal data?
Yes - it seems like you somehow managed to overwrite address 0x2417. Currently the value stored there is 0xFFFF and it should be 0x9FC0
Best regards
@slavysis Thank you! I put there your supplied value, and sensor is fully restored! 👍
Much appreciated.
If you don't mind, i will send you tomorrow an EEPROM of MLX90641 - which was included
together in this Develoment package. I also broke it. Maybe with your help it could be restored...
Thank you!
So yeah, here is EEPROM of 90641..
eeprom-90641.zip
This sensor stopped working inside melexis dev software (says something about CRC error?)
Inside my software "HammingDecode" fails on multiple places.
So i don't know if it is recoverable, it seems there is alot of broken data...
Maybe you could send me some "good" default eeprom file, that i will programm into device?
Thank you!
I close the issue, as it is solved.
Regarding the EEPROM - if you ever have time to correct it, please notify me :)
Here is the proper EEPROM content for your MLX90641
eeprom_90641.xlsx
Best regards
Thank you!