You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Geometry

Panel geometry

2024-03-18 e-mail exchange about epixm panel geometry
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

e-mail exchange with Ric about test data
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


Ric created runs 308-data, 309-dark on

psdm: /reg/neh/operator/tstopr/data/drp/tst/tstx00417/xtc/

s3df: /sdf/data/lcls/drpsrcf/ffb/tst/tstx00417/xtc/ request Wilko to synchronize with psdm?

References

  • No labels