CERN Accelerating science

Radio Frequency

Actors: Operator, RF expert, timing expert

• The �Low Level� RF control system needs to manage the synchronization, frequency and phase of the cavities
• Low-level systems implemented in VME with FESA, access via CMW.
• Fast synchronization signals - SPS-LHC transfer.
• All function generation provided by FGCs from AB/PO.
• Schneider PLCs for control & surveillance of power equipment (klystrons, power supplies etc.)
• Access to PLCs via FESA/CMW. Some power controls (e.g. HV settings) via FESA.
• Mountain ranges, analog signals, time waveforms, high bandwidth remote acquisition
• Control of settings, functions...
• Fast feedback links...?
• Transverse feedback: probably stand alone control room application: functional spec required.
• Beam dump triggers from 400MHz and Damper via BIC.

• Asynchronous set of high level parameters (frequency, settings, gain)
• The system shall use the provide standard high level settings management facilities - control of phase, frequency, voltage etc.
• High level commands to allow traversal of state transition diagram
• All equipment shall be controllable from main operational software
• All measurement and control programs must be available in klystron galleries IP4, SR4, PCR & BA3 FC.
• Mountain range display, analogue signals from pickups at end of lines,
• Waveform acquisition: phase loop, injection transient signals.
• Transfer of fast synchronization signals
• Longitudinal feedback: monitoring  and control
• Low level: bloody pre-pulse diagnostics

Controls Issues

• Synchronization (bunch to bunch) & ms.
• Support.
• Alarms, Logging & Post-mortem

Applications

Wide band pickup feeding on-line bunch length measurement plus mountain range. This will be on top of OASIS (need an API). Analysis software, averaging, fitting etc. APW Acurist.

Survey all PO equipment and low level equipment. Power test and cavity conditioning via ad hoc specialist applications.

State control - settings generation - radial steering - cavities (voltage, frequency). Voltage partition.

LFB one function plus mountain range - gating on incoming beam (gain & phase), manage settings plus multiplexing

TFS: state, disable, gain, delays, phase

Function generation (RF_FGEN)

Here is an end-of-the-week update on the RF FGEN system: (May 2008 c/o Quentin)

* All crates are installed and powered *

The two FGCs that will be on PCGW15 are not available at the moment. They both need a bit of work and will hopefully be sorted out next week. In the mean time, software development can use the hot spare without risking disturbing anyone (RFMDA.SR4.SPARE)

* The RF_FGEN specification document V1.6 is now available here: http://proj-lhc-fgc.web.cern.ch/proj-lhc-fgc/download/pdf/RF_FGEN_spec.pdf. Please destroy any printed copies of earlier versions please.

* The operational LSA database is now available but has the original channel names/units which are not at all valid. This will be updated with Mike’s help once Andy can provide the definitive channel list.

* The Post Mortem system is not yet working but the PM team are working on the problem. Hopefully the issues will be resolved shortly.

1. Installation
    
   The final list of FGC device names has been agreed with John and is given in this table:
     

The systems in yellow are not yet online, the ADT devices are waiting for 400VAC to be cabled (don’t know when) and the others are waiting for the final crate to be installed (should be done by the end of this week).

Sixteen RF_FGEN FGCs have been made and 12 FGCs will be at point 4, four underground and eight on the surface.  One of these is a hot spare and will be used by the piquet to replace a failed unit during operation.

The systems in blue are available spares that will be kept online whenever possible for application development by Delphine et al.  If a system goes faulty then one of these will replace the hot spare until the failed unit is repaired so it is not guaranteed that both will always be available.

The 864 DEV system is for hardware tests by John and the 866 DEV system is for FGC software development by me.
  

2. FGC Software
    
   The systems are running V251 of class 59 software.  This seems to be quite stable but there will no doubt be a few tweaks required in the coming weeks and months.  Please report any issues to me.
    
3. Channel Configuration
    
   I saw that the channel assignments were being defined by Philippe.  For each channel we need to know the following parameters (see the default config file for the associated property names http://cs-ccr-www1.cern.ch/~pclhc/config/types/RFMDA.txt) :
    
1. Name (must respect the LHC signal naming conventions because the post mortem will use these names to label the signals)
2. Units (5 chars max)
3. Gain
4. Offset
5. Default acceleration
6. Default linear rate
7. Positive clip limit for real-time data (if used)
8. Negative clip limit for real-time data (if used)
9. Maximum clip limit for the channel
10. Minimum clip limit for the channel
11. Positive rate of change limit for the channel
12. Negative rate of change limit for the channel

4. Configuration Manager
    
   The configuration manager is fully operational and the configuration of all the powered systems is stored in the FGC operational database.  When setting up a system you must enter the command S CONFIG.MODE SYNC_DB to commit the changes to the DB otherwise they will be lost following the next reset.
    
5. Post Mortem
    
   The RF_FGEN FGCs will generate a post mortem dump if there is a global post mortem event sent over the timing network.  This is the only reason that a post mortem will ever be created.  The systems are current generating a dump but so far they are not resulting in valid data as seen by the post mortem viewer.  This is being investigated by myself and the PM team.  This class is the first to use dynamic signal names in the PM, so this will need to be debugged.
    
6. Specification Document
    
   The RF_FGEN specification document has been updated from V1.5 to V1.6.  I will release this new issue by the end of the week and will send you a link to where you can download it.

I hope we can completely finish the installation in the near future and can hand over the system to OP.  For this I need the final configuration of all the channels so please pass me this information once it is known.  Don’t hesitate to contact me if you have any questions.

FGC with 16 daisy chained nodes (16 bit integer to every node at 1 kHz)

• PLP
• CTRIM
• SINE
• TABLE

50 Hz publish, slow subscription through CMW, fast subscription via UDP

1.3 second Post Mortem & snapshot

ACS

- coupler position change in ramp - stagger changes between cavities - discrete changes

Need to check PLP parameters - linear rates & defaults

ADT

H/V - gain - delay [ns] - phase [beta] - pregain

Phase shifter

Beam control & LD

RF frequency - offset from 400 Mhz (2 channels - same f)

Radial steering

Radial steering via RT channel in physics (???). Surveillance.

Radial steering reference [mm]

Needs B field or momentum to calculate synchronous phase

LFB

Phase/gain

TFB

gain

ABORT

1. Behave gracefully in the case of beam loss
2. With beam
3. Abort injection

disarm before ramp ?

Outline of RF system & controls requirements

The LHC RF system   talk given by Philippe Baudrenghien at the CO-OP forum 1999

Longitudinal phenomena during the LHC cycle   Elena's talk at Chamonix 2001

Transverse damper through the cycle Wolfgang's talk at Chamonix 2001

RF operations through the LHC cycle

(Philippe Baudrenghien, revised September 2004 Philippe/Andy)

Pre-injection plateau - prepare for injection

Synchronization is not required here but the functionality will be invoked by timing later in the cycle.

400 MHz ON - 8 MV. 400 MHz and transverse damper mainly controlled by commands.

• Set RF frequency program to injection level (i.e. point zero of the ramp function?), possibility to vary it should be provided for MDs etc.
• Set the gain of the phase loop amplifier to filling value [command]
• set the gain and time constant of the synchronization loop amplifier to the filling value
• Close the phase loop around the vco (freq prgm/vco) - [command]
• switch the RF DRIVE ON [command]
• Switch the phase loop to the cavity sum signal (freq pgrm/cavity sum)
• Reset the revolution frequency generator [command] (The TTC transmitters run continuously and don't actually have a reset input. They do broadcast some reset signals, notably to reset bunch and event counters, but they do this repetitively).
• Check synchronization. Foresee training sequence in SPS for a pulse or two on the LHC cycle, during this time synchronization can be established. Only the revolution frequency is required.

Concerning the reset of the 40 MHz divider, it will happen BEFORE FILLING THE LHC, and we can do it at a fixed time before the first injection, so that the TTC has enough time to lock. Each LHC ring will call for 12 SPS supercycles to get filled and, of course, the reset WILL NOT HAPPEN AT EACH SPS SUPERCYCLE. It will happen only ONCE BEFORE THE VERY FIRST INJECTION into the LHC. I understand your point that it would be better for you if no reset was ever present. This reset philosophy is prefered by us because it automatically puts the equipment in a known state before we start the filling process.

Ramp to injection level

• Check all systems
• Check energy lock

Filling: First injection into given ring

Low level synchronizes transfer

• jump phase loop onto beam (beam/cavity sum) [timing]
• switch synchro loop on (either freq prgm/beam or freq prgm/cavity sum or freq prgm/vco) [timing]

We keep the pilot as a witness beam and dump onto TDI using the injection kickers to dump. Will need independent control of the injection kickers (wrt to extraction kickers of SPS) - would probably need this for MD anyway.

Filling: on all injections

General:

• Fill at head or tail of batch? fill one ring and then the other? Need the flexibility to do either.
• Hold energy: Energy error needs to be measured on injected beam before capture. (50 MeV = 0.15 mm). Measure & check on pilot and re-do if necessary.

Low level:

• Before each injection, update the bucket selector (common freq. sent to SPS) and the phase of the 400 MHz sent to the SPS [timing]. We need a field in the timing telegram identifying the bucket for each ring.
• Generate injection pulses for the kickers [timing]
• Generate injection pulses for BI [timing]

Longitudinal feedback

The 200 MHz system will not be installed at LHC startup. Instead we inject directly into the 400 MHz bucket. Longitudinal feedback on 400 MHz provides active damping during the injection process on the injected batch.

• resynchronize the divider that provides the gating of the long. feedback input/out to act on the incoming batch only [timing] (cf. injection bucket selector)
• raise the gain of the longitudinal feedback. A (gated?) function generator will raise and then lower gain, the generator will be triggered by a timing event. 1 ms resolution over 100's ms. Some time after injection (after damping of transient) reduce the gain of the feedback progressively (to avoid injecting RF phase noise). [timing, function]

What diagnostics will we have that the longitudinal feedback is working well (e.g. gain settings)? Beam loss... Built-in diagnostics?

Transverse damper (similar to longitudinal damper)

• resynchronize the divider that provides the gating of the long. feedback input/out to act on the incoming batch only [timing]
• raise the gain of the feedback. A (gated) function generator will raise and then lower gain, the generator will be triggered by a timing event. 1 ms resolution over 100's ms. Some time after injection (after damping of transient) reduce the gain of the feedback progressively (to avoid blowing up the emittance).. [timing, function]

Prepare ramp

• Measure the longitudinal emittance and readjust the voltage functions for the ramp.
• 400 MHz: change coupler and tuner offset to ramp position [command or timing] (is this necessary now we don't have the 200 MHz ?)
• Transverse damper: re-scale the analog front end (change gain) to cover the full ADC range. Reduce analog output gain accordingly. [command and timing and function]

Ramping

Low level

We normally ramp with synchro loop (both rings locked to the same reference) to avoid a big re-phasing before physics, and to ensure correct crossing point for maximum separation for long-range beam-beam. However, this requires an accurate frequency function derived from the true machine energy. So during commissioning we ramp with radial loop (i.e. fixed radial position, variable frequency) and we can feed forward the measured frequency corrections into the function (responsibility of LSA?).

• Download frequency function versus time [function]
• Radial loop on  (for commissioning only. In operation we remain on synchro-loop. Needs to be done after last injection and before start ramp [command/timing].

At injection we use high synchro loop gain for accurate positioning of incoming beam in bucket. At top energy we use high phase loop gain to avoid emittance blowup.

• Vary the gain of the phase loop amplifier during the ramp [function].
• Vary the gain and time constant of the synchronization loop amplifier during the ramp [function] (time constant must be > synchrotron period).

400 MHz: 2 voltage functions (I and Q) per cavity through the ramp [function]

Transverse feedback

• gain function through the ramp [function]
• on request from BI: change gain for a while, switch damper off, excitation... [timing, command and function] (needs to be re-discussed)

During the ramp

1. Emittance blow up via 400 MHz (1 eVs to 2.5 eVs) at a predefined energy. Blow-up via phase noise [timing, function or window, noise amplitude/spectrum?? discuss with Thomas/Elena].  Simultaneous increase in voltage function to adjust bucket area.
2. Reduce bunch length. Raise voltage to the maximum [function]

Do we pre-program these actions into the ramp functions, or do we use separate functions triggered by special timing events, or do we manage this internally in the LL HW?

Top energy, before collisions

Big re-phasing could be done but not foreseen, since we ramp with frequency lock. Might be a small nanosecond phasing error. Fine adjustment of collision point will be possible.

Low level

• set the gain of the phase loop amplifier for re-phasing [function]
• set the gain and time constant of the synchronization loop amplifier for re-phasing [function]
• re-phase using frequency program [command/timing]
• switch the reference of the synchronization loop to synthesizer if needed [command/timing]

400 MHz

• set the voltage to the value for re-phasing [function]

Dump

Some action must be taken on power amplifiers to avoid an over-current when the beam is dumped (heavy beam loading). Just before normal beam dump switch RF off - All RF power equipment off. Pretty clear that having done this the beam dump MUST take place [timing].

Ramping Down

Power saving actions on the power amplifiers.