I can state that this is not typical of the Pico384.
It looks like a timing glitch in the read-out IC but this could be caused in the video processing stage as well.
IIRC the ULIS Pico384 is the new generation of Microbolometers that just need the master clock input and not the usual H and V timing signals. The master clock generates all required timing signals for the ROIC. These are the H sync, V Sync and Pixel clock. The control lines to the ROIC set it up but do not create any timing signals.
Older generations of ULIS microbolometer were slaves to external timing signals and could even suffer damage if a timing signal was absent ! Designers had to be very careful about how they supplied the H, V and Pixel clocks to the microbolometer and safeguards were designed in to protect against loss of a timing signal.
The modern Pico384 acts more like a master timing source as once it is set up and has the master clock applied, it generates not only the internal sync and clock signals but it also outputs sync and clock signals to the video processing stages that follow. Effectively the master clock sets overall timing and the microbolometer ROIC sets all image related timings.
In your image it looks like a column is out of alignment but I suspect the microbolometer is rotated 90 degrees so it is a row error as you say. I am wondering whether the master clock contains a glitch signal that is causing this problem. It would be interesting to see an oscilloscope capture of the master clock to see how clean it is. Remember, we know the Pico384 does not normally have this issue and all it's timings come from the external master clock. The master clock is therefore the first place to check for weirdness
I am not certain that this is the problem though as the following rows are read out with the correct timing with respect to the rows that preceded the glitch. I would expect a master timing glitch to throw all subsequent rows out of step.
If this is a master clock glitch, the camera effectively has a fault and should be repaired under warranty.
Another possibility is a bug in the video processing stage that is introducing a timing offset in one row as it is read out. Note that the offset does not cascade through the following rows. The timing steps out of spec for one row of pixels and is then correct in the next row. Weird stuff. A software timing issue would be harder to diagnose without the camera in some form of debug mode.
Hope this is food for thought
Fraser
Home
Help
Search
Login
Register
