M5Stack T-Lite is a Wi-Fi thermal imager with the same MLX90640 IR array thermal camera found in the M5Stack Thermal Camera 2 Unit plus a 1.14-inch color display to visualize the results on the device itself.
Based on the ESP32-PICO-D4 system-in-package with WiFi and Bluetooth, the solution allows the user to access the 32×24 pixels thermal image either on the built-in display, or streamed to the local network or the cloud.
M5Stack T-Lite specifications:
- SiP – ESP32-PICO-D4 system-in-package with ESP32 dual-core Tensilica LX6 microcontroller with 448 KB ROM and 520 KB SRAM, 2.4 GHz WiFi 4 and Bluetooth 4.2, and a 4MB SPI flash
- Thermal camera – Melexis MLX90640 infrared (IR) sensor with 32×24 pixels IR array, range: -40°C to 300°C with +/-1.5°C resolution, FoV: 110°x75° (See datasheet)
- Display – 1.14 inch color TFT LCD with 240×135 resolution, ST7789v2 driver
- Expansion – 4-pin Grove HY2.0-4P interface (“Port A”) with I2C, GPIO, ADC, or UART
- Misc – Passive buzzer, SPM1423 PDM MEMS microphone
- Battery – 3.7V/160 mAh battery
- Power Supply – 5V @ 0.5A via USB Type-C port, AXP192 PMU
- Dimensions – 69 x 26.6 x 6.35mm
- Weight – 30.1 grams
- Temperature Range – -40°C to +85°C
The documentation only provides information about the hardware, although the documentation’s webpage does integrate a web-based firmware flasher that currently says “Current Product Don’t Have Test Firmware”. Having said that, I could also find the firmware’s source code to be built with Platform.io. The hardware is basically an M5StickC-Plus with an MLX90640 Thermal HAT so it should be programmable with UIFlow, MicroPython, and Arduino.
The M5Stack T-Lite thermal imager can be used for temperature detection warning, circuit temperature anomaly monitoring, non-contact temperature measurements, intrusion/movement detection, and visual IR thermometers.
The M5Stick T-Lite Wi-Fi thermal camera ships with a 20cm USB Type-C cable, a lanyard, and a user manual/quick start guide. It is sold for $79 plus shipping. The company also launched the ESP32-S3 version of their Atom controller with the AtomS3 development kit with a 0.85-inch display now available for $15.50.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
It’s interesting in that they assembled together inside a tiny box all the components I’m using on my Odroid-Go + MLX90640 thermal cam. The main problem with the ESP32 here is that it doesn’t have native I2C, so it must be done in software and is very slow. I looked at the code and they’re setting it at 100 kHz. At two bytes per pixel, and two images required (due to the checkerboard pattern), that’s about 3.6 images/s max (it’s still about twice what I’m getting). But it means lots of noise if you move even just a little bit.
It’s really missing a micro-SD reader I think, unless it’s possible to emulate a USB-storage device using the USB port and retrieve captured images, which would be nice (though I doubt it since the Pico-D4 doesn’t seem to support USB). I’m only seeing JPG being used to export images over the integrated WiFi HTTP server.
Overall that can be a great device for the price, but with some limitations. At the same price we can find other, more autonomous, devices with internal storage and twice the frame rate (but without WiFi).
ESP32 has hardware I2C which can run at up to 4 MHz clock.
Yeah, I’m not sure what he was on about. Perhaps esp8266, which doesn’t have he support for i2c
Interesting. On my odroid-go it’s using bit-banged i2c and it looked like the source code was doing the same, given that it was measuring loop count per millisecond and setting timings for each state. I should probably have a look at how it works on my board, in case I could speed it up to 1 MHz.
So I said some bullshit. I had already dropped that bit-banging code long ago. It turns out that the sensor is sometimes slow. Adding timers shows that sometimes it can take the approximate time of one extra frame to perform a transfer. I suspect that at certain moments when trying to download a subpage at the moment it’s about to get refreshed, there possibly is some locking or cancellation and retry.
Willy can I ask you a question about thermal imagers? If agree able read below.
What stops the heat sensor being used as a high speed angle variable scanner. Then the results used to simulate a interpolated image at high resolution?
The results being more pleasing to the eye. Yet yealding great thermal data recording point, over a bigger area at the scanner head.
Thank you
⛄🎀🎄🍑🤔
You should not move while taking a snapshot because it takes time to get an accurate measutement. I guess it’s due to low-frequency photos carrying very low energy, so you need to “charge” the thermal pixels. You can’t use them like a regular camera. For example it’s also apparently very frequent to have a small percentage of bad pixels in such sensors. The code used to retrieve a frame usually detects abnormal reads and will replace them with interpolation from adjacent pixels.
Thank you for taking your valuable, time to reply.
I’m most illuminated.
Again thank you.
🎄
TL;DR: T-Lite IR camera – nice affordable hardware M5STACK, but bad software options.
The M5Stack T-Lite’s $10 USD additional cost over the display-less M5Stack Thermal Camera 2 for the added 1.14 inch 240×135 color TFT LCD display seems reasonable ($80 vs $70). Remember, in unit quantity the MLX90640 32×24 110deg FOV sensor alone (like both M5STACK IR cameras have) costs $61.66 [1], while the MLX90640 32×24 55deg FOV sensor costs $56.25 [2].
However, the M5Stack T-Lite’s firmware source is hard to find and MicroPython-only tangled up with PlatformIO baggage. That’s not acceptable to me. Neither is the only other software option being a .bin blob rolled-up in an Easyloader .exe download which VirusTotal shows with 4/71 positive hits.
Agreed. Most often you’d like a list of source repos, a makefile, a toolchain and a list of prerequisites, and to run “make” while still being able to understand what’s happening behind the scenes. But nowadays most often projects turn to magic tools that do everything in your back in a non-reproducible way. When the build breaks, the vendor can only respond “I don’t know, for me it works, please try to reboot your computer”. Python and Arduino ecosystems are such examples (who never saw a pop-up in inkscape when invoking a plugin that started to fail after a pip install or python upgrade). PlatformIO seems even more complicated to me, for now I still have no idea how to use it even after reading a bit of doc.
What would be nice would be some user-friendly tools to ease dependency management (enumeration of installed and available, download etc), board management (soc, config, flashing etc), and the rest should happen in the developer’s preferred IDE/editor, using preferred SCM and just typing “make -j$(nproc) something”. Good integration with an existing IDE is okay but it shouldn’t be the other way around.