Trying to solve the vertical clocking problem (Feb 4-7, 2005) Test conditions 277 kHz clock –...

7
Trying to solve the vertical clocking problem (Feb 4-7, 2005) Test conditions • 277 kHz clock – instead of the 100 kHz recommended • V_reset = 1V • V_bias_gate = 2.4 V • V_bias_power = 3.3 V • Vtesten, Htesten = 0 – a 1 enables frame and line checks • Formats: main -- 1024 x 1024 tried 2048 x 2048 also 512 x 512
  • date post

    21-Dec-2015
  • Category

    Documents

  • view

    213
  • download

    0

Transcript of Trying to solve the vertical clocking problem (Feb 4-7, 2005) Test conditions 277 kHz clock –...

Trying to solve the vertical clocking problem (Feb 4-7, 2005)

Test conditions

• 277 kHz clock – instead of the 100 kHz recommended• V_reset = 1V• V_bias_gate = 2.4 V• V_bias_power = 3.3 V• Vtesten, Htesten = 0 – a 1 enables frame and line checks• Formats: main -- 1024 x 1024

tried 2048 x 2048also 512 x 512

IR Single & CDS (1024 x 1024)

Used hot & dead columns as well as image features to identify the quadrants sampled in each frame

IR Single• 3 of 4 frames were of lower left quadrant (the one closest to origin)• 1 of 4 frames was of the upper left quadrant (1025 < y < 2048)

CDS• Every fourth frame cycle also exists here, but hard to determine orientation since

IR Single Frames (2048 x 2048)

Vertical• 1st frame

• bottom – none• Top -- 9 pixels

• 2nd & 3rd frames• bottom -- 5 pixels • Top – 4 pixels

• 4th frame• appears to be a

difference frame – can’t identify ref pixels

Vertical• 1st frame

• bottom – none• Top -- 9 pixels

• 2nd & 3rd frames• bottom -- 5 pixels • Top – 4 pixels

• 4th frame• appears to be a

difference frame – can’t identify ref pixels

11

22

33

44

Horizontal• 4-pixel borders on left and right

for images 1-3• can’t tell if it exists for 4th image

Horizontal clocking is okay

Folder: Feb4Filenames: IRS_2048_0017-20.fits

IR Single Frames (2048 x 2048)

• Turned on the reference pixel row to see if we can use it to distinguish start of frame

• REFMODE = 0, meaning that reference pixels are reset as with other pixels (instead of reset being during the entire read cycle)

• Now the frame has a streak pattern repeating every 4th column

Don’t understand why reference row alters the readings on all other pixels

• Turned on the reference pixel row to see if we can use it to distinguish start of frame

• REFMODE = 0, meaning that reference pixels are reset as with other pixels (instead of reset being during the entire read cycle)

• Now the frame has a streak pattern repeating every 4th column

Don’t understand why reference row alters the readings on all other pixels

Folder: Feb4Filename: IRS_2048_0021.fits

CDS Frames (2048 x 2048)

• Only frames 2 and 6 look anything like CDS differences. • Other frames might as well be IRSingle. • Note that the reference pixel row is still enabled, causing vertical streaks, and perhaps the gradients in frames 2 and

6.

• Only frames 2 and 6 look anything like CDS differences. • Other frames might as well be IRSingle. • Note that the reference pixel row is still enabled, causing vertical streaks, and perhaps the gradients in frames 2 and

6.

11

22

33

44

55

66Folder: Feb4Filenames: CDS_2048_0001-6.fits

Vertical clocking is problematic

• Can’t seem to generate LINECHK or FRAMECHK pulses, even after adding extra overclocking pulse for VCLK in idle-mode and read array assembly subroutines

FSYNCB

VCLK

LINECHK(same response for FRAMECHK)

HCLK

Should have been a pulse here for LINECHK & FRAMECHK, but seee NONE for either signal, even though internal & external settings

for VTESTEN & HTESTEN are set high<-----------------------

Adding an overclock to VCLK still doesn’t give FRAMECHK signal (change made to idle assembly routine)

Things are okay in the horizontal direction

• Two pre-charge pulses in HCLK give rise to three integrator pulses ? Why ?

• However, horizontal clocking is okay in both IRSingle & CDS images, so this is not a real problem

HCLK

Integ_out

Integ_in

Mux_out

conv

Falling edge of HCLK clocks in new pix