2/14/2024 4:33 PM
Dubrovin, Mikhail
O'Grady, Paul Christopher
Hi Mikhail,
  I have pushed an update to the ePixM detector interface to git (epixm320.py), so I believe it is ready for you to make more real.  I recorded some data for run 308 in /reg/neh/operator/tstopr/data/drp/tst/tstx00417/xtc, which is accessible from any NEH DRP host (drp-neh-cmp0*) and also even from psbuild-rhel7.  Could you take a look when you have some time?  In case it helps, we have a confluence page for the ePixM at https://confluence.slac.stanford.edu/display/PSDMInternal/EpixM.  Feel free to add to it.
  This request can almost certainly wait until Chris gets back, if you prefer.
  Thank you,
  Ric

Dubrovin, Mikhail
Thu 2/15/2024 2:48 PM
Hi Ric, Thank you, I will check what needs to be done. Mikhail
Claus, Ric

Dubrovin, Mikhail
Thu 2/22/2024 8:40 AM
Hi Ric, Why are you doing this on pcds? Are these data available on s3df? Mikhail

Dubrovin, Mikhail
Thu 2/22/2024 8:44 AM
In /sdf/data/lcls/drpsrcf/ffb/tst/tstx00417/xtc/ I see tstx00417-r0305-s000-c000.xtc2 as a las run. There is no run 308. Mikhail


===

3/15/2024 4:54 PM
Dubrovin, Mikhail
O'Grady, Paul Christopher
Hi Mikhail,
  I took a short pedestal run with the ePixM.  The file is here: /reg/neh/operator/tstopr/data/drp/tst/tstx00417/xtc/tstx00417-r0309-s001-c000.xtc2.  As before, you may need to copy this file to a more convenient working space for you as I think the FEE teststand doesnт€™t have access to the more usual file systems.
  Since Iт€™m not sure that Iт€™ve got the code right yet, this run was taken at 1 Hz with 10 events per step.  There are 3 steps in which the gain mode changes as per the ePixM confluence pageт€™s Pedestal Scans and Charge Injection section.  You can find the page here: https://confluence.slac.stanford.edu/display/PSDMInternal/EpixM
  On Chrisт€™s encouragement, Iт€™d like to ask to you to take a look at the file and let me know of any issues you find.  Once the bugs are sorted out, I can then take a longer run with, say, 2000 events per step at a higher rate for more detailed analysis.
  Thanks,
  Ric

3/15/2024 5:44 PM
Dubrovin, Mikhail
Claus, Ric
O'Grady, Paul Christopher
Hi Ric,
Thank you for the reference to the file. I will try to check if it works for dark calibration asap.
Mikhail
Claus, Ric

====

datinfo -k /reg/neh/operator/tstopr/data/drp/tst/tstx00417/xtc/tstx00417-r0309-s001-c000.xtc2

(ps-4.6.3) [dubrovin@psanagpu106:~/LCLS/con-lcls2]$ datinfo -k /reg/neh/operator/tstopr/data/drp/tst/tstx00417/xtc/tstx00417-r0309-s001-c000.xtc2 -d tst_epixm
==== 00 run: 309 exp: tstx00417 detnames: tst_epixm
run.timestamp LCLS2 int: 4943735348944167 > epoch unix sec: 632303053.357981 > 1990-01-13T23:44:13
tst_epixm detector object
step_docstring detector object is missing
det.raw._seg_geo.shape(): _seg_geo is None

Step 00  metadata: None
  Event 00000 t=632303054.942564sec dt=632303054.942564sec/record ndarray from list: segments shape:(1,) size:1 dtype:int64 [0]  timing is None, pulseId is N/A
    det.raw.raw(evt) shape:(1, 384, 768) size:294912 dtype:uint16 [20241 20020 18446 18837 19347...]
[W] epix_base._cbits_config_segment - MUST BE REIMPLEMENTED - return None
None
  Event 00009 raw  shape:(1, 384, 768) size:294912 dtype:uint16 [20213 20026 18372 18801 19424...] 

Step 01  metadata: None
  Event 00000 t=632303064.739798sec dt=9.797234sec/record ndarray from list: segments shape:(1,) size:1 dtype:int64 [0]  timing is None, pulseId is N/A
    det.raw.raw(evt) shape:(1, 384, 768) size:294912 dtype:uint16 [45911 49264 43317 47515 46529...]
[W] epix_base._cbits_config_segment - MUST BE REIMPLEMENTED - return None
None
  Event 00009 raw  shape:(1, 384, 768) size:294912 dtype:uint16 [46034 49268 43426 47506 46702...] 

Step 02  metadata: None
  Event 00000 t=632303074.537032sec dt=9.797234sec/record ndarray from list: segments shape:(1,) size:1 dtype:int64 [0]  timing is None, pulseId is N/A
    det.raw.raw(evt) shape:(1, 384, 768) size:294912 dtype:uint16 [20301 20071 18393 18848 19429...]
[W] epix_base._cbits_config_segment - MUST BE REIMPLEMENTED - return None
None
  Event 00009 raw  shape:(1, 384, 768) size:294912 dtype:uint16 [20291 20035 18353 18798 19387...] 
Problem reading dgram header.
[I] DONE, consumed time 4.192 sec


Event 00009 raw  shape:(1, 384, 768) size:294912 dtype:uint16 [20291 20035 18353 18798 19387...]

O'Grady, Paul Christopher
Tue 3/19/2024 8:46 AM
Good to know … thanks for the clarification, Chris. chris
Kenney, Christopher J. <kenney@slac.stanford.edu>
O'Grady, Paul Christopher
Alnajjar, Dawood;
​Doering, Dionisio;
​Claus, Ric;
​Dubrovin, Mikhail
​
Hi Chris,
Your assumption has always been correct - until now.
For ePixM each detector is composed of four mechanically separate chip pairs. 
These ASIC-"sensor" pairs are significantly more complex and hence risky and may have lower yield. These
"sensors" are also limited in size to one lithographic reticle field. 
Sorry.  But ePixM will need metrology. 
Thanks,
Chris
O'Grady, Paul Christopher <cpo@slac.stanford.edu>
​
Kenney, Christopher J.
​Alnajjar, Dawood;
​Doering, Dionisio;
​Klaus, Ric;
​Dubrovin, Mikhail
​
Hi Chris,
Just to check: I had the impression these units of 4 asics (whether in a square or in a line) should be one solid piece of silicon which shouldn’t need metrology.  Do I misunderstand?
chris

Kenney, Christopher J. <kenney@slac.stanford.edu>
​Alnajjar, Dawood;
​O'Grady, Paul Christopher;
​Doering, Dionisio
​Claus, Ric;
​Dubrovin, Mikhail
​
HI Mikhail,
I've performed a metrology on a module and will provide you with the file this week.
Thanks,

Chris
Alnajjar, Dawood <dnajjar@slac.stanford.edu>
​O'Grady, Paul Christopher;
​Kenney, Christopher J.;
​Doering, Dionisio
​Claus, Ric;
​Dubrovin, Mikhail
​
Hi Mikhail & Chris,
Thanks for reaching out. The Pixel size is 50um x 50um, and we assume no large pixels at this point. Also there are no gaps between pixels. 
@Kenney, Christopher J. would you know if there are gap between the ASICs?
Thanks,
Dawood

Alnajjar, Dawood <dnajjar@slac.stanford.edu>
​O'Grady, Paul Christopher <cpo@slac.stanford.edu>;
​Kenney, Christopher J.;
​Doering, Dionisio
​Claus, Ric;
Dubrovin, Mikhail
​
Hi Mikhail & Chris,
The Pixel size is 50um x 50um, and we assume no large pixels at this point. Also there are no gaps between pixels. 
@Kenney, Christopher J. would you know the gap between the ASICs?
Thanks,
Dawood

2024-03-18 11:18am
O'Grady, Paul Christopher <cpo@slac.stanford.edu>
​Kenney, Christopher J.;
​Doering, Dionisio;
​Alnajjar, Dawood
Claus, Ric;
​Dubrovin, Mikhail
​
Chris K., Dionisio, Dawood,
Could you send Mikhail the geometry for the 4 asic epixm panel?  He needs to know pixel sizes (including things like “large pixels”) and any gaps between pixels/asics.
Thanks!
chris