Flir E4 Thermal imaging camera teardown

[joe-c]

After fiddling around with my LA on the FLIR i got it to work with the USB/RS232-converter, Baudrate is 38400. It seems the cam just responds to the commands if sent twice, dont know why ...

With Telnet a command just ends with (char)13, but while using Uart you have to send (char)13 as start byte and also (char)13 as end byte.

[mikeselectricstuff]

After fiddling around with my LA on the FLIR i got it to work with the USB/RS232-converter, Baudrate is 38400. It seems the cam just responds to the commands if sent twice, dont know why but it isnt such a problem cause i gotta poll the answer from the FLIR anyway. Gotta look if i find a nice small enclosure for the modded cam. 

I never noticed that when I was playing - what FW version are you using?

[Garfield]

With the hack does it increase the E4 thermal sensitiviely from 0.15c to 0.06c?

AFAIK nobody has figured out the exact reason for the sensitivity difference in spec between E4 and E8 (if any) - could be sensor differences, could be more accurate calibration. I don't think any reference to it has been found in any of the config files.

Hello,

I think the E4 has the same thermal sensitivity like the E8. But on the E4 was a "noise generator" enabled with the value of 150... this seems to be a thermal additional noise for each pixel. If you use a stock E4 and deactivate the noise generator you'll get a clean image.

So the hack does not incase the thermal sensitivity... he prevent only the deterioration of your thermal image.

Thanks joe-c

[Echo88]

Indeed joe-c, one needs to send CR before and after each command via UART, now it acknowledges every sent command 

[Fraser]

For those with a general interest in thermal imaging cameras and what lives inside the case, I have just done a quick teardown of the NEC AVIO F30 compact thermal camera.

https://www.eevblog.com/forum/testgear/thermal-camera-teardown-nec-avio-f30-compact-camera-aka-mikron-mikroshot/msg512006/#msg512006

Aurora

[Echo88]

The communication with the FLIR did work with my program, but i recognized that the FLIR tends to lose communication over RS232 after about an hour and doesnt respond (by program and simple terminal-program) till completely restarted. Also the responsetime of the FLIR is a little bit slow with about 300ms (also gotta expect the minutely calibration which stops the rs232-answers for the time).

I stopped using the UART to get the min/max-temps and instead im using an OCR-algorithm to extract the temps from the videostream in realtime. Also i did extract the pseudocolor-palettes to get my own pseudocolorstream without relying on the FLIR for this.

[sofisticated]

Maybe my question is boring but I should ask. Is there any hope for E4 firmware 2.3? Today I received mine and all fun halved when I see frmwr 2.3. 

Hello to everyone by the way.

[mikeselectricstuff]

Maybe my question is boring but I should ask. Is there any hope for E4 firmware 2.3? Today I received mine and all fun halved when I see frmwr 2.3. 

Hello to everyone by the way.

There's always hope.... the problem is there are now far fewer people interested in working on it now that we all have early versions.
There are still plenty of avenues to explore & I'm sure there's a way....

[SalsaShark42]

I think I'm going to take a crack at 2.3.

So far, I haven't seen any serious / documented attempts.

Does anybody know if the key is hard coded or not? Not sure how easy disassembling the comparison routine will be...

[mikeselectricstuff]

I think I'm going to take a crack at 2.3.

So far, I haven't seen any serious / documented attempts.

Does anybody know if the key is hard coded or not? Not sure how easy disassembling the comparison routine will be...

If I were looking at it, I think the first approach would be to figure out how an old  unit that was upgraded during repair was still able to be hacked ( see a few pages back) if you can convince the SW it's running on an older unit, that may be a potential way forward.

[joe-c]

I stopped using the UART to get the min/max-temps and instead im using an OCR-algorithm to extract the temps from the videostream in realtime. Also i did extract the pseudocolor-palettes to get my own pseudocolorstream without relying on the FLIR for this.

this sounds really interesting. Why you do this?

Btw... the temperatures you grabbed are not the real high and low of the thermal image.
The measurement box gets the real min and max inside the image... the values in the scale shows you only, from who to who the pseudo color was translated from the temperatures. This values are near... but not the same... see attachment.

But it's a real interesting thing to do it that way... and it's even faster than the UART/Telnet connection.

Maybe it's possible to change some things in the Scale settings to get this more accurate...
.image.contadj.autoAdj.TSpanMin                       4
.image.contadj.autoAdj.TSpanMinAuto                   8
.image.contadj.autoAdj.filterParam                  0.5
.image.contadj.colDistr.filterParam                    1
.image.contadj.colDistr.linearPercent                100
.image.contadj.colDistr.plateauPercent               100

[Echo88]

Hmm interesting, do you get the real pixel-temperatures by getting the raw-image from the jpg? Is there a possibility to extract the real temperatures from the pixels in the livestream? At the moment im gonna work on my stereo-cams so the thermalcam-stuff gotta wait for a few days. 

[TurboTom]

If I were looking at it, I think the first approach would be to figure out how an old  unit that was upgraded during repair was still able to be hacked ( see a few pages back) if you can convince the SW it's running on an older unit, that may be a potential way forward.

Hi there -

I've been lurking around this forum for some time and also own a "pimped" E4 (originally with a 1.19.8 on a 1.1 H/W) but this topic now convinced me to sign in and report my findings. Being the type of guy who loves to play around and experiment with these things on one side and somewhat a perfectionist on the other, I always got a little annoyed about the fact the flirtools still recognized my "E4++" as an E4 and also tagged the downloaded images as such.

This made me experiment with the service menu and the eeprom settings where I finally was able to change the camera into a "real" E8. Now I couldn't resist to use the software update function of flirtools to update the code to 2.3.0 (we've got a -pimped- 1.22.0 at work which seems to utilize the calibrating shutter much less frequently than mine which goes through this procedure annoyingly often, so I expected a F/W update to change this) and the worst thing that could happen (in my opinion) would be that I cannot take the way back anymore. Having bought the camera inexpensively (well, sort of...) second hand, I wouldn't have to bother about losing its warranty anyway.

Well, to cut a long story short, the update procedure went through but upon the final reboot, I got an error message that the update was unsuccessful. Strange thing, since the Camera is running okay (with the menus of a stock E8) and reports a F/W 2.3.0 in the on-screen sysinfo. In the config files, it's tagged as a "2.3.0*". It still reported errors in the FlirInstallNet's "check installation" function but I got that sorted by manually copying the appkit.rev and prodkit.rev files from the update container to the installation directories.

The files are not encrypted or in any other way scrambled compared to the 1.19.8 original configuration. So I assume that the encryption mechanism is either related to a hardware change or it lies burried deeply in the operating system files (maybe in the bootloader??) that cannot be replaced easily by a firmware update.

I don't know if this information helps getting closer to the point but having benefitted so much from all your work here, I think it's only fair to try to contribute something in return.

Cheers,
Thomas

[mikeselectricstuff]

I suspect the latest FW has a "legacy" mode that can use older config files if it thinks the hardware is older. It could even be a simple as looking for serial numbers below a certain point, however it could also be something more involved, using the eeprom and/or bootloader.

 

[joe-c]

Hmm interesting, do you get the real pixel-temperatures by getting the raw-image from the jpg? Is there a possibility to extract the real temperatures from the pixels in the livestream?

No... this image shows only the live image from the Camera. The mbox 1 was set to full screen and the Values could get with:
rls .image.sysimg.measureFuncs.mbox.1.maxT
rls .image.sysimg.measureFuncs.mbox.1.minT

but this Screenshot shows only, what the Camera LCD shows.

And yes... it should be possible to get the real temperatures from live stream. Maybe with a change of the facet_Z3.rcc there the values was shown as a binary pixel line at the side... this is maybe a better way to recognize the values and let you see more from your image... but this is a huge change.

I now was not able to get values like the Spot temperature... because I don't know  how get values from resource tree without a working sample.
There was a commented function...but this wont work.

[TurboTom]

I suspect the latest FW has a "legacy" mode that can use older config files if it thinks the hardware is older. It could even be a simple as looking for serial numbers below a certain point, however it could also be something more involved, using the eeprom and/or bootloader.

Mike -

what actually makes me believe that the secret lies hidden in the bootloader is that this seems to be the only portion of the code that apparently hasn't been changed by the update procedure -- at least it hasn't a date tag and all the others are now tagged significatly after the manufacture date of the camera:


Camera Name    Part #    Serial #    Date
FLIR E8    63901-0101    63909xxx    2013-12-03

HW-id hwtype    System UID
Z3    C358E202000xxxxx

Kits Name    Version    Date
SW combination   2.3.0
appkit   2.1.2   23-May-2014
userconf   E8 1.1   25-Oct-2013
ASCO OS image   18.1.20   2014-06-05
prodkit   0   28-Feb-2014

Calibration Name    Date
org    2013-12-03 13:23:30

Hardware Name    Part #    Revision #    Serial #
camcore   T198304   01   6380xxxx
detector   *   *   *
mainboard   T198283   10   2003xxxx

Firmware Name    Version    Date    From
IRDM   0.0.1.0   -   -
POLLUX   0.1.0.0   07-Apr-2014   FLIR
POLLUX_FPGA   8.7.0.0   -   FLIR

Software Name    Version    Date    From
AppCore   25.0.0.1   22-May-2014   upalmer@SE-BRYGG5/ALPHA_1.12
AppServices   25.0.0.1   16-Apr-2014   upalmer@SE-BRYGG5/ALPHA_1.12
Bootloader   16.0.4.0   -   FLIR
ResMon   25.0.0.1   03-Apr-2014   upalmer@SE-BRYGG5/ALPHA_1.12
WinCE   6.0.0.0   2005   Microsoft
appcore_dll   1.12.1.1   03-Apr-2014   upalmer@SE-BRYGG5
common_dll   1.12.1.1   29-Apr-2014   upalmer@SE-BRYGG5
facet_core   25.0.0.1   22-May-2014   upalmer@SE-BRYGG5/ALPHA_1.12
facet_ui_qml   25.0.0.1   22-May-2014   upalmer@SE-BRYGG5/ALPHA_1.12
fvd   16.0.48.0   Apr 8 2014   upalmer@SE-BRYGG4

Usage Statistics Number of cold starts   64
Number of shutter operations   2057
Number of focus moves   0
Laser time (hrs)   0
Max. operating temperature (?C)   47.07
Max. operating temperature time   2014-08-02 00:09:36
Min. operating temperature (?C)   21.89
Min. operating temperature time   2014-02-16 11:53:36
Operating time (hrs)   44
Up-time (hrs)   0


Maybe someone could compare the package versions/dates with a 1.19.8 camera without the update applied. Unfortunately I didn't safe a screenshot of the configuration before I applied the update. This may give other hints what to address to understand the new locking mechanism.

Cheers,
Thomas

[f15h]

FYI
There is a source in Austria - which still has one pcs (Firmwareversion 1.19.8 and Serialnumber 63908584) on stock
 www.messgeraete-shop.at

[sofisticated]

Mine is a new one came with 2.3 firmware. I would share its data if it helps to understand what has been changed (I know that you are asking for older fw, maybe this also makes some help). I couldn't make a snapshot like you did (because of I'm very newbie to this). But i can write what I can see on screen when I go for "device settings>camera information" long press on right of middle button (usb RNDIS mode switcher)  and "version information" data tab. At that screen information quite similar to your snapshot with a few differences. Here I'm writing them (screen doesn't show any date nearby them, only versions).

IRDM                 0.0.1.0
POLLUX             0.1.0.0
POLLUX_FPGA    8.7.0.0
camcore             T198304-01-6382****
detector              *_*_*
mainboard          T198283-11-2020****
appkit                 2.1.2
confkit               E4 1.2L
osimgkit             18.1.20
prodkit               0
AppCore             25.0.0.1
AppServices        25.0.0.1
Bootloader          16.1.7.0
ResMon               25.0.0.1
WinCE                6.0.0.0
appcore_dll          1.12.1.1
common_dll         1.12.1.1
facet_core           25.0.0.1
facet_ui_qml        25.0.0.1
fvd                     16.0.48.0

Bootloader has suspiciously different number than yours (I think you only upgraded and old device with new 2.3, mine came with it in the package).
 I'm also adding the files version.rsc  and postlog.txt where you can find it at root of simply connected at usb as cam. It is listing some interesting data also.



 

[imau]

Thank you guys for your hard work!

I've purchased an used E4 with firmware 1.22.0. Owner was unaware about the hack and he sold because he wasn't using the camera.

Now my camera is modded successfully.


Now, I would like to enable video recording such as E8 does.

Is it safe to play with conf.cfc settings?

[luis garcia]

FYI
There is a source in Austria - which still has one pcs (Firmwareversion 1.19.8 and Serialnumber 63908584) on stock
 www.messgeraete-shop.at

Hi.
How did you manage to know the firmware version ? I cannot see anything in the website. I found this link on the site:
http://www.messgeraete-shop.at/de/Waermebild-Inspektions-Kameras/Waermebild-Kam.-Serie-Ex/Waermebildkamera-Flir-E4.html

[Tom9999]

  You can call up store ask for S/N that only way.

[luis garcia]

Apparently they do not sell to final customers.:-(

[sofisticated]

Dear Mike and Thomas,

I'd like to share what I've been discovered when playing with my new E4 fw 2.3.

It looks like activating RNDIS mode is blocked by new software at new devices. I tried many combinations while attempting to activation of usb connections but no result. I shot a video for my attempts; you can see it is not possible to activate by device buttons. Secret menu comes with 10 seconds pressing to medium button but usb mode is not selectable. Is there any way other than RNDIS usb mode to reach config file in the system? I was trying to edit config file manually as forum user vmp did on his 2.3 updated old device "https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg478554/#msg478554"

Here is video of one of my attempts
 

[bookaboo]

If you search through Mikes original hack you can enter RNDIS mode using flirinstallnet and the FIF files from Mikes earlier hacks.

[sofisticated]

Sorry for my ignorant warning. I've succeed as described by Mike's older posts. It has a connection and I downloaded conf.cfc from my device. But I couldn't get it deeper. ftool.exe comes as "Tail part 2 invalid" and with a blank .txt file generated. It looks like decription is not working as vmp made. I'm adding my conf.cfc here if anyone can use it for decription...