Products > Thermal Imaging

Shifted pixel columns on Therm-App

(1/5) > >>

Ultrapurple:
A number of Therm-App imagers have one or more pronounced 'streaks' on the display, where an entire column is shifted down (or up) one or more pixels. This is quite distinct from normal bad pixel effects: experiments have conclusively shown that it is a column being 'read late' (or early). The attached picture shows an example, which was deliberately engineered to look bad (zoomed image, sharp horizontal transitions etc). In Real Life™ it doesn't look anything like as significant.

Is the Therm-App (or the Pico384 it's based on) unusual in this respect, or is it something that's seen in other imagers?

Fraser:
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

Fraser:
The more I think about this, the more I think it is a software timing glitch in the video processing stages. The H and V sync signals are sent to the video processing stage. If for some reason one of the row read outputs is delayed during video processing, you will get your symptom. The next row will be resynchronised by the ROIC sync signal that is always correct and in step with the ROIC reading of the microbolometer.

Your symptom of a stepped row is like the video processing stage having a hiccup before resuming normal operation and synchronisation. Such a hiccup could be caused by higher priority processing task that interrupts the video processing stream. The fact that the stepped row remains on the image rather than just a single frame glitch suggests a repetitive hiccup caused by a timing locked interrupt of some sort.

I am way outside my comfort zone when it comes to the idiosyncrasies of software video processing timing signals and interrupts so maybe someone else will better understand what could cause this problem ? I may even be talking out of my backside. Forgive me if this is the case.

Fraser

Fraser:
The attached block diagram may assist you in understanding the topology of modern ULIS microbolometer camera system.

This information is already in the public domain so I am not releasing sensitive material

The DAC's set the bias voltages on the pixels and the ADC converts the analogue read-out of the pixels to digital format for video processing. Note the Reset/INT/MC inputs. The MC input is the Master Clock. The sync signal outputs can also be seen.

This is a development board for the ULIS Nano and Pico 384 and 640 microbolometers. It is similar in many respects to what will be configured within the therm-App but minus the ancillaries like the display etc.

Fraser

Ultrapurple:
Thanks Fraser

Mine is not the only one that has this issue; there has been some discussion about it on the  Flickr Therm-App group. The few examples posted on the Flickr page have the glitches in different positions on different imagers; by no means all are affected, and it seems to happen with different back-end processing software (the native Therm-App app and Therm-App Plus for definite, not sure about others) so that suggests it's either happening in the hardware/firmware or the driver. My thought is that it's probably happening in the hardware (ie sensor) because I had the same effect in the same place on the original firmware before it was upgraded from 9Hz to 25Hz frame rate.

Just to make sure we're speaking the same language, for the 4:3 384 x 288 Pico384 I'm calling the 384-pixel axis a "row" and the 288-pixel axis a 'column'. So, when held in TV orientation the rows are horizontal. The scan definitely seems to be row-by-row (the 8.7Hz version has the classic rolling vertical shutter effect), so why it would glitch at exactly the same place on each line - and read out the previous line is a total mystery.

My cameras are old enough to be out of guarantee. It was only because the warranty had expired that I felt comfortable having the case opened for the 25Hz upgrade: doing so goes straight through the 'warranty void' label.

So yes, it is very odd indeed. The only practical 'cure' suggested so far is to mark that entire column of pixels as bad, but that would probably be even more noticeable than the present glitch.

Can you post a link to fuller details of the dev board? I guess it's expensive...

Navigation

[0] Message Index

[#] Next page