Flir E4 Thermal imaging camera teardown

[Fraser]

With regard to increased noise and lines on the displayed image. I have no such issues with the much earlier upgrade to firmware 1.19.8 / HW1.1 and do not recall others having this issue with the unencrypted cameras.

I cannot say that the newer hardware version isn't causing the issues, but I have to wonder whether some of the more recent 'enhancements' to the menu are an issue in themselves. A possible case of 'going too far' or over stretching the elastic 

IIRC I have read some reports on the 2.3.x menu upgrade suggesting that it has an effect on the cameras OS speed of response. If the addition of too many enhancements has had this effect, I strongly recommend reducing the enhancements to those that are truly needed rather than 'nice to have'.

It should be remembered that the E4 microprocessor was not originally selected to run the routines of the much higher specification Exx cameras and the latest upgrade may be over taxing its resources. IIRC the Exx series has TWO processors inside it as against the E4's single processor. Why should this matter ? Well a modern thermal camera uses a lot of processing on the data that it receives from the microbolometer. That processing is designed to clean up the image. FLIR are past masters at such processing and you only have to look at images produced by the SEEK thermal camera to see what a relatively 'RAW' thermal image looks like. Not pretty !  If the processor resources are being overtaxed it may have a detrimental effect on the image processing algorithms and the cameras overall stability.

With the original upgrade to the unencrypted cameras some very clever members of this forum collected together features from higher specification cameras in the Exx series (and others). these features were never supposed to be present in the Ex series and so were grafted into the configuration.  Some features did not work and caused instability in the camera. IIRC these were relating to Delta T and Humidity. Two versions of Menu upgrade became the standards. I stuck with version 2 whilst others went on to use a later version that had the Delta T and Humidity enabled but unstable. I have not regretted that decision to stick with the Version 2 Menu upgrade. My camera is very stable.

It was noted that as more menu options were added there was a slight slowing of the cameras  OS but Menu V2 has no noticeable effect that I can see. Most users seemed happy with the excellent features that had been added, namely more Colour Palettes, Zoom function, Manual span control etc. A decision was made to stop adding less useful functionality as that could slug the processor and risked instability in the camera. I consider this a good call.

IIRC the latest menu upgrade has added a lot of extra features over and above what was originally provided in the early upgrades. Some may find the additional features useful but, for me, the E4 was never intended to have every available feature of the OS enabled. Remember, this OS is common to a large range of FLIR cameras and may be considered a common platform with only the required features enabled. If you try to add all the features to a camera that was not designed to cope with such, you are asking for trouble. The E4 can become overcrowded in terms of its displays and also its OS routines.

It would be good to have an upgrade for FW 2.3.x that had the same features as the earlier proven V2 menu. this could be used to compare the cameras OS performance and any other issues that seem to be present in the latest camera upgrade.

I leave you all with this final comment..... more is not always better 

Aurora

[Bud]

P.S.: Does it seems so or I am imagining things, or read something like that but it appears to me there is more noise and less frequent calibrations of the image after installing the menu hack?

If i understand correctly, calibration is performed until temperature inside the camera reaches 35C, so calibration cycles become less frequent as the camera warms up. This is normal.

"running lines" down the screen, pixel walking... vertical stripes holding on place...

Press and hold Archive button for 2 sec, this will force a calibration cycle, see if you get spatial noise  (stripes) calibrated out right after that, if not then something could be wrong with the camera in general, i.e. factory calibration.

how do I check actual Noise setting applied in my conf

You need to decrypt the conf file. A script to do this was published in this thread.

[Bud]

IIRC I have read some reports on the 2.3.x menu upgrade suggesting that it has an effect on the cameras OS speed of response.

Not that i can see except some lag navigating in archive, but that may be because i have too many stored pictures. Simply adding measurements does not seem to slow camera down, in fact it holds very well, the only limitation is screen size, you can only place that many measurement boxes there.

  If the processor resources are being overtaxed it may have a detrimental effect on the image processing algorithms and the cameras overall stability.

I can attest no problems with stability here, the camera never dies on me

  Some features did not work and caused instability in the camera. IIRC these were relating to Delta T and Humidity.

True for 1.19, for 2.3.0 it was sorted out and works ok.

My camera is very stable.

Same is my 2.3.0 

[Solare]

@Aurora

Nice explanation... not that I really believe that adding palette to the list of options, even without enabling it, would slow down CPU ... but the general hint is clear - keep it minimal.

I don't know yet which are other Menu options (V1, V2, etc.), I installed the one referred to from Fubar procedure, and it has extended sets of palettes, measurements but not looking overcrowded with options. T ex., no Gradient measurements, circle areas, line and stat measurements etc. Overall, interface now seems balanced, and yes, you are right promoting this philosophy.

I remember you also played with polyolefin films to protect lens... I also bought some 12 um film and it works just nice, both in IR and visible! However, I have a problem applying it... how to fix it on the E4 front? Whatever I tried, I couldn't have good fixture, without folds and it very easily sags and drops Sticker tape doesn't help, also string from nylon or metal do not fix reliably... how in fact you achieved this?

[Solare]

@Bud

Are all the units assembled in Estonia?

Mine is from there, as well as some other user's,  the post of whom I read in this thread... also complaining vertical stripes at cold temperatures ("they are always there, but usually are masked with bright hot details")

When I set temp span to 4C t ex., and observe room in the night when all the temperatures are close, I see the vertical stripes pretty well, they are quite wide (16 pixels or so) and non uniform, but the pattern is always there.

Upon calibrations, they 'almost' disappear on the warmed up unit, and for several seconds the image is clear; then they start to emerge, together with random pixel aliasing and drifting, effectively degrading S/N ratio. That's why I asked you is that possible somehow to set more frequent calibrations (ideally in the Menu the threshold for calibration, or 'intensity' of calibrations could be set).

My unit is factory new, calibrated in Feb 2015, so I don't think the calibration is soooo misaligned... but then I asked you and others where their/ your unit originates from... maybe Estonia is a place of origin of BAD sensors because my image quality is substantially inferior to yours.

[alank2]

It is likely they bin them and put the ones with a less clear image in the lower models since the resolution and noise creator covers it to some degree.  I do see a similar thing in my E4 that arrived on Tuesday with the vertical stripes.

[Solare]

I hate them!!!!!

They must not do that, they must put equally random sensors on equally random cameras!!!!

 

Okay... I have spent 2 hours trying to locate ftool.exe version which is capable of decrypting (at least) 2.3.0 conf.cfc, so far no good... I mean, I found few, but nest they do is 'Tail part 2 failed' and that's it...

Spare on me, I cannot read anymore!!!!! Thee Who Knows where it is, raise your voice!!!!!!

[Bud]

I do not know if all cameras made in Estonia.

There is no calibration frequency setting in the menu. I'd think it is driven by internal temperature so you cannot change it. Also you cant expect cold camera to perform, you should wait till it warms up and increases time between calibration cycles, then make your judgement.

Forget about ftool, it was for earlier version of firmware, it is not working for 2.3.0. You have to locate a python script. Work this thread backwards until you find it. Decrypting your cfc will tell you if there was any errors in blindly patching the unit. You can fix any errors in a text editor and reencrypt the file.

[nostromo]

Thank you all for this great topic.
I sucessfully converted my E4 1.22.0 to E8 (including the additional menu) using Marphy's TIConfig.
Easy and without any problem. I followed exactly as described in Marphy's Blog:
- Installed FLIR camera drivers
- Executed TIConfig.exe >> packages >> FLIR Ex Series >> Device Configurations >> Firmware 1.2x >> FLIR E8 Configuration (1.2x).zip >> hit “Upload to device” >> switch off / unplug / take battery out >> put battery back in turn on
- Applied the Menu Upgrade package (FLIR Ex Upgrade Beta3.zip) >> Cold start

Worked like a charm   

[Solare]

Hmmm,

just playing with my converted E4 looking out of my window at people passing by (I live on 8th floor so it is observation from 20 meters height, at the distance over 50 meters away). It was early evening and surrounding temperature was 25.

I was expecting to see walking bodies glowing white in Iron palette(assuming these are not zombies) as I believed their temperature is well above 30C. But they didn't glow white! Then, I used 'color above threshold' palette so they should appear red, while the surroundings should remain gray.

I was surprised to see that all people in my area are actually zombies, because they didn't trigger the threshold anyway... they were of course not naked, but close to that at such temperature, but they appeared only slightly warmer than surroundings, so I had to set the threshold to 25.5 before they started to emerge red in grey.

At this distance, a typical figure of man is 12 to 16 pixels high, 6 to 8 pixels wide. Quite enough I would say for successful detection. Meanwhile, my own body, although observed from 10 meters in mirror, shows 35.4 C and 36.6 with the camera at the closest possible point.

Question: are they really zombies or something is wrong with measuring distant objects temperature? 50 meters are clearly not enough for factors like humidity come into play.

P.S> I expected that even a single pixel measurement will trigger the threshold, no matter how cold the surrounding pixels are... but now I assume some interpolation or statistics is applied to a group of pixels and, basically, it results in some limiting gradient value along the chosen direction or what?

[Solare]

@all,

@Mike

I also would like to re-trigger the topic about empty slots on the E4 motherboard. It is over 2,5 years from the first Mike's teardown post and we still have no idea, which IC is on the E8 board soldered in this empty slot?!! As far as I can understand, once we know what the IC is there, we can solder it in and, have wi-fi and Bluetooth enabled?

Have anyone digged into this topic specifically?

[Chanc3]

Hmmm,

just playing with my converted E4 looking out of my window at people passing by (I live on 8th floor so it is observation from 20 meters height, at the distance over 50 meters away). It was early evening and surrounding temperature was 25.

I was expecting to see walking bodies glowing white in Iron palette(assuming these are not zombies) as I believed their temperature is well above 30C. But they didn't glow white! Then, I used 'color above threshold' palette so they should appear red, while the surroundings should remain gray.

I was surprised to see that all people in my area are actually zombies, because they didn't trigger the threshold anyway... they were of course not naked, but close to that at such temperature, but they appeared only slightly warmer than surroundings, so I had to set the threshold to 25.5 before they started to emerge red in grey.

At this distance, a typical figure of man is 12 to 16 pixels high, 6 to 8 pixels wide. Quite enough I would say for successful detection. Meanwhile, my own body, although observed from 10 meters in mirror, shows 35.4 C and 36.6 with the camera at the closest possible point.

Question: are they really zombies or something is wrong with measuring distant objects temperature? 50 meters are clearly not enough for factors like humidity come into play.

P.S> I expected that even a single pixel measurement will trigger the threshold, no matter how cold the surrounding pixels are... but now I assume some interpolation or statistics is applied to a group of pixels and, basically, it results in some limiting gradient value along the chosen direction or what?

Did you setup the parameters of the camera properly? There should be an option to set the distance.

[Solare]

Yes, there are options.

But also, there is plain Physics.

The only thing which influence signal which is proportional to distance is water in air. This is set by Humidity and also by temperature sensor on the motherboard. We can only set Humidity explicitly.

Anyway, the effect of water in air is accounted for is only several percents per decade of distance. In other words, this is clearly NOT enough to make living warmblooded creatures appear at 25C at only 50 meters away.

If this is not sufficient for you, consider this.

I have some hot pixels in the very middle of the bodies (central pixels) but not on the boundary. But actual distance from the sensors pixels to the whole body is the same! If what you claim were true then, by all means, the whole body would trigger the threshold, but it doesn't.

Any other suggestions?

[mikeselectricstuff]

@all,

@Mike

I also would like to re-trigger the topic about empty slots on the E4 motherboard. It is over 2,5 years from the first Mike's teardown post and we still have no idea, which IC is on the E8 board soldered in this empty slot?!! As far as I can understand, once we know what the IC is there, we can solder it in and, have wi-fi and Bluetooth enabled?

The E8 does not have bluetooth or Wifi
It is not known if there is any support for the unpopulated part in the Ex software. 

[Solare]

hi Mike,

thanks for quick response,

but really, why is that empty slot there? I though it is populated on E8! Have you actually a chance to look inside E8? Or maybe anyone you know who did?

I bet, this motherboard is not a replica from EX0 so, even if this slot is unpopulated it might be 'reserved' for future functionality, or it might be the original design allowed for Bluetooth and wi-fi but then, due to marketing reasons they decided not to interfere with EX0 model range and thus left it unpopulated.... much likely it was a decision made already after the design was made and the motherboards were printed in bulk quantities... as it happens with marketing often last minute decision...

This could mean that if we only knew the IC which is in the EX0 responsible for the functionality, it should fit the unpopulated slot and work, if the drivers are provided (if not already there as plug-n-play option).

Anyway, thanks!

 

[alank2]

I gotta say Mike, I really enjoy your videos and reviews.

[mikeselectricstuff]

hi Mike,

thanks for quick response,

but really, why is that empty slot there? I though it is populated on E8! Have you actually a chance to look inside E8? Or maybe anyone you know who did?

I bet, this motherboard is not a replica from EX0 so, even if this slot is unpopulated it might be 'reserved' for future functionality, or it might be the original design allowed for Bluetooth and wi-fi but then, due to marketing reasons they decided not to interfere with EX0 model range and thus left it unpopulated.... much likely it was a decision made already after the design was made and the motherboards were printed in bulk quantities... as it happens with marketing often last minute decision...

This could mean that if we only knew the IC which is in the EX0 responsible for the functionality, it should fit the unpopulated slot and work, if the drivers are provided (if not already there as plug-n-play option).

Anyway, thanks!

 

AFAIK we don't know much about the Ex0 - even whether it uses the same sensor.
The reason the footprints are there are that when they started designing, they wouldn't necessarily have known which variations would actually be sold, so they gave themselves some options that they could decide on later.
If a competitor launched a BT equipped unit in a similar price range, they'd have the option to compete with it  fairly quickly.
 

[Solare]

Btw, Mike, since you are here...

Do you still have your old original E4?

[mikeselectricstuff]

Btw, Mike, since you are here...

Do you still have your old original E4?

Yes - it gets used fairly regularly.
 No plans to investigate further since establishing that the sensor is outputting 9fps.

[Solare]

Aha, so its should be a couple of meters away from you then?

Could you please find on the sticker the information about manufacture place?

Mine is Estonia. Curious what is yours, thanks!

[Solare]

So far I am not happy with noise levels achieved after the hacks.

See attached image of two power supplies running... is what I actually have.
compare to images after hack posted elsewhere and you will understand why I am unhappy!

But in fact, there is more noise on live stream than on snapshot. It is very finely granular, pixel noise which changes with every frame so overall live video is noisy... also horizontal lines moving up and down spontaneously, and vertical stripes... calibration removes for some dozen of seconds the latter two, but not the pixel noise.

I tried to measure actual noise levels in Service menu on web-server after replacing original 2.3.0 web folder to one found in older FW versions... it loads, runs, but not all the applets are running. Noise measurements - among them

I used also cfccfg.py script with my SUID key to hopefully decrypt my newly created by hacks conf.cfc file, which is encrypted.
It worked, or at least I believe so, I can see there is NoiseTargetMk = 0...

Either my sensor is really really bad, or guys @ Flir found another way to spoil image...

You could help me investigating this, but I am a newbie and I don't have all the tools by my hand.

For example, how do I use:

rset command

from which shell?

Can I set explicitly the Target Noise value on the running unit?

Or do I have to modify the line in conf.cfg file decrypted before, accordingly... and then encrypt it with my SUID back to get the conf.cfc and upload it replacing the file I have now?

Is there any other tool / better way to play with noise without taking too much risk of bricking the device?

Thank you!

[leoibb]

Hello all I keep popping on and off. Any more updates apart from
The menu.

[Fraser]

@Solare,

Presume you are aware that small spans on the E4 do have noise in them. The smaller the span, the greater the nose content. This is just a limitation of this entry level technology. Try looking at a kettle wile it is heating, you will likely see very clean images in Auto mode as the span selected will be large.

It is very hard to obtain low noise, small temperature span, images at this price point.

Aurora

[Solare]

Aurora,

I got your point But I intentionally set the span (not the smallest possible) which show the problem, naturally.

Even if I use autospan, and there are relatively hot objects in center view like human body, I have this fast noise in blue, it's dancing here and there. However, on videos and pictures found here on Thread, I can see excellent signal to noise ratio in all the case and little to no temporal noise.

[Solare]

A brief comparison... recently on this Thread, a user on my request kindly provided his hand shot with smallest span possible - 2C. Just now I repeated the same with my arm.

The attached are jpegs (mine is radiometric I believe, FLIR006)

Enlarge and you'll see finely grained pixel noise o mine.