Hi everyone, I am looking to get the ToT out of my detector. I am using the GenericPropagation, Pulse Transfer, and DefaultDigitizer modules to obtain the signal. I have added a threshold and set the qdc_offset to the negative of the threshold. I got the image below and not sure why it doesn’t look like a typical ToT plot. I used the getSignal() function in PixelHit. Am I plotting the right thing or is there a problem with the offset that is causing the signal to look this way? Thanks!
Uploading: data.root…
source_measurement.conf (1.0 KB)
detector.conf (117 Bytes)
minipix_tpx3_flex.conf (521 Bytes)
Hi @oobie2142 ,
I assume what you’re posting is the spectrum of ToT values? What’s the unit of the y axis?
And may I ask what you are expecting to see as a typical ToT plot?
I re-ran the simulation and spotted potential sources of you not seeing the desired signal:
a) In general, I’d advice to enable the output_plots for all modules to debug the simulation. It will help you spotting issues in the configuration, such as …
b) the GenericPropagation has a default integration time of 25ns, which for your detector is much too short. See the drift_time plot for this module
c) Please have a look at the cluster_size plots in the DetectorHistogrammer. You will see that you have a lot of charge sharing, which seems physical, for one thing looking at the charge collection time in your sensor, for another thing …
d) you defined your beam with a zero beam size, meaning you will be always aiming at the sensor center, which is probably the exact corner between four pixels. You could either aim at a different position or spread the beam by defining a beam_size (see documentation) to average over several incidence positions.
I hope this helps a bit 
Cheers
Paul
@pschutze Hi Paul thanks for these! I am trying to observe charge sharing and see how much energy is lost. I will make sure the beam hits a pixel directly I never thought of that so thanks! I am confused on the conversion between pixel charge [ke] to ToT. I think I asked this before in another thread you answered, but that was with the DepositionCharge module. Is there a way to get the ToT in ns?
The ToT is strongly dependent on the front-end circuits (how quickly does the signal go back to the baseline). Hence, the determination of the ToT reqiures knowledge on the front-end.
The way it works in the DefaultDigitizer is the following: also the “ToT” is initially computed in units of kiloelectrons. The explanation is maybe a bit hidden in the documentation this parameter:
qdc_resolution : Resolution of the QDC in units of bits. Thus, a value of 8 would translate to a QDC range of 0 – 255. A value of 0bit switches off the QDC simulation and returns the actual charge in electrons. Defaults to 0.
Hence, changing this parameter should provide you with a more reasonable ToT value. However, this only uses the pulse you get from the sensor and does not take into account any shaping/amplification in the front-end. You could mimic this by defining a qdc_slope.
If you require a more accurate simulation of the front-end, I suggest using the CSADigitizer, which requires a certain parameterisation of the amplification circuit, but provides you with information that would likely be more suitable for your readout chip.
Paul
@pschutze Thank you Paul I really appreciate the explaination. I will give the documentation a look again, I missed that parameter. That makes way more sense now and I think I can look at the specs on our detector in our lab and compare.
I am assuming using the CSADigitizer module will increase the computational time?
Every operation does 
Depending on your simulation, it might not be significant, though. Best is to try it out and check the time scores displayed at the end of the execution, for example:
(INFO) Module GeometryBuilderGeant4 took 18.0804ms
(INFO) Module DepositionGeant4 took 1.78032s
(INFO) Module ElectricFieldReader:detector1 took 0.137525ms
@pschutze Excellent, I appreciate it Paul
