Close

how to buffer data for display writes from more complex sensors such as mlx90460 or flir 80x60

A project log for mlx90640 sensor works w 800 bytes

Everywhere i read people are excited to get mlx90640 working. here are examples using arduino w 800bytes ram, and 1k with calibrated DEG C

jamesdanielvjamesdanielv 10/19/2018 at 05:010 Comments

i have several methods to increase Arduino performance. i use non float interpolation. I use spi bursting, i sometimes used half pixel processing to allow every other line on big displays, and i use cell buffering to reduce changes to screen 2x-5x, and finally i control data bandwidth to allow most changed pixels priority because noise is also a factor otherwise. here is how i'm thinking some of this will play into the mlx90460

One of the ways i'm getting good performance from Arduino (in many cases on par with arm processors) is that i incorporate buffering at the level of the analog world. the input side, not the display resolution. we only write areas on the display that change, and when a lot is going on, only the areas that change the most because analog is noisy. to keep performance on a small memory footprint, we need to think of areas on screen as cells. this is similar to though processes of jpg imaging, and mpeg encoding. look for areas that change. however we will look at areas as a group of cells. 

on amg8833 we use 2 bytes for each of 64 cells. but we only see a range of 1024 values.

the code i use for that sensor is if values are different in cell area we write cell. now with the more complex mlx90460 sensor we have 32x24 sensors. we still want to break up cells data into 8x8 areas for buffering, so what we do is add all 12 cells together, and store a 2 byte number of those values per cell. if number is different it will be updated on screen. this allows us to use the same buffer space as before, only difference is 12 numbers are higher. adding numbers together doesn't use much processing power and comparing number values with stored values is very low cost to code time. we are still doing the same thing looking for changes at input. 

on another note, we will not be sub sampling as far up to get more detail with this sensor, so there may actually be less processing time to scale data. my goal with this sensor is to have it working at least at 64x48, and then at 128x96 resolution. and possibly higher.  this only requires 2 levels of upscale which is very easy to do. (or so i think so far).

Discussions