General Notes

STA Archon X12: http://www.sta-inc.net/wp-content/uploads/2013/08/Archon.pdf

  • Variable name is: QRIX:STA:CCD:01:IMAGE1:Pva:Image, but only have to provide QRIX:STA:CCD:01:IMAGE1 to pvaDetector
  • this works: caget -S QRIX:STA:CCD:01:LAUNCH_EDM 
    • currently returns /cds/group/pcds/epics-dev/ddamiani/ioc/common/archonCam/current/children/build/iocBoot/ioc-qrix-archon1/edm-ioc-qrix-archon1.cmd
  • to synch the timestamps have to run at low rate (1Hz) and click "Set" on the main panel while running
    • NOTE: we also have to disable "Linescan" mode in the submenu (i.e. turn off the frame batching) to do this
  • IMPORTANT: Dan writes about Linescan boolean (i.e. batching): only use it for FVB at rates above 10Hz.
  • currently (Feb. 26, 2024) the camera is unresponsive to requests to transmit new frames.  used to work in the detector lab (an older LCLS1 machine).  issue with network interface or sysctl params?
  • currently runs on daq-rix-ccd-01
  • currently working rate is 1Hz: issue could be either the daq readout machine or the controller
  • FVB mode is 1x4800.  Full frame is 4800x1200
  • One big piece of silicon, but 16 readout chips that readout in parallel in the 4800 direction (300 each)
  • Area detector IOCs run into trouble at high rates.  300Hz is hopefully OK.  1kHz is very worrisome (worry software timestamping wouldn't work at this rate either).  this is because the IOC can overwrite a buffer that hasn't been transmitted yet.  In particular the timestamp would get corrupted (perhaps related to gateway timestamp corruption issue?).  Dan puts in a 1ms sleep between frames to avoid this.  No obvious buffer-locking mechanism that would protect against this in the IOC.  Possible workaround: could make an IOC that doesn't depend on epics area-detector code.
  • Archon supports
    • full image
    • full vertical binning
    • partial vertical binning (8x, 16x). Found we could get 10Hz with 16x.
    • horizontal binning (but no horizontal ROIs that give any speedup)

The "Linescan" boolean turns on/off batched-images:

Calibration

Archon pedestals can be deployed to the calibration database using this command line from Mikhail.  See this page for details about this command: Dark processing for LCLS2 area detectors.

det_dark_proc -k "{'exp':'rixc00121','run':140,'dir':'/sdf/data/lcls/drpsrcf/ffb/rix/rixc00121/xtc','detectors':['archon']}" -d archon -o work -D

Bank Structure

There are 16 banks of 300 pixels (4800/16=300).  The last 36 pixels of each of these banks are test pixels which can be used for common mode.

Daniel Jost writes:

We are confident, that 4224 px should be the correct number for the detector. I can double check with the manufacturer, but there is another piece of the puzzle. When we plot up the FVB images taken in run 139 we see very pretty noise. However, the detector area has regions with different gains and should thus yield steps in the spectra. I attach example plots.

Archon_det_px.pdf

Phil writes:

note that there are test pixels which don't correspond to the CCD active area.

My simple common mode algorithm does
cols = 4800
banks = 16

...
                for b in range(1, banks+1):
                    try:
                        frame[r, colOffset:colOffset+bankN] -= frame[r, colOffset+bankN-36:colOffset +bankN].mean()
...

So I claim that

>>> 4800 - 36*16
4224

is what you want.  The users don't want the 36 test pixels/bank.  That's what I was talking about re sacrificing columns for timestamping and making sure it didn't mess up common mode or v.v.. 


  • No labels