Page History
Geometry
Panel geometry
- size of the ASIC is 192*384
- epixm panel: raw shape:(1, 384, 768) or: (384, 4*192)
- 50um x 50um pixels, no wide pixels
Code Block | ||||
---|---|---|---|---|
| ||||
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
|
Test data
Code Block | ||||
---|---|---|---|---|
| ||||
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...] |
...
s3df: /sdf/data/lcls/drpsrcf/ffb/tst/tstx00417/xtc/ request Wilko to synchronize with psdm?
Geometry
Panel geometry
- size of the ASIC is 192*384
- epixm panel: raw shape:(1, 384, 768) or: (384, 4*192)
- 50um x 50um pixels, no wide pixels
Code Block | ||||
---|---|---|---|---|
| ||||
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 |
Gain
Configuration info for gain (from Ric's e-mail) for AHL, SH, SM
Mode | CompTH_ePixM | Precharge_DAC_ePixM | |
---|---|---|---|
Auto-gain | 12 | 45 | |
Soft High | 0 | 45 | |
Soft Low | 63 | 50 |
References
- EPIX10KA2M References
- EpixM - by Ric and Chris
Overview
Content Tools