-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
R1 calibration #155
Comments
Yes I have to admit it seems coming from nowhere.
They were obtained with |
Cool I was not aware, could you give me the link? |
It is part of the calibration document... :D sorry... |
I tried to plot these 4 spline-functions .. but something must have went wrong .. the right side looks not correct at all. There is negative gain drop ... and negative nsb rate ... Notebook to create the image https://gist.github.com/dneise/96c8df2e8e15f29308e725b90158e334 |
Yes that is exactly the source of the problem. Sorry, I should have also shown this plot in the picture above... I had it in that notebook, but I did not show it here, since it did not show the problem as nicely .. so I deleted it. You say:
I think it is of high importance to quote the source of (magic) numbers when used inside of code. Or when read in as a look-up-table or so. This goes into the direction of provenance... numbers in the code-base which are not traceable do not break reproducibility, so having the numbers in the code, without knowing where they come from is much better than e.g. reading them in from a text-file and the text-file is missing in the repo ... But still not referencing the (internal) paper these numbers came from makes it hard to understand. In this case, you said, these numbers came from a simulation. So I assume this simulation was checked in somewhere and could be referenced here. like this:
Of course this still has the problem that some random guys named dominik, might have a look at that script and say: "the name is bad, let's rename it" ... not knowing that this script is an important reference... one solution is to always use perma-links to cite simulation-code, which yielded a certain result which is the basis for further decisions. On github pages, I think one can still hit the
Another point which is interesting I think:
A reader of the code might spend hours understanding code ... which then later turns out to have never been used at all. Maybe somebody produced that code in 30 minutes ... planning to use it later ... then something else was suddenly more important and that code was forgotten. I totally understand, but still is might be great time-eating-monster. I personally assumed that using the baseline-std-deviation is much more often used, since one is independent of a dark-baseline run, which might or might not exists... |
See for example a first try to get some of our code into ctapipe. There is this |
I used the digigcamtoy to create the same plot again. I varied the gain an non-surprisingly, when the gain is low enough that the gain-drop stays low even at elevated rates (find quantitative expression), the std-deviation of the baselineshift versus the nsb-rate stays nicely bijective. In the digicamtoy the default value for the gain is close to 6 ... in digicampipe I've seen 23... So I wanted to ask, if there is any source to learn what typical gain values in digicam are? This plot was generated with this code: |
Thanks for the plots! Ok not sure yet I fully understand the meaning of the result you show. As before it seems puzzeling...
They are the same.
Now in the calibration I am normalizing pulse integrals such that the area of the integrated pulse is equal to the amplitude of the regular pulse. |
Also could you push the plot you have to |
Ah I see ... So both numbers are correct.. of course ... damn not enough sleep. I think, when 23 is the result of an integration then its unit might be (LSB * samples) or (LSB * ns)... or so. Sure .. erm .. I'll open a new PR for that plot only so it does not get mixed up with the other pep8 stuff, I was playing around with |
yes you are right, less confusing. |
Yes that is correct, and indeed all ADCs do a bit of integrating/averaging while their "sample-and-hold" circuitry is sampling. In FACT we did some calibration of the LSBs to actual voltage, measured at some point after the pre-amp. However we never bothered to really calibrate this voltage signal to the current pulse flowing through the SiPM... so it was pretty worthless. LSB, mV ... in principle it could have been also "apples" ... in the end all what counts is what the gain is. Anyway when we did some integration of this voltage over a range of time, of course the result had some unit like "mV * ns" or "mV * samples" depending on how the guy doing it liked to work with time ... a sample in FACT is more or less exactly 0.5ns .. so when people did not explicitely state the unit, there was always a factor 2 to be missed easily. I guess in digicam where a sample is 4ns .. it is very easy to miss this factor of 4... so stating the units explicitely might help, once somebody defined what you in digicam mean with an LSB, everything is defined and not arbitrary anmore... However, one more comment ... Just stating that the gain is 23 LSB * ns when integrating over the pulse might also miss a little bit of important information. The question is often how you defined your integration window, and how did you define the baseline? Otherwise two people finding pulses and integrating over them, might do it differently and come up with totally different numbers of p.e. when using the same number for the gain. I assume 23 is the result when integrating the entire pulse over dunno 100ns using trapz? While in digicampipe I've seen one is integrating over 7 slices using simple-summing-rule. |
Yes totally agree that's why a p.e. is not : my adc / gain but rather: my computed charge with method X / the gain I obtained with method X
That's why I want to normalize each charge to the same "units"
Thanks for asking. It is 7. |
So doing some calculations I found out that there is a maximum at (which is what your plot tends to show): f_{nsb} = 1/(RC) = 1.17 GHz (for all gains) This is only due because of gain drop! |
cool can you show the calculations? (a picture of the whiteboard / piece of paper is fine if you got no time to digitize it ) |
Can anyone tell me where these numbers come from?
digicampipe/digicampipe/utils/calib.py
Lines 4 to 30 in acd9fa0
So far I only found out that:
The other two, do also not really look like measurements, but more like coarsly samples functions.
I must admit in the beginning when I saw these numbers, I assume they were measurements .. but after plotting them, I am not so sure anymore.
The text was updated successfully, but these errors were encountered: