Close

mlx90640 sensor output at 64x48, calibrated on a 328p nano, using 1k of ram!

A project log for spi write up to 64 colors at a time on Arduino!

amg8833 equivilent sensor thermal cam is a perfect example of how to write faster with spi lcd displays. 128x128 sample fast on Arduino.

jamesdanielvjamesdanielv 09/03/2019 at 23:030 Comments

https://hackaday.io/project/161499-mlx90640-sensor-works-w-800-bytes

I have recently verified and tested, and made changes to the MLX90640 code and it works on arduino uno, and nano currently outputting data to terminal. this will change and data output to lcd will be possible soon. anyway the code currently uses about 1k with resolution doubled, without it uses ~750 bytes. this is during compile. but there are no heavy pointer uses in the functions, and the stack never is saturated as memory arrays have been reduced. the biggest array so far is the 256 byte buffer for the DoubleResolution function with its main purpose to reduce i2c reads from mlx90640 sensor memory, and reduce complex calculations of To calc Deg C to only once per mem cell per capture.

i have been working with the amg8833 sensor for a while, and while it is good and i have it upsampled only the luminescence information really increases. finer detail is missing. this is where the MLX90640 sensor shines. also it has better fidelity, or resolution detail. 

My goal for both of these sensors is to have them working at better resolutions and working on the uno. this requires rethinking how each sensor works and operates. in some aspects the code for the amg8833, works faster than the arm version. unfortunately the code for the most part also only was designed to work on uno. this will be a different story for the mlx90640 code. 

This is something that i had in the back of my mind for the mlx90640. it will maintain compatibility across processors in the Arduino family with minimal code modification.

here is an image of the nano hooked up to the sensor (btw i switched to using a 35x70deg field of view)

here is an ascii graphics art output of the sensor to terminal. it has a 2ooms second delay per frame just to show image on screen for a little bit

this is output in image mode (not as accurate) upsampled and sending data to terminal as ascii graphics art output on atmega 8bit processor. (same as uno for processing power, and uses about 1k of mem)

now on uno, i thought it would be better to show raw value outputs. i am doing a karate chop about 6 inches in front of sensor for this video below

video above is using the same code as previous video, just output mode is switched to show deg c, and its output detail is from To Calc the accurate output of cell with all the calibration information.

below is information from compile

so the mlx90640 sensor i have had working on arudino for some time, but i have not had it working calibrated. now it works calibrated, and it works at a similar speed as the arm version with some debatable shortcomings. 

the arm processor uses heavy ram storage and thrashing to reduce i2c requirements. but it also just waits there 98% of the time doing nothing so it can meet the timings of the ram refresh before the data is overwritten.

the arduino 8bit version utilizes the storage of data on the internal mlx90640, while requests for calibration settings are already stored and copied into its flash from a table. it reads 1 cell at a time, and has a resolution doubler. it does not wait as long as the arm version does. both arm and arduino versions are limited by i2c bus and math calculations. i have reduced the i2c requirements on the arduino thru caching of data that is to be read more than once for resolution doubling. 

Both arm and arduino versions can currently output 3840 cell samples at best resolution per second. 

we will only need about 5 of these samples for lcd mode, and the rest can be of faster image mode processing that is about 2-4 times faster than To deg c calc mode.

Anyway further caching improvements are in the works, and better math shortcuts for more performance are on the way.

this makes the mlx90640 project cheaper for those just starting out, and it allows more memory freedom for those with projects. for example the teensy-lc compiles to just under 3k of ram, leaving room for other processes to be added. the teensy3.1/3.2  compiles to about 5k, about 15k less than the original code. and every 8bit to 32bit processor can take advantage of the resolution doubler to 64x48 

the code is still experimental and has a lot of settings and features that make it easy to verify it works similar to the old way, many of these are not needed so a cleaned up version of code will be worked on at some point in time.

MY goal for the mlx90640 sensor is to have it working on arduino 8bit uno processor and have it also outputting data to an lcd display, similar to the way the amg8833 project has done for some time.

Discussions