some notes around eeprom and 9hz, but nothing new informations
./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
the address A0h is common to all Serial EEPROM devices (with hard-wired pins A2, A1 and A0 to low)
I think I've now worked out all the I2C devices :
0x92 Temperature sensor
0xD0 Realtime clock
0xAE EEPROM
0xAA BQ27510 battery manager
eeprom address 0xA0
Hmmm. found code that looks for the string "T198389" from I2C address 0XA0, and if found "SB0801 detector found " else "ULIS detector found"
don't write direct to eeprom...
I have tried changing E4 to E8 in the eeprom with no effect.
I have found code (100033AC for those following along) that reads 16 bytes from the EE, checksums it and if sums OK, stores the EEPROM values somewhere , and if not stores 80 and 60 in the same locations. Still looking at other eeprom related code. I think the 6 near the resoltion data is also significant - seems to correlate with the "downsampling setting" vales displayed at boot.
I only had a very quick try at changing the ee so could be I got the sum wrong.
..use rset or web frontend
> rset version.product.name E8
It is blindingly obvious how to extract the 60fps stream - just needs a bit of work to implement it.
unfortunately Flir doesn't sale a Ex with higher frame frequency, so surely the firmware doesn't support frequency > 9Hz
for inspiration a snip from a rls -r -l
Flir E4
.image.sysimg.basicImgData.distrData: (15)
rw----------n- 0 root root <i> imageFreq 9
Flir E40
.image.sysimg.basicImgData.distrData: (15)
rw----------0- 0 root root <i> imageFreq 30
syntax for (
rw)
rwcdrwcdrwcd0p*1 user group <a> resource_name "value" Explanation:
First rwcd = owner read,write,create,delete rights flags.
Second rwcd = group read,write,create,delete rights flags.
Third rwcd = other read,write,create,delete rights flags.
0p*1 = subscribers, persistance, not default, users counts and flags <a> = node type (ascii/integer/double/index/entry)
For resources with fixed string values, all alternatives are listed as well.
find string "imageFreq" in old FW 1.18
./appcore.exe
distrData.imageFreq
--
./appcore_dll.dll
imageFreq
--
./ProdApp.exe
.image.sysimg.basicImgData.distrData.imageFreq
found this post
Maybe it is a language thing, but I am confused right now:
I thought, modifing the 4 bytes at 0x001016ec from "05 00 a0 e1" to "01 00 a0 e3" will enable 30Hz but in your posting above you say 100ms between each frame = ~9 Hz. Did I miss something or did I understood something wrong? So no 30Hz by changing appcore.exe?
That hex will enable something and rls will report 30 for some values that were formerly at 9. but nontheless the effective framerate will stay under 10Hz.
Anyway the Ex is quick enough so one does not have to wait too long for a new image ... I don't have a big urge to investigate that further