1 / 7

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

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

kamala
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. IR Single Frames (2048 x 2048) • 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 • 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 1 3 Folder: Feb4 Filenames: IRS_2048_0017-20.fits 4 2

  4. 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 Folder: Feb4 Filename: IRS_2048_0021.fits

  5. CDS Frames (2048 x 2048) 1 3 5 2 4 6 Folder: Feb4 Filenames: CDS_2048_0001-6.fits • 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.

  6. Adding an overclock to VCLK still doesn’t give FRAMECHK signal (change made to idle assembly routine) FSYNCB VCLK 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 <----------------------- LINECHK (same response for FRAMECHK) HCLK 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

  7. Falling edge of HCLK clocks in new pix Mux_out Integ_in Integ_out HCLK conv 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

More Related