amazing project!
It clearly shows your dedication in every aspect of the complete project.
The lovely designed Focus mechanism.
The Housing.
The Software and even the PCBs are designed with love!
I really appreciate this.
Hi! Many thanks!
You are reading the sensor out with 60fps?
Yes, the raw 14-bit per pixel data is comming out at 60fps. I left in my previos posts a link to my google drive with a video, captured right from ther sensor.
Here is the link:
https://drive.google.com/file/d/1QfK6TBKxTnJjb9-Vjo1R4MsX56F_mhFq/view?usp=sharingI advise you to download (~180MB) this video before viewing, as not smart youtube downgrades video quality too much.
How low can the clock for reading go, so it i spossible to readout at 10fps? or ist just internally fixed to 60fps?
We don't have and I believe will never have access to datasheets of this core, so I actually don't know that. Original board is forwarding clock at 73.636MHz, I'm using the same value. You will be able to experiment with clock rate, as soon as the HDL-design will be published.
On the other hand, I don't think that you really need it. If you would like to integrate this camera with any other hardware, you can choose USB, HDMI, AV or a low speed interface access over GPIO lines at X9 connector of the P-board. I have plans to implement a SPI interface over GPIO line, so that you can control the camera and readout the video data at any FPS you would like.
For what is the CMD Pin on the sensor? 1 Wire? Any information on that?
Forget about any standard interface with this FPA, everything is proprietary, the CMD interface as well. There are a lot of thing to tell about, I'm preparing a special manual for this. Well, the short answer, this is a 1-bit command line, synchronous to the main clock (73.636MHz). It is used to control the sensor. According to my investigations, a special 22 byte command is sent to the sensor to get each new frame. First two bytes of the command are 0x3F and 0xC0. I'm 99.9% sure, that this is a preamble that helps the core to detect a new command. Why? There is no any other strobe to validate the incomming command, 0xC0 = ~0x3F, very likely to be a preamble. Also, the core does not stream anything if I flip any bit in these two bytes. Other 20 bytes keep some special data to control the sensor. Unfortunatelly, the command fields are not byte aligned, that makes investigations a bit harder. There are a lot of bits that do not affect anything. Also a command for one sensor may not fit another, as themal array parameters are very different from core to core. Though I don't know what all the command fields are doing, I could find some common command pattern that should fit all sensors and a single special field that you can quite easily tune to get the image. I have tested this algorithm on my three FPAs and could make all of them working well. I'm sure that the more people will play with this sensor, the faster we will find out the function of each command field. Another way is to reverse engineer the firmware and get this data from original EEPROM. But, I'm not sure that this is a good idea, as this is an intellectual property of Avtoliv/FLIR.