Real Time Beam Synchronous Acquisition (RTBSA)

ASOT-1 - Getting issue details... STATUS

Objectives

This module introduces the RTBSA GUI. After completing this module, an operator should be able to:

• Plot and interpret a signal vs. time
• Plot and interpret two signals against each other
• Plot and interpret the Fast Fourier Transform (FFT) of a signal
• Tune a signal using the plots (either visually or using linear/polynomial fit)
• Use the standard deviation filter

Introduction

Beam Synchronous Process Variables (PVs) are signals that are tied to the beam pulse that generated them. RTBSA uses this feature to build a pulse by pulse "picture" of the beam so that we can see correlations between signals that would otherwise be hidden.

Background

What is a PV?

PV stands for "Process Variable." We have a lot of devices on site, and those devices generate a lot of data. BPMs (beam position monitors), for example, constantly monitor where the beam is relative to the center of the beam pipe. One singular BPM, however, has a lot of signals that it reads out (chief among them x position, y position, and charge), and each one of those signals has a channel dedicated to reading it. It's kinda analogous to TV channels for a BPM TV - x position is on channel 2, y position is on channel 3, etc (except that the channel names are a little more complicated, like BPMS:LI24:801:X). Those channels are PVs.

Note: There are some devices that only have one signal that they read out (and therefore only on PV associated with them)

What does it mean to be tagged to a pulse?

Say that we have a train of pulses with pulse IDs 1 through 4, and say that we have a BPM somewhere watching them go by:

That BPM is going to send out data packets for each of its measurement channels every time it sees a pulse. Say that we care specifically about the beam's x position, so we tune into that specific channel. The data packets sent over that channel contain not only the raw beam position value, but also metadata like the timestamp and PV name. Crucially, the timestamp has the pulse ID encoded into it (one of 1 through 4 in our illustrated example) so that we know which pulse this data packet belongs to. Not all PVs have this encoding, but the ones that do are said to be beam synchronous.

What does this have to do with RTBSA?

Well, RTBSA stands for Real Time Beam Synchronous Acquisition, and it's a tool to help us correlate signals (PVs) in real time. 

How it Works

Data Buffers

A selected BSA PV is given a dedicated data buffer to hold its most recent values. Using the example above, let's say that we have a buffer size of 4 (so that we only store the 4 most recent values):

Where the first row is the pulse ID and the second row is the x position that the BPM saw for that pulse. While the PV is selected, the data buffer keeps getting written to modulo the buffer size so that when it sees pulse 5, it would become:

This is pretty much the backbone of the whole program.

A vs. Time

The simplest use case, where we have one PV with one associated data buffer. The default (and maximum) buffer size is 2800, but that can be reduced if desired. Whatever the buffer size n, we display the n most recent points as long as a kind of rolling EKG:

This is useful for seeing erraticisms in a signal (maybe you suspect a klystron phase is wandering), or to see how it's trending (maybe you're messing with a quad and you want to see if that's increasing/decreasing/doing nothing to the pulse intensity).

FFT

TODO ask Ahmed

B vs. A

The crown jewel of RTBSA. If there are two PV selected at once, there are two data buffers getting filled simultaneously