is it a possibility in the future to be able to get higher FPS ? or is it the sensor that only can make 9 fps ?... just out of curiosity ..
The sensor is apparently capable of outputting raw 60 FPS data, but so far nobody has found out how to extract useful information from it.
Before I forget them, here some memos from the last "binary inspection" run
WEBSERVER:
Comm\HTTPD\VROOTS\/service = \FlashBFS\system\web\service\ (UserList: flir)
-> http://192.168.0.2/service/ -> Service menu
Comm\HTTPD\VROOTS\/Prod = \FlashBFS\system\prodisapi.dll
--> http://192.168.0.2/Prod --> The server encountered an error.
I think you mean the old firmware.
in FW 1.21 there is no ProdISAPI.dll and folder \FlashBFS\system\web\service\
It's just a memo what I found - it's still present in the new firm as well (not necessary to be functional)
NEW-21/strings-registry:1525:Comm\HTTPD\VROOTS\/Ram
NEW-21/strings-registry:1528:Comm\HTTPD\VROOTS\/Tmp
NEW-21/strings-registry:1531:Comm\HTTPD\VROOTS\/service
NEW-21/strings-registry:1536:Comm\HTTPD\VROOTS\/Prod
NEW-21/strings-registry:1539:Comm\HTTPD\VROOTS\/
OLD-17/strings-registry:1525:Comm\HTTPD\VROOTS\/Ram
OLD-17/strings-registry:1528:Comm\HTTPD\VROOTS\/Tmp
OLD-17/strings-registry:1531:Comm\HTTPD\VROOTS\/service
OLD-17/strings-registry:1536:Comm\HTTPD\VROOTS\/Prod
OLD-17/strings-registry:1539:Comm\HTTPD\VROOTS\/
... it's still present in the new firm as well (not necessary to be functional)
you are right
a sample from FW 1.21
/FlashBFS/system/web/inc/usermenu.inc
menuRow("Service Menu", "/service/index.asp", "mainmenu", selectedMenu == "mnuServiceWeb");
but there is no folder service...
After the hack, is there anything different from the E8 ? or is it exactly the same ?
It has more features than E8. I suggest you to visit first page ;-)
But you don't get the additional battery and the front-label still says "E4"
ahhahah.. i will not cry for that, paying almost 5000 more !!!
A quick question: does the Ex battery have the I2C bus connected to it?
Flir connected the eeprom over i2c. As I wrote above the eeprom is the now the dongle for resolution settings.
In new firmware the i2c.exe for manipulating i2c devices is
removed https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg382118/#msg382118 :
from old FW:
./i2c.exe
Usage: i2c [2] {r|w} <address> <no of bytes if read> <data to write>
i2c [2] f <filename>
Write example: i2c w A0 11 22 33 - Write 11h 22h 33h to A0h
Read example 1: i2c 2 r A0 10 - Read 10h bytes from A0h on I2C2:
Read example 2: i2c r A0 10 80 - Write 80h and Read 10h bytes from A0h
Read example 3: i2c r A0 10 80 40 - Write 80h 40h and Read 10h bytes from A0h (16-bit addressing)
File example 1: i2c f vf.txt - Read command from file
./web/service/Diag/BIT.asp
Response.Write("The Battery test will try to detect the battery via I2C.<br><br>");%>
Response.Write("The EEProm test will try to detect the EEProm(s) via I2C.<br><br>");%>
Response.Write("The Temp Sensor test will try to read the temperature sensors via I2C.<br><br>");%>
Flir connected the eeprom over i2c. As I wrote above the eeprom is the now the dongle for resolution settings.
No major deal to "fix" that then.....
Do you see anything that would prevent i2c.exe being installed via the installer?
The battery has no intelligence - just a 10K thermistor. It has 3 pins, therefore no I2C
And what would be the point in doing anything with the battery anyway?
A vehicle charger seems a plausible accessory, but not quite sure how it would fit with the current E4 hardware
There is an I2C battery manager, but it's on the board. I vaguely recall that it does have a small amount of OTP memory. The part number is probably in this thread or the video
is it a possibility in the future to be able to get higher FPS ? or is it the sensor that only can make 9 fps ?... just out of curiosity ..
The sensor is apparently capable of outputting raw 60 FPS data, but so far nobody has found out how to extract useful information from it.
It is blindingly obvious how to extract the 60fps stream - just needs a bit of work to implement it.
Flir connected the eeprom over i2c. As I wrote above the eeprom is the now the dongle for resolution settings.
No major deal to "fix" that then.....
Do you see anything that would prevent i2c.exe being installed via the installer?
The battery has no intelligence - just a 10K thermistor. It has 3 pins, therefore no I2C
And what would be the point in doing anything with the battery anyway?
A vehicle charger seems a plausible accessory, but not quite sure how it would fit with the current E4 hardware
There is an I2C battery manager, but it's on the board. I vaguely recall that it does have a small amount of OTP memory. The part number is probably in this thread or the video
Well, the firmware seems to be somehow generic for several models/cameras - but I find it a very strange coincidence that there's a big I2C cleansweep done and a I2C-related driver added. The only "truck" charger that I've seen (for Ex) is a car-charger and it's a plain (probably rebranded Chinese) 12V->5V USB adaptor.
the old procedure to unlock the eeprom and take changes (from my notes)
source: /web/service/inc/eepromlock.inc and /web/service/EEProm/edcaminfo.asp
# start prodapp and wait some seconds (the same as >start prodapp )
> rset appl.supv.exec prodapp
#unlock eeprom
> rset system.eeprom.unlock 1235
# write name E8
> rset version.product.name E8
#lock the eeprom
> rset system.eeprom.unlock lock
I am unsure if the prodapp.exe must be started for writing the eeprom
is it a possibility in the future to be able to get higher FPS ? or is it the sensor that only can make 9 fps ?... just out of curiosity ..
The sensor is apparently capable of outputting raw 60 FPS data, but so far nobody has found out how to extract useful information from it.
It is blindingly obvious how to extract the 60fps stream - just needs a bit of work to implement it.
Anyone of you guys will try that ?
is it a possibility in the future to be able to get higher FPS ? or is it the sensor that only can make 9 fps ?... just out of curiosity ..
The sensor is apparently capable of outputting raw 60 FPS data, but so far nobody has found out how to extract useful information from it.
It is blindingly obvious how to extract the 60fps stream - just needs a bit of work to implement it.
Anyone of you guys will try that ?
Sure. Right after I finish the other 43586534535 projects.
I suspect that you have bad luck that quite a few of us on here have quite a bit of motivation for high resolution, but a who-the-hell-cares attitude about fps. As in 9 fps is quite enough for all the stuff I do with it. PCBs and assorted other electronics tend to stay put and in focus, soooo...
I am more motivated to make a linux bootloader, and even
that is fairly low on the list.
You probably would have better luck with that on an RC helicopter forum or some such.
But then, who's going to put a $1k camera on a crashy copter.
Anyways, just watch Mike's video again to see how blindingly obvious the todo list is staring you in the face.
I wanted to say thanks to everyone working on this project from the tear down, firmware, hacks to the BFIC software.
Great job to everyone and thanks and thanks for all your time and effort.
Seeing that the time is running out to grab one of the units without the newer firmware may be running short I went out to my local Grainger store and bought a E4 today after conforming it had the needed firmware.
I got home and backed up all the files on the camera to a folder on my hard drive then installed the hack and all worked as it should. I then added the menu hack and now I have an E4 updated to an E8+
My model is: E4 1.1
Serial# 639125**
Part no. 63901-0101
Software 1.19.8
Calibration date: January 18, 2014
I will say again thanks to everyone's effort to make this project happen. Without the hack I would not have made the purchase of the E4
What version hardware is involved with these crashes and what Taucher Menu version is installed ?
1.0, menu 3 with zoom
Model 1.1, soft 1.19.8, menu 3 with zoom. But IMHO its hardware/OS problem. Many times I saw flash/firmwares corrupted by writing in wrong place after hardware malfunction or without any case, "just because".
It is blindingly obvious how to extract the 60fps stream - just needs a bit of work to implement it.
Anyone of you guys will try that ?
Sure. Right after I finish the other 43586534535 projects.
Ditto. 320x240 - Hell yes. 60fps (noisy, uncalibrated) - Meh.
For anyone buying in the USA, remember that there is a FLIR free gift promotion active on the Ex series until March.
Take a look at my post here:
https://www.eevblog.com/forum/reviews/flir-e4-the-useful-information-thread/msg362566/#msg362566
Even if you have already purchased your E4, you are eligible
Sadly this is only available for US sales (I tried, and failed, to claim on a UK purchase)
Fine print: must send in within 30 days of purchase and cannot return item once redeemed. I just reread it, I thought I had til March 31 to redeem.
I received my free borescope yesterday. I'm a little annoyed they subbed in the BR70 for the BR80, but hey, free is free.
Complain. FLIR seem pretty good on the Customer Relations front.
They may sort it out for you.
@dtbp,
30 days is a decent period of time. I highlighted this offer sevral times in this and teh useful information thread to ensure teh word was out on th eoffer. In my experience teh time limitations on tehse sorts of offers can actually be quite flexible when you speak to teh companies nice customer relatiosn officer. It you have exceed the registration period contact teh customer relations team and plead your case. (very busy, illness, forgot about it whilslt testing the lovely new camera etc)
With regard to not being able to return teh camera.....why is that an issue ? If you receive the camera, test it for a week or so and are happy with it, why would you be wanting to return it ? This caveat is to prevent people deliberately buying an E4 claiming the freebie and then returning the E4 for a full refund. i.e underhand behaviour to fet the freebie for free with a purchase.
Complain. FLIR seem pretty good on the Customer Relations front.
They may sort it out for you.
Packing slip says "BR70 replaces BR80. BR70 has the same form, fit, and function."
Approximate retail value is the same. Might be that they were out of BR80s. Not really worth the hassle to complain.
It is blindingly obvious how to extract the 60fps stream - just needs a bit of work to implement it.
Anyone of you guys will try that ?
Sure. Right after I finish the other 43586534535 projects.
Ditto. 320x240 - Hell yes. 60fps (noisy, uncalibrated) - Meh.
I don't think it will do 60Hz - not clearly without a major overhaul or real temp control. I can see it doing 30Hz due to the boot log stating 30Hz is not allowed seeming to indicate that the hardware is capable but I think that 60Hz signal being fed to the FPGA needs the extra 30Hz to clean things up and make them usable. Most of the smaller FLIR stuff seems to max out at 30Hz from what I have been reading.
Looking at what changes that 1.21 has included - updated CRC's and removal of the I2C and web components - that may be the hint as to what is vulnerable. The resolution upgrade depended on the CRC functions but there really has not been much work done that required the use of the I2C/web stuff. I have a feeling that a I2C edit of the eprom may be the only thing standing in the way of unlocking 30Hz functions of the FPGA's output.
@dtbp,
30 days is a decent period of time.
I agree. I don't have a problem with any of the terms of the offer, just giving other people a heads up about the time limits if they were dragging their feet like me.
It is blindingly obvious how to extract the 60fps stream - just needs a bit of work to implement it.
Anyone of you guys will try that ?
Sure. Right after I finish the other 43586534535 projects.
Ditto. 320x240 - Hell yes. 60fps (noisy, uncalibrated) - Meh.
I don't think it will do 60Hz - not clearly without a major overhaul or real temp control. I can see it doing 30Hz due to the boot log stating 30Hz is not allowed seeming to indicate that the hardware is capable but I think that 60Hz signal being fed to the FPGA needs the extra 30Hz to clean things up and make them usable. Most of the smaller FLIR stuff seems to max out at 30Hz from what I have been reading.
Looking at what changes that 1.21 has included - updated CRC's and removal of the I2C and web components - that may be the hint as to what is vulnerable. The resolution upgrade depended on the CRC functions but there really has not been much work done that required the use of the I2C/web stuff. I have a feeling that a I2C edit of the eprom may be the only thing standing in the way of unlocking 30Hz functions of the FPGA's output.
And then it could look like
http://www.mathworks.fr/company/newsroom/FLIR-Speeds-Thermal-Imaging-FPGA-Development-Through-Automatic-HDL-Generation-From-MATLAB.html ;-)
It is blindingly obvious how to extract the 60fps stream - just needs a bit of work to implement it.
Anyone of you guys will try that ?
Sure. Right after I finish the other 43586534535 projects.
Ditto. 320x240 - Hell yes. 60fps (noisy, uncalibrated) - Meh.
I don't think it will do 60Hz - not clearly without a major overhaul or real temp control. I can see it doing 30Hz due to the boot log stating 30Hz is not allowed seeming to indicate that the hardware is capable but I think that 60Hz signal being fed to the FPGA needs the extra 30Hz to clean things up and make them usable. Most of the smaller FLIR stuff seems to max out at 30Hz from what I have been reading.
Looking at what changes that 1.21 has included - updated CRC's and removal of the I2C and web components - that may be the hint as to what is vulnerable. The resolution upgrade depended on the CRC functions but there really has not been much work done that required the use of the I2C/web stuff. I have a feeling that a I2C edit of the eprom may be the only thing standing in the way of unlocking 30Hz functions of the FPGA's output.
There is no evidence seen to date that the 9Hz isn't nailed into the FPGA.