...

• will use a new detector for beam time
• *** 5kHz epixM
  • run-trigger and daq-trigger patterns:
    • 5k,5k
    • 5k,120
    • 5k,2.5k
  • matt provides "divisors-of-5k" script which should still work
• *** timing scans
  • (done?) configuration scan
    • Looks like cas/epixhr_timing_scan.py should work for the ePixM, too
• *** fibers/nodes
  • have 11 working fiber pairs and 1 broken one. epixhr uses 3 (2 data 1 timing) epixm uses 5 (4 data 1 timing 1 register)
    • • cpo submitted Jira to fix broken fiber and add fix cassettes between 208 and src
      • need to check that all 11 are working
  • Chris Ford is tasked with running timing/data fibers in 208/srcf and by default will use cmp034 for the epixM
    • • need detector group help going from mezzanine to hutch
• *** does psana handle disabled lanes correctly?  currently the disabled lanes get a fixed number put in them (lane-number).  this may work with Mikhail's.
• tstx00417 in ~tstopr/data/drp/tst/tstx00417/xtc/ runs 313 and 314 but shape may be incorrect.
  • (done) run 316 has the data organized as (4, 192, 384).  Previously, it was (1, 384, 768).
• cable to see acquisition window on the scope?
  • dawood will check
• intensity scans
  • done by changing the beam so no work required from daq group
• pedestals
  • soft-low
  • soft-hi
  • threshold in the middle SA
  • mikhail will work on "placeholder" infrastructure but there are subtleties that we won't worry about for the beam time 
• don't necessarily need calibrated data
• (lower priority) more precisely define how we handle the gain-switching, if at all?
  • soft-low (configurable threshold at one extreme)
  • soft-high (configurable threshold at the other extreme)
  • configurable threshold in the middle
  • what are the nominal gains? nominal gain ratio is 4.7
• bit 15 is gain mode, bits 0-14 are data.  data bits may be trimmed in the future (13 or 12?)
• (lower priority) charge-injection
  • mikhail/ric are putting in placeholder code, but doesn't work: waiting for ASIC/FPGA fix

DAQ-Segments With Multiple Free-Floating ASICs

*** problem: 1 epixM segment has 4 "panels" ("multi-panel segments")
*** need to add new idea: "panels"

Conclusion (mikhail's requirement): if we had a 12-asic epixm detector, then each epixM daq-segment must have "quanta" 4 panels (3 daq-segments total).  Agreed! three .xtc files each with shape (4,192,384) but det.raw.raw() reshapes it to (12,192,384).  Mikhail 

Terminology: segment means daq-segment.  What's the terminology for asics in daq-segment?  panels, virtual-segments, asics, sub-segments, vsegment?  Mikhail suggests we use "panels" for now.

everything stays the same (1 serial number per segment)
except: 1 segment has 4 panels with geometry that is looked up with seg serial#
does it make it easier to reshape (4,192,384) to (384,768) but has variable geom?
  - doesn't help.  difficulty: breaks rule that all panels are identical
could we add a new "segment" idea where we override the daq-segment-numbers? "panels"

processing of partial detector is important (e.g. daq-segments 2,7)