When dealing with potential lockout situations (like fixing something remotely) I tend to start a timer of say 1 hour so if somehow whatever I did locks me out, when the timer runs out it either undoes it, reboots etc.
Just tried adding the copy commands to applaunch.dat and no effect.
however commenting out appcore does stop the main app running.
Maybe applaunch.dat can only run executables
cmd /? :
CMD [/[C|K] command][/P][/Q][/T:bf]
/C command Runs the specified command and terminates.
/K command Runs the specified command and remains.
/P CMD becomes permanent and runs autoexec.bat
(cannot be terminated).
/T:bf Sets the background/foreground color (see COLOR command).
\>Bad command or filename
Even more RESPECT
Even more RESPECT
+1
Time to save or update an OFFLINE version of this thread.
What? You mean you didn't mirror this thread and the entire Flir firmware exe/zip/iso/pdf collection?
Mass production of a product like the E series is most cost effective if most mechanical and electronic parts are the same, with just firmware differences. The BoM is then kept as small as possible and the manufacturing line is simplified.
With regard to deletion of this thread....... would Dave do that ? He supports that Wiki Leaks chap doesn't he ? Freedom of speech and all that.
What? You mean you didn't mirror this thread and the entire Flir firmware exe/zip/iso/pdf collection?That post meant for provoking a further mass generation of the off-line mirrors, silly.
So when's the video coming out? O0BTW:
The word 3vlig (trevlig) is used in Swedish meaning nice!
Interesting coincidence.
So when's the video coming out? O0BTW:
The word 3vlig (trevlig) is used in Swedish meaning nice!
Interesting coincidence.Or confirmation of my .rcc file induced suspicion that this was made by their Swedish software team. That resource file is full of se.flir references.
Mike,
I may be totally wrong as you know more about the firmware than me, but I have not herad of this noise insertion technique in a TIC before. Bit padding, yes, but not noise insertion.
The Uncooled Microbolometer is a noisy beast and much time and money has been spent trying to tame it in order to provide nice clean images with as little internally generated noise as possible. My 1st Generation FPA PM570 is pretty noisy when compared to the later 3rd Generation FPA PM695 on this front. FLIR have spent a lot of time developing the FPA and also the noise REDUCTION algorithms and capabilities. As you know, my PM695 has 3 modes for noise reduction.
1. Off - for fast moving targets like cars and animals etc.
2. Normal - Everyday observation, hand held, non fast moving targets.
3. High - Lowest noise mode for static targets only and tripod mounting of camera is essential.
Having used these modes, it appears the noise reduction works by comparing captured frames and deleting the random elements before display. The frame rate appears much slower as a result. The PM695 provides a very nice image in the 'Noise redcuction OFF' mode and you can pan the camera easily. With the mode set to 'High', any movement of the camera or target causes really impressive image smearing and pixelation.
I would be amazed if FLIR did not employ noise suppression in the E series. Is it not possible that the noise suppression is switched OFF in service mode to provide the raw, fastest update without interferance from the noise algorithms and processes. That is what I would do in a service mode. Keep it to raw basics, without any bells or whistles active to confuse the testing or CALIBRATION
.caps.config.image.targetNoise.enabled bool true
.caps.config.image.targetNoise.targetNoiseMk int32 135
I can't help feeling that, with the 320x240 resolution, MSX has just 'crashed and burned'
I still like the idea on low resolution TICs and when there is low thermal difference between objects in the field of view.
60fps is a must for high speed thermography of targets moving through the field of view. 9fps is fine for static objects.
I recall that someone saw an E5 camera running at 60 fps at a German exhibition ? I don't think I deampt it. If so, the lens may not be such a limiting factor.
I remain surprised that the UI is so sluggish on this camera. From your investigations, it appears to use a powerful main processor. I wonder if the image processing hogs the MIPS ? FLIR need to fix that. Possibly verbose, inefficient programming combined with Win CE OS ?