With how expensive thermal cameras are, why not build your own? This is the goal with which [Dan Julio] set out a while ago, covering the project in great detail. While the ultimate goal is to create a stand-alone solution, with its own screen, storage and processing, the TCam-Mini is an interesting platform. Using the 160×120 pixel FLIR Lepton 3.5 thermal sensor, and combining it with a custom PCB and ESP32 module for wireless, he created a wireless thermal camera called the TCam-Mini along with accompanying software that can display the radiometric data.
The project is available on GitHub, as well as as a GroupGets crowd-funding campaign, where $50 gets one a TCam-Mini board, minus the $199 Lepton 3.5 sensor. Not cheap, but quite a steal relative to e.g. the FLIR One Pro camera add-on module. Compared to the aforementioned FLIR One Pro, there’s a definite benefit in having a more portable unit that is not reliant on a smartphone and accompanying FLIR app. Being able to load the radiometric data directly into a desktop application for processing makes it a closer match to the professional thermal cameras which [Dan] states that he’d like to get as close to in terms of features as possible.
Recently [Dan] has also begun to further characterize these Lepton sensors, in order to see whether their accuracy can be improved from the rated +/- 5-10 °C. For this he repurposed an old in-ear thermometer calibration device. Along with tweaking the ESP32 firmware, there is still a lot that can be done with the TCam-Mini, but it sure looks like a fun project to tinker with if one is into Leptons.
Another good reason to build your own is that the official FLiR app crashes with older devices and when you report issues against it, you’ll get a reply that the older devices are unsupported.
FLIR support is atrocious. One of my first tasks at my current job was to integrate a FLIR thermal camera with an existing machine. Any questions took weeks of struggling to get an answer. I ended up burning many dozens of hours reverse engineering things that should have taken just a few hours. Unfortunately, because my solution worked, we’ve continued to use these FLIR cameras since. My guess is they only really care about their military cash-cow contracts and maybe high-volume commercial customers, and my employer usually only buys a couple per year so we don’t qualify.
It’s led me to push really hard to switch to Micro-Epsilon. Their cameras are good, their software is pretty good, and even if I would have done some of their I/O differently, you can get analog-outs and manual shutter trigger with just a small breakout box, which is a huge leap in capability over FLIRS for us. Another plus is that every single question I’ve put to their engineering team is responded to within a couple hours, and I don’t think they’ve taken longer than a day to get me an answer on even the most esoteric questions.
I would have leave a generous PCB grounding on the other side of the Lepton sensor.
Does it need to be Lepton 3.5? I’ve got a Lepton 2 module sitting around which should plug right in, but has different specs.
Statement of bias: I ordered one.
I asked the same question in the groupgets forum. The creator’s response was that the code as written only supports the 160×120 data blocks of the current Leptons. He has no intention of trying to support the older hardware, but since the code is posted it should be possible for someone else to tackle. While I haven’t verified that they are electrically the same, quick review of the github code made me think that if they are it would not be too difficult. A few things to consider:
– The current data transfer is for an array of radiometric true-temperature data. The older Leptons have fewer cells and are not radiometric. The data is encoded as as a JSON base64 string, so it should not be difficult to change the payload (I’d probably change the message type though, to avoid confusion).
– The viewer software is written for the current data format. This could be handled by:
1. Modifying the viewer software
2. Using a different viewer
3. Use the existing viewer, but fake the Lepton 3 data using the Lepton 2 data as a starting point (scale up by 2x, and “fake” a conversion to some true temperature data range.
Option 2 would probably be preferable. It looks like the current viewer is designed around the radiometric data stream. Just parsing the JSON messages and building a simple viewer would probably be easier (after all, you won’t have the true temperature data anyway, so many of the features of the current viewer don’t apply).
– I did not look at what changes would need to be made to the configuration and status messages.
I do not know if I will attempt the modifications. I have both an older lepton and a 3.5 that I got with a uvcam board. On the one hand, I’d be a lot more willing to risk the older lepton in some situations where I’m just looking for hot spots but the more I think about it, I don’t know if I want to give up on the idea of having true temperature data,
I’m curious what amount of lag this adds to the system in transmission of realtime thermal readout data.
Very cool stuff!
I’m not sure if you are looking for precise lag measurements (I don’t know how to measure precisely). But when I move my hand in front and watch the streamed image I’d say the lag is 0.5s to 1.0s.