search

padsley / k600analyser

Code for the K600 analyser including plugin codes for silicon, clover and HAGAR data
1 stars 4 forks source link

Odd TOF Issue with Some PR228b Data #77

Closed nichubbard closed 8 years ago

nichubbard commented 9 years ago

Some of the data from PR228b has the problem that by default the pad1:tof plot has the wrong TOF appearing on the histogram, so you see TOF corresponding to the next RF pulse, rather than the main pulse. This can be fixed (it seems) in f-place by removing the if (t_tof == 0) condition on line 2579 (case TOF_TDC_CHAN:). Which I believe Phil did during the experiment, until we fixed the tof offset.

I am not sure this necessarily works on all the runs, and it seems a bit of a dirty hack. I was wondering if there could be a better way to do this, and if this issue is a potential indicator of worse things happening. Should some logic similar to the multiTDC thing be implemented where it prefers pulses in a specific window?

padsley commented 9 years ago

This isn't a problem to fix with the multiTDC code. I think.

Retief and I will have a think and get back to you.

Can you give me a datafile to look at?

Also, an updated version of the code that you're using would be helpful.

nichubbard commented 9 years ago

Run 1033 or Run 1047 are example runs with the TOF issue. I upload my code to my own repo https://github.com/nichubbard/pr228b-analyser I'll commit and push changes later today, which will include the f-plane "fix"

nichubbard commented 9 years ago

If you need a copy of the .mid.gz files let me know and I'll put them on google drive or something.

neveling commented 8 years ago

Forgive the long response: most of it is for my own benefit. The if (t_tof == 0) condition in the code is to ensure that the value assigned to tof in the code is the last value that the multihit TDC digitize, and because of the way the timing works this means it should be the first beam pulse's information.

Thinking back, this was put in place at a time when the analyzer was still very primitive and I wanted to enforce consistency to be sure which RF signal was used for TOF determination.

The only reason it causes problems now is because the signal from the trigger that goes into the RF-AND-trigger logic unit was wider (400-ish ns) than the beam pulse separation times (270-ish ns). So for every good trigger we see 2 pulse-selection RF signals, and hence have 2 potential timing outputs (due to multihit TDC capability). It just turns out that for some runs the 2nd RF signal per trigger has a better relative position i.e. the alphas are not on the edge of the 270ns time range.

I suggest you simply create 2 tof variables in your code, one dependent on the (t_tof == 0) condition and the other not, so that you always have a useful variable available in the Tree to gate on without having to bother to do any re-analysis. At present it would seem that all the runs of the 2nd WE up to 1069 do better with the 2nd RF pulse. (Note the tof variables for the other TDCs were put there so that we have redundency for tof measurements should any one TDC go bad, and should be kept as is.)

I do not think it is necessary to make any permanent changes in the analyzer to accommodate this specific issue as it should not be a problem if the NIM trigger electronics are optimized for each run.

padsley commented 8 years ago

@neveling and I just spoke about this and we agreed that we shouldn't make changes to the sort code to account for this. The fix for Nic should be limited to his experiment only as the experimenter (me, in this case... sorry) should set the RF such that there is one locus. In which case you (@nichubbard) should make the change for your version of the code and then use that. We don't intend to make any other fixes.