Flir E4 Thermal imaging camera teardown

[tomas123]

after understanding the BT.601 offset, I found a simple solution:

The colors are right, but the brightness is limited (16..238?).
With 16 Bit convert (Q16) we can simple stretch the brightness from 16*256=4096 to 238*256=60928

check your IM colorspace (switch between RGB or sRGB )

Code: [Select]

$ exiftool -b -Palette FLIR0074.jpg | convert -size 224X1 -depth 8 RGB:- -separate -swap 1,2 -set colorspace YCbCr -combine -colorspace sRGB -level 4096,60928 -resize 448x30! iron16.pngperfect:


compare with a screenshot from FlirTools GUI

[mrflibble]

Nice!  Your exiftool + imagemagick pipes are even more convoluted than mine. I like it! 

[georges80]

Regarding the charging current. The chip in the external charger (L4001) uses a linear trickle charger to trickle charge a battery at 50mA in order to meet the minimum charge voltage. It then switches to a PWM charger. PWM will likely confuse a DC current monitoring device as it isn't dc it is switched DC 
You would need to monitor the charge current with a dc current probe and oscilloscope.

Are you sure about that?

The LTC4001 runs at nominally 1.5MHz switching speed (when not in trickle mode - which would be a rare situation). I really doubt you need a current probe/scope (I have both). A correctly operating decent meter should have no issues displaying an accurate average measured current (either input current or output current). At that switching frequency the output is essentially DC.

I think many folk get confused with PWM since it can be mean a) full load switching at some frequency and some duty cycle OR b) the PWM used by a switching regulator to drive a DC:DC converter's inductor. b) is what the LTC4001 is doing and the output is essentially clean DC.

cheers,
george.

[ClamzOnProzac]

Last week I received my E4 (E4 1.1; sn 639083xx; fw 1.19.8; cal Nov 27, 2013). Enhancement to the E8+ level was relatively painless. Worth every penny. Many thanks to those who have made it possible!

That said...

When I pointed the E8+ at an ice bath I came to understand the concern voiced in some previous postings: a temp reading in the 21-22F neighborhood is out of line with the 32.5F reading from a cheap pocket IR thermometer. One would feel utterly justified in tossing a glass thermometer with similar error.

So, to set up a reality check in preparation of doing some parameter fiddling on CALIB.RSC, I copied the file and stripped the last # CRC32 line, then ran it through the Python script presented in message #260.

I found that the resulting CRC32 didn't match the original file CRC32.

However, presenting the same file to CheckCRC.exe (see link in message #264) yields the original CRC32 number from the file.

I know next to nothing about the internals of CRC encoders and decoders. Is an alternate number acceptable to the internal CRC checker of the FLIR instrument? Has anyone else stubbed a toe on this?

[tomas123]

Your exiftool + imagemagick pipes are even more convoluted than mine

it was a hard work together with Phil decoding the Flir Exif Headers
Phil is a master of perl and my parts are reverse engineering of unknown Flir tags and build the IM pipes

I'm very interested in your workflow
please publish more about it   

[mrflibble]

So, to set up a reality check in preparation of doing some parameter fiddling on CALIB.RSC, I copied the file and stripped the last # CRC32 line, then ran it through the Python script presented in message #260.

I found that the resulting CRC32 didn't match the original file CRC32.

Maybe because post #260 is using the wrong flavor CRC? Use this instead:

Code: [Select]

import binascii
import sys
with open(sys.argv[1], 'r') as fp:
    data = fp.read()
    crc32_line = '# CRC32 %08x\r\n' % (binascii.crc32(data) & 0xffffffff);
    print crc32_line , ;

Edit: yes, self.data, that'll works. This was a snippet from a class method, so fixed now. The point is you should use binascii.crc32(). I use that for crc32 of resource files, and works just fine.

Update: to be sure I just tested it and both zlib.crc32() and binascii.crc32() give the correct result. So maybe user error? See my code above for the correct syntax of the CRC32 line.

[Fraser]

@Georges80,

No not certain. I saw PWM and, as you say, thought more complex to measure with a DC current meter than a simple DC current. Oooops showing ignorance of these charge systems now 

Thanks for the clarification. 

[mrflibble]

it was a hard work together with Phil decoding the Flir Exif Headers
Phil is a master of perl and my parts are reverse engineering of unknown Flir tags and build the IM pipes

Well, I for one am glad for said hard work because it is damn handy. And I do like Phil's perl code, nice and readable. I used to do a lot of scripting in perl myself, but slowly migrating to python lately.

I'm very interested in your workflow
please publish more about it   

Yeah I intend to finish up some tools and publish them, but I have this affliction called Too Many Projects.

[ClamzOnProzac]

mrfibble and All,

"Edit: yes, self.data, that'll works. This was a snippet from a class method, so fixed now. The point is you should use binascii.crc32(). I use that for crc32 of resource files, and works just fine.

Update: to be sure I just tested it and both zlib.crc32() and binascii.crc32() give the correct result. So maybe user error? See my code above for the correct syntax of the CRC32 line."

Yes indeed, both zlib.crc32() and binascii.crc32()  yield the same CRC32 number. Unfortunately, both are not  the number I recorded from the .rsc file before deleting the CRC32 line and its EXACT duplicate generated by running CheckCRC.exe on that edited file.

To muddy the issue, I noticed that Wikipedia claims that zlib CRC32 is a different flavor of a  more mainstream CRC32 (see the table in the Wikipedia entry for "Cyclic redundancy check").

This is the kind of thing than can bruise a man's forehead, and being a good sport I'm trying my best to blame the user. So... I made a one line text file the content being "blah,blah" (no quotes and with one CRLF pair) and ran it through the three CRC32 decoders in question.

The  results are...
zlib.crc32() and binascii.crc32()  = ce5f6c51
CheckCRC.exe                           = 6134ae5a

This is troubling.  Anyone care to duplicate this?  BTW: I'm running Python 2.7 on WinXP SP2.

A very Happy Holiday to everyone!

[mrflibble]

Alright, just tested the binascii.crc32() code as recently posted on python 2.7 on linux (debian). Result:

Code: [Select]

# CRC32 6134ae5a

To differentiate between a file read problem and a crc32 problem try this:

Code: [Select]

import binascii
data2="blah,blah\r\n"
crc32_line2 = '# DOUBLE CHECK CRC32 %08x\r\n' % (binascii.crc32(data2) & 0xffffffff);
print crc32_line2 , ;
I get the same correct result there as well.

[Force]

Hello! My first post
I am wondering if the E4 can be used in a car, for avoid driving over deers and people at night? I drive early in the morning, and want to avoid hitting others. I,m looking for a "cheap" way to recognize humans and creatures, in the forest beside the road. Or Is it just for close distance? I cant read or write so god in english, but I,m doing so good I can. I am impressed and jealous of the knowledge, that people have in this thread.
Can the E4 be adapt or changed in somehow to do this?
/ Force

[mrflibble]

The E4 is only 9 fps, so maybe not the best option for vehicle safety. There's been some talk in the thread about automotive thermal camera's as well, which is probably what you want for this.

Mike also did a teardown of an Audi camera here:

[gabriel.klein]

@Force

You can use VLC on Linux to connect to the camera.
You can then use a Raspberry with a small screen to connect to the camera using the USB cable.

Perhaps we might do something with the USB host mode of an Android tablet...

[mrflibble]

@ClamzOnProzac:
In my code I always use binary mode for blobs for which the crc has to be calculated, but it just so happens that on linux text mode open() also works fine. Which is why the code you mentioned also gave me the correct CRC32 under linux. Not so for windows though. Just to be sure I put it through the test. I installed Python 2.7.6 on win7 64-bit, using the Python 2.7.6 Windows X86-64 Installer found here. I then did some tests with this code:

Code: [Select]

import binascii
import sys

def test_crc(label, data):
    print "{0:14s}: {1:=08x}".format(label, ((binascii.crc32(data) & 0xffffffff )) )

test_crc("blah,blah\\r\\n", "blah,blah\r\n")
test_crc("blah,blah\\r",    "blah,blah\r")
test_crc("blah,blah\\n",    "blah,blah\n")

with open(sys.argv[1], 'r') as fp:
    data = fp.read()
    test_crc("TEXT   OPEN", data)
   
with open(sys.argv[1], 'rb') as fp:
    data = fp.read()
    test_crc("BINARY OPEN", data)

When run against the same old file as before you get this:

blah,blah\r\n : 6134ae5a
blah,blah\r   : 503bf9f2
blah,blah\n   : ce5f6c51
TEXT   OPEN   : ce5f6c51
BINARY OPEN   : 6134ae5a

Seems pretty obvious what is going on.

Executive summary: use the "rb" flag for open() and problem solved.

[iDevice]

I received my lens adapter from Lune3D last week and I could try my Chinese CO2 laser lens at last.
I went for the 50mm one as advised by Mike and it works a treat.
The only issue is that there is a lot of aberration on the edges, I wonder if the lens has really to be put with the convex side towards the camera lens like Aurora advised.
I would have put it the other way around by default, but because the whole setup seems fragile, I don't want to try to reverse it if not necessary, so I would appreciate experience from others in that matter.

But I have another question: Although it's very nice for very high magnification work, I discovered that the 50mm lens is really a very close macro lens. I have to be at about 3 to 4 cm or something from subject which is often impossible due to large components around and FOV is too narrow as well for many purposes.
So I would like to know what focal length would be suggested for a working distance around 10-15 cm ? 

[olsenn]

The E4 is only 9 fps, so maybe not the best option for vehicle safety.

It's not uncommon for automotive TIC's to operate at 9Hz as well, since they want people to be able to take their vehicles out of country on road trips without having to apply for a permit through the government first. They would otherwise need to have a security check done on all customers prior to purchasing one of their cars as well. 9Hz is sufficient.

[Taucher]

Some questions for experts (or someone else) on menu-hack:

I played around with my E4/8 and added and replaced some color palettes. But how can I change the palette icons?
I also customized the palette names in the language file, but unsuccessful when the length is not equal (e.g. want to replace "Arctic" with "Coldspot")

And what about zoom? Why is it not in use? Ok, digital zoom, what else? I activated zoom and it works fine.

@Icons: check my footer for URLs - there's a RCC file pointer in the postings how to unpack and repack RCC files (they conintain the icons)
@Zoom: please share your finding / config(s) - I did some very quick tests (icons showed up - but without function) and dropped it

[Taucher]

The E4 is only 9 fps, so maybe not the best option for vehicle safety.

It's not uncommon for automotive TIC's to operate at 9Hz as well, since they want people to be able to take their vehicles out of country on road trips without having to apply for a permit through the government first. They would otherwise need to have a security check done on all customers prior to purchasing one of their cars as well. 9Hz is sufficient.

Subversive suggestion:
Place your E4 behind the windshield and take a look how good the transparency of glass is - totally independent of Hz

Automotive electronics have nearly as hard requirements as airborne and/or mil electronics - there's a lot of engineering required to make a sensible automotive product - if you like hacking an E4 into pieces and re-assembling it in automotive-style enclosures etc. ... then just do it - but be prepared to face some problems and to invest a lot of work.
Most likely it's just a waste of time/ressources trying to re-invent the wheel while there are already perfect wheels available.

[Fraser]

Simple car night vision:

1. Buy an Ex Cadillac Deville Raytheon night vision camera. 320x240 30fps and it outputs a simple composite video feed. They often appear on e*ay.com at decent prices a and are designed to sit behind the car grille. i.e. they are weather proofed with a lens protector to prevent lens damage when in use.

2. Take the Mercedes route, fit a powerful IR illuminator to the front of the car and use a standard night vision CCD camera. This is not thermal camera technology but it works for Mercedes 

[cuisinart]

Happy holidays everyone, and thank you for your contributions!

[Fraser]

@iDevice

An issue you need to consider with the auxiliary lenses is that the E4 cannot change focus to compensate for any discrepancy in the output of the lens. I used the concave side facing the target as it has its focal convergence point at the required ~50mm point. The lens converts the light to parallel beams for presentation to the E4 lens. No focus adjustment is therefore needed by the E4. In the reverse orientation the lens will work buts its set ~50mm focal point OUTPUT will possibly not be optimum for the E4 lens and some defocussing may occur.

I have taken some sample pictures for you to look at. The titles are the descriptors but here is more info.

Conc-T is the concave side facing the target
ConV-T is the convex side facing the target
100mm shows the image produced using the 100mm FL lens
E4lens shows the image without any auxiliary lens and a view of the test pcb (RS232 to Ethernet adapter)

Please decide which orientation of the 50mm lens suits you best. There DOES appear to be edge distortion with the concave side facing the target but in my tests this orientation appeared to have a sharper centre focus. I can only assume that this is due to the manner in which the lens is used on the E4 as my PM695 works fine in that configuration. My PM695 has a ~60mm diameter, 24 degree FOV lens though.
Note: my OEM close up lenses are orientated with the concave side facing the target and the convex facing the camera. The E4 application may differ due to the small fixed focus lens and the large FOV ?

[mrflibble]

This one seems to fit well...



Merry Randomized Winter Seasonal Winter^* Festival Amalgamation!


(*) still like the winter version better, since that's where it originates from.

[Captain Morgan]

First post here.

Hack worked fine on new unit purchased in Dec. The Calibration Certificate says the site was Estonia Date: Nov 28, 2013

E4 1.1
Software V 1.19.8

The resolution is beautiful. THX for the mod, files and instructions.


.

[Researcher]

Good day, friends! I just discovered this awesome thread!
Please tell, is there a hack for latest Flir E4 HW model (1.1) with
latest firmware (1.2something), or I am too late to the party? 

[mrflibble]

Good day, friends! I just discovered this awesome thread!
Please tell, is there a hack for latest Flir E4 HW model (1.1) with
latest firmware (1.2something), or I am too late to the party? 

Exactly 1 post before you is someone using E4 1.1, and reporting the hack to work. So hardware revision is not an issue. As for firmware, 1.2somethings sounds nice and undefined. If you want to know for sure apply the hack (E8.cfg) and report if it works for you.