Weird signal shape for proportional counter

I am simulating a proportional counter (just to study the basics and to make sure that I am using Garfield correctly) and getting a strange shape for the signals like below:

The top picture is when there is only 1 proton penetrating the detector, and the bottom picture is when 100 protons penetrating the detector.

These are raw current signals produced by Garfield with fC/ns on the y-axis and ns on the x-axis. I am trying to understand why these signals are shaped like that. I would expect the signal to have a sharp rise time and then a slower fall time from what I read in Knoll. So, I just want to make sure that I am not simulating this incorrectly. Here are the files that I use to produce the above data.
signal.cpp (5.5 KB)
isobutane_mobility.txt (379 Bytes)

Please let me know if more details are needed to explain my simulation.

Hi Henry, let me invite @hschindl over, the Garfield expert!


thanks for the nudge, and apologies for not having reacted earlier! I’ll try to look into it today/tomorrow. At first glance, the signal shape doesn’t look totally wrong to me though…

Hi @hschindl,

Thank you for looking into it.

Hi @hschindl,

Have you gotten the chance to look at my code for the proportional counter?

Sorry it took so long! I had confused myself by changing things in the code (and introducing a bug in the process) while looking into your question.

There is one slight issue with your code, which is that the proton energy you’ve been using is too low for the model used by Heed to be applicable. Which is why you’ve probably seen warnings like

EnTransfCS::EnTransfCS(...): WARNING: negative adda

which are admittedly highly cryptic. I should replace them by a more meaningful message.

But that’s just as a side note, it doesn’t really matter for what you were asking.

To understand the shape of the signal, it’s easier to start with a single electron avalanche. I’ve attached a small program (a slightly simplified version of yours) where you can toggle between two different methods for calculating the electron (and subsequently the ion) signal:

  • The first one uses DriftLineRKF which uses the average drift velocity and Townsend coefficient (these transport parameters are taken from a gas file isobutane_50_Torr.gas which you’ll also find attached). With the option EnableIonTail switched on, it then also simulates the ion signal (again using the RKF integration method) by distributing the starting points of the ions along the electron drift line according to the avalanche growth profile. This method is quite instructive because it gives you the average signal without any fluctuations. From the attached plots (single_electron_rkf.pdf and ion_tail_rkf.pdf) you see that the signal has indeed a short electron pulse with a steep rising edge, followed by a long ion tail.
  • The second method simulates the electron avalanche using microscopic tracking and subsequently every ion produced in the avalanche using the RKF technique, like you did in your program. The signal then looks more “noisy” because of the fluctuations in the avalanche, but I think it’s more or less consistent with the one obtained using the first method.

Now if you have a charged-particle track, the signal will become a bit more complicated because the individual electrons produced along the track will arrive at different times at the wire, so you’ll get a superposition of the above “single-electron type” signals with different time offsets.

In your particular example you had a lot of primary electrons along the track which is maybe what caused the confusion.

Let me know if you have any questions/doubts…

single_electron.cpp (2.9 KB)
isobutane_50_Torr.gas.txt (25.3 KB)

single_electron_microscopic.pdf (11.0 KB)
single_electron_rkf.pdf (10.4 KB)

ion_tail_microscopic.pdf (23.9 KB)
ion_tail_rkf.pdf (23.2 KB)


Thank you so much for your work! I have one follow-up question. Regarding the Heed model, does the warning affect anything else in my simulation besides the number of initial electron-ion pairs that get produced by the charged particle?

For my application, the detector is used to detect light particles that usually have energies in the range of tens of MeV. So, I would like to stick with my current setting of initial kinetic energy if possible.

it’s “only” the number of primary electron/ion pairs that will be wrong. There are two issues actually:

  • The photo-absorption ionisation (PAI) model, which is used by HEED is not applicable for “slow” particles (low βγ), so the calculated cross-section won’t be reliable.
  • HEED doesn’t update the cross-section as the particle loses energy in the gas. So TrackHeed won’t work if your particle is slowing down significantly in the gas. In these cases TrackSrim (SRIM | Garfield++) or TrackTrim (TRIM | Garfield++) might be better options.


I will make some changes to my code to start using TrackSrim. Thank you again!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.