305 lpgbt temperature

[cbell1402]

Solves 305 by estimating the internal temperature of the lpGBT board.

1. Reads the lpGBT CHIPID from the efuses
2. Checks if a calibration_results.yaml file already exists
3. Checks if the CHIPID is in that file
4. If not or if the file doesn't exist, opens the lpgbt_calibration.csv file (downloads the csv file if needed) and finds the constants
5. Finds temperature of the lpGBT internal sensor based on some formulas using the calibrations constants and ADC measurements
6. Prints the temperature for the user

Print out for if the correct constants already exist in the yaml file:

 > GET_LPGBT_TEMPS
 --- Current lpGBT CHIPID: CC2BDEC9 ---
  > Found existing calibration file 'calibration_results.yaml'...
  > Inferred Junction Temperature (TJ_USER) from vref_tune: 45.366795 degrees C
  > Updated 'calibration_results.yaml' with TJ_USER
  > VREFTUNE REG: 103
  > Calibrated Voltage: 0.5049 V
  > ----------------------------------------------------
  > lpGBT Internal Temperature: 25.94 degrees C
  > ----------------------------------------------------

I followed Gabi Hamilton's slides very closely for this
https://github.com/user-attachments/files/23972425/CassettesTemps_CWM_Oct15.pdf

[tomeichlersmith]

This is excellent and detailed work! I am curious about making this more specialized so that it can be faster (and not have to download the CERN CSV and/or have a cached YAML). What are these used for? Could we take out the few lines that correspond to our chip IDs and hard-code those into the software? (Documenting where we got the numbers from for future reference.)

The EcalSMM and HcalBackplane use the same lpGBT mezzanine design so, as long as these calibrations don't change much from chip-to-chip, I think we could hard-code them. Thoughts from your experience?

[tomeichlersmith]

I guess the reason I'm pushing in this direction rather than keeping the current (more general) solution is that I'd like the temperature to be included in a Target::status function within pflib allowing pftool and other programs (most obviously, the Rogue run control) to query this information.

[cbell1402]

I do think that we could make it specific to the chip IDs that we have. The constants pulled from the CSV files are used in the formulas to calculate optimal VREF_TUNE, TJ_USER (estimated junction temp), an ADC voltage, and, finally, estimated sensor temperature. The values in the CSV are sufficiently different that using just one set of constants could cause major erroneous temperature estimates. I actually tested this on UVA's TRG and DAQ lpGBTs. I mixed up the two chip IDs and found an estimated temperature of hundreds of degrees.

So, if we do want to make it hardcoded, I would just need the various chip IDs. I could put it all into the .h or something.

[tomeichlersmith]

Oh so the chip IDs are like serial numbers and not the different types of chips? What happens if the chip IDs are not in the CSV? For example, the DAQ lpGBTs on the EcalSMMs at SLAC (I don't think) have been properly tested and so their serial numbers would not be present in any kind of testing database.

(This statement comes with the belief that the DAQ and TRG lpGBTs on the HcalBackplane are the same mezzanine, they are just configured differently.)

[cbell1402]

Yes, they are like serial numbers. To my knowledge, the DAQ and TRG lpGBTs are the same but would have different chip IDs and also likely different constants.

There is some more information here
https://lpgbt.web.cern.ch/lpgbt/v1/analog.html#calibration-data-format-and-distribution

Also, it looks like there are "typical" constants listed here
https://lpgbt.web.cern.ch/lpgbt/v1/electricalCharacteristics.html#temperature-sensor-characteristics

So, perhaps I could do some testing to see if we get reasonable temperature readings with these default constants. Perhaps reasonable could be defined as +- a few degrees C. The only issue is, I would need to know the actual temperature from someone physically present at the mezzanines.

[tomeichlersmith]

Unfortunately, I do not have access to that area of cern.ch (probably because I'm not in the proper "HGCAL Electronics" egroup or something).

Anyways, I do have physical access to the HcalBackplane and its lpGBTs here at UMN so I'd just need to find a temp sensor that I can use to verify that the "typical" constants are good enough.

I still think your detailed code is good especially in the long term where we would have a specific set of well-tested lpGBTs. This would then give us a database of calibration constants to either look-up live or cache in a local CSV/DB/YAML file. Just trying to think about how to structure it so it can fail to do the precise calculation quickly and quietly.

[tomeichlersmith]

After chatting with Jeremy about this - I should correct what I said earlier. The lpGBTs we are using should be in the database, but Jeremy confirmed that the average constants should be ok. His idea is to put most (all?) of this temperature code into the lpGBT C++ object instead of a task, have the default calibration constants be the average values but have a separate function that can do the calibration procedure if requested. This way we can default to a fast/rough estimate and do a slow calibration if we want a more precise estimate.

[cbell1402]

If I understand correctly -

• I should put most of the functional code into lpGBT.cxx and lpGBT.h
• The functions should default to the average constant values
• I should just have the task call on those functions
• Have another function that does downloads and/or looks at the CSV for better temperature estimation
  Does that sound right?

[tomeichlersmith]

Yes, have the precise calibrations that require download "opt-in"