You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Reset internal counters.
Enable synthetic data generation. caput $(P)$(R)TestDataEn-Sel enable
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.
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.
The text was updated successfully, but these errors were encountered:
guilhermerc
changed the title
Checking phase syncing of BPMs' decimators
Check phase syncing of BPMs' decimators
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.
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:
Lets say we picked
PT_n
.Lets say they picked
HLE
.Configurations:
PT_n
.HLE
to pulsePT_n
in all AFCs Timing.After phase syncing BPMs' decimators, the following steps should be done
caput $(P)$(R)TestDataEn-Sel enable
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.
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.
The text was updated successfully, but these errors were encountered: