Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check phase syncing of BPMs' decimators #1019

Open
guilhermerc opened this issue Aug 25, 2023 · 2 comments
Open

Check phase syncing of BPMs' decimators #1019

guilhermerc opened this issue Aug 25, 2023 · 2 comments

Comments

@guilhermerc
Copy link

guilhermerc commented Aug 25, 2023

We recently exposed a feature for BPMs to generate synthetic data based on internal counters. These counters increment at their respective rate and can be synced (reset) across all BPMs by pulsing an external trigger. This can then be used for checking the phase syncing of BPMs' decimators.

Things left to decide:

  • Which physical trigger should we use? Lines 3 and 6 aren't being used, but we can use reuse another line too.
    Lets say we picked PT_n.
  • Which high-level event should we use? FAC group can better decide this.
    Lets say they picked HLE.

Configurations:

  • Route logical trigger 3 to physical trigger PT_n.
  • Set event HLE to pulse PT_n in all AFCs Timing.

After phase syncing BPMs' decimators, the following steps should be done

  1. Reset internal counters.
  2. Enable synthetic data generation.
    caput $(P)$(R)TestDataEn-Sel enable
  3. For each acquisition rate in {TbTAmp, FOFBAmp, FAcqAmp},
    acquire all BPMs [*];
    pick any antenna (counters are replicated in {A, B, C, D}) and check if data across all BPMs is equal.
    If data isn't equal, the phase syncing procedure for this acquisition rate should be redone.
  4. Disable synthetic data generation.
    caput $(P)$(R)TestDataEn-Sel disable

[*] There's a known bug for acquisitions higher than 2046 samples, so one should use < 2046 for this step.

@guilhermerc guilhermerc changed the title Checking phase syncing of BPMs' decimators Check phase syncing of BPMs' decimators Aug 25, 2023
@ericonr
Copy link
Contributor

ericonr commented Aug 25, 2023

One risk of using the ACQ cores for this procedure is interfering with any diagnostic or experimental scripts. So I'd potentially consider using the much less commonly used ACQ_PM cores, which, IMO, is even more attractive once we consider that we have to disable the orbit interlock when test data is enabled.

Which physical trigger should we use? Lines 3 and 6 aren't being used, but we can use reuse another line too.
Lets say we picked PT_n.

If we go with the above suggestion, it seems reasonable to me to use the PsMtn physical trigger (though I'd still like to discuss a new physical trigger for experiments, instead of overloading the FOFB physical trigger).

Which high-level event should we use? FAC group can better decide this.

IMO we should definitely have a new high level event.


Finally, for checking Monit rate synchronization, we could discuss adding AmplA-Mon monitoring to the sofb-mon IOC, so measuring an "orbit" with AmplA-Mon and verifying that all antennas have the same amplitude is possible.

@ericonr
Copy link
Contributor

ericonr commented Aug 25, 2023

Another point to be considered here, if desired, is if we are going to change the synchronization scheme for switching.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants