Log of Problems and Solutions - Revision history

Weizeor: /* SOLVED 2-8-2012 Jitter and Flashing of image */

2013-01-09T14:07:34Z

SOLVED 2-8-2012 Jitter and Flashing of image

← Older revision		Revision as of 14:07, 9 January 2013
Line 1:		Line 1:
	== SOLVED 2-8-2012 Jitter and Flashing of image==		== SOLVED 2-8-2012 Jitter and Flashing of 1st column in image==
	'''PROBLEM:''' On front illuminated image it was observed that the images had a flashing on the first column and that there was a pixel jitter.		'''PROBLEM:''' On front illuminated image it was observed that the images had a flashing on the first column and that there was a pixel jitter.

Weizeor: /* SOLVED 2-8-2012 Jitter and Flashing of image */

2013-01-08T22:28:18Z

SOLVED 2-8-2012 Jitter and Flashing of image

← Older revision		Revision as of 22:28, 8 January 2013
Line 6:		Line 6:
	'''SOLUTION:''' Extend the end time of state 4 from 96 ticks to 245 ticks. This will prevent the system from entering state 5 until the fCRICs are done sending out their data. Since this state is only used for 6 pixles it will not have a signifigant inpact on the total readout time.		'''SOLUTION:''' Extend the end time of state 4 from 96 ticks to 245 ticks. This will prevent the system from entering state 5 until the fCRICs are done sending out their data. Since this state is only used for 6 pixles it will not have a signifigant inpact on the total readout time.

			== SOLVED 6-1-2012 Buffer chips could get more than 5V==
	'''PROBLEM:''' It was possible through software to apply more than 5V to the buffer chips. This allows developers and users to issue a "Self-Destruct" command. This has been tested out and verified to work. (Too soon to joke?)		'''PROBLEM:''' It was possible through software to apply more than 5V to the buffer chips. This allows developers and users to issue a "Self-Destruct" command. This has been tested out and verified to work. (Too soon to joke?)

	'''SOLUTION:''' Initially there was a Software fix, but a hardware solution ~~should~~ was implemented and was included in the final 12 boards.		'''SOLUTION:''' Initially there was a Software fix, but a hardware solution was implemented and was included in the final 12 boards.

	== NOT SOLVED YET ==		== NOT SOLVED YET ==

	Noise and gain not as good as we would like on the prototypes with the buffer chips.		Noise and gain not as good as we would like on the prototypes with the buffer chips.

Weizeor: /* NOT SOLVED YET - Buffer Chips should not recieve more than +5V */

2013-01-08T22:24:21Z

NOT SOLVED YET - Buffer Chips should not recieve more than +5V

← Older revision		Revision as of 22:24, 8 January 2013
Line 10:		Line 10:
	'''SOLUTION:''' Initially there was a Software fix, but a hardware solution should was implemented and was included in the final 12 boards.		'''SOLUTION:''' Initially there was a Software fix, but a hardware solution should was implemented and was included in the final 12 boards.

	== NOT SOLVED YET ~~- Buffer Chips should not recieve more than +5V~~==		== NOT SOLVED YET ==
	'''PROBLEM''' It is possible through software to apply more than 5V to the buffer chips. This allows developers and users to issue a "Self-Destruct" command. This has been tested out and verified to work. (Too soon to joke?)

	~~'''SOLUTION''' Software protection has been implemented in~~ the ~~GUI, but a hardware solution should be implemented~~.		Noise and gain not as good as we would like on the prototypes with the buffer chips.

Weizeor: /* SOLVED 2-8-2012 Jitter and Flashing of image */

2013-01-08T22:23:23Z

SOLVED 2-8-2012 Jitter and Flashing of image

← Older revision		Revision as of 22:23, 8 January 2013
Line 6:		Line 6:
	'''SOLUTION:''' Extend the end time of state 4 from 96 ticks to 245 ticks. This will prevent the system from entering state 5 until the fCRICs are done sending out their data. Since this state is only used for 6 pixles it will not have a signifigant inpact on the total readout time.		'''SOLUTION:''' Extend the end time of state 4 from 96 ticks to 245 ticks. This will prevent the system from entering state 5 until the fCRICs are done sending out their data. Since this state is only used for 6 pixles it will not have a signifigant inpact on the total readout time.

			'''PROBLEM:''' It was possible through software to apply more than 5V to the buffer chips. This allows developers and users to issue a "Self-Destruct" command. This has been tested out and verified to work. (Too soon to joke?)

			'''SOLUTION:''' Initially there was a Software fix, but a hardware solution should was implemented and was included in the final 12 boards.

	== NOT SOLVED YET - Buffer Chips should not recieve more than +5V==		== NOT SOLVED YET - Buffer Chips should not recieve more than +5V==

Weizeor at 20:56, 1 March 2012

2012-03-01T20:56:29Z

← Older revision		Revision as of 20:56, 1 March 2012
Line 1:		Line 1:
	== 2-8-2012 Jitter and Flashing of image==		== SOLVED 2-8-2012 Jitter and Flashing of image==
	'''PROBLEM:''' On front illuminated image it was observed that the images had a flashing on the first column and that there was a pixel jitter.		'''PROBLEM:''' On front illuminated image it was observed that the images had a flashing on the first column and that there was a pixel jitter.

Line 5:		Line 5:

	'''SOLUTION:''' Extend the end time of state 4 from 96 ticks to 245 ticks. This will prevent the system from entering state 5 until the fCRICs are done sending out their data. Since this state is only used for 6 pixles it will not have a signifigant inpact on the total readout time.		'''SOLUTION:''' Extend the end time of state 4 from 96 ticks to 245 ticks. This will prevent the system from entering state 5 until the fCRICs are done sending out their data. Since this state is only used for 6 pixles it will not have a signifigant inpact on the total readout time.


			== NOT SOLVED YET - Buffer Chips should not recieve more than +5V==
			'''PROBLEM''' It is possible through software to apply more than 5V to the buffer chips. This allows developers and users to issue a "Self-Destruct" command. This has been tested out and verified to work. (Too soon to joke?)

			'''SOLUTION''' Software protection has been implemented in the GUI, but a hardware solution should be implemented.

Weizeor: Initial

2012-03-01T20:38:30Z

Initial

New page

== 2-8-2012 Jitter and Flashing of image==
'''PROBLEM:''' On front illuminated image it was observed that the images had a flashing on the first column and that there was a pixel jitter.

'''CAUSE:''' The pipeline in the fCRIC must first be purge before we get the real data from the CCD. This is done in state 4 of the readout state machine. After state 4 the readot goes to state 5 where it starts saving data. The state machine was entering state 5 while in the middle of the data transfers started in state 4.

'''SOLUTION:''' Extend the end time of state 4 from 96 ticks to 245 ticks. This will prevent the system from entering state 5 until the fCRICs are done sending out their data. Since this state is only used for 6 pixles it will not have a signifigant inpact on the total readout time.