Lepton 3.5 Thermal Imaging Camera

Documenting my experiments with the FLIR Lepton 3.5 thermal imaging camera.

Similar projects worth following
I bought a FLIR Lepton 3.5 mounted on the Pure Engineering breakout after using a friend's thermal imaging camera to analyze heat generation on a PCB I designed. The Lepton 3.5 can output absolute temperature data (Radiometric) at 160x120 pixel resolution. I decided a thermal imaging camera would be a good tool to have and decided to build my own. I have started with a Teensy 3.2 based test platform but eventually want to turn a Beaglebone Black with 7" LCD cape into a full-featured, networked, camera using the PRUs to handle the real-time video SPI feed from the Lepton. I hope the documentation in this project is helpful to others who might also want to play with these amazing devices.

The long-term goal is to create a capable thermal imaging camera using the Beaglebone Black and a 7" LCD cape as the platform matching some of the features of high end commercial products.  However it soon became obvious that I'd need a simpler platform to learn how to use the Lepton module when I started reading the documentation and playing with the various demo codebases.  It is a very capable device with a moderately complex interface, both firmware and hardware.  Although the device has good default settings I found enabling some features wasn't well documented and the video SPI interface (VoSPI) challenging to implement due to its real-time constraints.

There are a lot of other great projects online to help get going with the FLIR sensors.  Pure Engineering is to be commended for making these devices available to makers and provides a wealth of code examples, many designed to work with the previous Lepton models.  Max Ritter's DIY Thermocam is probably the most mature and well known.  He has done a great job and I pored over his code.  Damien Walsh's Leptonic is also really well done and works with the Lepton 3.5 as well.  Both Max and Damien were very gracious when I sent them various questions.

I decided to follow Max's lead and build a test platform using a Teensy 3.5 that I had (selected for the multiple SPI interfaces and copious RAM).  Unfortunately after soldering the Teensy to a Sparkfun breakout board I stressed the processor BGA package and made the board unreliable.  So I replaced it with a Teensy 3.2 hoping it would have enough resources to successfully interface to the Lepton.  It does, barely, and the next project log describes the test platform hardware.


Test platform schematic

Adobe Portable Document Format - 26.67 kB - 07/10/2018 at 19:11


View all 18 components

  • tCam-Mini updates!

    Dan Julio11/25/2021 at 16:04 0 comments

    New Group Gets Campaign

    Group Gets recently introduced  the inexpensive Lepton FS, which is really a Lepton 3.5 that failed some tests.  It still works as a thermal imaging camera but its accuracy as a radiometric camera isn't guaranteed.  I played with one and my unit was pretty accurate at room temperature (perhaps its internal compensating temperature sensor wasn't working).  The modules identify as a Lepton 3.5 so work with the tCam-Mini FW just fine.

    Group Gets is having a campaign pairing a Lepton FS with a tCam-Mini for $129. My commission and their profit on these units is pretty much zero but the campaign is a good way to get an inexpensive thermal imaging camera.

    New Firmware

    Over the summer and into the fall I've been working on and testing new firmware for tCam-Mini and have posted it to the github and my website.  This version 2.0 firmware has support for the new hardware Slave IF necessary for tCam-Mini to be the sensor for tCam and several other good new  features.

    • Improved performance over Wifi - The camera can stream up to the full 8.7 FPS the Lepton is capable of putting out.
    • Support for Lepton 3.0 - The non-radiometric 160x120 pixel camera module is now recognized by the FW and handled properly.
    • Support for over-the-air firmware updates - After loading this new version via the serial interface, future updates can be sent from the Desktop application running on any platform.

    One note is that the new firmware will only run on tCam-Mini's with revision 3 ESP32 chips and at least 8 MB of Flash memory (e.g. the PCB version).  The increased memory is required to hold the multiple OTA firmware slots used by the ESP32.  Cameras based on the TTGO development board can't be upgraded beyond FW 1.3 but will remain compatible with future versions of all my supporting software.

    In addition to the firmware source now on github, there are precompiled binary files, instructions and the necessary Espressif Windows utility in github and on my website.

    I will document the new hardware Slave IF soon.  In addition to use with the tCam firmware running on the gCore hardware (also soon to be documented), I think it would be useful for other controllers like the Raspberry Pi which have traditionally struggled to keep up with the VoSPI interface. 

    Updated Desktop Application

    In addition, I've release version 2.0.0 of the Desktop application.  The primary feature is support for OTA FW updates but it also has several other changes.

    • Support for Lepton 3.0 - since the Lepton 3.0 doesn't support radiometric output the application suppresses all temperature displays and controls.
    • Added the ability to resize the main window.
    • Added three new color palettes - Banded, Black Hot and Sepia
    • Modified the FPS display to use timestamp information from the camera or video file and changed the averaging algorithm for a more accurate display over time.
    • Support the new Apple Arm Macs with a universal build - still have a separate x86 build for older versions of OS X.
    • Some internal restructuring and minor bug fixes.

    Built for 64-bit x86 Linux, 64-bit x86 Windows, 64-bit x86/Arm Mac OS X, and 32-bit Arm Linux (Raspberry Pi).  Available in the github repository or my website.

  • Finally! tCam = gCore + tCam-Mini

    Dan Julio10/06/2021 at 03:03 0 comments

    I am so happy to make this log entry.  It's been a long haul - probably much more time than I should have spent - but my final vision for tCam is coming together. 

    The hardware is based on a new version of gCore, my ESP32 dev board, which replaces the FireCam prototype I have been developing firmware on.  Aside from form-factor the main feature the new gCore brings is a much higher performance display which allows the full 8.7 fps frame rate.  It accomplishes this by using the ESP32's SPI interface running at its fastest rate of 80 MHz feeding a serial-to-parallel converter driving the ILI9488-based display through an 8-bit parallel interface.

    Adjusting task priority and SPI bus speeds, along with a larger checksum, has made the communication between tCam-Mini and the tCam firmware reliable.  The shutter control has become a physical button (not shown in the pictures here) which will be mounted in a yet-to-be-designed 3D printed enclosure along with the other electronics.

  • Dual ESP32 tCam - work in progress

    Dan Julio05/30/2021 at 20:27 0 comments

    About five days of coding and debug of the tCam and tCam-Mini firmware has yielded the first attempt at a higher performance version of tCam with the Lepton VoSPI pipeline and json image encoding being performed by the ESP32 on a tCam-Mini and the rest of tCam operation running on the ESP32 in the tCam prototype.  With mixed results.

    The two boards are connected using a serial interface (at 230400 baud) and SPI interface (at around 6 MHz).  Communication between the two boards is via the same json command protocol that is used over the network.  All packets, except image packets, are sent back and forth via the serial interface.  This allowed easy re-use of the command processing code.  The image packet (at about 52 kB) is too large for the serial interface and is read by the tCam ESP32 from the tCam-Mini ESP32 with a SPI interface after tCam receives a new "image_ready" packet via the serial interface.

    My main goal in splitting the processing between two ESP32 chips (four cores) was to improve performance and that seems to have been achieved.  I can now get over 7 fps on the tCam LCD display (up from 3-4.5 fps before).  The GUI update process is now the longest running activity per frame and limited, I think, by the maximum 26.67 MHz SPI clock rate of the HX8357 LCD controller.   The update process should be shortened, and fps increased further, by using a controller like the ILI9488 with a 40 MHz SPI interface.

    Unfortunately there is occasional data corruption in the image data transferred via SPI between the two ESP32s.  SPI Signal quality looks good (clean edges and plenty of setup and hold time) so I suspect that the tCam-Mini ESP32 SPI Slave can't always keep up (or there is some data corruption by the tCam SPI Master).  The ESP32 SPI Slave is a pretty simple device and comes with a lot of caveats.  For my scenario, where it only supplies data, I setup a buffer full of data, trigger the driver to start operating when it sees chip select asserted and wait for a callback from it indicating it's ready.  Then I send a short json "image_ready" packet via the serial interface which triggers the tCam SPI master to initiate the transaction.  The transaction is pretty long, typically around 52 kB.  It might be possible to try smaller transactions except each one will need a handshake via the serial interface which, at some point, will probably make it impossible to keep up.  A kludge might be to include a checksum and simply discard corrupt images but that seems like an ugly fix and will impact performance. 

    So unfortunately my initial experiment is of mixed success and there is more digging to do...

  • New Blackbody Radiator and Lepton Accuracy testing

    Dan Julio05/11/2021 at 17:49 0 comments

    Trawling eBay netted a reasonably inexpensive Accuthermo FC100D TEC (Peltier thermo-electric cooler) controller mounted in an enclosure from Wells-CTI with a 12VDC 8A power supply and TEC H-bridge driver.  The FC100D uses PWM and bi-directional control of the TEC along with a NTC temperature sensor to provide precise temperature control (heating and cooling).  I used a 12V TEC sandwiched between an aluminum block (with a hole drilled in it for the NTC temperature sensor) and a CPU cooler heatsink with fan.  This setup can be controlled between 10-60°C.  The front surface of the aluminum block was coated with Black 3.0 paint to form a high-emissivity black body radiator.  Unlike the IVAC9000 this radiator can be adjusted to specific temperatures.

    Temperature Readout Script

    Previous testing (two log entries ago) revealed how the Lepton’s radiometric output varied for the first approximately 30 seconds after a flat-field correction.  Using the python library I wrote a simple script that triggers a FFC, waits 45 seconds and then averages approx once/second spot-meter readings over the next 90 seconds to create an average temperature reading for use in determining a Lepton’s accuracy and linearity over a temperature range.

    I also removed the potentiometer from the IVAC 9000’s high-side because it caused too much temperature drift.  The IVAC9000 is now my temperature reference at 26°C and 38°C.  Using the new script produced the following results using two cameras with a distance of 15 cm between the camera and the radiator.  I made several runs with each camera at each temperature to check the repeatability of measurements after a FFC.  Camera tCam-Mini-B132's emissivity = 1.0, tCam-Mini-CB49 emissivity = 0.97.

    CameraIVAC9000 temp

    The longer average values show fairly low deviation between runs (each run takes over two minutes) and the average accuracy of the Lepton is pretty high (operating at room temperature).

    Comparing new radiator with IVAC9000

    Next I adjusted the new black body radiator to 26°C and used the same cameras to measure its output using the new script so I could get an idea of the accuracy of the FC100D and its temperature sensor.   Several runs were done again.


    Averaging all runs showed that the new radiator runs less than 0.5°C lower than the IVAC9000 unit at 26°C.

    Measuring Lepton accuracy across a series of temperatures

    Finally I ran a series of readings with two cameras at 10, 20, 30, 40, 50 and 60°C and plotted both the individual averages to look at variability and then an average of averages to look at a highly averaged accuracy.



    Plotted data

    I think the results are good news.  The Lepton appears, at least over this temperature range, to be linear device amenable to a two-point calibration (gain/offset).  Up next is to decide if a calibration is best applied to radiometric data once it’s been read from the Lepton or if it can be applied to the Lepton’s internal calculations using its RBFO parameters.

  • Updated tCam-Mini firmware and Desktop App

    Dan Julio05/01/2021 at 21:46 0 comments

    Working on tCam required changes to the Desktop Application to support file transfer.  In addition there are some new commands and responses that I just added to tCam-Mini as well.

    The github repository has been updated and the files are also available for download from my website for people who don't want the entire github repository.

    tCam-Mini gets the following new commands and responses

    • run_ffc - Triggers a Flat Field Correction in the Lepton.  I plan to use this for data collection while reading values for calibration but it can be used anytime a FFC is desired.
    • get_lep_cci/set_lep_cci - a generic mechanism to access the Lepton's CCI registers via I2C.  I think this might be useful for anyone who wants to explore the Lepton's Command Interface (within reason - it's easy to crash the Lepton or camera, for example by disabling the VSYNC signal).   These commands generate a new cci_reg response.
    • cam_info - a generic response message that is used to carry things like acknowledges for other set commands or can be used by the camera to indicate a problem.

    tCam-Mini also got a small performance boost by moving a buffer out of PSRAM into the faster ESP32 local memory.  I can sometimes get over 8 fps on my unit with an external antenna now.

    The application got a bunch of new features.

    • Ability to download files from tCam and a preference for a default folder for all image files (whether downloaded from tCam or created by the application).
    • A FFC button on the main window.
    • A new log window that can be displayed to watch the json packets going back and forth between the application and camera.  It's useful for me while debugging and I figure it might be useful for people who want to create their own software to communicate with the camera as they can see the contents of the json commands.
    • A new CCI Register access window to allow reading and writing Lepton CCI registers (and executing run commands).
    • A couple of bug fixes.

  • Visualizing the effect of a FFC on temperature data

    Dan Julio04/28/2021 at 15:35 0 comments

    The Lepton closes its shutter, performing an action called a Flat Field Correction (FFC), occasionally as part of its non-uniformity correction (NUC) to generate a uniform output compensating for temperature changes, pixel variation and lens effects.  Closing the shutter exposes all pixels to a uniform temperature so the NUC algorithm can generate calibration offsets for each pixel.  A FFC can be triggered manually but is usually performed automatically by the Lepton based on several inputs including ambient temperature changes since the last FFC and a 3 minute timer.   Without a periodic FFC, drifts in the output values of each pixel cause increasing temperature error measurements and degradation of visual images over time.

    All very good except that there is a noticeable change in the absolute radiometric temperature data after a FFC as shown below.   The graph shows the output of the spotmeter measured once per second over a 10 minute interval while imaging the 26°C IVAC black body radiator.  The FFC operation, occurring every 3 minutes, is clear.

    The change is less than the specified accuracy of the Lepton but still significant if one wishes to improve on that accuracy.  I found two interesting pieces of data in this experiment.

    1. It takes about a minute for the Lepton to settle down after a FFC so this time constant should be used when collecting data for calibration.
    2. Outside of the period after a FFC the Lepton appears to hold about a 0.5°C precision. 

    The second item has me considering a modification to the tCam firmware to show something like a green dot during the period of stability so users know when the radiometric readings are more stable and likely more accurate.

    Following are expanded (time axis) portions of the above graph showing behavior during the FFC and during steady-state.

  • tCam Progress

    Dan Julio04/24/2021 at 14:30 0 comments

    I have not given up on the goal of a full feature handheld thermal imaging camera with the features I want.  For the past several weeks I have had a chance to put significant effort into the original tCam prototype, now running on Firecam hardware because it has a 4-bit SD Card interface. 

    Most of the work has been adding filesystem support and the ability to save and playback both images and videos with file formats that are compatible with the desktop application.  In addition I added commands to allow the application to offload image files from the camera and remotely control it.  While there are still performance issues - especially when attempting to stream or record and display images - the camera is feature complete - at least with respect to the features I envisioned when I started this project.  I plan to do some experimentation with buffering in the tCam-Mini code to improve performance (and also backfit some of the new command features).  I’ll see if those help tCam but I suspect it will still be necessary to offload Lepton VoSPI capture to another processor for best performance.

    I am still contemplating the best hardware design for the final tCam camera but I plan to use this code with only driver changes.  The tCam codebase is about 24k total lines of C code, runs in seven FreeRTOS tasks and makes heavy use of the external PSRAM in the ESP32 WROVER module.  I did experience one of the ESP32 Revision 1 silicon bugs related to PSRAM access.  Very occasional data corruption (but repeatable, fortunately).  Replacing the strncpy library function with memcpy fixed the bug for me - probably because they have different instruction sequences.

    Here are the various GUI screens showing operation of the camera from control to file management and image/video playback.

  • [Finally] starting to look at accuracy!

    Dan Julio03/29/2021 at 18:56 0 comments

    One of my many goals with this project is to characterize the Lepton's performance and see if I can improve the stated +/- 5 - 10°C accuracy.  I have finally started to make some progress in that direction.

    The Black Body radiator is a gold standard for measuring an imager's performance and providing a known temperature for calibration.   Unfortunately, commercial units are often very expensive limiting their availability to hobbyists.  Fortunately older devices can be had - and repurposed - from places like ebay.

    A collection of very knowledgeable thermal imaging enthusiast exists on Dave Jones' wonderful eevblog website and a couple of them put me onto the idea of repurposing an old calibrator designed for in-ear temperature monitors.

    The IVAC 9000 probably sold, originally, for thousands of dollars but go for a fraction of the price in the used market.  It contains two radiators precisely temperature controlled using Thermoelectric Controllers (peltier) at 26°C and 38°C.  The user plugs a cable into the battery compartment of the thermometer and sticks its tip into a plastic receptacle in front of one of the radiators and the device will read the thermometer and upload appropriate calibration data.  The two temperatures are picked for calibrating a device designed to measure human temperature but aren't really far enough apart for a thermal imaging camera visualizing a much larger range.

    The radiators are made up of two blocks of aluminum with the TEC sandwiched in between.  The front block is painted with a very high emissivity (0.97-0.99) paint and contains a thermistor.  The IVAC 9000 controller uses an H-bridge to control heating and cooling of the TEC to maintain a very precise temperature. 

    Originally I was going to try to replace the controller with my own but another smart hacker experimented with simply adding a series resistance to one of the thermistors to trick the existing controller into maintaining a different set point.  Using a multi-turn pot allows dialing in a higher temperature on the "high" side of the unit.  Unfortunately adding a parallel resistor to the "low" side thermistor didn't successfully result in a lower temperature so there's probably some limit in the firmware or the physics of cooling the low side.  I decided to take this tact as it was MUCH easier and to also add a precision temperature monitor that I could access remotely via Bluetooth for use in a calibration process if possible.

    I stripped off the front panel to get a view of the entire radiator (the two circular regions in the photo above) and put the old control panel PCB inside the unit.  The temperature monitor goes in front.  My unit can sustain 26 and 64°C as the two temperatures which, at least, is a start.

    Measuring some Leptons

    With the unit up and running it was time to see how some Leptons performed.  I took some quick readings of two tCam-Minis, the tCam prototype and a Flirone Pro connected to my phone.

    All cameras were placed about 10cm from the radiator with the spotmeter in the center of the image aimed at about the center of the radiator.  Emissivity for the tCam cameras was set to 0.97 and the Flirone Pro set to "Matte" (they don't give the user precise control over the actual value).   The cameras were running for at least 30 minutes before taking a measurement.

    CameraLow-side (26°C)High-side (64°C)
    Flirone Pro26.767.2

    Exciting to finally get data and to see it make some sense.  All the cameras were well within the specified range but it will be interesting to see if a calibration can be figured out.  To do that will may take the ability to more easily measure at a larger range of temperatures and to that end I'm also working on another radiator using an off-the-shelf TEC controller.

    First distance...

    Read more »

  • Laser-cut front/back plates for tCam-Mini

    Dan Julio03/29/2021 at 02:40 1 comment

    A super simple set of SVG and DXF drawings have been uploaded to my github that can be used on a laser cutter to cut a pair of front and back plates out of a piece of plastic.  They can be mounted with ~8mm stand-offs for the front plate and ~5mm/ stand-offs for the rear plate.

  • Rev 2 PCB testing

    Dan Julio03/11/2021 at 19:19 0 comments

    I received and tested the Rev 2 PCB design.  The very minor revision was an attempt to improve Wifi performance and make it easier to mount the LED.  As shown below Wifi performance is about the same.

    I tested Wifi performance with three setups.  One with the tCam-Mini acting as an Access Point and my laptop connected to it in the same room.  A second with tCam-Mini configured as a client connected to a OpenWrt router in the same room and a third with the camera configured as a client connected to a Netgear router in a different room.  I streamed data for three minutes to compute an average fps and I ran each test twice.  The average values are shown below, including a board with an external antenna.  There is some variability, even with three minute runs, due to Lepton FFCs that occurred while measuring.

    SetupRev 1 - internal antennaRev 2 - internal antennaRev 1 - external antenna
    Access Point4.36 fps4.48 fps5.94 fps
    Client -  OpenWrt router4.68 fps4.19 fps6.34 fps
    Client - Netgear router4.86 fps4.89 fps6.05 fps

    Clearly an external antenna improves performance.  Interestingly the Netgear router in another room performed better than the Openwrt (fairly old mips-based chipset) in the same room.

    Firmware Revisions

    Rev 1.2 firmware fixes two issues that have come up during testing and board bring-up.  The first was a bug where the board would not connect to an AP if its first attempt failed (it would reconnect later with no problems).  The second was a hardware issue where I found the Lepton was not being left in a good condition if its external crystal oscillator took too long to startup.  I found this testing alternate crystals since currently the crystal I specified is unobtanium. 

    I have an idea about how to improve the camera's performance in firmware.  Right now a single task handles converting the Lepton data into a json string with Base64 packed data and pushing into the ESP32's network stack for transmission.  If pushing the data causes the task to block then I may be able to increase performance by splitting the process into two tasks so the next frame can be converted to a json string while the previous frame is loaded for transmission.

View all 37 project logs

Enjoy this project?



sullivan wrote 08/09/2021 at 18:53 point

Hi Dan. Love the project. I have been playing with a Lepton 3.5 on the breakout board 2 and Raspberry Pi 4B. The thermal images I am getting are in the range of 8300, not the radiometric, T-linear mode I am expecting. Do you get images in the 30000 range where the formula: T(degC) = pixval/100 - 273.15? If you are also in the range of 8300, how are you converting to temperature? Thanks in advance for the advice.

  Are you sure? yes | no

Dan Julio wrote 10/06/2021 at 03:15 point

Hey Sullivan, I'm so sorry for this tardy reply.  For some reason I no longer seem to get notifications when someone posts here.  Are you sure you're switching the camera into radiometric mode with TLinear?  If so then what gain level is your lepton running at?  In High gain mode the resolution is 0.01° which means the data is in the 30000 range (e.g. 25°C -> count of 29815) but in Low gain mode the resolution is 0.1°C (25°C -> 2981).  In my cameras I set Radiometry, Radiometry TLinear, AGC Calcs all true.

  Are you sure? yes | no

leoshmu wrote 01/12/2021 at 03:23 point

Thank you for this excellent project. I am curious about pushing the limits of frame rate. Are you able to achieve a full 9Hz frame rate on the thermal video stream, or do you find that the frame rate is limited to less than 9Hz in practice. Could you imagine getting 2 leptons integrated together and offsetting the thermal stream so that they are off by 55ms, allowing for a combined 18hz signal? Perhaps something with a master clock circuit and then controlling each lepton separately based on the clock timing? Also I'm curious, why do you prefer the pure thermal board to the lepton v2 breakout board? 

  Are you sure? yes | no

Dan Julio wrote 02/04/2021 at 03:26 point

Hey Leo, thanks for the kind words.  I have been able to achieve the full 9Hz frame rate using the Beaglebone's PRU (in AGC mode) and with the ESP32 (both radiometric and AGC modes).  With the ESP32 I more-or-less dedicate one of the two CPUs to getting data out of the Lepton (and I use the VSYNC signal).  I will shortly be posting the code for tCam-Mini which is capable of reading the full frame rate (but not quite capable of sending that frame-rate over the WiFi).

Regarding your interesting idea of using two devices:  I'm not sure how to synchronize them.  I think there is a lot of internal processing that ends up affecting when the device is capable of sending a video packet - and things like a FFC also impact its ability to output a valid frame.  I suspect - but have no proof - that it is capable of a higher frame rate but held back in firmware (the sensor response time seems to be around 50 mSec).  I'm not up to it but I've wondered if someone could hack it.

I like the pure thermal board because it's smaller - I don't think there are any performance related differences.  Now, with tCam-Mini, I'm moving to directly mounting the sensor on my own boards.  

  Are you sure? yes | no

Ailsamly wrote 08/18/2020 at 10:30 point

Hi Dan,

I also plan to build a small thermal camera with a  suitable thermal sensor module, I want to connect it to a mobile platform and do building inspection (like water damage and air leakage and other thermal anomalies) .  The thermal sensor will be 5-10cm in front of the wall. I want to follow Max Ritter's project DIY-Thermocam. But I am not sure whether the resolution of Flir lepton can fulfull the requirements of mine. Do you have some ideas? Thank you!



  Are you sure? yes | no

Dan Julio wrote 12/26/2020 at 19:11 point

Hello Leyuan, I apologize for this tardy reply.  For some reason I never saw your post.  I think the Lepton should work from a distance of 5-10 cm.  However I can't answer your question about the resolution as I'm not sure what the characteristics of the things you are looking for are.  I can only suggest seeing if you could borrow a camera from someone and do some experimentation before committing to your own build.  Good luck though!  Sounds like a cool project.

  Are you sure? yes | no

Richard wrote 05/30/2020 at 16:15 point

Hi Dan,

According to Flir's datasheets, the Lepton uses 3.0V for IO functions, but the Teensy's on board Vreg runs at 3.3V. Did you do any level translation on the VOSPI and I2C interfaces or modify the Teensy to run at 3.0V, or just put 3.3V on the buses? I'm about to start a Lepton project of my own and want to be sure I don't kill my expensive sensor!


  Are you sure? yes | no

Dan Julio wrote 05/30/2020 at 16:49 point

Hey Richard,

You're right, they specify a 2.8-3.1 volt VDDIO.  But they also specify that the maximum on an IO pin is the lesser of VDDIO + 0.6 volts or 4.8 volts (table 18 - Absolute Maximum Ratings).  The Pure Thermal breakout boards have a 2.8 volt regulator feeding VDDIO so the maximum input voltage should be 3.4 volts.

To be honest I didn't pay attention to this spec when I first started.  I saw that the Pure Thermal boards were used with many different 3.3V SBCs so I jumped right in.  It wasn't until later I saw the specs you are referring to.

Although it doesn't seem like good engineering practice, I have run several Lepton 3.5 modules for long periods of time and this does not seem to change their functionality.  One could design their own breakout board for the Lepton and provide 3.1 volts to VDDIO which would lessen the over-voltage condition even more or provide resistor dividers on the SCLK and CSN signals (and pull SDA/SCL to the VDDIO rail).  As I work on what I hope is my final thermal imaging camera I am contemplating a full custom PCB (eliminating the breakout boards) and this is probably what I'll do, especially after your timely email :-)

  Are you sure? yes | no

Avi Cohen wrote 11/14/2019 at 11:45 point

Hi Dan, 

Is the code open to download?

  Are you sure? yes | no

Dan Julio wrote 11/14/2019 at 17:09 point

Hey Avi, 

yes, it's in the github repository.

  Are you sure? yes | no

Sophi Kravitz wrote 07/10/2018 at 17:21 point

hi Dan! This is a cool project! This is happening pretty soon:

  Are you sure? yes | no

Dan Julio wrote 07/10/2018 at 18:09 point

Hi Sophi!  I saw that.  I'm not sure I'll have anything for the Lepton 2.5 but I will contribute a port of FLIR's LeptonSDKEmb32OEM library for the Teensy which might be applicable to the ESP32.

  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