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.
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?
Indeed joe-c, one needs to send CR before and after each command via UART, now it acknowledges every sent command
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.
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.
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....
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...
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.
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
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.
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
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.
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.
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
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
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.
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?
You can call up store ask for S/N that only way.
Apparently they do not sell to final customers.:-(
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
If you search through Mikes original hack you can enter RNDIS mode using flirinstallnet and the FIF files from Mikes earlier hacks.
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...