Flir E40 Upgrade & Configuration

[ElectroTuna]

in your config files I see
...

Thomas, sorry, I am confused. You are really familiar with the details of this stuff, but some of this stuff is foreign to me.

I was under the impression that Thermal Fusion will be an added option in the image type selection, and it won't replace MSX. After all, why can't you have both?

Unfortunately, I am still not sure which fields I must change to enable that... I don't know what 'rls' actually is.

As for calibration, I found a way (thanks to your comments) to read my cal files with Matlab. I plan to add a new 'dead pixel' to my cal file and hope that the camera will then remove that annoying dead pixel from my images. Once I am successful I will post a tutorial for that too along with everything else (and credit you as well of course).

[ElectroTuna]

Tomas,

Do the calibration image files have some kind of checksum? I modified the field for the deadpixel, but then I lose the whole calibration completely... I have to restore the original files before it goes back to normal.

 

[tomas123]

I was under the impression that Thermal Fusion will be an added option in the image type selection, and it won't replace MSX. After all, why can't you have both?

Yes you can have both, but do you need thermal fusion (feature junkie)?
simple edit the lines, as described above

Do the calibration image files have some kind of checksum? I modified the field for the deadpixel, but then I lose the whole calibration completely... I have to restore the original files before it goes back to normal.

please describe exactly, what do you have modified and the result of lost calibration

the is calibration of temperature parameters
   for details see my excel sheet here
   http://u88.n24.queensu.ca/exiftool/forum/index.php/topic,4898.msg27546.html#msg27546

12 edit temperature calibration values of E4 in /FlashFS/system/calib.rsc for improvement of measurement accuracy
https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg348622/#msg348622
https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg348703/#msg348703
the Excel sheet   
   https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg358979/#msg358979
   https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg350457/#msg350457

...and a bad pixel mapping

[Fraser]

Thanks to all for another very interesting thermal camera thread. I am a long term owner of an E4 but the comments on modifying the bad pixel map is of great interest in case it is needed in the future. I own a TEST 880-1 that has three dead pixels visible so I will be taking a look at that cameras software soon to see if its map is accessible. Different camera but hopefully the same principles fro dead pixel mapping.  Keep up the good work. 

Aurora

[tomas123]

Do the calibration image files have some kind of checksum?

alle config-txt-files have checksums

config files uses CRC32

sample in bash

Code: [Select]

a crc32 sample on command line
// count lines
$ wc -l FlashFS/system/calib.rsc
     801 FlashFS/system/calib.rsc

//print last line
$ tail -n1  FlashFS/system/calib.rsc
# CRC32 ef8f7e0e

//calc a new crc32 for 801-1=800 lines
$ crc32 <(head -n 800 FlashFS/system/calib.rsc)
ef8f7e0e

or search crc32 in https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown

[tomas123]

the comments on modifying the bad pixel map is of great interest in case it is needed in the future

Firmware_FlirE4
\FlashFS\system\calib.rsc

Code: [Select]

.calib.detector.deadPixMap entry
.calib.detector.deadPixMap.ds250C_we_ap_fi_le index
.calib.detector.deadPixMap.ds250C_we_ap_fi_le.fileName text "ds250C_we_ap_fi_le_static.gan"
\FlashFS\system\maps\ds250C_we_ap_fi_le_static.gan
use exiftool and imagemagick

Code: [Select]

>exiftool ds250C_we_ap_fi_le_static.gan
ExifTool Version Number         : 9.75
File Name                       : ds250C_we_ap_fi_le_static.gan
Directory                       : .
File Size                       : 151 kB
File Type                       : FLIR
MIME Type                       : application/unknown
Creator Software                :
Gain Dead Map Image Width       : 320
Gain Dead Map Image Height      : 240
Gain Dead Map Image Type        : TIFF
Gain Dead Map Image             : (Binary data 153804 bytes, use -b option to extract)

> exiftool -b -GainDeadMapImage ds250C_we_ap_fi_le_static.gan > 1.tif

>identify 1.tif
1.tif TIFF 320x240 320x240+0+0 16-bit Grayscale Gray 154KB 0.000u 0:00.000

> convert 1.tif -depth 8 1.png


the next step is tricky
see the exiftool documenation
http://cpansearch.perl.org/src/EXIFTOOL/Image-ExifTool-9.76/lib/Image/ExifTool/FLIR.pm

the embedded image is a 16 bit raw binary
exiftool add a tif header to the raw datas (uncompressed 16 bit tif)
the best way is to poke the additional bad pixels direct to ds250C_we_ap_fi_le_static.gan with a hexeditor
   - open the tif in an image editor and edit the additional pixels
   - save as (uncompressed) 16 bit tif (or use imagemagick convert)
   - find the binary differences of the pixels and poke them with an hexeditor to ds250C_we_ap_fi_le_static.gan

[Fraser]

@tomas123,

Thank you 

Aurora

[ElectroTuna]

Tomas,

I did exactly what you said a few days ago as well.

But there are some interesting additional issues:

1) In my 'map' directory, I have three files which the camera seems to use for calibration and bad pixel. One of them has the term '120C' and the other '650C' both with .gan extensions. There is also a third file, with a .dpx extension.
2) Flir Tools can open ALL these files and you can see dead pixels. I can also read them with Matlab or with a hex editor.
3) My .dpx file is identical to the '120C' file, but the '650C' file has much more bad pixels in it. It looks like the calibration matrix is difference when the camera is set to different temperature ranges. Although I am not 100% sure yet what the purpose of the .dpx file is.
4) I tried changing the field which corresponds to my bad pixel and modified it in all three files. But after I saved the files, the camera lost all calibration and many bad pixels showed up. I had to restore it back to original.

This is where I am now. So it seems there is more to it than just changing the fields.

In the EXIF documentation, I see the following:

Code: [Select]

    # set file type if reading from FFF or SEQ file ($tagTablePtr will not be defined)
    $et->SetFileType($type eq 'FFF' ? 'FLIR' : 'SEQ') unless $tagTablePtr;

    # FLIR file header (ref 3)
    # 0x00 - string[4] file format ID = "FFF\0"
    # 0x04 - string[16] file creator: seen "\0","MTX IR\0","CAMCTRL\0"
    # 0x14 - int32u file format version = 100
    # 0x18 - int32u offset to record directory
    # 0x1c - int32u number of entries in record directory
    # 0x20 - int32u next free index ID = 2
    # 0x24 - int16u swap pattern = 0 (?)
    # 0x28 - int16u[7] spares
    # 0x34 - int32u[2] reserved
    # 0x3c - int32u checksum
The last line hints at a checksum. Perhaps after 'poking' the dead pixel, a new checksum is needed, otherwise the camera assumes the file is corrupt and this destroys the calibration procedure. Had I not saved a backup of my calibration files, I would have ruined it.

[tomas123]

sorry, I forgot it because the checksum is ignored by flir tools and exiftools

as attachment the document for calculating the checksum

Code: [Select]

   unsigned long  dwChecksum;   /* Data checksum   4  32 bytes */

       dwChecksum is checksum of tag data block. It may be set to
       0 when not used.
       When used, 2 types of checksums are allowed:
       1) Type 1 for longword aligned data:
          dwChecksum & 0xC0000000 == 0x80000000.
          Checksum is calculated as the sum of all 32-bit longwords in the
          tag data block given by dwDataPtr and dwDataSize modulo 0x20000000
          or'ed with 0x8000 0000 (MSB always set, MSB-1 always 0).
       2) For possible odd number of bytes in tag data, algorithm 2 exists:
          dwChecksum & 0xC0000000 == 0x40000000.
          Checksum is calculated as the sum of all bytes in the
          tag data block given by dwDataPtr and dwDataSize modulo 0x20000000
          or'ed with 0x4000 0000 (MSB always set, MSB-1 always 0).
   */

but first try

Code: [Select]

"Checksum may be set to  0 when not used."
the different map file names comes from range:
E4 250 °C temp. range
E40 120 and 650°C temp. range

PS: on shell there is a interesting command

>ftest
usage: ftest [-q] [-n nr] [-e] [-x] [-i imageid] [-g groupid] [-s siteid]
           [-l 0|1] [-t <tag>:<subtag>:<rev>:<file>] [-j <file>] [-d <tag>]
           [-m] [-f] [-c <file>] [-r <x>:<y>:[e:]<file>] [-a <file>]
           [-v <file>] [-b <file>] <image1> [image2] ...
       -q   quiet mode, only print error messages (on stderr)
       -n   read file <nr> in seq file, or "iter" to iterate whole file
       -e   extract parts to file
       -x   extract each image in a sequence
       -i   replace EXIF image ID with <imageid>, "rand" creates new
       -g   replace EXIF group ID with <groupid>, "rand" creates new
       -s   replace EXIF site ID with <siteid>, "rand" creates new
       -l   replace stitchLast with 0 or 1
       -t   replace/add <tag> with data from <file> at revision <rev>
       -j   replace JPEG pixels with data from <file>
       -d   delete <tag> from file
       -m   force map stats calc on image
       -f   force loading by ignoring broken CRCs
       -c   create color JPEG <file> from FFF data
       -r   rescale to size <x>x<y> in <file> (add :e: for exact rescale)
       -a   resave using original format to <file>
       -v   save IR pixels as temp values as csv data in <file>
       -b   save image1, image2,... to seq <file> (.csq = compressed)

[tomas123]

Do have tried the service menu of E40?

http://192.168.64.1/service/index.asp
login: flir
pw: 3vlig

then activate Service Mode

there you can also map the dead pixel


PS: I never used the EEPROM unlock password: 1235

fast way to count the mapped bad pixel:

first convert ds120C_we_ap_fi_le_static.gan with exiftool and IM
then

Code: [Select]

$ identify -verbose ds120C.gif
  Histogram:       
     17: (  0,  0,  0) #000000 black
     76783: (255,255,255) #FFFFFF white
  Colormap: 256

[tomas123]

ah I see, that the current fw of E40 Late 2013 v4.9.0 has no service menu   

the important files for mapping bad pixels from old E40 FW 2.23.14

Code: [Select]

$ ls flir_exx_pn490_v2.23.14_update_pack/E2comb_v2.23.14.fif/FlashFS/system/web/service/ImgCorr
ActivateDigFilters.asp GainMapResult.asp Operability.asp StaticMap.asp StaticMapResult.asp
GainMap.asp GainMapSelCase.asp OperabilityLog.asp StaticMapCalc.asp StaticMapWarm.asp
GainMapCalc.asp GainMapWarm.asp PixKill.asp StaticMapCold.asp gainmapcalcGF.asp
GainMapCold.asp ImgCorrSelCase.asp ShutterMap.asp StaticMapPrepare.asp index.asp
see here for links to this files
https://www.eevblog.com/forum/testgear/flir-e40-upgrade-configuration/msg561542/#msg561542

you can simple read the html files of the old FW and make the same steps on the shell (setResourceValue = rset)

sample:
search for activating the service mode in Web GUI (file name HighRes.asp = full resolution  ):

Code: [Select]

$ cd flir_exx_pn490_v2.23.14_update_pack/E2comb_v2.23.14.fif/FlashFS/system/web
$ grep -i -r highres *
service/Diag/HighRes.asp:      restree.setResourceValue( "prod.preparation.command",  "restartHighRes" );
service/inc/servicemenu.inc: menuRow("Activate Service Mode", "/service/Diag/HighRes.asp", "submenu1", selectedMenu == "mnuDiagResolution");
service/index.asp:                    <FORM ACTION=diag\HighRes.asp METHOD="POST">
we get

Code: [Select]

restree.setResourceValue( "prod.preparation.command",  "restartHighRes" );and this is the same command on the shell

Code: [Select]

#start HighRes Modus
>rset prod.preparation.command restartHighRes
on the old E40 the command restartHighRes perform following 2 steps:
(1) copy service config files and folders from
     /FlashFS/system/service/appcore.d
     to
     /Temp/appcore.d
     and calculate a new CRC01 checksum for the copied config files (it's a integrated crc01 keygen  )
(2) boot Exx to full resolution over restartapp.bat

Code: [Select]

$ cat flir_exx_pn490_v2.23.14_update_pack/E2comb_v2.23.14.fif/FlashFS/system/restartapp.bat
set PATH=\windows;\FlashFS\system\;
rset .watchdog.enable false
rset .services.log.active false
ps -k Prod
ps -k prod
ps -k uicore
ps -k Gui
ps -k MediaServer
ps -k appcore
ps -k AppServices
ps -k Resmon
ps -k Bit
ps -k syslog
ps -k Cam
ps -k cam
ps -k geni
ps -k dig
ps -k Dig
ps -k watch
ps -k Watch
ps -k RTP
ps -k fwa
ps -k progress
ps -k Med
delay 1
start appcore
delay 10
start prodapp
Not all listed processes are running!

for better understanding of the restartapp.bat I will illuminate the Exx boot process:
(1) start the windows ce (NK.bin)
(2) over a windows registry entry CE starts the flir batch file FlashFS/system/applaunch.dat
(3) applaunch.dat start the appcore.exe
(4) appcore.exe start the Flir binaries  (like the Flir GUI)

after booting we get this process list

Code: [Select]

\>ps
Process NK.EXE          (87 threads), id 0x00400002, loaded at 0x88190000
Process udevice.exe     ( 1 threads), id 0x01550002, loaded at 0x00010000
Process udevice.exe     ( 2 threads), id 0x01630002, loaded at 0x00010000
Process udevice.exe     ( 1 threads), id 0x01F20002, loaded at 0x00010000
Process udevice.exe     ( 1 threads), id 0x03BF0002, loaded at 0x00010000
Process servicesd.exe   (18 threads), id 0x04030002, loaded at 0x00010000
Process cmd.exe         ( 1 threads), id 0x05000006, loaded at 0x00010000
Process appcore.exe     (35 threads), id 0x05530006, loaded at 0x00010000
Process AppServices.exe (17 threads), id 0x070D0006, loaded at 0x00010000
Process Resmon.exe      (12 threads), id 0x07260006, loaded at 0x00010000
Process MediaServer.exe (15 threads), id 0x07380006, loaded at 0x00010000
Process uicore.exe      ( 9 threads), id 0x07850006, loaded at 0x00010000
Process CMD.EXE         ( 1 threads), id 0x090C0046, loaded at 0x00010000
Process ps.EXE          ( 1 threads), id 0x04C1001E, loaded at 0x00010000
i.e. the command "ps -k uicore" from restartapp.bat kills the process uicore.exe


applaunch.dat old E40 FW v2.23.14

Code: [Select]

$ cat flir_exx_pn490_v2.23.14_update_pack/E2comb_v2.23.14.fif/FlashFS/system/applaunch.dat
# Show intro bootlogo and start progress
progressapp -f \flashfs\system\bootlogo.bmp
# Start command shell on the RS-232 port
cmd /R
# Register a default user
defaultusr
# Start appcore. Appcore starts other necessary processes
appcore

and now with some new CRC checks in FW v4.9.0 against hacking in E40 Late 2013

Code: [Select]

$ cat flir_exx_pn645_pn646_v4.9.0_update_pack/E2qtcomb_v4.9.0.fif/FlashBFS/system/applaunch.dat
# Show intro bootlogo and start progress
progressapp -f \flashbfs\system\bootlogo.bmp -d1
# Start command shell on the RS-232 port
cmd /R
# Register a default user
defaultusr
# Start appcore. Appcore starts other necessary processes
appcore

# doCRC FlashBFS\system\appcore.exe 1819648 214275933
# doCRC FlashBFS\system\common_dll.dll 1225216 3648436271
# doCRC FlashBFS\system\appcore_dll.dll 708608 3728193282
# doCRC FlashBFS\system\progressapp.exe 29184 4017170338
# doCRC FlashBFS\system\defaultusr.exe 5120 1997273047
# doCRC FlashBFS\system\chargeapp.exe 32768 1583842125
# doCRC FlashBFS\system\ui.d\design_ui_E2.xml 54099 4047603580
# doCRC FlashBFS\system\ui.d\facet_E2.rcc 861107 3311570564
# doCRC FlashBFS\system\ui.d\toolbar-config_E2.xml 6522 1692081231
# doACRC FlashBFS\system\appcore.exe 1819648 2566311456
# doACRC FlashBFS\system\common_dll.dll 1225216 1513280386
# doACRC FlashBFS\system\appcore_dll.dll 708608 3192873875
# doACRC FlashBFS\system\progressapp.exe 29184 3808303586
# doACRC FlashBFS\system\defaultusr.exe 5120 2154779382

@ ElectroTuna
Contains your FW 3.18.0 (E40 1.0) in applaunch.dat also the anti hack doACRC part??
If not, then you still have the web front end with the service menu and my explanation was unnecessary 

+++ticker+++ticker+++ticker+++

ATTENTION ALL USERS
the new firmware (1.21.0) is likely designed to hinder/stop the hack!

look for yourself - introduction of a new CRC algo ....

Code: [Select]

Applaunch.dat:
# doCRC FlashBFS\system\appcore.exe 1760768 3442989494
# doCRC FlashBFS\system\common_dll.dll 1193984 3567384037
# doCRC FlashBFS\system\progressapp.exe 27648 3868968713
# doCRC FlashBFS\system\defaultusr.exe 5120 784976136
# ID all
# CRC03 aad87665
... do I need to say more?   

PS: I like the "all" keyword there

PS: I hope you have now enough informations for understanding and hacking a E40 

[ElectroTuna]

Jesus Tomas! You should write a book!

I have the resolution enabled, the magnifying ability up to X4 (from X2) and I have turned the noise off. I still don't have that stupid Thermal Fusion. I will try a few other things.

I am also working on a simple way of injecting bad pixels manually and either regenerating the CRC or using that ignore CRC option.

I don't seem to have the files for the web access. I did use Telnet to connect to the camera and I do see the processes running with 'ps'.

[ElectroTuna]

These lines added to both config files did NOT enable thermal fusion:

.caps.config.ui.fusion.thermal entry
.caps.config.ui.fusion.thermal.enabled bool true
.caps.config.ui.fusion.thermal.auto bool true
.caps.config.ui.fusion.thermal.interval bool true
.caps.config.ui.fusion.thermal.above bool true
.caps.config.ui.fusion.thermal.below bool true

[ElectroTuna]

This is my header for my calibration file: (In hex)

Code: [Select]

46 46 46 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 64 00 00 00 40 00 00 00 0e
00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 02 5a 20 00 00 00 00 e0 b5 cc a1
00 05 00 02 00 00 00 64 00 00 00 01 00 00 02 00
00 02 58 20 00 00 00 00 00 00 00 00 ba de ee fe
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02 00 40 01 f0 00 00 00 00 00 00 00 3f 01 00 00
ef 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Which hex segments are the CRC?! Man, I am going crazy! 

[tomas123]

These lines added to both config files did NOT enable thermal fusion:

.caps.config.ui.fusion.thermal entry
.caps.config.ui.fusion.thermal.enabled bool true
.caps.config.ui.fusion.thermal.auto bool true
.caps.config.ui.fusion.thermal.interval bool true
.caps.config.ui.fusion.thermal.above bool true
.caps.config.ui.fusion.thermal.below bool true

I can't guess, what do you make wrong, if you only post snippets.
There are some syntax restrictions and CRC pitfalls.

You must learn to check the loaded configuration with "rls"!
see my post above

hint from old E40:
The fastet way to load configurations is using temp path for config files and the script restartapp.bat
After full reboot the camera is restored to standard configuration

You don't give me the asked informations about your firmware!
clone your filesystem with ftp and post the directory listing
or post appkit.rev and prodkit.rev

[tomas123]

This is my header for my calibration file: (In hex)

Code: [Select]

46 46 46 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 64 00 00 00 40 00 00 00 0e
00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 02 5a 20 00 00 00 00 e0 b5 cc a1
00 05 00 02 00 00 00 64 00 00 00 01 00 00 02 00
00 02 58 20 00 00 00 00 00 00 00 00 ba de ee fe

Which hex segments are the CRC?! Man, I am going crazy! 

I'm disappointed 

64 Byte Header

In the EXIF documentation, I see the following:

Code: [Select]

    # set file type if reading from FFF or SEQ file ($tagTablePtr will not be defined)
    $et->SetFileType($type eq 'FFF' ? 'FLIR' : 'SEQ') unless $tagTablePtr;

    # FLIR file header (ref 3)
    # 0x00 - string[4] file format ID = "FFF\0"
...
    # 0x3c - int32u checksum

0x00: 46 46 46= FFF
0x3c: e0 b5 cc a1

and the next checksum is in the 32 Byte index
see pdf above

Code: [Select]

typedef struct tagFLIRFILEINDEX-> ba de ee fe

edit:
first try zeroing the checksum

[ElectroTuna]

Sorry Tomas, I was too haste in my questions.

Unfortunately setting the CRC field (ba de ee fe) to (00 00 00 00) does not work. I guess the CRC needs to be re-calculated.

[ElectroTuna]

I am working on re-calculating the CRC based on this:

Code: [Select]

Type 1 for longword aligned data:
dwChecksum & 0xC0000000 == 0x80000000.
Checksum is calculated as the sum of all 32-bit longwords in the
tag data block given by dwDataPtr and dwDataSize modulo 0x20000000 or'ed with 0x80000000 (MSB always set, MSB-1 always 0).
This means taking data from positon 0x200 in the file all the way to the end in 32-bit chunks and summing them all up. Then the final sum value is modulo 0x20000000 and finally or'ed with 0x80000000 which sets the MSB to 1.

But the CRC I get is not the same as the one in the file...

[tomas123]

This means taking data from positon 0x200 in the file all the way to the end in 32-bit chunks and summing them all up.

not to the end - look for dwDataSize
add longword (4 Byte) as you wrote

Code: [Select]

00 05                                            Type   FFF_TAGID_GainDeadMap = 5,
      00 02                                      wSubType
            00 00 00 64                          dwVersion
                        00 00 00 01              dwIndexID
                                    00 00 02 00  dwDataPtr  0x00000200
00 02 58 20                                      dwDataSize 0x00025820
            00 00 00 00                          dwParent
                        00 00 00 00              dwObjectNr
                                    ba de ee fe  dwChecksum 0xBADEEEFE

[ElectroTuna]

Tomas,

The initial index, plus the data size takes us to the very end of the file. 0x25820 is 153,6832 bytes, which is 32 bytes more than the resolution in 16-bit numbers (320*240*2).

I am using Matlab:

%% Generate CRC for Flir Ex & Exx thermal camera calibration files.
clear alll; clc;
FileID = fopen('ds_we_ap_fi_le.dpx');
CalFileChar = fscanf(FileID, '%c',inf);
CalFileDec = uint8(CalFileChar);
CalFileHex = dec2hex(CalFileDec,2);
fclose(FileID);

ModID = '20000000';
RevArray = [0 1 2 3];

DataFileChar = CalFileChar(hex2dec('201'):end);
DataFileDec = uint8(DataFileChar);
DataFileHex = dec2hex(DataFileDec,2);

SumData = 0;
for ChunkIndex = 1:4:length(DataFileHex)
    TempData = '';
    for DataIndex = 1:4
        RevIndex = ChunkIndex + RevArray(DataIndex);
        TempData = [TempData DataFileHex(RevIndex,:)];
    end
    SumData = SumData + hex2dec(TempData);
end
CalCRC = mod(SumData, hex2dec(ModID));
CalCRCBin = dec2bin(CalCRC, 32);
CalCRCBin(1) = '1'; % MSB always set to 1;
CalCRCHex = dec2hex(bin2dec(CalCRCBin),8);

Remember that Matlab array indexes start from 1.

[tomas123]

Phil (Exiftool) and I both reengineered all the known Flir stuff last two years.
 
I haven't enough time check the algorithm but I'm absolute sure that the pdf is the right key.
I suggest first hack the dwChecksum of tagFLIRFILEHEAD (the Head & index checksum )

there are only a few byte

Code: [Select]

46 46 46 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 64 00 00 00 40 00 00 00 0e
00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 02 5a 20 00 00 00 00 00 00 00 00
00 05 00 02 00 00 00 64 00 00 00 01 00 00 02 00
00 02 58 20 00 00 00 00 00 00 00 00 00 00 00 00
flir sometimes use a reversed byte order in the data stream (usSwapPattern)

see here
https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg348398/#msg348398

[tomas123]

I also can't calculate the checksum of the header

see attachment

you have not posted your file list appkit.rev and prodkit.rev

next try https://www.eevblog.com/forum/testgear/flir-e40-upgrade-configuration/msg563460/#msg563460

Code: [Select]

>rset prod.preparation.command xyz

[tomas123]

on my PC I found the old FW v3.12.7 for your E40 Late 2013 ( FLIR Exx P/N:645xx / 646xx )
flir_exx_pn645_pn646_v3.12.7_update_pack.zip
and there are all files for WebGUI inside

Code: [Select]

> dir flir_exx_pn645_pn646_v3.12.7_update_pack\E2qtcomb_v3.12.7\FlashBFS\system\web\service\Calib
21.08.2013  20:23             2.331 AccMeas.asp
21.08.2013  20:23             9.743 AccMeasMeasure.asp
21.08.2013  20:23               515 AccMeasProtocol.asp
21.08.2013  20:23             4.725 AccMeasRemove.asp
21.08.2013  20:23            10.017 AccMeasSelect.asp
21.08.2013  20:23             8.231 AccMeasSetObjpar.asp
12.09.2013  12:01             4.203 CalibAcc.asp
21.08.2013  20:23             1.067 index.asp
21.08.2013  20:23             3.427 SysCalib.asp
21.08.2013  20:23             7.762 SysCalibActivate.asp
21.08.2013  20:23             6.841 SysCalibAddLensCase.asp
21.08.2013  20:23            12.181 SysCalibCalculate.asp
21.08.2013  20:23            13.272 SysCalibEditLimits.asp
21.08.2013  20:23             9.292 SysCalibEditMeas.asp
21.08.2013  20:23             6.244 SysCalibEnaDisa.asp
21.08.2013  20:23             3.954 SysCalibFarFocus.asp
21.08.2013  20:23             8.372 SysCalibMeasure.asp
21.08.2013  20:23               513 SysCalibProtocol.asp
21.08.2013  20:23             6.154 syscalibRangeEnaDisa.asp
21.08.2013  20:23             9.998 SysCalibSelect.asp
21.08.2013  20:23             5.895 SysCalibSwitch.asp
21.08.2013  20:23            12.171 transmission.asp
              22 Datei(en),        146.908 Bytes

Code: [Select]

> dir flir_exx_pn645_pn646_v3.12.7_update_pack\E2qtcomb_v3.12.7\FlashBFS\system\web\service\ImgCorr
21.08.2013  20:23             7.123 ActivateDigFilters.asp
21.08.2013  20:23             2.882 GainMap.asp
21.08.2013  20:23             9.935 GainMapCalc.asp
21.08.2013  20:23             5.588 gainmapcalcGF.asp
21.08.2013  20:23             5.819 GainMapCold.asp
21.08.2013  20:23             9.655 GainMapResult.asp
21.08.2013  20:23             2.385 GainMapSelCase.asp
21.08.2013  20:23             2.689 GainMapWarm.asp
21.08.2013  20:23             6.803 ImgCorrSelCase.asp
21.08.2013  20:23             1.566 index.asp
21.08.2013  20:23             5.246 Operability.asp
21.08.2013  20:23             1.684 OperabilityLog.asp
04.09.2013  12:22            47.416 PixKill.asp
21.08.2013  20:23             5.660 ShutterMap.asp
21.08.2013  20:23             1.558 StaticMap.asp
21.08.2013  20:23             5.138 StaticMapCalc.asp
21.08.2013  20:23             7.070 StaticMapCold.asp
21.08.2013  20:23             3.144 StaticMapPrepare.asp
21.08.2013  20:23             8.810 StaticMapResult.asp
21.08.2013  20:23             3.864 StaticMapWarm.asp
              20 Datei(en),        144.035 Bytes

as attachment the relevant part (file size limit here is 1mb)
rename to zip

watch for the full file list of the firmware v3.12.7 in folder kits.d (appkit.rev and prodkit.rev)


some screenshots from the bad pixel mapping procedure

Instruction

These pages are used to create gain maps. Gain maps even out variations in sensitivity througout the detector, and variations in the transmission of the optical elements of the camera.

The camera can have many gain maps, so different calibration cases can use different maps.

On the Select Case page you shall select a case on which the new map shall be based.

You will then take images of two mapping blackbodies  , preferably one in the upper and one in the lower part of the temperature range, using the Warm Image and Cold Image pages.

Popular mapping temperatures are 30°C, 100°C and 300°C.

When both images are taken, you will on the Calc Map page be asked how the new map shall be applied.

The map can become more or less specific, ranging from a default map meant for all cases to a map only used for the selected case.

The dead pixel replacement codes in the gain map are normally lost during the gain map calculations, so the camera Operability can change for the worse. You had better use the Pixel Replacement web page to clean the image afterwards.

[tomas123]

wow,
I found a menu, where you can replace single dead pixels!
the page only work with internet explorer ( no firefox or chrome)

Select a method 


show all bad pixels (currently mapped)


kill a single bad pixel

[Fraser]

Tomas123,

Excellent findings Sir !

Hopefully the E4 Service Menu operates in a similar manner. Being able to kill individual bad pixels, as they occur, is an excellent capability to have. Microbolometers are qhite relaible but, just like a CCD cell, you can suffer individual pixel failures over time.

Reference Blackbodies...... I have been looking at making some as the commercial units are very expensive and even then, teh chepaer types using hot air and flat plate radiators are a pretty uneven surface for calibration. Ok for checking accuracy though. Whne searching for "Blackbody" on ebay or Google I was presented with all manner of interesting images    I suggest serches on "IR calibration source" is a safer option 

Aurora