Update TOA and TOT scans

[knh3dg]

• Added a new toa scan which aligns the toa threshold to a set adc target in the low range. Functions on multiple ROCs in parallel. Example graphs are below.
• Added a new tot scan which aligns the tot threshold to a set adc target in the high range. Functions on multiple ROCs in parallel. Examples graphs are below.
• Added a scan which prints information about central_charge_to_l1a, phase_strobe, and phase_ck
• Fixed a type assignment bug in global_pedestal_level, strengthened slope cuts, and changed the target adc to 150
• Updated channel_wise_calib_scan to function with multiple ROCs enabled, scanning over rocs in parallel
• Updated default settings of local_pedestal_level to be in-line with other commands
• Renamed a previous command labeled "toa_scan" to keep name consistency

After setting up the ECON/ROC/DAQ, ROC calibration should go as follows:
TASKS.LOCAL_PEDESTAL_LEVEL
TASKS.GLOBAL_PEDESTAL_LEVEL
TASKS.TOA_SCAN
TASKS.TOT_SCAN

If TOA_SCAN or TOT_SCAN is having trouble, e.g. many trim values are 63, try setting the target calib to a higher value. Note that TOA_SCAN aligns in the low range while TOT_SCAN aligns in the high range. Using more events, e.g. 100 instead of 10, should also improve consistency, but from my testing the difference is often quite small.

[tomeichlersmith]

At first glance, this looks really good; however, it is a lot of new code so I want to test it more thoroughly.

While I'm working on that, how do these developments relate to #433 and #428 ? You delete files that they are editing in those PRs, so does this PR replace those?

[knh3dg]

While I'm working on that, how do these developments relate to #433 and #428 ? You delete files that they are editing in those PRs, so does this PR replace those?

I am pretty sure I have left their files untouched. I did delete some files related to the old tot scan, but I don't think I deleted any files related to the toa scan. Which files are you referring to?

[tomeichlersmith]

Oh yea, you're right, I misread tot_vref_scan and toa_vref_scan.

My question remains though - it looks like you have implemented toa_scan which does the tuning of the toa_vref and trim_toa parameters which #433 and #428 are also looking at working. Is the purpose of this function the same or am I misunderstanding?

[knh3dg]

Oh yeah, the purpose of the function is the same. The plan was to get a working version. Once Pierce and Will finish their functions and we see how effective they are, we can pick one going forward.

[cmantill]

Jack, Pierce and Will summarized progress here and shared it with CMS folks: https://docs.google.com/presentation/d/1PuzthVSWL0KrQL0XiZCgzaWRW_tTlfmDLGLtzZWkPWk/edit?usp=sharing

I'll note that Jack's procedure for the TOA vref and trim tuning is not the same as the one from CMS, whereas Will's + Pierce's follows the CMS procedure. However, Jack's procedure seems to work fine. I suggest merging his algorithms for now.

• @knh3dg can you add proper documentation in this PR and later on the wiki on the steps you take to run them?
• when Pierce's + Will's updates are ready we can go back and make a decision on which to keep.

[tomeichlersmith]

A second, more thoughtful read of the code (still haven't tried to run it!) gives me more confidence. It looks like a thoughtful algorithm, well done!

You can also add doxygen-style comments within the functions themselves, e.g.

  /**
   * First, we incrementally lower toa_vref from its maximum of 255 until XXX
   */

This would then end up in the online doxygen manual: https://ldmx-software.github.io/pflib/
(although many of the pages there have gone stale and I need to update them)