Close
0%
0%

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.

Similar projects worth following
https://youtu.be/tLwYMQjD0l4 Spi writes are far from fast and are not properly optimized! This project allows data to travel at highway speeds for fast lcd updates even on Arduino spi!Imagine a highway using traffic stop signs, traffic would get backed up because of the time it takes cars and busses and trucks to get up to speed. spi protocol is busy. it is complex, and this causes traffic to back up a lot. one way to make it work better is to remove the stop signs, and make traffic flow more orderly, in this case allow up to 16 pixels (or cars) of data to pass thru before a red light. the during red light time we do math, and let other data thru. this dramatically speeds up lcd writes on spi display. as things don't need to slow down and get back up to speed (the initialization steps to write pixel data). this project compiles using Arduino ide 1.6.5, multi writes work in 1.8.5 also

this project uses code that allows between 4 to 256 rectangles to be written in a single instruction or single set of instructions without need for command mode, windowset, pixel address commands for each pixel. this allows effective and efficient spi data transfer of data with minimal command overhead. for 64 rectangle at a time look at program links.

if using the spi optimized driver files and a st77xx display (i'm optimizing for ILI9341 by end of october 2018) you will get incredible update speeds to display. if using a display other than the ones i have mentioned, i have created a wrapper that takes my display commands and translates them into universal drivers for adafruit. you'll get the performance from the reduced command overhead (4-10x) but wont see the 2x-3x boost that comes with spi bursting, memory optimizations as these need to be built into the display drivers)

video below shows project details and is only 3-4min. This is just for an article format to discuss methods and ways of speeding up lcd displays that use SPI. It explains why SPI is slow, and methods to increase performance by over 30 times! example of use can be found here https://www.thingiverse.com/thing:3050327 it is a complete thermal pointer, that works at 64x64 resolution on Arduino mega, 64x64 on uno! There is so much overhead to writing pixel information, writing rectangles reduces this overhead, but now a newer method, writing several rectangles at once with minimal overhead. this alone leads to 16x performance for Arduino, where buffering the entire screen is not an option due to limited memory.  there is also double speed to SPI on Arduino. SPI bursts are now twice as fast! (with everything it is able to do 64x64 at ~10fps!) newer code is in beta section of my downloads for speed with 64x64. 

weird tech jargon below!

Yes some people use buffers but the spi transfer itself is also not optimized. There is often a lot of overhead other than pixels for display of data.

originally code was written per pixel, and being that Arduino code didn’t know where pixel was, each pixel needed an address, so 2 bytes for x, 2 bytes for y address, and for color data, in 16 bits it required 2 bytes of data. Only one time was window size defined, at initialization, or at start of lcd use, the window size was set to full display size.

On Arduino buffering of the entire display is often not possible as the memory requirements are a lot.

There has been a really clever method that came out and it was to write rectangles, as long as data had same color it is faster to write areas of the display. Set windows size commands that takes 6 or more bytes, set start address, and then write same color 2 byte data, again and again. 

The display is usually set to a mode that automatically advances pixel location after color data is sent. This seems faster, but the closer the information gets to the display resolution the slower this method becomes because of the overhead to set the starting positions of the window size for the rectangles. At reasonable resolutions the display update rate gets down to a few frames a second.

What I have is a possible solution to the speed of spi, using the rectangle command to draw several rectangles at once, utilizing the set window command, but allowing rectangle command to write several rectangles within the larger rectangles with individual colors, and only uses up to an additional 32 bytes of ram, but speeds up display writes by up to 16 times because overhead is only used every 4 or 16 pixels, instead of each time!

Also removing the wait of spi. Spi data is usually checked to ensure that the write of serial 8 bit data is complete. Why do we have processor stall and wait for this to complete....

Read more »

IMG_6074.PNG

this is amg8833 sensor running on an Arduino uno equivalent with software. it uses 23878 bytes flash and 1068 bytes ram. i'm working on software that enhances detail and outputs resolution so far at 64x64 resolution with some built in filtering to reduce noise, and increase detail and auto temp. shown in image is my leg, the temp and surrounding temp with a built in color bar to show range. it is auto ranging temp. it is doing about 10 frames a second at 64x64 detail with subsampling, and filtering features enabled.

Portable Network Graphics (PNG) - 360.78 kB - 09/23/2018 at 10:49

Preview
Download

version3a.png

new housing for device. updates on thingiverse https://www.thingiverse.com/thing:3050327 this has a base that has better balance and is resistant to tipping.

Portable Network Graphics (PNG) - 49.65 kB - 09/16/2018 at 07:06

Preview
Download

IMG_5993.PNG

this is image of my hand from 64x64 and enhanced mode of thermal cam sensor amg8833 there are still artifacts that i need to remove. files are now removed and linked to locations in github, it allows for proper tracking of updates.

Portable Network Graphics (PNG) - 260.07 kB - 09/09/2018 at 06:56

Preview
Download

thermal_cam_9_8_working_bugs.zip

Newer versions with bugs fixes are on github sketch uses 952 bytes ram 26950 bytes flash, 64x64 sub sample. still fixing bugs, have some block effects, so i think there are errors in how the color information is handled. still shrinking code, and reducing ram. uno has about 5-6k to program other functions.

Zip Archive - 370.78 kB - 09/09/2018 at 06:47

Download

  • improving filtering. will include optical offset. still trying for better filtering

    jamesdanielv11/11/2018 at 00:29 0 comments

    the 128x128 subsample method is noisy. i'm trying to resolve this by fixing possible issues using simulation.

    i'm currently simulating upsample in javascript code.  ill post a link when web version is uploaded and article is up for the non float upsample method used. i thought it would have been uploaded a week or so ago but  it will be out this next week sometime. i hope to have it capable of 32x32 (the simulation) and eventually 128x128. this simulation code will help me fix noise issues at 128x128 and possibly greater upsample resolutions.

    i have already included optical correction which compensates for individual sensor variation of angle. this effects and improves the pixel color accuracy. i included compensation on a hunch, and with trial and error it proved to be the correct thing to do. it slightly averages pixels together about  1/16 depending on specific settings in code. this is before subsampling is used. 

    there is an other effect that i am going to implement that will make image upsampling have less shadowing and it is pixel offset calculation. depending on position of sub sampled pixel there should be a set amount of offset to its brightness value compared to its neighbors. 

    i would have posted more results sooner, but i ran into this optical error, it can be viewed in both upsampled views and shows with a darker and lighter shadow in both 16x16 and 16x16 corrected. 

    i have spend a little bit of time trying to see if i could make this better. granted in real life such a sharp contrast in backgrounds would most likely not be possible, but i spent time to see if there was something that could be easily done to make it look better. 

    after bit of trial and error i found out that even with other upsample methods this specific sharp contrast and small size of image had issues with other upscale methods. so it is not just my method that has this issue, it still bugs me, but not as much as it did. part of the issue is no shadow information in image. this would not be an image in real life. 

    here below is how it is output thru gimps upsampling algorithms from 8x8 grid to 16x16 grid, image was cut and pasted from screen snap shot of image scaled to screen 1600%

    I will see how this algorithm works to see if improvements can be made in my subsample method.

  • ili9341 320x240 at >10fps(20fps interlaced) 32x32 interpolated blocks) using amg8833 sensor

    jamesdanielv11/07/2018 at 02:22 0 comments

    beta release of ili9341 display working at an average of 10fps (20fps but interlaced). need to finish up feature changes and buffer size adjustments for mlx90460 sensor, then get 64x64 mode working for ili9341 display.

    including new features on 32x32 mode such as AdvancedColorVisualSeperation. setting this with a number greater that 0 enables it. whatever number above what you set to is the color range intensity that is amplified, so unlike narrowing temp range which also brings more noise, this just shows more details around objects. im still working on methods that handle saturation, currently i'm just clipping it at max intensity false color value

    and optimize 3 setting that reduces display writes by half, and some other minor tweaks.

    also starting to put in code that allows sensor buffer size to change. this is important for adding mlx90460 sensor to be used in code in future.

    to turn on and off AdvancedColorVisualSeperation set it to true or false. it can saturate images.

    https://github.com/jamesdanielv/thermalcam/blob/updates-(possibly-unstable)/ThermalCam_ili9341)32x32.zip

  • simple thing that can speed up any ili9341 display in my case additional 20%

    jamesdanielv11/06/2018 at 00:01 0 comments

    Since i have been getting the ili9341 display ready for fast 32x32 (and 64x64, 128x128) subsampling of amg8833 sensor the ili9341 display has 4 times as many pixels as the st7735 display i have working at fast speeds. to increase performance i am doing tricks that cut down display writes to about half, and the rest is thru driver optimizations.

    I have found out that the driver for set window always sends 4 byte commands for x, and 4 byte commands for y no matter what the display position is, yet most of the time only one or the other is needed.

    here is the setAddrWindow command driver as it is in ili9341 driver :

    void Adafruit_ILI9341::setAddrWindow(uint16_t x, uint16_t y, uint16_t w, uint16_t h) {
        uint32_t xa = ((uint32_t)x << 16) | (x+w-1);
        uint32_t ya = ((uint32_t)y << 16) | (y+h-1);

        writeCommand(ILI9341_CASET); // Column addr set
        SPI_WRITE32(xa);


        writeCommand(ILI9341_PASET); // Row addr set
        SPI_WRITE32(ya);

        writeCommand(ILI9341_RAMWR); // write to RAM
    }

    here is my optimization. it reduces command overhead by 33%. still you will need to send either x, or y and at least set ram buffer command on each screen location update. my goal is to not use screen location updates but they are needed at least for every square block write to display (64 times) or when only writing half the display one time per line call so we can skip a line, so 64x15 (64 blocks. a block on this display is 30x32 pixels) or 960 times per frame.  the time savings is significant enough to raise frame rates about 20% in itself when doing half fill mode as location window changes every other line for fills within a fill square of multiple colors.

    keep in mind the caching of values and comparing. if no change we don't write both x and y we only update one of them.

    long xaCache ; //two ram values that use 4 bytes each are needed to make this work.

    long yaCache; //place values at top of page where the code is, in my case it is adafruit_ili9341.cpp

    void Adafruit_ILI9341::setAddrWindow(uint16_t x, uint16_t y, uint16_t w, uint16_t h) {

        uint32_t xa = ((uint32_t)x << 16) | (x+w-1);
        uint32_t ya = ((uint32_t)y << 16) | (y+h-1);
        if (xaCache != xa){
        writeCommand(ILI9341_CASET); // Column addr set
        SPI_WRITE32(xa);xaCache = xa;
        }
         if (yaCache != ya){
        writeCommand(ILI9341_PASET); // Row addr set
        SPI_WRITE32(ya);yaCache = ya;
         }
        writeCommand(ILI9341_RAMWR); // write to RAM
    }

  • reduced block write time from 2300us to 1900 (this is for 32*30 pixels area)

    jamesdanielv10/18/2018 at 05:09 0 comments

    this is for ili9341 display. it has 4x as many pixels to write. if we write every other pixel line we get similar visual with 2x performance. since we can only go up to 128x128 (this is scaled to 2x2 pixels per sample on this display) sub sampled (only 64x64 with good results so far) this seems acceptable. 128x128 is being worked on and will be updated within 2 weeks. i've got an other article blog coming out on how to do super sub sampling without floats.

    more pixel writes in a row make faster pixel writes because every time you change x or y position requires command overhead. just by switching direction that lines are made for every other line write it speeds up 8x8 block size (30x32 pixels) to 1900us, from 2350us. instead of writing 30 pixels and having 16 write new position commands overhead, we have write 32 pixels with 15 new positions command overhead. only difference is we write top to bottom, rather than left to right. we write 64 of these blocks

    this equals 8.22 fps *2 (keep in mind buffering blocks reduces writes 2x -5x!, so average frame rate is 16.44fps)

  • beta version of ili9341 working 10-15fps in 16x16 mode download link

    jamesdanielv10/18/2018 at 04:42 0 comments

    https://github.com/jamesdanielv/thermalcam/blob/updates-(possibly-unstable)/ThermCam_ili9341_16x16.zip

    this version has 16x16 working quickly on ili9341. 32x32 mode is about to be uploaded. current 16x16 drivers are only completed enough to allow for 16x16. when 32x32 mode is ready 16x16 will be re uploaded with latest drivers. 64x64 sub sampling should be working by end of week. it already works for st77xx displays, the ili9341 has 4 times as many pixels and also requires different display drivers. the above download link should work out of box for ili9341, and amd8833 sensor

  • you can write half as much data to ili9341 display and have it look great!

    jamesdanielv10/17/2018 at 21:40 0 comments

    the screen resolution of the ili9341 is 4x what the st77xx display i also support is. i have done optimizations that speed up ili9341 spi performance

    here is how long it takes to write a solid 30x32 block (creates a near square pixel on screen in 8x8 mode, on 320x240 display)

    default driver is on right side for timing in microseconds, spi optimizations is on the left side (we do calculations  or data manipulation while spi is writing, instead of stopping and waiting for spi to complete.

    but it gets even better. 

    if you only write every other line (you send a lot of data, and write every other line, you get better performance. not as huge as before, but it makes frames per second higher. up to 64 of these pixel blocks are written every second (buffered modes reduce this about 50%)

    and here is the image results of just writing every other line on screen

    you really can only tell if your eyes are within 6 inches of display.  it might be touch screen plastic over the display or the display itself, it diffuses the light, so the gap between lines is minimal.

    here is some data  without processing overhead (300us) to show best frame rates possible with defaults and so far.

    default driver: 4300us per block= 4300x64=275200 or 1000000=3.6 fps best case

    spi optimized :2850us per block= 2850x64=182400 or 1000000/182400=5.48 fps * 2 (just over 10fps buffered)

    this mode: spi optimized :2360us per block= 2360x64=151040 or 1000000/151040=6.62 fps * 2

    remember not every pixel updates or changes at once. using buffers 2x-5x frame rates.

    default driver does have buffering but only on arm cortex.

    i think i can also make every other line method better by making pixels area larger. the more in line writes at a time the fewer set pixel overhead commands are used. to get every other line i had to increase command overhead for each line start.

    video below is in 16x16 sub sample mode for the ili9341 display. i still need to modify drivers to do more resolution (little overhead) most of overhead is display writes. the st77xx display can do 64x64 subsample well.

  • new ili9341 extender. tilts display upwards for easier viewing

    jamesdanielv10/16/2018 at 20:21 0 comments

    ili9341 display i'm currently making display drivers for, needs a better viewing angle. in testing the display angle is hard to see, so i tilted it up a little bit. it still slides into the thermal cam housing design here:

    https://www.thingiverse.com/thing:3050327

    here is a digital image of ili extender

  • ili9341 starting to work in thermal cam! lots of speed up work to do. it is also a touchscreen. Creating driver for this display that will optimize it as well.

    jamesdanielv10/13/2018 at 04:55 0 comments

    ili9341 working on Arduino.  led backlight power lighting is in 3v pin, and lcd power 5v icsp header along with gnd  miso and mosi pins, enough power pins are left for powering amg8833 or mlx90460 sensor. there is other pin i/o to spare for touch and other devices. larger display might require more than a dry cell 9v can deliver. switching to alkaline, or running 2 9v in parallel. will keep posted on batteries used. for now it is back to using usb, while testing and rewriting drivers

    ili9341 working on Arduino.

    using 16x16 resolution for testing image without camera flash. on the st77xx display i have it working good to 64x64, while 128x128 works but has artifacts still.

    screen shows dim from camera flash, testing it in 16x16 mode. drivers not optimized. adafruit has made some changes to the workings of the SPITFT of the drivers, and it means that the ili9341 drivers work a little different. i am not able to combine libraries so i have added a new sketch that defines what spi mode (internal library or one i include and a lcd_mode sketch that i can just drop in files for and switch which drivers work or not. i use

    // #if lcd_mode ==0 

    or //#if lcd mode == 0 at top of page code for it to run or not run . 

    currently running at interpolateMode of 1, or 16x16, going to test out InterpolateMode of 2 and up later on, these are 32x32, and 64x64 and 128x128. this display is 240x320. it also is a touch screen. i might get the touch screen working as well on this display. my goal is to support the ili9341 display and the st7735 display from adafruit. other displays should work with some troubleshooting. only accelerated mode will work for these two displays. ( 10fps or 20fps interlaced mode ) 

    i have not made optimized drivers yet for the ili9341. it runs currently at an average of 8fps, but it also only updates the pixels that change and prioritizes the ones that change the most in color value. if i place my hand over sensor and take hand away and all pixels change it slows down quite a bit. 

  • more ili9341 driver issues. reset was not called even though it was defined in code

    jamesdanielv10/12/2018 at 05:55 0 comments

    during continued testing i had other issues where display would intermittently fail after using it for a while. i checked and replaced wires, even soldered over connectors on Arduino board (they were loose anyways), finally i tried directly wiring cs, and reset. if reset was gnd it always worked. cs didn't act differently.

    the code that init display for adafruit (granted this is not an adafruit display)

    while using adafruits graphics tests found this issue with reset pin not even being used in code! :

     Adafruit_ILI9341 tft = Adafruit_ILI9341(TFT_CS, TFT_DC);

    changed it to this

    Adafruit_ILI9341 tft = Adafruit_ILI9341(TFT_CS, TFT_DC,TFT_RST);

    second set of problems solved. i'll check another display when it arrives saturday.

    i switched inputs to this to match pin out in thermal cam sketch. 

    #define TFT_DC 8
    #define TFT_CS 10
    #define TFT_RST 9

  • ili 9341 lcd works at 5v now. but i'm not 100% sure why. to be continued. ordered 1 more

    jamesdanielv10/12/2018 at 02:45 0 comments

    here is the display working at 5v, i'm not sure why it now works. i gave up on the resistor divider and re-soldered the connections i cut yesterday. soldering was a pain until i lifted up the lcd, and pulled up the flex, which was glued to pcb. i checked resistance of small wires i added and wire across the cut traces. although thin adds less than a 0.5ohm resistance. i checked the resistance in between between the pads and it was still high, continuity was zero .i checked resistance between gnd and wire trace assuming maybe the flux had created a resistor circuit. nope. so far the only thing that makes sense is folding back the flex cable from board. i checked glue as well, it does not conduct. i bought another display and will do two things when i get it, i will bed the flex board to release it from pcb, and if that does not work i will clean solder tip and heat up pcb to see if it breaks down to form a resistive area. then lastly i will apply flux. it is a mystery to me. ill post a how to video when i figure out why it did not work, and why it does now. i know i had wiring correctly because it did work with led used to lower voltage to 3v logic levels.  when i hooked up display  after fixing it from the cut traces and pulled back lcd flex, i tried testing pins individually to see if any would work at 5v ttl of Arduino. one by one they all worked, i thought weird, so i wired it without breadboard. it still worked. thought maybe 5v was plugged into 3v. nope it was to 5v.


View all 30 project logs

Enjoy this project?

Share

Discussions

jamesdanielv wrote 09/30/2018 at 06:41 point

adding the mlx90460 sensor to be able to work with this project has been complex. so complex it has its own article blog here https://hackaday.io/project/161499-mlx90460-sensor-works-w-800-bytes 

currently sensor outputs to terminal and shows a visualization of all sensors in a grid pattern similar to a picture. i have added ability to change hz, ad resolution and switch between continuous and step mode (single shot mode) as well as read sensor values and compare them to values stored in progmem (created another program that extracts them for cut and paste)

  Are you sure? yes | no

jamesdanielv wrote 09/26/2018 at 06:30 point

MLX906040_example32ataTime.zip file , that is linked here https://github.com/jamesdanielv/thermal_cam_mlx90640

shows how to access registers for modes and status of sensor and read what page it is on. it reads a full 32 pixels at a time. as long as reading of memory is after both passes has completed then all data will be there, even reading one byte at a time. 

this sketch currently uses 706 bytes and 5720bytes flash

  Are you sure? yes | no

jamesdanielv wrote 09/26/2018 at 03:47 point

added link to test file for Arduino mlx90640 sensor. 

https://youtu.be/r1J1AwunTps video showing sensor working on Arduino uno equivalent 

https://github.com/jamesdanielv/thermal_cam_mlx90640

demo uses 522 bytes ram, and 4260 bytes flash. 

  Are you sure? yes | no

jamesdanielv wrote 09/23/2018 at 10:48 point

fixed further issues with 64x64 (blockiness), and filters to reduce noise when enhancing sensor colors. code still needs clean up, but again ill wait till 128x128 resolution.

https://github.com/jamesdanielv/thermalcam/tree/updates-(possibly-unstable)

going to test more and then put it in the regular software branch.

some new working settings

threshold// settings to have level below a certain amount show as lowest color to reduce noise 

SubtractColor//similar to threshold but post processing. removes darker colors

autorange true//this allows sensor temps to be auto calibrated to what is on screen

showcolorbar //this allows lcd to show colors used on screen and in a color bar map

showtemp // shows temp and also at left and right side of color map bar

https://github.com/jamesdanielv/thermalcam/tree/updates-(possibly-unstable)

adding a new photo showing device working in 64x64 mode with color bar. look at files section for photo

  Are you sure? yes | no

jamesdanielv wrote 09/22/2018 at 04:16 point

i'm uploading an example file for Arduino that takes a row of sensor data from the MLX90640 sensor and outputs different dot sizes to terminal, so you can see your hand cross sensor. what i like about this sensor is you can instruct it to send only the data you want to use at a time. i have not incorporated calibration into sensor. any ways this is the first example out there for Arduino uno (in my case duemilanove) . it uses about 4k flash and 480 bytes. it needs clean up that will happen when i post to its own github. at this point it is functional. quite ugly but it works. ill continue playing around with it, but it is a side show until i get amg8833 at 128x128

  Are you sure? yes | no

jamesdanielv wrote 09/17/2018 at 23:14 point

forgot to mention, i added ability to capture screen data by just sending 'c' ascii 67 in serial  monitor, this will return values of all sensors in a single shot. it helped me resolve some of the issues with the color banding that was causing blockiness issues at 32x32. with auto temp feature enabled this output is usually within 0.5 degrees of min and max temp on screen and is sent as floats.

  Are you sure? yes | no

jamesdanielv wrote 09/17/2018 at 08:53 point

https://github.com/jamesdanielv/thermalcam/tree/updates-(possibly-unstable)

still able to keep ram around 1k for sub sampling up to 64x64. 128x128 is a work in progress

resolved blockiness issues up to 32x32 and offset errors. still working on resolving issues with 64x64 blockiness. i think what i need to do is reduce error from calculations for pixtel color and position space. with multiple divides, there is greater error in pixel color. the div used is basically a divide by 2 or a >>1  (shift right). so i think resolving the rounding errors will resolve this for higher resolutions. either by starting off with a value *8 or 16 (8 or 16 times higher to allow more resolution detail), or just noting the error and adding it in later. the rounding error is from the 1 bit resolution detail of the calculations, no float. again issues are resolved for up to 4*4 sub sampling of pixels, but to do 8*8 sub sampling or 16*16 requires rounding considerations, or so that is my current thought... will post when 64x64 sample from 8x8 matrix blockiness is removed.

i'm still using 3 pixels for calc of sub sampling because it is superior to bi-polar sample with sharper detail.

i have resolved issues in pixel position calculations and removed the cross effect for up  to 64x64 resolution. pixels on screen are averaged differently that side pixels. still this is fastest method avail on Arduino and currently for up to 4x4 sub sample calculations have no visible difference, and more clarity than other methods of pixel sub sampling. after 64x64 sub sample errors completely fixed will post a video on how other people can do high speed non float sub sampling.

https://github.com/jamesdanielv/thermalcam/tree/updates-(possibly-unstable)

  Are you sure? yes | no

jamesdanielv wrote 09/07/2018 at 09:47 point

https://github.com/jamesdanielv/thermalcam/blob/updates-(possibly-unstable)/thermalInterpolateWork.zip this build has 64x64 sub sampling using a total of 920 bytes of ram for entire sketch. 64x64 res of screen is 8x8 samples, sub sampled with each pixel measurement as a 8x8 sub sample. this runs as fast at 64x64 as previous version did at 32x32. however.. i need to troubleshoot color values on edges. i'll have it fixed soon. 32x32 works great. i have added in enhancement features that enhances color changes, and shadows. so smaller objects can be seen. i know now it is possible to run 128 x128 resolution detail from arduino, as memory overhead is no longer a limit. buffer size of 32x32 is done with 40 bytes, 64x64 ram buffer is is about 132 bytes, but sketch >34k is too large for 64x64 for uno. will fix that. working on shrinking code down with minimal penalty. 

  Are you sure? yes | no

jamesdanielv wrote 09/04/2018 at 21:55 point

I'm currently using the amg8833 chip, I'm also now looking into compatible with the MLX90640. I have some more info on the voltage compatibility issues with using the MLX90640 directly with Arduino and use of sparkfun board with MLX90640 on it: the resistor values on the i2c lines (sda, scl) are just 2.2k pull up resistors. however looking thru documentation of data sheet MLX90640 section 13.1 confirms that the i2c is 5v tolerant  and in spec (2.6v-5v). it may even work without pull up resistors if the Arduino internal pullups are used (20k). if using part without sparkfun board, i can only recommend use of 2.2k resistors because this will be my setup.

  Are you sure? yes | no

jamesdanielv wrote 08/20/2018 at 21:09 point

yes, i saw a similar sensor on sparkfun https://www.sparkfun.com/products/14768. in theory the code should work by just changing array size, but it will likely run into memory issues as of 8_21_18. I am working on reducing memory requirements of sub sample.  as for arrays size change feature You can thank adafruit.com for that as https://github.com/jamesdanielv/thermalcam is referenced to adafruit's. might run into issues with memory avail, but i'm working to remove need for most of buffers for sub sampling. that in itself is worthy of an other article. non float sub sampling. just to be clear i am not sponsored by adafruit or sparkfun.  as always thanks for the information about other sensors.

  Are you sure? yes | no

Chase Rayfield wrote 08/20/2018 at 20:27 point

http://www.futureelectronics.com/en/Technologies/Product.aspx?ProductID=MLX90640ESFBAA000SPMELEXIS9097119&IM=0&utm_source=octopart.com&utm_medium=CPCBuyNow&utm_campaign=Octopart_Ext_Referral is an interesting part.... 24x16 for not much more than this 8x8 sensor.


The 55 degree FOV model is in stock the 110 degree one is not.

  Are you sure? yes | no

jamesdanielv wrote 09/02/2018 at 02:55 point

hey i checked on those sensor prices from future electronics and they are only if you buy 20 at a time. the 8x8 sensor is reasonably priced for just one at a time purchase.

  Are you sure? yes | no

jamesdanielv wrote 09/02/2018 at 23:19 point

sold out? i don't know. it is easy to overlook qty requirements as i did several times. but that is useful info on digikey so thanks. i've got one of these sensors on the way (MLX90640) the good thing is many of these sensors keep there resale value. it is worthy to know that the voltage input needs to be 3.3v. (not a problem if hooked up to Arduino 3.3v, or using a teensy, or equivalent)  I'm a little concerned about the compatible input and output voltages grey area of the sensor and the Arduino, but will base my code around Arduino still as i think playing favorites with mcu's doesn't win for anyone.  Making something work on Arduino usually guarantees compatibility even if it may be a little work for the end user of different product. if voltage logic  is the harry edge with voltages it has some unique issues especially with latency and propagation delays, especially if the slew rate is slow (not strait up and down logic signal). this means it will either work, work only at a slower speed, or just add in a $0.50 buffer to scale voltage, or use a low voltage mcu chip.  as always from you or anyone feel free to correct. i would love to be wrong about this! just to be clear i am not recommending a specific platform, just testing and making cool stuff work on Arduino...  i should add that i ended up purchasing a https://www.sparkfun.com/products/14768 because it came on a board, with what i believe is logic to allow for voltage difference. in this case i think just a voltage divider over the input pin of the sensor ic2. so for example 2 1k resistors may work in place of buffer. the board is not compatible with uno but it is because of math and memory requirements. hopefully i'll change that.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates