i have made this code work on Arduino. examples for testing use less than 800 bytes ram.

[jamesdanielv]

this isn't really an issue , except for the mlx90460 mlx90640 code provided does not work on Arduino.

hello, i have code that i'm working on using the mlx90460 mlx90640 sensor. the link is here:
https://github.com/jamesdanielv/thermal_cam_mlx90640

i'm taking advantage of the fact that the mlx90460 mlx90640 sensor has built in ram and can store data.
what the code the link above does is read 1 line of ram at a time (up to 32 sensors) . it currently does not calibrate temp data but that will be easy enough to do on the fly using eeprom to store sensor calibration eprom. and read it from eeprom, or preload it and load it into flash instead of ram (progmem)

any way the examples i have currently work,
there is a sketch to see if mlx90460 mlx90640 is can be detected
a sketch that reads 1 page and 16 sensors and outputs to terminal so you can see it working
a sketch that reads and shows on the terminal an entire output of 768 sensors with 5 levels of output characters. ((space), .,+,o,O)

https://github.com/jamesdanielv/thermal_cam_mlx90640

[nseidle]

Hi - this is very exciting! I encourage you to continue however the floating point calculations and manipulations may require more RAM than is available on a 328 based Arduino.

[jamesdanielv]

it might require float performance, or it might not.
thermopile sensors (mlx90460 . mlx90640) are more complex than Thermistor (amg8833 as described in its diagrams) sensors but not by much

for example i've already BETA code for the amg8833 sensor at 64x64 resolution here: https://github.com/jamesdanielv/thermalcam/blob/updates-(possibly-unstable)/thermal_cam64x64.zip

[ralvescosta]

Hi @jamesdanielv

I'm starting the study with MLX90460, i'm found the your's exemple is very cool, but i have some question. Which Arduino model do you using for testing this project?

Thanks for you atention.

[jamesdanielv]

hello, i'm using the Arduino Duemilanove, an equivalent to the uno, uses ATmega328. Duemilanove has 1.5k less flash than UNO.

[jamesdanielv]

hello all.

i have a functional version that works on uno, nano, teensy-lc. and it runs using factory calibrations and outputs temp in deg c.

first off i would like to thank spark fun and melexis because the reality is it would have taken a lot longer to make code if they didn't provide an example that worked.

Also even though melexis documentation * edited with original remarks at end* it was not easy to read thru. in all fairness it was good enough. print it out and read it with a ruler under the area you are reading thru it. the terms are so similar, and so much is going on it will drive you up the wall. I sincerely apologize, as the documentation seems so far to be ok. this is with hours and hours going back over the example section 11 Calculating Object Temperature, and 11.2.2.2 and the examples for completion. I have offered 20$ to anyone that reads this who has tools or the ability of time or exceptional skill to read thru it and find errors. you will earn it.

my code now works even on uno and on 8bit variants as far as i know. I post errors in the issues section when i find them. so far i have had engineering students offer me feedback on how to make some things more clear; but it is usually helping with the i2c setup instructions and i will incorporate this into a Faq's guide. not everyone gets the sparkfun board, and people seem to think they can get away with not using pull_up resistors. external 2.2k are a must if not using sparkfun board, but i would recommend a person get the board. I should also note I'm not being paid to do this, and am not requesting money. I have personal interest in thermal camera sensors and how they will eventually help with certain mining tools and terrain mapping.

unlike my amg8833 sensor code, my goal was multi processor compatibility.

the current mlx90640 code uses about 1k of ram and about 20k of flash.

this code is experimental and it is a little messy because it needs to work in old and new methods so anyone can compare functions. i would expect this to clean up over time.

memory management is controlled thru Z_MemManagment.h in this file :
NEW_METHOD false will result in similar memory techniques as sparkfun melexis code.

NEW_METHOD true will result in new memory managemnet that requires less than 1k of ram at

compile time.

it defaults to NEW_METHOD true

needless to say old methods will only work on a processor with more than 32k of ram (a whole lot of memory thrashing, loading and unloading pointers onto stack, for example.
https://github.com/jamesdanielv/thermal_cam_mlx90640

here is a video of the output on arduino uno. output of deg is at 32x24 to keep screen manageable.

https://www.youtube.com/watch?v=XDSGqFgfQfU

and by the way it works at 64x48 resolution too! as in video here

https://www.youtube.com/watch?v=BC5gONWO-gg (this is teensy3.1/3.2)

if you are doing own code, the function
DoubleResolutionValue(x,y) returns the new resolution interpolated value (0-63,0-47)
Readmlx90640To() reads the memory location directly (0-767)
read the helpful_hints for more information.

currently the teensy3.1/3.2 runs faster with everything in ram and its superior math performance

but only by a margin. the uno and teensy_lc are about the same, except teensy has a faster i2c

bus, and both teensy processors have direct usb communications. the uno however can do serial

comms at up to 1mhz so it is not much of an issue. anyway i am working on improving i2c

performance to reduce calls to the i2c chip, and improving the math performance on uno.

there is some irony for the arm version and the old mem method. the processor waits in a while

loop for all the data to be read from twice. it literally spends 98% or more of its time in a while

loop! new method can be more efficient as well it only is in a while loop waiting for offset and

gain data from page read of sensor. this part of code will change in the future as i do not think i need to read it twice, other than vdd, and gain values. time will tell and it is in a constant state of progress.

enjoy, and please provide me feedback and questions. i would like to create a faq guide and

explain some of the new methods and functions.

I could not substantiate my original claim of errors within the 3hrs i gave myself to find them again. this does not at this point mean that they are not there, just that i don't have time to look further, and i did poor documentation of some of the issues i ran into. it is possible that It is me that is in error as well. But to be sure. I'm offering 20$ of my Own cash in paypal read end of this comment.

I removed the original statement i had earlier. at this time i can not very it:

• original edit * is flawed and full of errors the code none the less is usable and works. I'm sure if i did a 100+ page manual it would have errors as well.
  if you find errors in the melexis document and are the first to email me about it ill paypal you 20$
  jamesdanielv@msn.com
  https://hackaday.io/project/161499-mlx90640-sensor-works-w-800-bytes/log/168468-let-my-mistake-make-you-20

[LBuydens]

Hi James,

I'm product manager for the MLX90640. Do you by chance have a list/markup of the errors/bugs you have found in our documentation? We always look to improve our material.

[jamesdanielv]

it will take a couple days to get the list of items together, but i'll do it to improve the documentation. i can not be 100% sure of the corrections, but i can show where it does not match the or contradicts in the documentation, or shows the wrong registers to program, sometimes it is the wrong bytes as many variables are extracted from a 16bit data path and only use 1 or two bytes, some time i think it is the wrong memory address. it will take some time to go thru but i am happy to make a list. is there an email where i can send a pdf with highlights to the errors, or for things to double check with melexis about?

[LBuydens]

That would be very much appreciated.
Please send it to LBU@melexis.com

[jamesdanielv]

hello LBuydens ... with the 3hrs i had budgeted looking thru I can not confirm what i has said earlier. at this point, I do apologize. I offered up 20$ in paypal if someone finds something. the areas i thought did not match were section 11, and the example numbers plugged into section 11.2.2.2
I also commented here about it:
https://hackaday.io/project/161499-mlx90640-sensor-works-w-800-bytes/log/168468-let-my-mistake-make-you-20

[LBuydens]

Thanks for looking into it in any case. We'll review chapter 11. Luc

…

On Sun, Sep 8, 2019 at 12:49 PM james ***@***.***> wrote: hello LBuydens ... with the 3hrs i had budgeted looking thru I can not confirm what i has said earlier. at this point, I do apologize. I offered up 20$ in paypal if someone finds something. the areas i thought did not match were section 11, and the example numbers plugged into section 11.2.2.2 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7?email_source=notifications&email_token=AH5OUOZ3OSDRFBNKCBNLRQDQITKELA5CNFSM4FXILNH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6FNB7A#issuecomment-529191164>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH5OUO3IYETVP2LZV4H62G3QITKELANCNFSM4FXILNHQ> .

-- Luc Buydens Product Manager Melexis Technologies nv Transportstraat 1 B-3980 Tessenderlo Phone: +32 13 611 656 Fax: +32 13 672 134 Mobile:+32 485 556 217 E-mail: LBU@melexis.com Website: www.melexis.com

---------------------------------------------------------- The content of this e-mail is CONFIDENTIAL AND PROPRIETARY. Please read our disclaimer at http://www.melexis.com/mailpolicy