Flir E4 Thermal imaging camera teardown

[mrflibble]

It looks like the forum software eats $$$. Oh wait, I think I see what's happening. Some clever php monkey needs to take a course on input handling. At any rate, if you put a [url] tag around it yourself it leaves it alone: linkie

Or you can change the $ to %24, and you can leave it our there without explicit tag: http://support.flir.com/DocDownload/Assets/75/English/T559504%24A.pdf

[all_repair]

I expect a hackable E4 would not lead to a significant reduction in E8 sales, but would lead to a large increase in E4 sales to the hobbyist/budget market.

You bet! I already placed my order. Finally I can check my prototypes about hot spots and heat spreading. A resolution of 80x60 was nothing to write home about, but 320x240 for 1200 Euro (incl. VAT) is fair.... and as I side effect I can check my house for hidden problems.

Yah, I have no need or hardly need a ThermoCam, but now I am going to get one to check for shorted cap, shorted rails, etc.

[Psi]

Is the webcam output 320x240 when in service mode and is the framerate higher as well? 

[amyk]

From the fvd.dll, it appears not long after FVD_Init starts, and after calling function that reads downsampling setting from I2C (not sure if EEPROM or sensor) it tries to open

Code: [Select]

\Temp\__higres.cnfand if it can, it just closes and deletes the file without trying to read anything from it... and writes

Code: [Select]

FVD_Init: Oneshot high resolution modethen write something into memory and continues... so one thing to make this persistent might be to create that file on the device and mark it read-only. (This is assuming the filesystem of WinCE is similar enough to a standard Windows one to have attributes and such.)

[bean_dip]

Can someone post a copy of this file for those of us not brave enough to open our cameras for the serial port?

[mikeselectricstuff]

Can someone post a copy of this file for those of us not brave enough to open our cameras for the serial port?

At the moment the only way in is via the serial port as it is the only known way to get a console prompt, to put the USB into RNDIS mode.
There does appear to be a hidden menu to enable RNDIS - until this is found you need to open it.
 

[mikeselectricstuff]

Someone has a sense of humour!
In service mode :

\temp>type __highres.cnf
HandsOff
\temp>

Also in temp is a config.cnf file - this may explain why modding the config files in flashfs didn't appear to do anything -  maybe it's only looking at files copied into \temp 

Left unit in auto-poweroff sleep overnight and seems to wake up OK.

[mikeselectricstuff]

Looks like a normal startup deletes everything in temp - actually I think temp is a RAM volume as it's above the flash-x-FS directories

[mikeselectricstuff]

BTW updated connector pinout
Starting from end nearest to the unpopulated FFC connector

1 On/Off switch (to ground)
2 Power - Vbattery during run and charge - possibly via a FET switch as I didn't see continuity to bat terminal
3 Console TXD
4 Console RXD
5 Debug  TXD
6 Debug RXD
7 0V
8 /Reset
9  Output
10 Input
11 Output
12 Input
13 Input
14 I2C SDA
15 I2C SCL
16 0V

Pins 10-13 look like they may be build option resistors - two have 10K to +3.3v, two have 1K to ground.

the connector will take a standard 16 way 0.5mm jumper cable, e.g. Molex 0210200165 available from Digikey amongst others

[Pinkus]

Just received the shipping note of my ordered E4. So I will definately get an E4 before Flir is able to roll out a new "improved" firmware to all cameras. 
Can't wait to receive it.
Kudos to Mike and all other contributors!

[mrflibble]

Looks like a normal startup deletes everything in temp - actually I think temp is a RAM volume as it's above the flash-x-FS directories

taken from camera.cmd:

Code: [Select]

$SHOW "Combined firmware (1.18.7) is intended for FLIR Z3-Series"
# Clean from potential earlier install
rmdir \temp\OS
rmdir \temp\APP
rmdir \temp\PROD
...
#Here if OS is not 16.0.10, mark OS for update
md \temp\OS

Those check do seem to imply at least a certain level of persistence. Then again, it could be leftovers from development on a persistent fs + "doesn't hurt to leave those checks in". So in the end ... 

But can't you check the \temp mount point to find out what type of FS it is?

[PA0PBZ]

prodapp.exe @ 19FB8:

Code: [Select]

LDR     R2, =aRestartingInHi ; "Restarting in high resolution mode/serv"...
LDR     R0, [R8,#0x54]
MOV     R1, #0
BL      sub_8F178
LDR     R1, =aW         ; "w"
LDR     R0, =aTemp__highres_ ; "\\Temp\\__highres.cnf"
BL      fopen
MOVS    R4, R0
BEQ     loc_19FF8
LDR     R0, =aHandsoff  ; "HandsOff"
MOV     R3, R4          ; FILE *
MOV     R2, #8          ; size_t
MOV     R1, #1          ; size_t
BL      fwrite
MOV     R0, R4          ; FILE *
BL      fclose

[mikeselectricstuff]

Useful Hack no. 2...
To start service mode without using the web interface, just the console....
In normal mode copy some files as shown below into the images dir (seem to be some restrictions on where you can write - was getting quota type messages).
You can find the files by getting into service mode and FTPing  from \temp - Only need to do this once.

Add this batch file as serv.bat

md \temp\appcore.d\
md \temp\appcore.d\config.d
md \temp\appcore.d\factory.d
copy __highres.cnf \temp
copy conf.cfg \temp\appcore.d\config.d\conf.cfg
copy bw.rsc \temp\appcore.d\factory.d\bw.rsc
copy rndis.rsc \temp\appcore.d\factory.d\rndis.rs

Once done, you can now get service mode from the console after a cold start :
cd \flashifs\<wherever you put the files> - note PC must be disconnected)
serv
stopapp
restartapp

You are now in service mode. USB mode is RNDIS. This appears to be specified in rndis.rsc so may be chnageable - stay tuned.

The latter commands are batch files in flashbfs - should be possible to combine everything into a single batch file.

[tom66]

Could those commands be placed in a sort-of autoexec.bat file (don't know if WinCE has a similar set up?) That way it enters service mode upon power up?

[mikeselectricstuff]

BTW note when restarting, there is a delay when it appears the keypad has frozen - this is just the startup time, and because progressapp isn't running you don't see a progress bar

Is the webcam output 320x240 when in service mode and is the framerate higher as well?

By default, USB is in RNDIS mode, so no webcam. The video over NDIS protocol does not appear to be implemented.
However if you modify  the USB mode string in rndis.rsc to "UVC_MSD", you are in service mode with mass-storage and UVC working as normal. Note I did this by copying the file from usb.rsc in the FW update so the CRC is right - I don't know if it actually checks the CRC though

[mikeselectricstuff]

Could those commands be placed in a sort-of autoexec.bat file (don't know if WinCE has a similar set up?) That way it enters service mode upon power up?

There is a file called applaunch.dat

# Show intro bootlogo and start progress
progressapp -f \flashbfs\system\bootlogo.bmp -g flashbfs\system\bootlogo_legal.bmp -d
# Start command shell on the RS-232 port
cmd /R
# Register a default user
defaultusr
# Start appcore. Appcore starts other necessary processes
appcore

However this may be dangerous as if the cmd/R isn't run you could find yourself locked out of the console  - the only potential way back in would be the hidden menu to enable RNDIS for telnet or FTP  access

[tom66]

So you could perhaps use a fork to launch a batch file - for example the "START" command on windows creates a second command interpreter and as long as the command interpreter can be found, the command should not fail.
But what I don't know is if this will open up a command window on top of the thermal image   

[mrflibble]

My guess is they only use CRC to check if the file transfer of new files (during a firmware upgrade) is succesful. During firmware upgrade it uses kitcrc for that.

Code: [Select]

kitcrc -c \FlashBFS\system\kits.d\appkit.rev
...
kitcrc -c \FlashBFS\system\kits.d\prodkit.rev

Based on kitcrc exit code it then says "Congrats" or "Screw you hippie!".

And you can probably add the RNDIS stuff to applaunch.dat by the looks of it. Probably want to make it create a file first time, then based on file existence do your extra stuff or not. That way you only execute your funky stuff first time around. In case of hang you reset and it will skip it.

What does cmd /? say btw? Apparently /R attaches it to rs232. Any other juicy options?

[mrflibble]

However this may be dangerous as if the cmd/R isn't run you could find yourself locked out of the console  - the only potential way back in would be the hidden menu to enable RNDIS for telnet or FTP  access

Nah. just make a file existence based bit of logic in the bat file that either does A or B. Make it so that reset toggles between executing branch A and B. And /obviously/ you test this mechanism first with something harmless. Been there, done that, reflashed it. @_@

[mikeselectricstuff]

Just tried adding the copy commands to applaunch.dat and no effect.
however commenting out appcore does stop the main app running.

Maybe applaunch.dat can only run executables

cmd /? :
CMD [/[C|K] command][/P][/Q][/T:bf]

  /C command  Runs the specified command and terminates.
  /K command  Runs the specified command and remains.
  /P          CMD becomes permanent and runs autoexec.bat
              (cannot be terminated).
  /T:bf       Sets the background/foreground color (see COLOR command).
\>Bad command or filename



maybe cmd /c copy.. might work - stay tuned...

[Stonent]

However this may be dangerous as if the cmd/R isn't run you could find yourself locked out of the console  - the only potential way back in would be the hidden menu to enable RNDIS for telnet or FTP  access

Nah. just make a file existence based bit of logic in the bat file that either does A or B. Make it so that reset toggles between executing branch A and B. And /obviously/ you test this mechanism first with something harmless. Been there, done that, reflashed it. @_@

When dealing with potential lockout situations (like fixing something remotely) I tend to start a timer of say 1 hour so if somehow whatever I did locks me out, when the timer runs out it either undoes it, reboots etc.

Useful when messing with network settings on a remote system.

[mikeselectricstuff]

not quite... Looks like the delete happens too soon - I can copy the files in, but by the time appcore starts, __highres.cnf has been deleted.


oh hang on a min, something has also deleted the dir I put on flashBFS with the files - maybe need to copy from flashifs... 

[mikeselectricstuff]

New applaunch.dat

# Show intro bootlogo and start progress
progressapp -f \flashbfs\system\bootlogo.bmp -g flashbfs\system\bocmd /c bootlogo_legal.bmp -d
# Start command shell on the RS-232 port
cmd /R
# Register a default user
defaultusr
cmd /C md \temp\appcore.d\
cmd /C md \temp\appcore.d\config.d
cmd /C md \temp\appcore.d\factory.d
cmd /C copy \flashifs\hack\__highres.cnf \temp
cmd /C copy \flashifs\hack\conf.cfg \temp\appcore.d\config.d\conf.cfg
cmd /C copy \flashifs\hack\bw.rsc \temp\appcore.d\factory.d\bw.rsc
cmd /C copy \flashifs\hack\rndis.rsc \temp\appcore.d\factory.d\rndis.rsc

# Start appcore. Appcore starts other necessary processes
appcore

Pwned.
Hang on, maybe not, but I did fiddle with a cfg file to try getting PIP.... stand by!

[mikeselectricstuff]

Panic over, definitely pwned 
Tried 3 restarts from power-off and all good.

Oh, and standby/restart seems to work OK as well.

Interestingly with this hacked startup.dat, the startup progress bar actually works properly.

Putting the files in flashifs means you can fiddle easily via MSD interface, and disable the hack if necessary by just moving the files off.

Hopefully PIP and any other E8 goodies can be enabled - no more time to hack now.
 
Just make sure it isn't plugged into the PC when starting as the flashifs filesystem won't be mountable - it starts in standard mode.

[Fraser]

Even more RESPECT