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

    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