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

  • timescale is July 2021
  • archon is name of controller (not sensor)
  • manufactured by STA company
  • 4096x256 we think (Phil says 4x larger than LCLS1, so maybe 8192x512?)
  • TTL trigger
  • unusual batched-image output that makes timestamping more difficult
  • trigger timing delays should be same as LCLS1 since it's the same accelerator.
  • have a front-end node feeding drp
    • also discussed having data go directly to DRP, but we felt it was less flexible
  • two modes:  full-image "tuning" (10Hz) and high-rate "lineout" (up to 200Hz).  they may have sped it up.
    • in full-image mode you get a "clear" on each trigger
    • in high-rate line mode runs continuously (can do a "clear" but slows it down)
    • CONCERN: is timestamping fast enough?
  • camera trigger event-code must be a low enough rate to be compatible with the full-frame readout in "tuning mode"
  • funky state-machine-like programming interface (STA-provided qt gui (includes an IDE for writing a sequencer program which Kaz also uses)
  • standalone non-IOC program on the front-end that speaks p4p
  • configuration via PVs
  • if triggering too fast, aborts frame acquisition, but frame counter still goes up by.  so you can detect dropped triggers
    • 64-bit camera-timestamp information is also provided to help detect off-by-one (reset when camera is put in acquisition mode)
  • have a PV "macro" that changes many settings to switch between tuning/lineout mode
  • visualization for tuning mode: if it's done in C++ can maybe support both CA/PVA (pythonViewer needs CA)
    • question: should we use AMI or python viewer?
  • drp run pvaDetector (Dan has concerns that 200Hz won't be possible with epics AreaDetector, maybe have to use tcp (easier than pgp)? could still be CA, just not AreaDetector)
  • evr in the front-end node.  should it be an xpm-style (like encoder) or controls-style (like Andor).
    • advantage of XPM style is that it stop at endrun which helps avoid longterm off-by-one.  maybe important because timestamping is more difficult than Andor.
    • need to ask Matt:  can we change the eventcode locally on the evr (our preference) or do we have to change an xpm setting
  • ask Matt: should the front-end node be able to assert dead time?
    • possible answer from cpo: feels like front-end node will read out as best it can, and if it can't keep up it won't send out an image on every shot, which PVADetector can tolerate.
  • ask Matt: if we use an xpm-style evr how do we get the timestamp?  Chris Ford should know this too from his encoder work.
  • might be an Archon PC in ASC that could be used as the front-end box.  Needs the EVR.
  • most software development can be done without a sensor (or sensor powered off, for safety)
  • Archon has a static IP interface (doesn't do DHCP) so typically plug it in directly to PC.
  • ask detector group: has the controller been changed?  might require changes to code.

Archon Complexities

From Dan Damiani on Nov. 17, 2023 after most of it is implemented

  • Dan thinks we won't reach 200Hz (timestamp fetching doesn't work, channel-access area detector won't be fast enough)
  • If batching is disabled (called "linescan" mode in IOC) only get ~20Hz but each image is timestamped, so more reliable
  • If batching is enabled get much higher rates, but only the first event is reliably timestamped and a "frame complete" time which is the end of the frame.  but we roughly know what the readout time, so get some measure of the last image time.
    • would be nice if manufacturer would timestamp every frame
  • Major concern: about once per day the camera can lose timestamp synch, either in batched or unbatched mode
    • Mike B. thinks this might be because we're missing a timestamp from the TPR timestamp FIFO with the "event2" module
    • This could be an effect of the fake evg (done in software).  Might be OK for real timing system.  We'll see when we hook it up in the hutch.
  • Dan is going to write a "resynch" script because the timestamp synching is somewhat complex because linescan mode must be disabled
  • A good thing: unlike the andor this camera can have a "fast clear" generated by the trigger signal which Dan put in the .acf file.  Can also have a continuous-clear, but could be partway shifting the charge out when a trigger comes in.
  • source code for libarchon.so lives in lcls1 daq but can be compiled standalone and gets included in the IOC.  Also a ton of code in the IOC.  Three .acf files (code for microcontroller) for the various generations of controllers.

Common Mode Algorithm

From Phil Hart.  He writes: "Hi, in 2d mode I see very little difference.  In 1d mode I just checked and see
test pixel region mean rms tInt500_no_CM: 3.90
test pixel rms tInt500_with_CM: 3.75

That's in electrons.  I guess it doesn't matter that much.  Still eventually we'll need some calibration information beyond pedestal, and the users won't want the test pixels (if psana exposes them - I should have mentioned the above code runs on the native format)."

    if ped is not None:
        if True:
            for r in range(rows):
                colOffset = 0
                for b in range(1, banks+1):
                    try:
                        frame[r, colOffset:colOffset+bankN] -= frame[r, colOffset+bankN-36:colOffset +bankN].mean()
                    except:
                        rowCM = -666
                        print("rowCM problem")
                    colOffset += bankN
  • No labels