LHC PM on-demand - BI follow-up #4

Friday 1 Mar 2024, 10:00 → 11:00 Europe/Zurich

CCC (CERN)

10:00 → 10:20 BLMs

Speakers: Christos Zamantzas (CERN), Mathieu Saccani (CERN), Stephen Jackson (CERN)

• The idea is to use the capture functionallity (circular buffer frozen with a timing event)
• buffer is used for recording data for IQC during injection and switches to record longer periods for studies, including UFO buster, when sequencer prepares for the ramp
• Maximum buffer size is ~43kSample
  • Stephen: increased buffer size to 43kS (was ~25kS)
  • Stephen: Added property to buffer 100Hz data publishing at 1Hz - needs full release and deployment to be tested
    • ACTION (Christos + Stephen + Georges): to be decided whether 100Hz CMW publishing should be kept (compatible with George's devs in Nov'23)
      • It seems that the data sometimes arrives in bursts implying a pile-up on the FECs => this is not useful for collimation team to do beam-based alignment => this property will be protected with RBAC
      • collimation team will continue doing the alignment using 100Hz UDP data
      • ACTION (Dion + Stephen + Christos): make a concentrator to apply conversion factor, (counts to Gy/s) taking 1Hz CMW publishing of buffered 100Hz data, and log to NxCALS
• VME read-out overhead is ~15s for a full crate, i.e. 256 BLM devices
• The available RSs and their refresh periods are listed in the table below (source be found here)

• ACTION (Stephen): add two more RSs in the selection, i.e. the 320 & 640μs integrals
  • Mathieu: added the RSs to the FW and regenerated the driver
• The UFO buster is using the 80μs RS
  • Dead-time depends on the RS selected; (min = 1.7s & max = 27.9s)  + 15s for the readout
  • Repetition of triggers should be > once per minute
  • The possibility to link different RSs to this buffer need to be added both in the FW and SW
  • ACTION (Andrea Calia/Georges/OP by restart'24): this may entail changes to the sequencer to allow selection of the new sampling frequencies
    • ACTION (Stephen): Stephen proposes to send an email to Delphine
  • ACTION (Christos by restart'24): how frequently this buffer is read-out can have an impact on the temperature of the electronics - this needs to be assessed
    • ACTION (Stephen): will implement max freq data readout in the code (this will be either hardcoded or a FESA configuration field) - decided to go with once per minute

10:20 → 10:40 BPMs + BFC

Speakers: Andrea Boccardi (CERN), Diogo Alves (CERN), Manuel Gonzalez Berges (CERN), Michal Krupa (CERN)

• BPMs
  • Only FW has access to 44.1Hz data
  • Capture mode
    • provides a position per bunch and per turn
      • Max # bunches x # turns = 131072
    • ACTION (Manuel by restart'24): check if there's a field in the FESA server that allows to skip turns (i.e. dowsample data) - there is no field. If this functionality is required it will have to be implemented
    • There exists a concentrator maintained by BE-CSS
      • it gets capture data from the BPMLHC classes and writes it to files
      • it has both an IQC stream and capture stream
    • ACTION (Manuel by restart'24): configure capture data, as well as the corresponding meta-data, to be logged into NxCALS (or check whether this is already the case) - this is already the case subject to NxCALS limitations
    • ACTION (Diogo+Manuel by restart'24): run tests to check whether capture mode impacts the latency/jitter of the UDP packets sent to the BFC
• BFC
  • Already implemented FastDataBPM and FastDataCOD properties publishing 25Hz position and deflection data
    • data is buffered by the BFC
    • publishing rate is 1Hz
    • preliminary testing with ~50 BPM FECs sending data seems to indicate negligible impact on the cycle processing time of the BFC
  • ACTION (Diogo by restart'24): provide also 25Hz dp/p and df data in a property (FastDataRadial) to be notified at 1Hz - done and deployed

10:40 → 11:00 DOROS

Speakers: Manuel Gonzalez Berges (CERN), Dr Marek Gasior (CERN)

• In the present PM implementation using 25Hz data, the positions are calculated by the FESA class but switching effects and gain changes are not corrected
  • should have dedicated boxes, configured without switching and listening to either BST or SW event, dedicated for studies
  • a new property may have to be created
  • 25Hz data is a rather limiting sampling rate if we're interested in analysing 10Hz events
• TbT orbit data
  • bandwidth of orbit data is from DC to 100Hz
  • not fully operational ... there are some issues that have to be investigated and fixed -> ACTION (Manuel by restart'24) - now works if we configure it manually (not using a 'user-friendly' property)
  • ACTION (Manuel): check the possibility of triggering this from a GMT event
  • switching will prevent data usability
    • should have dedicated boxes for studies, configured without switching and listening to either BST or SW event
    • a long-term renovation effort of the FESA class, which will start in 2024, can take into account the requirement to make precise orbit readings and temporary non-switching compatible
  • data decimation is in principle possible but needs to be checked -> ACTION (Manuel by restart'24) - this setting existis and is working
• TbT oscillation data
  • bandwidth of oscillation data is from 500Hz to 5kHz
  • cannot compete with BBQ data quality
  • continuous BBQ data is already being logged in NxCALS
• Was agreed that the way to go is to configure a few DOROS boxes on some standard BPMs and use them for dedicated TbT orbit measurements -> ACTION (Manuel by restart'24) 
  • ACTION (Manuel): provide 'easy-to-use' FESA interface for OP to configure (# turns + decimation + freeze or capture), arm and trigger specific devices for capture - ongoing
    • Agreed to protect this API via RBAC so that only a pre-defined sub-set of (device names) BPMs can be triggered - ongoing
  • the idea would be to have a UCAP node to do some processing and provide logging into NxCALS