0
\$\begingroup\$

I am reading a video signal from a CCD array. For some reason I get this extreme vertical jitter. I use decoupling and bypass caps everywhere possible. But it does not seem to be the noise issue. Any one has an idea of what could be the reason of such jitter? The yellow clock signal is just for reference. Here are superimposed frames of the video:

enter image description here

TRIED:

  1. Different illumination intensities - the fluctuations present in the dark too.

  2. Tried different light sources: flashlight, diode lamp, luminescent lamp, laser.

  3. Tried running the microcontroller with the internal clock (no external oscillator).

  4. Tried running the setup from a 12V battery (no mains).

  5. Tried using electronic switches DG642 and EL7156 instead of direct connection to the microcontroller.

  6. Tried switching/interchanging the probes (as you can see, the TTL signal looks just fine).

  7. The oscilloscope and the power supply seem to be grounded since the power sockets have the third 'ground' pin.

  8. Tried three different kinds of CCD arrays.

  9. Do not seem to have any high power electromagentic devices around me.

  10. When I measure a signal from a waveform generator, no fluctuations are present.

  11. I use bypass and decoupling capacitors everywhere I should.

I am seriously stuck. Please, help!!!

Perkin Elmer RL1024PQ sensor

Vishay DG642 video switch (pin driver)

Intersil EL7156 pin driver

\$\endgroup\$
15
  • \$\begingroup\$ Why you are direct us to fake buttons? Do you have your own case in photo or even in rough sketch? Your field of interest it is very important, but please help the community to support you. \$\endgroup\$
    – GR Tech
    Apr 7 '14 at 20:51
  • \$\begingroup\$ It's difficult to explain what I mean. The picture does not provide enough information. I can not upload video on stackoverflow website. So, I uploaded it to the website with the link in the question. \$\endgroup\$
    – Nazar
    Apr 7 '14 at 20:55
  • \$\begingroup\$ also, what I mean by 'jitter' is the fluctuating amplitude of the signal. The horizontal segments should be stable flat. \$\endgroup\$
    – Nazar
    Apr 7 '14 at 20:59
  • \$\begingroup\$ OK. The orientation of the capture plays important role: In 90 deg. turn looks like as jitter, but in the correct orientation it is fluctuation!! \$\endgroup\$
    – GR Tech
    Apr 7 '14 at 21:02
  • 1
    \$\begingroup\$ The waveform on your scope is inverted from the one shown in the datasheet. You're going to have to show us your CCD interface circuitry, including all of the clock drivers as well as the video output chain and ADC. \$\endgroup\$
    – Dave Tweed
    Apr 14 '14 at 13:26
1
\$\begingroup\$

First off, you are not seeing jitter, jitter is a lateral (time) variation in a vertical edge this is a vertical variation (voltage) in a flat part of the curve.

So this sensor is designed to be operated as a CDS type signal processing scheme, sample the reset level sometime after Phi_rg is high and before Phi_1 negative edge and then sample again once the floating gate settles (Q_2 dumps charge onto the floating node). This removes the common signal and the KTC noise signal.

In general these types of devices should not be driven from a micro-processor. The voltage variation on the waveform (both jitter wise and in amplitude) couple directly into the sense node and inject a signal into the most sensitive part of the whole sensor.

When I designed with these devices we would derive signals from an FPGA and then re-clock them externally with SGL (single gate logic) D-FF to remove Jitter and these would be powered from a separate power supply with lots of filtering.

Your power supply rails of your micro-processor are bouncing your signal that then is capacitively coupled to the sense node through the RG transistor of the sensor. Clean up that signal chain and do CDS.

You also have to be careful with edge rates on the CCD transport registers and return current flow on the PCB (signal bounce). Vrd (see page 4) also has to be very very clean. i.e. a separate power supply/regulator.

\$\endgroup\$
3
  • \$\begingroup\$ Would it matter to use CPLD or FPGA? Also, I could use SGL on only two out six clocks. Since other clocks require weird voltage supplies: -4V +4V, 0V 8V, -4V 8V... The application note for this CCD recommends to use pin drivers (referenced in the question above). Would the be equivalent to your SGL? Any recommendations? \$\endgroup\$
    – Nazar
    Apr 18 '14 at 14:00
  • \$\begingroup\$ FPGA or CPLD either should be fine as long as you "buffer" them through an external driver that has a clean supply (and separate). Of course I am assuming you want to get the cleanest images possible, you can compromise if you don't want that. \$\endgroup\$ Apr 18 '14 at 22:53
  • \$\begingroup\$ Just learned VHDL. Now - setting up the CPLD. In the second passage of your answer you recommend to sample the signal twice: first one within the high state of RG gate and the second time when H1 (yellow signal on the image) is low? Right? I plan to have a 10MHz data rate, so sampling would be tough if I was taking two samples. Is there a good way to sample and hold until I get the second sample, and then use differential ADC to calculate the signal? \$\endgroup\$
    – Nazar
    May 6 '14 at 13:43
2
\$\begingroup\$

Try syncing your scope on the power mains. If the voltage fluctuation becomes stable, then likely you have interference from an outside electrical source coupling into your circuit. Fluorescent lighting would be a good candidate. Try shutting down or moving away from any high power electric motors or other equipment. Also cover the CCD lens and make sure that you have an electrical problem even with a black scene. It's possible that you are seeing the optical effects of room lighting variations as captured by the CCD.

\$\endgroup\$
7
  • \$\begingroup\$ NateOcean, thank you. The power cord of the oscilloscope has a third ground pin, so I assume that it is synced to the power mains. I do not really have any other high power equipment next to me. Also, covering the array + turning off all the lights produces the same fluctuation. The image shows the output signal after four Op Amp stages. However, when I measure the signal directly form the CCD video output, the fluctuations are there too. Any other suggestions? \$\endgroup\$
    – Nazar
    Apr 8 '14 at 13:05
  • \$\begingroup\$ I just tried a different brand of CCD. The same problem. So, I guess it is indeed some external effect. Is there any way to fix it? \$\endgroup\$
    – Nazar
    Apr 8 '14 at 13:33
  • \$\begingroup\$ Having an earth pin does not mean your scope is synced to the mains - a common name for mains sync mode is "line", look for it in the trigger / time-base config. (bring back knobs & buttons on scopes I say!) \$\endgroup\$
    – John U
    Apr 9 '14 at 19:41
  • \$\begingroup\$ Just tried to measure in the 'video' trigger mode (Rigol DS1102E). Still the same problem. I do not think that it's just a measurement artifact. First, I noticed this problem when I connected the CCD to an ADC. I had extreme noise of the entire image. Then I zoomed in on the signal and found out that I have these fluctuations. \$\endgroup\$
    – Nazar
    Apr 9 '14 at 20:17
  • \$\begingroup\$ Just to check a few things since I have probably spent years staring at video waveforms, what is the bandwidth of the scope? Have you adjusted your probes using the calibration square wave from the scope or another source? It just reminds me of probes that are not adjusted for impedance. \$\endgroup\$ Apr 9 '14 at 23:34
1
\$\begingroup\$

This is what normal linear Pixel array signals look like without using HSync on scope to HSync on display chip. Clock speed affects gain from light integration time and thus amplitude sensitivity. Variation between pixels shows as your jitter between pixel integration values. Since there are black pixels at each end included with fringe pixels, most of the amplitude variation will be at both ends. Since you are displaying all the pixels overlapped, it will appear as amplitude jitter. I might expect the outer 10 pixels to be most affected by aperture effects. Custom devices without black window apertures will improve on this feature but lack the black level. I suppose that is why they have 10 black (blocked) pixels at each end.

  • I have not found any application notes, but the buffered frame rate is 200KHz out, but the imager input is 70KHz max. Frame rate.

- What steady light source are you using and what are the dominant wavelengths. There will be more ripple in the blue range for light sensitivity "non-uniformity" . The older products have specs like +- 6% @50% , 635nm, which is red.

  • What frame scan rate?
  • Where is your schematic and test conditions?
  • Are your scope probes calibrated? The TTL has excessive overshoot, as does the video. Use a very short gnd lead.
  • is there any switched capacitance signal injected by the switches?
\$\endgroup\$
0
\$\begingroup\$

From a quick look at your scope shot, it seems this jitter you are referring to is actually your signal. It seems we are looking at the value of individual pixels being clocked out. Since only a few can be shown on the scope at a time, snapshots of many different short runs of pixels are displayed in rapid succession on the scope. The different brightness values from the different pixels therefore show up as different heights of the output waveform.

\$\endgroup\$
7
  • \$\begingroup\$ I thought so too, but if I provide uniform illumination (or absolute darkness) on the array, all active pixels should show similar heights. Which is not the case. I realize that not all pixels are ideal, but my low to high range is about 2V, the deviation of 400mV (which is 20%) is a lot. \$\endgroup\$
    – Nazar
    Apr 14 '14 at 15:45
  • \$\begingroup\$ @Naz: Have you actually looked at the resulting picture? \$\endgroup\$ Apr 14 '14 at 15:47
  • \$\begingroup\$ Yes, I just did. It shows a wavy pattern at about 200kHz. \$\endgroup\$
    – Nazar
    Apr 14 '14 at 15:53
  • \$\begingroup\$ How can you see 200 kHz on a video monitor?? \$\endgroup\$ Apr 14 '14 at 17:08
  • \$\begingroup\$ @ScottSeidman You probably can not ))). But since I knew the time to acquire one line, I counted how many wave crests were on one line, and thus, approximate frequency. \$\endgroup\$
    – Nazar
    Apr 14 '14 at 21:14

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.