set_toa function for tasks #177
Conversation
…w class that inherits from DecodeAndWrite that could be used when we don't want to write anything to a csv
…_toa so that it applies the parameter to the roc instead of returning a test handle
… DecodeAndBuffer to the CMake
|
Please let me know if you think of a better name for the subclass. You have to run cmake again for the new class to be recognized |
include/pflib/DecodeAndBuffer.h
Outdated
| /** | ||
| * Subclass for implementation | ||
| * | ||
| */ | ||
| class DecodeAndBufferToRead : public DecodeAndBuffer { | ||
| public: | ||
| DecodeAndBufferToRead(int nevents); | ||
| virtual ~DecodeAndBufferToRead() = default; | ||
| virtual void write_event(const pflib::packing::SingleROCEventPacket& ep) override { | ||
| DecodeAndBuffer::write_event(ep); | ||
| }; | ||
| /// Read out buffer | ||
| std::vector<pflib::packing::SingleROCEventPacket> read_buffer(); | ||
| }; |
There was a problem hiding this comment.
Why do you have the extra subclass? I don't think it would be necessary...
include/pflib/DecodeAndBuffer.h
Outdated
| * of every event. | ||
| * | ||
| */ | ||
| class DecodeAndBuffer : public Target::DAQRunConsumer { |
There was a problem hiding this comment.
I think we can use the decoding already done and instead of writing to a file we write to a buffer.
- inherit from
DecodeAndWrite - add constructor which sets the size and reserves space
- override
write_eventtopush_backinto buffer after checking size - add
get_buffer()function
Then I don't think the secondary subclass is necessary.
There was a problem hiding this comment.
I guess what I'm saying is to have your old implementation in its own files and #include "pflib/DecodeAndWrite.h" since its needed.
include/pflib/DecodeAndBuffer.h
Outdated
| /// Buffer for event packets | ||
| std::vector<pflib::packing::SingleROCEventPacket> ep_buffer_; | ||
| /// Capacity of the buffer | ||
| int buffer_size_; |
There was a problem hiding this comment.
Instead of storing our own member for buffer_size_, we can use the std::vector::capacity() function. This returns the total capacity of the vector which we control directly when we call reserve.
|
A quick comment here, I hope not to intrude or disturb the process here! When we are trying to calibrate for TOA_VREF, should we use pedestals or charge injection? I had discussed with my advisor Cristina that we might want use pedestals for TOA_VREF and then charge injection for TRIM_TOA. What do you guys think? The idea is that TOA_VREF should be set right above the pedestals, so that TOA can be sensitive to triggering off of even very small incoming signals. And then TRIM_TOA uses charge injection so we can send identical signals into each channel and then calibrate the TOA reading to be the same for each of them. |
|
I want to add that I really appreciate what you guys are doing and have been very excited to see this work! Thank you! |
|
I'm unsure what the best process is. We definitely don't want the TOA to trigger on any pedestals, so that could be a criteria we add to this I haven't read the source that @andpet1324 cites and so maybe that is being done there and this is just the first step. The TOA threshold is probably the most complicated one to tune since it has the most complicated criteria. TOT is a bit easier since we just want it to trigger "early enough" to take over before ADC reaches saturation. TOA needs to never trigger on pedestals and be as low as possible so we can get timing information for weaker signals. |
|
I agree with you. Perhaps it is best to use both the pedestals and charge injection like that! I'll go see if I can find a definitive answer in my sources. I have access to some CMS and LDMX documents, so I'll report back on what they say. |
|
Update on the toa analysis: There seems to be variation on how to go about the pedestal alignment. Here's some data I pulled from the CMS collaboration, so thanks to Cristina for helping me find these resources! A group from University of Maryland that worked on "TileBoard Quality Control" for CMS said that the first step in TOA threshold alignment is to set toa_vref without injection (using pedestals) so that the global threshold is above pedestal variations. Then, use low range charge injection to fix the trim_toa. Finally, they use linear regression to fit the trim_toa values for each channel. Additionally, I looked at some toa analysis code from the TileBoard Quality Control team, and their code does exactly what they said to do (check toa_vref with pedestals, then trim_toa with charge injections). Additionally, their code suggests to add 10 to the calculated toa_vref, so that you can account for small variations in both pedestal fluctuations and the calculated toa_vref. However, when we look at the paper Andreas recommended earlier by González Martínez, he recommends injecting a small charge into each channel to calibrate the TOA threshold. Then, after setting the trim_toa, you do another scan of toa_vref without charge injection (pedestal). So in this case, he's using both charge injection and pedestals to set the toa_vref threshold. So, it looks like we can do it both ways! |
- update documentation with advice on how to use buffer - return const refs to avoid copying data - drop unnecessary members now that we are inheriting from DecodeAndWrite
set_toa sets TOA_VREF for a specified channel. A small charge injection is sent to the channel, and the TOA_VREF is scanned. The first threshold with a toa efficiency of 1 is selected the "correct" toa for calibration as described in José González Martínez's "Design and characterization of readout ASICs for SiPM detectors in pico-second timing measurements for the CMS HGCAL experiment" on page 99.
The function returns a parameter handle with the TOA_VREF for the specified channel.
Example of calling the function:
auto toa_handle = set_toa(tgt, roc, channel);