Page History

...

The window is established by the closing release of the reset switch on the input amplifier and then ended by the opening of the switch in the sample and hold.  Holes resulting from the ejection of electrons by the incidence of the x-ray photons are collected on the capacitor in the sample and hold section during the integration window when the switch is closed.  The window ends when the switch is opened and then the amplifier is again reset.  After some time to allow the sample and hold to settle, the ramp input and the counter start.  When the levels match the comparator fires and the counter stops, giving the digital value for output.

...

The integration window includes the arrival of the FEL and is framed by the closing release of the amplifier reset and opening of the sample and hold switch.  The duration of the integration window is determined by the "Int Time" parameter in the configuration.  A typical setting of 5000 gives an integration window of 40 microseconds.  To really understand the integration window we should look at the weighting function studies done by Sven Herrmann, Gabriella Carini, et. al. in various hutches at LCLS.

...

The weighting function shows the response at various flux levels vs time.  These curves are for a 40 microsecond integration window.  The 40 microsecond digital integration window starts with the command to close the sample and hold switchrelease the amplifier reset, at -40 microseconds in the above curves.  Since we now use the analog reset, several microseconds elapse from the time we command the release of the reset and when some response is seen in the curves.  In the discussion below we are talking about the digital window, but remember that the actual performance off the detector is determined by the curves show above.

Note also, that since the all the FPGA times start with a count of zero, we should addd one to the settings before using them.

The position in time of the integration window relative to the event code 140 timing, is the sum of three things. 

...

The second is the "Run Trig Delay" on the 140k and the "Run Delay" on the big CSpad.  For the 140k it is typically has been 11020, or 88.156 168 microseconds.

These first two contributions are not part of the actual acquisition cycle, but determine the start of it.

The next contribution is the "Acq Delay", clocked by the 125 MHz clock counted down by 128, so in units of 8ns * 128, or 1.024 microsecond.  A typical setting of 280, yields 286287.72 744 microseconds.

Applying the numbers on this places the start of the analog integration window at:

500 + ((11020+1)*0.008) + ((280+1)*1.024) = 874875.88 912 microseconds, with a 40 microsecond window ending at 920915.88 912 microseconds.

This would place the FEL (~896 microseconds) 21 20 microseconds into the window and 19 20 microseconds from the end.

When the stale stand-alone evr issue raised it's head, CXI scientists scanned and then used these numbers.

400 500 + (22580(11020+1)*0.008) + ((280+1)*1.024) = 867868.36 3912 microseconds, with a 40 microsecond window ending at 907908.363912

This would place the FEL 29 27 microseconds into the window and 13 from the end.  While this looks better in the curves above than our previous settings, it might be better still to go to about 30 microseconds into the window and 11 10 from the end.

While I am not suggesting changing the run trigger timing, changing the "Run Delay" to reflect this moving of the FEL 7.5 microseconds enough later in the window to put the FEL at about 30 microseconds into the window should be given serious consideration.  Specifically, that would mean setting the "Run Trig Delay" to 100809781, or 8078.704 256 microseconds.

This would bring the timing to:

500 + ((9781+1)*0.008) + ((280+1)*1.024) = 866 microseconds

Calculating the acquisition cycle time

The first contribution to the cycle time is the "Acq Delay" mentioned above as (280+1) * 1.024 microseconds, before the integration window.

...

After the integration window ends with the opening of the sample and hold switch, the logic waits "Dig Delay" in units of 8ns.  This is for the sample and hold to stabilize before we start the A to D.  A setting of 960 yields 7.68 69 microseconds.

Next the ramp into the comparator is started.  It steps "Dig Count" +1 times with a step interval of "Dig Period" +1 in units of 8ns.  The ramp completes its whole course so that all pixels, even those who are saturated with photons will see their comparators fire.  This total ramp time is thus ("Dig Count" + 1) * ("Dig Period"+1) in units of 8ns.  A maximum value "Dig Count" of 0x3fff and a "Dig Period of 25 yields a count time of 3,276407.6 9 microseconds.

Using these number we get:

((280+1)*1.024) + 40 + ((960+1)*0.008) + ((0x3fff+1)*(25+1)*0.008) = 36113743.000 304 microseconds.

Conveniently for our purposes, the firmware in the front end includes a method to count the acquisition cycle time when using these numbers.

...

Using a shorter "Dig Period" setting:

((280+1)*1.024) + 40 + ((960+1)*0.008) + ((0x3fff+1)*(12+1)*0.008) = 19072039.168 368 microseconds.

Yields:

acqTimer(645567)(5164536ns), or 5164.536 microseconds

In both cases, the cycle time includes 3.257368 125 milliseconds of unaccounted for time, that probably goes to transmitting the data, and is not configurable.