Flir E4 Thermal imaging camera teardown

[Fraser]

Maybe, but everything I have read on TIC design indicates that a lot of correction related maths is needed to form a decent image. It appears that the FPA is quite a badly behaved sensor that needs taming before its data is truly usable ? No inside knowledge on this though.

[mikeselectricstuff]

If people can buy and modify the E4 unit from something that can be exported into something that cannot (or is more tightly controlled like 60fps) then Flir will be worried about getting in trouble with the US government.
As such, this will be the driving factor for stopping the hack on future firmware.

I have no reason to believe that >9fps is possible with a hack (though you may get a little more with overclocking) - As the downsampling appears to happen in the FPGA there is no reason not to bake the limit into the FPGA. Whether they have or not is an interesting question - not impossible that they use the same FPGA code across a wide range of models.
Of course what we don't know is how different the hardware is from the Ex0 series...

[Psi]

If someone wanted to add a TIC to a quadcopter or RC aircraft, buying this, stripping out all the surplus weight and tapping the full-res output would be a pretty viable solution and relatively low-cost. 

RC drone with thermal camera could loosely be classed as using the camera as part of a weapon system.

It is however, an awesome idea

[Fraser]

Its already been done several times using a Tau camera core !

http://www.buzzflyer.co.uk/quadcopter-Flir-Thermal-Imaging-Camera.asp

http://bestquadcopter.com/flying-fpv-night-flir-infrared-camera/

Direct You Tube link

[mikeselectricstuff]

Maybe, but everything I have read on TIC design indicates that a lot of correction related maths is needed to form a decent image. It appears that the FPA is quite a badly behaved sensor that needs taming before its data is truly usable ? No inside knowledge on this though.

Probably - there are a couple of cal files that look like per-pixel data.
I'd expect at least a gain per pixel, perhaps linearitycurves, and maybe corrections for shutter-closed offsets over different temp ranges.
And bad pixel concealment.
Which is why I'm curious to look at the raw output. Bear in mind that a lot of apps don't need linearity/accuracy and high framerate at the same time.

[Psi]

I have no reason to believe that >9fps is possible with a hack (though you may get a little more with overclocking) - As the downsampling appears to happen in the FPGA there is no reason not to bake the limit into the FPGA. Whether they have or not is an interesting question - not impossible that they use the same FPGA code across a wide range of models.
Of course what we don't know is how different the hardware is from the Ex0 series...

Yeah, i guess the issue is more about the raw 60hz data being available on a 9Hz unit, rather than the resolution hack.

[nowlan]

If someone wanted to add a TIC to a quadcopter or RC aircraft, buying this, stripping out all the surplus weight and tapping the full-res output would be a pretty viable solution and relatively low-cost. 

I found this page earlier.
http://diydrones.com/profiles/blogs/tiny-thermal-cameras-for-drones
http://www.drsinfrared.com/ModulesDetectors/UncooledCameraModules.aspx

[mikeselectricstuff]

Of course there is another reason that a manufacturer may want to stop a hack - if someone was reselling hacked units, either with original  branding or rebranded (might be tricky to change the boot-up logos to rebrand though).

And no, it won't be me...!
Wouldn't surprise me to see the odd on ebay though, maybe more likely i3's

[Hypernova]

The question is whether Flir are sufficiently enligtened to realise it. Time will tell.

I wouldn't count on it, cooperate management types are by definition incompetent.

[mikeselectricstuff]

DRS makes nice equipment -- curious why it's not ITAR.

Anything over 9fps made in USA is covered by ITAR, and similar regs in other countries.

[ixfd64]

I wonder how hard it would be to write our own custom firmware.

[IanB]

If time averaged sampling is used to smooth out noise, then higher frame rates are going to be harder to achieve without upping the noise level.

One possibility is to have a bigger lens with a larger aperture. This would allow more radiation to reach the sensor in a given time, permitting a faster frame rate without compromising the S/N ratio on the sensor.

At some point performance increases will rely on physical design parameters and not simply on electronics.

[0xdeadbeef]

Yeah, but nobody says you'd need to use the full 60Hz. When sample twice, three or four times to reduce the noise by averaging, you'd still come out with more than 9Hz.
Besides, you could implement a moving average filter even with 60Hz and trade in noise for motion blur.
Anyway, Mike seems to assume that the complete signal/image processing is done in the FPGA/ASIC, so this would make it much harder if not impossible to change the 9Hz anyway.

[mamalala]

Too bad that i know absolutely nothing about WinCE internals (or any other Win internals, for that matter),

Neither did I before this.... !
Very impressed with what IDA can do - many years ago I spent a lot of time writing disassemblers for many different MCUs and doing manual tracing and cross-referencing with telephone-directory sized  disassembly printouts.

Indeed, IDA is a great tool. i guess you already found the button to give you a graphical "flow diagram" style view of the code, where the boxes contain the code fragments?

Greetings,

Chris

[olsenn]

Anything over 9fps made in USA is covered by ITAR, and similar regs in other countries.

Perhaps I am wrong, but I was under the impression that ITAR only governs the export of government furnished technical data, and not technology itself; that is to say that if an engineer creates a thermal camera that operates at higher refresh rate than 9Hz, but does so without accessing ITAR schematics or white papers, then the device is itself not ITAR. Feel free to call BS on this one though

[mamalala]

I have no reason to believe that >9fps is possible with a hack (though you may get a little more with overclocking) - As the downsampling appears to happen in the FPGA there is no reason not to bake the limit into the FPGA. Whether they have or not is an interesting question - not impossible that they use the same FPGA code across a wide range of models.
Of course what we don't know is how different the hardware is from the Ex0 series...

Is the FPGA a flash/EEProm type, or does it use an external EEProm for the bitstream? Or is the bitsream uploaded from a file through the WinCE? If the latter, it may just be matter of getting the "right" bitstream file...

Greetings,

Chris

[mikeselectricstuff]

Too bad that i know absolutely nothing about WinCE internals (or any other Win internals, for that matter),

Neither did I before this.... !
Very impressed with what IDA can do - many years ago I spent a lot of time writing disassemblers for many different MCUs and doing manual tracing and cross-referencing with telephone-directory sized  disassembly printouts.

Indeed, IDA is a great tool. i guess you already found the button to give you a graphical "flow diagram" style view of the code, where the boxes contain the code fragments?

Greetings,

Chris

I've not actually used it, just seen the listings for this and the x-ray. If I ever get something that needs some serious disassembly I'll probably buy it, as sometimes you need the flexibility to adjust options depending on what'd been found.

[mikeselectricstuff]

I have no reason to believe that >9fps is possible with a hack (though you may get a little more with overclocking) - As the downsampling appears to happen in the FPGA there is no reason not to bake the limit into the FPGA. Whether they have or not is an interesting question - not impossible that they use the same FPGA code across a wide range of models.
Of course what we don't know is how different the hardware is from the Ex0 series...

Is the FPGA a flash/EEProm type, or does it use an external EEProm for the bitstream? Or is the bitsream uploaded from a file through the WinCE? If the latter, it may just be matter of getting the "right" bitstream file...

Greetings,

Chris

It's RAM, loaded from a file on the WinCE filesystem. However it would be a lot of work to create a new one, even after a lot of effort just to work out the pinout- you'd probably need to risk sacrificing a unit to do it.

[mamalala]

I have no reason to believe that >9fps is possible with a hack (though you may get a little more with overclocking) - As the downsampling appears to happen in the FPGA there is no reason not to bake the limit into the FPGA. Whether they have or not is an interesting question - not impossible that they use the same FPGA code across a wide range of models.
Of course what we don't know is how different the hardware is from the Ex0 series...

Is the FPGA a flash/EEProm type, or does it use an external EEProm for the bitstream? Or is the bitsream uploaded from a file through the WinCE? If the latter, it may just be matter of getting the "right" bitstream file...

Greetings,

Chris

It's RAM, loaded from a file on the WinCE filesystem. However it would be a lot of work to create a new one, even after a lot of effort just to work out the pinout- you'd probably need to risk sacrificing a unit to do it.

Well, the idea was not so much about reimplementing it, but getting hold of one for the better models (unless even the higher models, sold inside the US, have the same limitations). There is a good chance that the signal connections itself are the same, i.e. based on the same circuitry, and just the bitstream is a different one depending on capabilities. Of course that would require to get hold of one in the first place ....

Greetings,

Chris

Edit: That reminds me about something that i was wondering for quite some time: is there anything like a disassembler for FPGA bitstreams? Maybe not something as sophisticated as IDA, but still? Or is the IP about what goes on inside an FPGA such a "mystery" that there is simply no way to produce such a tool?

[ataradov]

Edit: That reminds me about something that i was wondering for quite some time: is there anything like a disassembler for FPGA bitstreams? Maybe not something as sophisticated as IDA, but still? Or is the IP about what goes on inside an FPGA such a "mystery" that there is simply no way to produce such a tool?

There were a couple projects trying to reverse-engineer bitstream format for Xilinx FPGAs. It was shut down by Xilinx lawyers almost immediately as it became public. It is still possible to find a PDF describing the effort, but referenced files are all gone from public view.

[mikeselectricstuff]

I have no reason to believe that >9fps is possible with a hack (though you may get a little more with overclocking) - As the downsampling appears to happen in the FPGA there is no reason not to bake the limit into the FPGA. Whether they have or not is an interesting question - not impossible that they use the same FPGA code across a wide range of models.
Of course what we don't know is how different the hardware is from the Ex0 series...

Is the FPGA a flash/EEProm type, or does it use an external EEProm for the bitstream? Or is the bitsream uploaded from a file through the WinCE? If the latter, it may just be matter of getting the "right" bitstream file...

Greetings,

Chris

It's RAM, loaded from a file on the WinCE filesystem. However it would be a lot of work to create a new one, even after a lot of effort just to work out the pinout- you'd probably need to risk sacrificing a unit to do it.

Well, the idea was not so much about reimplementing it, but getting hold of one for the better models (unless even the higher models, sold inside the US, have the same limitations). There is a good chance that the signal connections itself are the same, i.e. based on the same circuitry, and just the bitstream is a different one depending on capabilities. Of course that would require to get hold of one in the first place ....

]The problem is that (if they have any sense) the pinout will be adapted to suit the PCB of the product - even a single pin swap would mean a very different bitstream. Add to that this product has the visible camera stuff handled by the FPGA.

It would however be interesting to see what signals & voltages are used to drive the sensor. It's a bit tricky to get at though - would need to make a riser board.

[PA0PBZ]

Code: [Select]

Ex  fpga.bin       FLIR....POLLUX......27-Jun-2013.............................,.......ASBB
Exx fpga_B2CO3.bin FLIR....MIRA........23-Aug-2013.............................8.......SLCO
Exx fpga_C4_55.bin FLIR....MIRA........26-Apr-2013.............................8.......SLCO


 

[mikeselectricstuff]

Anything over 9fps made in USA is covered by ITAR, and similar regs in other countries.

Perhaps I am wrong, but I was under the impression that ITAR only governs the export of government furnished technical data, and not technology itself; that is to say that if an engineer creates a thermal camera that operates at higher refresh rate than 9Hz, but does so without accessing ITAR schematics or white papers, then the device is itself not ITAR. Feel free to call BS on this one though

It covers movement of technical information and items, regardless of who does it.

[mikeselectricstuff]

Code: [Select]

Ex  fpga.bin       FLIR....POLLUX......27-Jun-2013.............................,.......ASBB
Exx fpga_B2CO3.bin FLIR....MIRA........23-Aug-2013.............................8.......SLCO
Exx fpga_C4_55.bin FLIR....MIRA........26-Apr-2013.............................8.......SLCO



..of course these files would be in firmware upgrade packages, but unless the PCB is identical they wouldn't be any use.

[PA0PBZ]

..of course these files would be in firmware upgrade packages, but unless the PCB is identical they wouldn't be any use.

Identical PCB, identical FPGA, Identical IR sensor... No chance I'd say