Skip to content
Snippets Groups Projects

Spike correction in commission mode and bug in Event.cc

Closed Alexander Droll requested to merge (removed):master into master

Hey there,

I've implemented an option for a spike correction. Basil measured some spikes in the SCurves of the 8CBC hybrid. I've seen them, too.
So I changed the code to have the option that these spikes are corrected. This means:

  • search algorithm for spikes
  • remeasuring the VCth values where the spikes occured
  • correcting these bins in the fSCurve histogram. In my opinion it is a problem in the data flow from the GLIB. I think that there went something wrong, but the discussion about the source of the problem is going on. The new option is named : --spikes or -x (I had no better idea for a shorty) It can be used additionally to the -n option of commission, so the spike correction can be turned off and on.

For the implementation I changed the following files:

SCurve.cc/h added some new methods and a new attribute float fSpikeHeight;:

  • bool findSpikes(std::vector& pSpikes, int pTGrpId, Module* pFe)
  • void correctSpikes(int pTGrpId)
  • void measureVCth(int pVCth, BeBoard* pBoard, int pTGrpId)

PedeNoise.cc: a few lines to start the spike correction

commission.cc: parser of the new command

Channel.cc/h: new methods:

  • void getSpikes(int pNumEvents, std::vector& pSpikeVCth, float pSpikeHeight)
  • void resetVCth(int pVCth);

And I found a bug in Utils/Event.cc: I corrected the getHits() method (return value was missing)

Maybe you like my solution.

Cheers, Alex

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Hi Alexander,

    I'm not merging this specific request for three reasons: a) first of all it should be based on the Dev branch and thus merged into Dev b) these spikes are most likely due to a bug in the GLIB FW that has since been fixed (I haven't run any dedicated study but with this bug, every 256, 3xx, 512th, 32 bit word in the data is 0 - I guess that is the reason) - so the whole issue should be fixed in FW rather than SW c) the GLIB (and CBC2) will soonish become obsolete and while I like your solution, it's only practical for some of the TDR measurements on a very particular subset of objects - I don't see a reason to complicate things like that for one particular measurement.

    May I therefore recommend you keep and share this version with Basil for his measurements?

    Thanks

  • Hi Georg

    Is this fixed GLIB FW available somewhere?

    Thanks, Basil

Please register or sign in to reply
Loading