agustiner
commented
2 years ago Note it's common to use "ext_ref" for internal flux ramp resets. That mode will look for a clock signal on the front of the AMC, but won't, and then switch to internal timing.
Environment
SLAC RF Lab, C03-25, C03-26, pysmurf v5.0.3 develop
References
ESCRYODET-838
Description
This change permits use of the SMuRF timing crate for receiving timing from the fiber or backplane for the purpose of synchronizing the flux ramp of multiple SMuRF carriers.
This code assumes three use cases for SMuRF carriers: 1. their timing is internal, 2. on slot 2, timing is received by the timing fiber connected to its RTM, 3. not on slot 2, their timing is received from the backplane of the SMuRF crate. To support these three use cases, the pysmurf cfg file was changed to support three configurations in the "timing_reference" key: "ext_ref", "fiber", and "backplane". Configuration on ext_ref is unchanged for the purpose of internal triggering. Configuration on "fiber" now receives the timing signal from the fiber connected on the RTM, and distributes that signal to the rest of the backplane. Configuration on backplane will receive these triggers and lock its flux ramp to that signal.
To test this code, one SMuRF timing crate and two SMuRF carriers C03-25 and C03-26 were configured at each with one AMC. The software used was pysmurf checked out to the develop branch at the time of this writing. C03-25 was configured on "fiber" and C03-26 was configured on "backplane" timing using experiment_fp31_cc03-02_lbOnlyBay0.cfg as the baseline configuration. After setup(), the flux ramp on both carriers were enabled with flux_ramp_on(). The 15 kHz flux ramps were synchronous to within 5 microseconds on average. No other software configuration was necessary for this test. P.S. I'm not sure why 15 kHz was selected by default.
More thorough documentation is available at https://confluence.slac.stanford.edu/display/SMuRF/Software+Timing+Crate
Testing procedures for the timing crate should be made as soon as possible.