EEVblog Electronics Community Forum
Products => Thermal Imaging => Topic started by: jbtronics on November 25, 2024, 09:14:02 pm
-
Hello everybody,
Recently I bought a Tooltop ET692B thermal camera for 130€ from Banggood. It has 160x120 thermal resolution plus a visible camera for image mixing. In my opinion the image quality is fine, however the available color palettes are quite limited, and the firmware could take some polishing in general (but nothing too bad).
The biggest issue I see is that you need to change into a different mode manual if you want to measure temperatures above 120 °C. The contrasts are visible in the picture; however, all temperature readouts just show “over” then. Similar things happen in high temperature mode, when the temperatures are below 120°C, so it's really hard to do measurements in systems with very high and low temperatures combined.
The camera can save movies and images. The movies are as far as I saw it just a screen capture. The image JPEGs however can be loaded in a special program “IRImageTools”, where you can do analysis on them. The file JPEG can be opened in any image viewer and just shows the screenshot of the camera. However, in the IRImageTools you can show temperatures at any point, adjust color palette and mixing factor (even if the visible picture were not visible in the original picture). Therefore, these JPEGs must contain the raw temperature data and the complete visible picture embedded in the JPEG (similar to the FLIR R-JPEGs)
However, I could not find a description of this file format anywhere, so I tried to reverse engineering that format.
Hardware
I found a string in the JPEG file “HT-04D”, which pointed me that this thermal camera is manufactured by HTI-Instruments as HT-04D.
For some older HTI camera (the HtI HT-A1) there were some teardown and firmware dumps a few years ago (http://www.blog.zapro.dk/?p=469 (http://www.blog.zapro.dk/?p=469)) so I started analyzing these firmware dumps. However, it appears that the cameras back then could not save JPEGs with these extra data back then, so I needed to dump the firmware of my camera.
A teardown of the hardware (see pictures below) revealed hardware pretty similar to the HT-A1 and the HT-H8 (see https://www.eevblog.com/forum/thermal-imaging/hti-ht8-has-a-ht301-inside (https://www.eevblog.com/forum/thermal-imaging/hti-ht8-has-a-ht301-inside)) just with a different PCB (marked as HT-03 on the PCB, so it is probably used in different cameras with different thermal modules).
Like the other models, it features a Allwinner A33 processor, so I tried to get into the Allwinner FEL mode. I was able to do so by holding the SELECT/ENTER button, press power for 2 seconds, and then press it quickly 3 times, all while holding SELECT. Afterward you can connect via USB and the FEL mode will appear on the PC.
It appears that this mode is probably not too helpful however, as it is pretty low level and I did not want to damage anything, so I did not proceed in that direction and dumped the firmware images at Linux level.
Similar to the HT-A1 and HT-H8 the HT-04 has 3 test pads with an serial UART to which you can connect with 115200 Baud and you get a full UBOOT console and Linux root console when the firmware started. From there, it was easy to dump all partitions into files in the internal memory and copy it over to a PC.
Firmware
The firmware appears to be pretty similar to the dumps of the HT-A1. The main application that runs on the camera is here called “HT-04” and appears to be a modernized version of the HT-A1 software. The binary still contains symbols, so it is pretty easy to load it in ghidra and get a well-readable decompilation.
An interesting thing is that this firmware seems to contain an built-in upgrade mechanism, which loads a specially named file from storage on shutdown to update (parts) of the firmware. The HT-A1 did not have such a thing, this seems to be a thing which was just added in the last few years to the HTI cameras. I have not looked further into this update mechanism, but that could be an interesting method for firmware hacking without needing to tear everything apart.
File format
Another new thing in this firmware are the image with extra data export. I was able to find the relevant method for it and this is just a JPEG which features another JPEG with the visible picture after the end marker (so that is ignored by image viewers). Afterward the temperature data and some metadata come. Using the code and structures decompiled by ghidra, it was straightforward to write a small python library that can extract all this data, which can be found here:
https://github.com/jbtronics/IRImageParser (https://github.com/jbtronics/IRImageParser)
I found some sample pictures of the HT-19 thermal camera, which seems to have a slightly older software version than the HT-04, but a nearly identical format (just one metadata field at the end is missing, compared to the HT-19). So, this parsing library will probably also work with other HTI cameras, which can use the IRImageTools for analysis.
Outlook
In the Zapro Blog some firmware hacks (in form of binary patching) were discussed to patch in different color palettes. This should be possible here too, you just need to find the correct addresses using ghidra (which should not be too difficult).
Maybe its also possible to fix the “over” problem with the temperature modes. It seems that the over text is shown when the camera would read a temperature above a certain limit. This limit could be probably changed to always show the read-out temperature value. The temperature modes seem to switch the gain of the thermal imaging chip, so the question is how accurate these values would be (as I assume that it probably has a reason it is implemented the way it is).
-
Have you seen this review and teardown video ?
https://youtu.be/1gfy12S63ic?si=jfJwZWSDGBaiPBCb
Look at time index 16:55. The core is stated as an infiray Tiny1C which is normally a 256x192 pixel core. If the ET692B is configured as a 160x120 pixel camera, it looks like windowing is being used to artificially lower the resolution. The HFOV supports windowing is present....160/256 = 0.625. 56 degrees HFOV (Tiny1C256) x 0.625 = 35 Degrees HFOV (ET692B)
Your ET692B is effectively using a 256x192 pixel Tiny1C module in a x1.6 Electronic Zoom mode to reduce its available resolution by a factor of 0.625. This appears to be an option that Infiray offer on their Tiny1C.
Fraser
-
Your ET692B is effectively using a 256x192 pixel Tiny1C module in a x1.6 Electronic Zoom mode to reduce its available resolution by a factor of 0.625. This appears to be an option that Infiray offer on their Tiny1C.
Interesting. I did not know that. But as I understand the datasheet of the Tiny1C, the resolution (or this zoom mode) seems to be some kind of option chosen at buying time, so there is probably no (documented) way to switch between the resolutions.
Also, it seems that the ET692B is not interacting with the Tiny1C core directly but only via an FPGA board which converts everything to a USB interface, called HM-TM31 (or longer HM-TM31-3RF/T20240104AACHEA0978186) in firmware and logs. It has the VID 0x2BDF and PID 0x102, which is from hikvision? (hikmicro?) (also the IR APIs are all prefixed with HK_). I am not sure if that correspondents to some known Hikvision/Hikmicro USB thermal adapter.
-
I included some script in my file format library (https://github.com/jbtronics/IRImageParser), which allows creating Infiray IRG files from the HTI JPG format.
That way you can use the Infiray IR Discovery, or Topdon TDView software for data analysis. This software is not great, but has more features and color palettes than the HTI/Tooltop IRImageTools, so some might find it helpful.
-
I was able to hack the firmware in a way, that the camera also shows temperatures below 110°C in HIGH Temp range mode, and not just OVER. As the temperatures are contained in the output files I was already suspecting that this was just a display thing on the camera, and I found the relevant code section using ghidra in the /work/app/ht-04 file, where something like this happens:
int value;
if (((tVar1 == RANGE_LOW) && (0x5b8 < value + 0xf0U)) ||
((tVar1 = GetTempRange(), tVar1 == RANGE_HIGH && (0x1152 < value - 0x498U)))) {
str = "OVER"
}
This comparison between an signed and unsigned int also causes it that values too low are seen as "OVER", even with just one comparison. I am not sure if this intentional (I suspect that this is an optimized compiler construct) or not.
So to avoid triggering the "OVER" output, this comparison needs to fail. This can easily modify by changing the 0x1152 value. I used ghidra to find the relevant fiie addresses.
In the end you need to change the bytes 0xE794 - E797, 0xED54 - ED57, 0xEF24 - EF27 and 0xF0F0 - F0F3 (from beginning of the binary file) of the HT-04 file in a Hex editor. They should contain the bytes 0x52 11 00 00 in the original state, and that must be changed to 0xFF FF FF FF.
That way, the comparison should always fail, as nothing can be greater than this value. Afterward, I replaced the /work/app/ht-04 file with my patched version, and it works like desired.
I would expect that the temperature accuracy (for low temperatures) decreases in the HIGH temp mode as the sensor gain is decreased. However, at least at room temperature, the differences between the LOW and (patched) HIGH mode readings seems to be sub 1 degree Celsius, so that is probably fine. For around 2 °C you then get offsets of multiple °C, so you should be a bit careful at these temperature ranges.
I think the patch is still pretty useful, as it at least gives you a rough temperature estimate for the surroundings and not the meaningless "OVER" temperature reading.
-
I got a Black Friday deal on a HTI-18+ based thermal cam, so I was looking around to do fun things with the device and found this thread. Great work so far, jbtronics!! Your software also worked on the images my camera produced, which confirms your suspicion that the image format is shared among multiple models.
Anyway, I decided it would be fun to reverse engineer the update functionality to make modding/enhancing recent HTI thermal cams accessible to everyone. Updating turned out to be implemented be quite straightforward - the ht-18 executable looks for a file with the correct prefix in the virtual USB drive root (the camera model number, in my case "HT-18P", which is also one of the metadata fields jbtronics' image viewer displays) just before the camera turns off. This update file is an obfuscated packed container file in which the file data and their relevant destination paths are combined. The updater has root privilege, so you can (re)place files anywhere you want.
I've tried to make usage of the packer Python script straightforward - download the file, and create a "files_to_be_packed" folder in the script folder. There you place the files you want to transfer to the thermal camera file system. The filenames should be the full destination path + filename, but with '/' substituted for '#' (because Windows doesn't like '/' in filenames). Example: "#boot#bootlogo_20.bmp" overwrites the 20% boot image (permanently! Make backups before!).
The script has three parameters:
--device, which should be your device name (default "HT-18P")
--firmwareversion, which doesn't really matter as long as it's different from the current version (checked internally with a strcmp()) (defaults to the date of creation)
--filepermissions, which sets the Linux file permissions of the files you're transfering (default 777).
The source code isn't too complicated and well commented, so you can look there if you want to know the exact details of how the packer works.
The thing runs a barebones version of BusyBox Linux, so (with the Tiny1C SDK freely available via the Xintest website) is could be possible to write our own thermal camera interface software that is a bit less clunky, as the hardware is more than powerful enough (AllWinner A33 quad core with Mali-400 MP2 GPU, 512MB RAM and 8GB eMMC storage) to do really cool stuff.
I've tried to compile cdc-acm,ko to use the USB port as a serial device (so we won't need to solder wires anymore for a debug shell), but haven't succeeded yet (kernel config isn't available on the device, and matching the kernel object vermagic with the right kernel compilation options still results in a "insmod: can't insert '/mnt/cdc-acm.ko': invalid module format"). Does anybody know how to fix that?
-
Hi, great work - very interesting.
@jbtronics: may I get permission to change https://github.com/jbtronics/IRImageParser?
I did a skript based on your work. dev-gonso is my username in github.
The skript alignes the temperature ranges across all images within one folder. This is because it is much easier to compare the pictures.
Regards
gonso
-
does that mean you can unlock a ET692B to run at full resolution?