3
\$\begingroup\$

I have an image sensor problem and I am looking everywhere to identify the problem but couldn't. Attached is the problem I observe. As you can see there are several horizontal lines in the image.

enter image description here

So far, I have checked power, clocks and all seems in order. Appreciate any ideas you may have. (If I get a test image from sensor-diagonal tiles etc-, all seems to be good. So, I am assuming it is not communication with the sensor. Sensor datasheet is here)

I am not looking for a specific answer but more of a direction and/or ideas. Somebody with the right experience could know where to look.

Apparently this type of problems can be observed in other sensors. See the link.

I have realized, I missed out one critical information, if I reduce the clock frequency of the sensor the problem disappears. So there is a clock frequency dependency. However I do not suspect read out since if I set the test pattern, regardless of frequency all is good.

Imager Power Supply Noise figures

Analog Supply Analog Supply, AC mode

Digital Supply Digital Supply, AC mode

UPDATE

After further testing, I figured the problem is same in every frame. Previously, I was wrong. Here is the 4 images from different times. Images are stiched together, all 480x752

enter image description here

Improve this question
\$\endgroup\$
  • 1
    \$\begingroup\$ I could give you an answer, but it's under NDA. How do you want us to help you if you can't give us information? \$\endgroup\$ – stevenvh Oct 11 '12 at 7:47
  • \$\begingroup\$ @stevenvh nonconstructive. If you have something good to contribute I am all ears. \$\endgroup\$ – Ktc Oct 11 '12 at 7:48
  • \$\begingroup\$ Like I said: we can't help you if you can't help us helping you :-). I understand it's not your fault, but as it stands the question can't be answered IMO. (No I can't answer it either, not even under NDA :-)) \$\endgroup\$ – stevenvh Oct 11 '12 at 7:51
  • \$\begingroup\$ @stevenvh I am hoping this is a common enough problem that somebody with the experience will notice it. I just attached a link with a similar problem. \$\endgroup\$ – Ktc Oct 11 '12 at 7:55
  • 2
    \$\begingroup\$ Is the pattern of lines the same in every frame, or does it change from frame to frame? \$\endgroup\$ – Dave Tweed Oct 11 '12 at 12:17
1
\$\begingroup\$

If the pattern of the column is the same whenever they appear, the problem is called fixed-pattern noise. This is just something you need to deal with, especially when dealing with a raw sensor. The sensor vendor should be able to help with characterizing it.

To deal with it, you can either go through a manual calibration procedure that allows you to derive offset and gain correction factors for each column, which you then store in nonvolatile memory, or you can develop an adaptive algorithm that can recognize and compensate for FPN in live images on the fly.

To characterize the FPN, you'll need to take a series of flat-field images (same amount of light on each pixel) at various light levels (including completely dark) and various exposure times. For each combination of light level and exposure, take the average value of the pixels in each column, and average these values over many frames (to eliminate thermal noise).

From this set of data for each sensor column, you will be able to determine what gain and offset values to apply to that column to eliminate the fixed pattern. You will also be able to determine whether the correction values need to be different for different exposure times, or a common set of values will work well enough for all exposure settings.

You'll also want to do this across a number of individual sensors, to make sure that the statistical variations among sensors don't invalidate the solution you come up with.

Improve this answer
\$\endgroup\$
  • \$\begingroup\$ you may be right and it's a good suggestion, but FPN typically manifests itself as first column oriented noise and then pixel by pixel variation (which in the strictest sense is how the term should be used). \$\endgroup\$ – placeholder Oct 11 '12 at 15:15
  • \$\begingroup\$ @rawbrawb I am not entirely sure. Here is the real weird thing, I read the frame row by row. So that black lines manifests themselves across every row. So it is not I get a bad row, I get a bad column. Is this FPN? I doubt it. \$\endgroup\$ – Ktc Oct 11 '12 at 15:19
  • \$\begingroup\$ @rawbrawb It turns out all images has the same noise pattern, could this be FPN? \$\endgroup\$ – Ktc Oct 12 '12 at 9:06
  • \$\begingroup\$ @Ktc The datasheet (thanks for providing the link!) specifically talks about "row-wise noise correction" on page 49. Do you have this feature enabled? \$\endgroup\$ – Dave Tweed Oct 12 '12 at 11:52
  • \$\begingroup\$ @DaveTweed Yes, row noise correction has no impact. I think our noise is on columns. If you look at the second image I attached, the images are 90 rotated, so as you can see the noise is on the columns. \$\endgroup\$ – Ktc Oct 12 '12 at 12:06
1
\$\begingroup\$

Can you post the whole image? Looks like bias lines on the CCD. I'm also going to guess it is a high frame rate sensor, because the lines are so noticeable. Are you doing anything else while reading out, or doing anything else with the sensor? I think the timing for each line has to be consistent.

Improve this answer
\$\endgroup\$
  • \$\begingroup\$ Sensor is CMOS, global shutter. MT9V032 \$\endgroup\$ – Ktc Oct 11 '12 at 15:07
  • \$\begingroup\$ I am not doing anything during the read out other than FPGA dumping the data to memory. CPU is active but it is waiting on a flag for frame to be dumped. \$\endgroup\$ – Ktc Oct 11 '12 at 15:17
  • \$\begingroup\$ @Ktc - Is the MT9V032 that sensor which is supposed to be under NDA? The datasheet is available for download on the Aptina website. \$\endgroup\$ – stevenvh Oct 11 '12 at 15:31
  • \$\begingroup\$ @stevenvh They made me sign an NDA :). Edited the question to reflect that. \$\endgroup\$ – Ktc Oct 11 '12 at 15:32
1
\$\begingroup\$

This can arise through several mechanisms which I'll list. But there is asome analysis you can do as well.

1) There looks like a vertical line through the image in which it should be a uniform grey (right hand side) plot that single column on a graph and look for patterns. -> if you see binary count sequences then it's likely the row decoders on chip. --> "solution" would be to increase by-pass capacitors and try to filter/split power supplies more.

2) If the noise looks less like a count sequence but still has some characteristic frequencies. then it could be Power supply noise. Look to your how well you power supplies are filtered, how your ground planes are laid out.

--> as an aside, you can run a FFT over that sampled column to see if there are dominant frequencies.

--> knowing the line rate you should be able to calculate the frequency of the aggressor signal.

Improve this answer
\$\endgroup\$
  • \$\begingroup\$ I have check the power supplies. 3.3V analog and 3.3V digital. 3.3V has about 10mV noise on it, the 3.3V digital slightly more. There is 100nF on each supply and analog is protected with a ferrite filter. \$\endgroup\$ – Ktc Oct 11 '12 at 15:09
  • \$\begingroup\$ I originally forgot to mention, if I reduce the frequency of the clock from FGPA to the imager, things improve massively. \$\endgroup\$ – Ktc Oct 11 '12 at 15:12
  • \$\begingroup\$ Added in a comment but post has been updated to reflect that. \$\endgroup\$ – placeholder Oct 11 '12 at 15:13
  • \$\begingroup\$ Sensor can give diagonal or some value I set as a test pattern. I looked at the diagonal looked very good. Later I set the pattern to an arbitrary number (2) and checked every pixel and it seems they are all 2. So the problem is on the analog side. \$\endgroup\$ – Ktc Oct 11 '12 at 15:15
  • \$\begingroup\$ The test pattern generators are in the digital domain, so you really should get a clean signal regardless of how crappy your supplies are. the fact that it is mostly row oriented tells yo that it is a slower signal -> means (usually) your power supplies. \$\endgroup\$ – placeholder Oct 11 '12 at 15:19
1
\$\begingroup\$

I've noticed similar stripes when powering the analog part of the MT9V032 with a switching regulator and a passive LC filter. You could try to generate the analog supply with a linear regulator with low noise and good PSRR (e.g. TPS79333).

Improve this answer
\$\endgroup\$
  • \$\begingroup\$ My circuit already has TPS71701 after the switcher to avoid these problems. It should be clean enough. \$\endgroup\$ – Ktc Oct 16 '12 at 7:03
1
\$\begingroup\$

Do you have the schematics of the Aptina MT9V032 Camera Board (MT9V032_DEMO_HEAD)? You can see that every supply pin has its 100nF cap with 1uF in parallel, but the PLLVDD pin is erroneously connected to VAA. Check the MT9V034 Board instead. Ferrites are good for high frequency noise suppression, but they do not work on low frequency noise, they may even increase it. You could also try a Ripple Blocker, e.g. MIC94300 from Micrel. There are free samples available. Could you post the camera parts of your schematics and layout?

Improve this answer
\$\endgroup\$
  • \$\begingroup\$ Andreas unfortunately I cannot post the schematic and layout but we have 0.1u on all supply pins and 10u at the background for noise suppression. It seems you have specific experience with this IC, we couldn't find the problem so far. \$\endgroup\$ – Ktc Oct 23 '12 at 9:01
  • \$\begingroup\$ We suspect the issue is largely due to the mode we are using (snapshot) vs. the general mode (master) \$\endgroup\$ – Ktc Oct 23 '12 at 9:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.