Implementation of the Tevatron 1.7 GHZ Shottky Tune Fitter. 

	Version 2.0

Adding second VSA

1.	Introduction.

This informal note describes the implementation of the 1.7 GHz Shottky monitoring software.  The 1p7GHz Tune Fitter is an essential component of this “Tune Meter” instrument.  The hardware – 1.7 Ghz resonator capable of reporting Shottky signals has been installed in FY04 [R. Paquaneli, RF Instrumentation Note #60].  It is now time to take advantage of this instrument in a systematic way: we will write both a data acquisition and analysis capable or running continuously, and control & monitoring tool.	
The project can be viewed as a port of the applications T122 (pa1973) and W101(pa1987) from the old Vax Console environment to the new PC/Unix based environment.  The justification for such a man-power intensive work is quite simple:  In order to report betatron tunes, and, possibly chromaticities, momentum spread and emittances for every bunch for each beams in due course, we need more computer power than the Vax has to offer. In addition, we want to add more options and program the GUI in a more modern environment, to save man-power cost in the long term.  Finally, Vaxes will soon – hopefully – disappear from the scene. 
         
2.	Overview of the Components

   The top-level architecture of this application is shown in figure 1. There are 4 boxes on this sketch:
	a. The GUI for the tune fits and results. It runs basically in two distinct modes: it either is completely passive, or, conversely, it controls the Vector Spectrum Analyzer (VSA) and the kind of fits we do.  In the former case, the GUI simply shows fitted spectrum and results. In the latter case the user will de-facto gain control over the OAC driving the fits and will be able to select beams or bunches. 

	b. The Open Access Client (OAC) will systematically loop over all requested bunches, all requested beams, or a predefined subset of these, set the hardware up, and request spectra from the VSA and fit the data. It reports the fitted values of the tunes and ancillary information to ACNET, so that we can data-logged this information on a continuous basis.   It can also report raw, smooth or fitted spectrum on demand via ACNET, such that the data can be displayed in the GUI.

Version 2:  Since we have 4 signals (Proton, Pbar, horizontal & vertical for both beams), we need two distinct dual trace VSA to be able to record all signals concurrently.  In June 2004, a second VSA has been added, and the Shotky OAC has been replaced by two OAC< shotpr (handling the proton signal) and shotpb (handling the pbar).  

	c. The VSA DA and the ROOT fitter. While the two packages mentioned above are written in Java, this vsa1p7Fits package is being written in C++.  The motivation for such a change of language is basically to improve the CPU performance, both at the level of DA (connection to the VSA) and to perform the fits. If we want to report the tune values ~ every minute, for each bunch and each beams, with only one VSA, this means that we have to get two fitted spectra every seconds.  Although at the present time, the fit does not seem to require no fancy convolution, nor advanced peak searching, (it is a simple two  -constrained- Gaussians on a flat background), getting the CPU performance is important.  Finally, the most advanced – in term of robustness – fitting package are now written in C/C++.  Note that this component is the only one that talks to the VSA via a direct, point-to-point (no third tier process) TCP/IP connection.  The other devices in the problem will be controlled by ACNET. 

Version 2: We have dedicated ROOT fitters for each OAC and VSA.  Note that these two distinct processes (TCP/IP servers) run concurrently and can run on the same system.  One has the port number 4025, the other has the port number 4026.  

	d. The TEK3034 Ocsilloscope viewer.  This scope is used to check that we have a signal coming into the VSA and that the bunch gates are set properly.  It might even not be software: we could do as well with a camera watching the traces. However, Ralph P. has downloaded various settings, and may be this needs to be controlled as well. 
Note that this box is not tightly coupled to any other applications (except the old Vax one, but this is not permanent), it could in fact be a standard GUI in front of it, all commercial (based on “remote LabView”, or nay other package use to control this type of device).  We will implement this one later, let us focus on the first three boxes.  

	These 4 distinct pieces can and most likely run on different computers. 
In particular, we do not want a CPU intensive component running on the same machine as the GUI, as the console on which this GUI runs must have guaranteed fast time response for other functions. 

Figure 1: Informal sketch summarizing the software components

3.	Implementation Details. 

	Some module – a few classes – will be used by both  the GUI and the OAC. They are written in the same language and deal with same set of devices.  We describe these objects first. Next, we'll go through the three major components (GUI, OAC, VSA/fitter).  I understand that we want both the OAC and the Console Application (GUI)  to be stand-alone entities that do not rely on other user libraries. If this is the case, we will simply clone these classes, one copy in  the OAC and one in the GUI.  Otherwise, may be we can create java packages such that we only have to maintain one copy of these.  This is obviously a safer software practice, for maintenance reasons.  To be discussed with Denise, Kevin or Jim.  These minor utility classes handle the communication between the ancillary devices and the Tevatron environment, and between the GUI and the OAC:

	a.  The BeamEnv class.  This class basically listens to the Tevatron basic devices status: (T:ERING and T:IBEAM), and reads the Sample Bunch Display (SBD) bunch length and intensities. The frequency at which we read this data is 1. Hz. The only public method are essentialy accessors: we need to know if there is beam in the machine (T:IBEAM > 0.1) and if the energy (T:ERING) is greater than 900 GeV. (Indeed, we plan to commission this application at 980: the bunches are too unstable, and the cogging change too often to give relevant data at 150 GeV.  However, we must leave this option open for future upgrades. Anyway, no matter what, we need this information. In addition, we need the SBD information to improve the fitted values of tune and chromaticity.  The 4 array devices that we need from the SBD are:

	-T:SBDPSS : Proton bunch length, in ns. 
	-T:SBDASS: Antiproton bunch length 
	-T:SBDPIS: Proton bunch intensity (e9)
	-T:SBDAIS: Antiproton bunch intensity. (e9)

	These arrays are dimensioned to 37, the first element is an average over all bunches (of no interest to us here) and the last 36 are contain the bunch-bunch information.  The bunch length will be used to compute the momentum spread, there will be a small private method to convert a measured bunch length to a dP/P.  

	Since the frequency at which these devices are reported is ~10 to 60 times higher than the rate at which we can get a decent tune measurement for a given bunch, it makes to average.  Thus, this class will keep track of the most recent value, and the value obtained by average over a fixed period, like two minutes (must a parameter easily changeable, probably an argument to the constructor).  As, this runs completely asynchronously with the rest of the application, the class will keep in memory the most recent time-average value and keep computing the current averages. 

The detailed list of the public “accessor” methods  will be available in the java.  They are sort of obvious (getCurrentBeam(), getCurrentEnergy(), getCurrentBunchIntensity(int ibunch), getCurrentBunchLength(int iBunch), getAverageBeam(), …)
Note that there will also be a method to compute the dP/P from a given bunch length.  Such an algorithm is already implemented in the OSDAPhysics package.. 

 	b. The BunchGating class: Contrary to the previous class, this one will read and set devices. So it's public method are of the type “Set” and “Get”. From the DA perspective, it sets and occasionally reads 4 ACNET variables. The 4 array device it controls are: 

	T:SHKGPH : Proton horizontal gate. 
	T:SHKGAH: Antiproton horizontal gate.
	T:SHKGPV : Proton vertical gate. 
	T:SHKGAV: Antiproton vertical gate.

	These are of boolean type (“state device”) dimensioned to 36, commensurate with the maximum number of bunches for coalesced beams. 
The old Vax routines to tun them off or on were called, 
dio_array_device_off_c and dio_array_device_on_c, I presume we have convenience methods in the new Java length to do the same.  

	Let me explains why we occasionally need to read these devices. This is simply because these can be set by the GUI.  Indeed, the user may decide to select a specific set of bunches.  The GUI will have a small panel to set this up.  It will then send a message via an ACNET state device that the OAC.  The OAC becomes a slave to the GUI. For instance, instead of looping over all bunches, the OAC will skip over bunches that are not requested, or simply keep taking data for a given gating configuration. Therefore, this class will have two distinct copies of these boolean arrays; the current values that have been most recently send to ACNET while running in standalone operations and the requested “mask” or settings, driven by the GUI. 
The default for this mask will be “all bunch on”.  Note also that the read method, unlike in the BeamEnv class, will be synchronous, read once.  But the method can be called multiple times, obviously.  Performance here is not critical, since the GUI drives it all. The OAC will go through a sequence of steps: pausing first, reading the requested setting, than resuming data taking and looping as requested over the bunches.
(or keeping the setting fixed). 

	c. The multiplexing gear, SetMUXVSA class  connecting 2 out of the 4 available signal (proton vs pbar, horizontal vs vertical) to the two available VSA traces. This box is needed because we do not have a second VSA device, and we are interested in the four channels (purchasing this 2nd VSA would simplify our application and increase the output rate by a factor two, but it is not in the cards right now).  This switching box is final state machine, with 4 discrete states: 

	Proton :  Trace 1 of VSA connected to Proton Horizontal, 
	              Trace 2 to Proton Vertical 
	Antiproton: Trace1 of VSA connected to Antiproton Horizontal,
	                    Trace 2 to Antiproton Vertical  
	Horizontal : Trace 1 of VSA connected to Proton Hor. , trace 2 to 		Antiproton, Hor. 
	Vertical :  same, but vertical signals.

	As the  BunchGating  class, the SetMUXVSA class simply sets this small switching network.  But it must keep track of what has been done.  Note also that we want to be able to set the MUXVSA independently from the bunch gating. For instance, we want to study the signal induced by the proton beam on the antiproton pick-ups.  (The Shottky cavity has good, albeit not perfect, directionality).   To implement this, a simple 16 by 16 multiplexing device is supported by the ACNET device T:MXADxx, xx = 00 to 15.  If T:MAXDxx = yy, then, output channel xx is connected to the input channel yy, where xx and yy are channel number, 0 through 15.  Currently, the input channel are (see T58 Vax console application, private communication from Jim Budlong) :

00	Horizontal Proton Sum Signal 	
01	Horizontal Proton Differential Signal	
02	Vertical Proton Sum Signal	
03	Vertical Proton Differential Signal	
04	Horizontal AntiProton Sum Signal	
05	Horizontal AntiProton Differential Signal	
06	Vertical AntiProton Sum Signal	
07	Vertical AntiProton Differential Signal	
08	Proton Gate, Horizontal	
09	Proton Gate, Vertical 	
0A	Antiproton Gate, Horizontal	
0B	Antiproton Gate, Vertical 	

Old Configuration 

The output channel are connected to the 4 input oscilloscope input channel (0 through 4), the out put channel xx = 04 is connected to an external trigger, output channel xx = 05 and 06 are connected to the VSA input trace 1 and 2 respectively.  Assuming this won’t changed (why would we doing this?), then we can easily set devices T:MXADC00, 01, 02, 03, 05 and 06 to implement the 4 configuration we want for this application: 

 xy                        00           01           02         03                   05               06     
    
Proton                 0           8            2         9                     1               3

Pbar                    4          10            6        11                   5                7

Horizontal          0          8            4        10                  1                  5 

Vertical              2           9           6        11                   3                7 

Note that the W101/pa1973 Vax console application is capable of doing more combinations ( for instance, interchanging VSA 1 and VSA 2 inputs, so that the vertical signal appears on trace 1 instead of trace 2, for instance).  I don't see the need for this.  We can decide once for all that the horizontal signal will appear on trace 1, and vertical signal on trace two when either the Proton or the Pbar configuration are chosen.  Trace 1 and Trace 2 of the VSA have equivalent capabilities.  (Note also that the C code in the file vsabox.c is a bit confusing, I obtained this mapping by reversed engineering, and discussing this Dave McDowell and Jim Budlong.)  So, to conclude this section, here is map describing Trace assignments:

Version 2: New Configuration, with two VSA.  Configuration for the shotpr OAC: 
 
xy                        00           01           02         03                   05     06    
    
Nominal                 0           8            2         9                     1      3 
        
Configuration for the shotpb OAC :

xy                        00           01           02         03                0D  0E  
    
Nominal                 0           8            2         9                     7       5

So,  as we have two distinct OACS, for nominal running (fixed!) The first OAC, shotpr,  will deal with the Proton Signal and will therefore set , at initialization,

T:MXAD05 to 1 and T:MXAD06 to 3 

While the second OAC, shotpb,  will set :

T:MXAD0D to 7 and T:MXAD0E to 5

That is it. The old mode 516 is no longer relevant.  We will run by default in mode 512, for both OACS  so the MUXVSA assignment for the VSA signals will be fixed.  However, the bunch gating will still be variable, depending on the mode. 

Case 		Trace 1 		Trace2

Proton Only		Horizontal 		Vertical 

 Pbar Only		Horizontal 		Vertical 

Horizontal Only	Proton  		Antiproton

Vertical Only	Proton		Antiproton.  

	d. The OACStateManager class. We need a small class to control and manage the various states in which the OAC will run.   There will be a new ACNET device, yet to be defined.   For the purpose of this document, it suffise to state it's description:   TeVTune 1.7GHz OAC Crntl.   This state device can have a status, reading, setting, and is 4 bytes long.  I was thinking making it 255 character long, so that it can be explicit.  However, we might want to set this device “by hand” at some point,  and we would have to write a spell checker when a causal user sets it up. It is as convenient to establish a small directory of state, and document it.  The purpose of this class is twofold: (i) manage this directory of states (ii) read and set the state, elementary SetState and CheckState methods that writes the requested value for the corresponding state, or reads the state.  Unlike the two previous class, the read this time if of “asynchronous – listening” type, as  the BeamEnv class discussed above.  The listening frequency is 5 Hz, if sustainable in Java without affecting the performance of the GUI, or the OAC. The role of this class  will become obvious when we get to the OAC per se. 

	The former function (the dictionary) can be easily implemented with a simple Java Map of the type (int, string).  A start on what these states are is shown on table 1. The keys are preliminary, if the implementer finds a better scheme, that's fine. 
The communication between the GUI and the OAC  will be implement based on a simple handshake, with two distinct ACNET devices.  One in principle could be enough, but the coding will be simpler if we have one device that is read by the OAC and set by the GUI ( or via any other application capable of setting an ACNET device), and an other device which set by the OAC, and read by the GUI.   This allows us to control the hand-shakes between the two processes, and clarify the list of action that need tot take place when a state change is detected, either in the OAC and the GUI.  This list will be described in the section below describing in details what needs to happen in each process. 

Thus, the constructor of  this class has one argument, Boolean, which states if the instantiation is done from the OAC or, conversely from the GUI.  The two ACNET devices for this message passing will be: 

T:TU7ST1 : Tune Fitter, OAC shotpr  State set by the GUI and read by the OAC 
T:TU7ST2:  Tune Fitter, OAC shotpr,  State set by the OAC and read by the GUI
T:TU7ST4 : Tune Fitter, OAC shotpb  State set by the GUI and read by the OAC 
T:TU7ST5:  Tune Fitter, OAC shotpb,  State set by the OAC and read by the GUI

The method checkState asynchronously reads one of these to devices, but never both. The method SetState also set only one of these two devices, the setting is synchronous, “immediate”. 
In addition to these two devices, the GUI will also listen via this class for the variable T:TU7ST3.  We need a third device to assert that only one copy of the GUI is running, to avoid conflicting settings on the VSA and/or the bunch’s gates and the multiplexer.  Prior to exiting, the GUI will reset this variable.  Upon starting a new instance of the main class “TevtuneShottky”, the GUI will check that this variable is indeed set to zero. If so, it set it to 1. Else, it will print a warning, advising the user to figure out who is using the system to avoid such conflicts. 

Note: these classes reside in the OAC shotpr source tree, but are used by both the main class of the shotpb and shotpr

A. The OACs  

	Prior to describe the main body of this new OAC, we need one more utility class: InterfaceVSA.  This class will be used only in the OAC. It is the only class that has “native” attribute in the OAC.  All communication between the C++ RootFit package and VSA DA is handle here.  If two big, we could split it in two parts, VSA/DA and fitting, but it probably is not needed.  This class has no ACNET functionality.  It has a minimal constructor, which essentially starts ROOT and checks the VSA.  It has the following methods.  All of them are minmum, since the real meat in them is in C++.  Their implementation is “native” (JNI).

	FixChromaticityAt(double value)
	FixdPoPAt(double value)
	ReadVSATraceData(int iTrace)  
	DoSmooth(int iTrace, double numBins); 
	DoFitModelOne(int iTrace);
	...
	GetTune(int iTrace) 
	GetChrom(int iTrace)
	GetEmittance(int iTrace)
	GetDPoP(int iTrace)
	.... 
GetVSACenterFrequency(double value)
	GetVSAFrequencySpan(double value)

	    ….

	SetVSACenterFrequency(double value)
	SetVSAFrequencySpan(double value)
	…. 

This list is not exhaustive. For detail, see the InterfaceVSA class.  
Note that all the corresponding C++ methods are straightforward procedures, with no extra threads being generated, except of course the C++ process itself instantiated by the JNI itself.  Thus, a thread in the OAC application will have to wait until a “return” statement from each of these methods is generated. We expect the CPU intensive “DoFitModelxxx” methods will take a fraction of one second, or less. 

The OAC main body becomes now relatively simple.  It is basically a state driven engine that uses the resources defined in the classes discussed above, and write to ACNET the result of the fits. It starts by doing what every OAC does in the system.  Its specific initialization phase consists of instantiating all the above class, one of each. The last initialization action is to set T:TU7ST2 to 256 (see definition below). It then reads asynchronously the State (device T:TU7ST1).   The OAC will be “ polling” this device. Here is list of action to be taken when the following states are encountered, while reading T:TU7ST1:

Case 0 :   Disabled or Paused state 
  The OAC is pausing.  That is, we will not ask data from the VSA nor do fits, nor change the bunch gate or the multiplexing (Beam/planes) configuration.  While in the paused state,  different settings for the VSA or different such configuration can be established, as lited down below.   The device T:TU7ST2  is set to 0, by the OAC, once the OAC is paused. Valid for both OACs 

Case 2 :   OAC is a not Stopped state 
  The OAC is no  longer to the C++/ROOT server.  This can be used to kill this server, and updating it.  The OAC can be reconnected to this new UNIX server process. 
Valid for both OACS 

Case 16 to 63 are reserved for controlling the fitting package. Note that prior to encounter such a state, the OAC has been paused. See above.  In all such cases, once the setting has been done, T:TU7ST2 is set to whatever T:TU7ST1 has been set. Then, the GUI restarts the OAC 

Case 16 : Set the fitting mode such that the Momentum spread dP/P is fixed, determined by the SBD data.  This is in fact the default mode of the fitting package, but it might have been overwritten (see below) .  Valid for both OACS 

Case 17 :  Set the fitting mode such that the momentum spread  is left as free parameter is the fit. Valid for both OACS 

Case 18 : Set the fitting mode such that the chromaticity is fixed.  This is not the default option for the fit.   The OAC reads the ACNET device T:TU7CHC (Current Chromaticity value), and gives this value to the fitting package. Valid for both OACS 

Case 19 :  Set the fitting mode such that the chromaticity is left as free parameter is the fit. Valid for both OACS 

Case 64 to 127 are reserved for controlling the VSA. Note that prior to encounter such a state, the OAC has been paused. See above.  The settings information is taken from specified ACNET devices. The OAC will read (synchronous, “immediate”, and read once) the ad-hoc device, and invoke the corresponding “Set”  method of the InterfaceVSA class.    In all such cases, once the setting has been done, T:TU7ST2 is set to whatever T:TU7ST1 has been set, such that the GUI is informed that the setting has been done.

 Valid for both OACS 

Case 64 Set the frequency center of the VSA traces to the value read in T:MWSCEN

Case 65 Set the frequency span of the VSA traces to the value read in T:MWSSPN

Case 66 Set the voltage range for  trace1 to the value read in T:MWSRG1

Case 67 Set the voltage range for  trace2 to the value read in T:MWSRG2

Case 68 Set the voltage “Low” range for  trace1 to the value read in T:MWSRL1

Case 69 Set the voltage “Low” range for  trace2 to the value read in T:MWSRL2

Case 70 Set the voltage sensitivity for  trace1 to the value read in T:MWSSC1

Case 71 Set the voltage sensitivity for  trace2 to the value read in T:MWSSC2

Case 72 Set the number of average the VSA performs to the value read in T:MWSAVG

Case 74 Reset the VSA, such the device is now running with the default values of the above parameters. 

Case 128 to 143 are reserved for resetting the VSA, or asking for specific request to the VSA, like recalibration.  Once again, note that prior to encounter such a state, the OAC has been paused by the GUI.  .    In all such cases, once the setting has been done, T:TU7ST2 is set to whatever T:TU7ST1 has been set, such that the GUI is informed that the setting has been done. 

Case 129  Request the VSA to re-calibrate itself. 

 Case 256 to 511 are reserved for actually running in normal mode. This is the basic functionality of the OAC.  In this mode, the OAC no longer rely on the GUI, and is completely standalone.  It can configure the Beam/Plane multiplexing box, the bunch gating box, and request data from the VSA using the InterfaceVSA JNI class. 

Thus, once this state change request is detected, the following action occurs: 

a.	Verify the energy is greater than 900 GeV and that the beam is greater them 0.1 e12. If not, go to sleep for 0.5 seconds and check again. 
b.	Else, 
a.	If need be (see specific states below) , read the bunch gating configuration, defined by the 4 ACNET array variables used in the BunchGating class.  These could  be the active bunches, for which we will report tunes, chromaticity, … 
b.	Set T:TU7ST2 to whatever T:TU7ST1 is set. 
c.	Start looping, as prescribed by the following states:

Case 256, 257 and 258 1 are reserved for actually running in normal, default mode, in which we loop over all bunches.  All bunches are considered, sequentially. The OAC will set control both the bunch gating and, if need be,  the multiplexing device as well. Specifically, 

Case 256: Default mode.  We loop over all beams and bunches, setting the gate “on”, for one bunch at a time. While setting the proton bunch gates, the multiplexing box must be set for “Proton”.   Then, after measuring the tunes, chromaticity,.. for each bunch in the machine (36 of them), the OAC will configure the multiplexing box for Pbar, set the pbar bunch gates, sequentially, to record the tune for every bunch. 
Deprecated !! in version 2

Case 257:  Proton only, We loop over all bunches, setting and leaving the multiplexing box in the ‘Proton” mode. Reports tunes, chrom., only for proton bunches. 
Handled only by schotpr

Case 258:  Pbar only, We loop over all bunches, setting and leaving the multiplexing box in the “Antiproton” mode. Reports tunes, chrom., only for pbar bunches. 
Handled only by schotpb

Case 260, 261 and 262 are reserved for running on all bunches within a train. These modes are very similar to the mode 256-258.  The bunch structure around the Tev has a 3-fold symmetry, to accommodate collision at CDF and D0, concurrently. There are 3 bunch trains, each comprising 12 bunches.  When a given bunch is selected, it is selected on all three trains, concurrently. All such 12 sets of bunches are considered, sequentially. That is, we set the gates for bunch 0,12 and 24, ON, (all other OFF); take a spectra and perform the fit, then set the gates 1, 13, 25, take data and perform the fit, then set the gates 2, 14 ,26, and so forth.  The OAC will set control both the bunch gating and, if need be,  the multiplexing device as well. The OAC will fill the T:TUBxxx ACNET array as in the above cases (256 – 258), setting the same values for 3 elements at a time, once one such iteration is done.  Specifically, 

Case 260:   We loop over all beams and sets of 3-bunches, one in each train,  setting the gate “on”, for 3 bunch at a time. While setting the proton bunch gates, the multiplexing box must be set for “Proton”.   Then, after measuring the tunes, chromaticity,.. for each such bunch combination in the machine (12 of them), the OAC will configure the multiplexing box for Pbar, set the pbar bunch gates, sequentially, to record the tune for every bunch. 
Deprecated in version 2!!

Case 261:  Proton only, We loop over all sets of 3-bunches, setting and leaving the multiplexing box in the ‘Proton” mode. Reports tunes, chrom., only for proton bunches. 
Handled only by schotpr

Case 262:  Pbar only, We loop over all sets of 3-bunches, setting and leaving the multiplexing box in the “Antiproton” mode. Reports tunes, chrom., only for pbar bunches. 
Handled only by schotpb

Case 274 to 282 are reserved for actually running in which we loop over all preselected bunches. Therefore, prior to start looping over bunch configuration, the OAC will the bunch gate devices, keep them in memory (the BunchGating class is all setup for this), then loop only over these pre-selected bunches, sequentially. The OAC will set control both the bunch gating and, if need be, the multiplexing. Specifically, 

 Case 282: We loop over all beams,  all selected bunches, setting the gate “on”, for one bunch at a time, if the pre-selection is “on” for that given bunch. While setting the proton bunch gates, the multiplexing box must be set for “Proton”.   Then, after measuring the tunes, chromaticity,.. for each such bunch in the machine (maximum 36 of them), the OAC will configure the multiplexing box for Pbar, set the pbar bunch gates will be set, sequentially, to record the tune for every bunch. 
Deprecated in version 2.0

Case 283:  Proton only, We loop over all pre-selected bunches, setting and leaving the multiplexing box in the ‘Proton” mode. Reports tunes, chrom., only for proton pre-selected proton bunches.   Handled only by the shotpr OAC

Case 284:  Pbar only, We loop over all bunches, setting and leaving the multiplexing box in the “Antiproton” mode. Reports tunes, chrom., only for  pre-selected pbar bunches. 
Handled by  in shotpb. 

Finally, last set of cases. This time, the configuration of the multiplexing box nor the gating configuration changes. It is set by the GUI.  Instead, the OAC is simply in a tighter loop, getting data from the VSA, fitting it, reporting current value of tunes and ancillary data  to ACNET.   In order to write to ACNET the appropriate variable resulting from a fit  (the VSA fitter knows only about traces, after all), the OAC will read the VMUXVSA status which has been set by the GUI. 

Case 512:   Performs only fits, on both trace 1 and trace 2 This is now the default mode, while using both OACS and both VSA concurrently. We will set the MUXVSA to gate on all bunches, by default, and hard-wire the connection as defined by the table above in such a way that the shotpr OAC connects to the Proton VSA (the old one, arbitrarily chose) and the new VSA is connected to the Pbar signal, handled by the second OAC named shotpb.  Upon initiating this mode, all bunch gates are turned On, for the corresponding beam.  

Case 513:   Performs only fits and  only on trace 1, by the shotpr OAC   Unlike case 512, we do not change the status of the bunch gates when going into this mode.  

Case 514:   Performs only and  only on trace 2, by the shotpb OAC   Unlike case 512, we do not change the status of the bunch gates when going into this mode.  

Note that the thread that will execute one of these loops will also have to listen to the thread reading the T:TU7ST1/TU7ST4, and of course, the beam intensity. 
The main class of the OAC will also have a bunch of methods to report the fitted values of tune, chromaticity, dP/P (optionally, see above) and the emittance to ACNET. We will define these ACNET variables very shortly.  Note that there will be two kinds of such variables: a set of scalar variables, and a set of arrays, dimensioned to 37.  While we loop over bunch (case 256-511) , or keep taking data with a given set of fixed bunch gates, we will report the current values of these fit results, i.e., the last fit result obtained for either the Horizontal or vertical plane (or for either beam).  These are the scalar variables. These “latest”  results will then be displayed by the GUI, and data-logged with a frequency of 1 Hz.  Note that we will also write to ACNET the current bunch for which the Gate is ON, if  relevant.   In default mode (looping over all bunches, pre-selected or not, we will also produce arrays, the index of these arrays being the bunch number.  The first element is the average over all bunches.  Finally, these ACNET variable will have – as part of their 6 letter names – attribute specifying the beam (“A” or “P”) and the plane (“H” or “V”). 

T:Tuabpq

Where :
“a”  is either L or B  Mnemonics : L stands for the latest, B for “all Bunches” 
“b”  is for the beam type, Antiproton (A) or Proton (P)
“p” is for the plane, either H or V
“q” is the physical quantity: 
	T : The tune itself, non-integer fraction of the beatron tune.
	P : The momentum spread, in units of 10^-4. (Only if the fit is set to let this quantity to be fitted ) 
	C : The fitted Chromaticity 
	E : The fitted emittance. 

The variable T:TUBUNC is the current bunch number on which we are gating. It is a scalar quantity, which only makes sense if we are indeed looping over bunch gates.  If the antiproton beam is currently selecting in the Multiplexer, then the value of T:TUBUNC is the bunch number (ranging from 1 to 36) + 100.  Conversely, if the Multiplexer is set to Proton beam, than it has the value of the bunch number ( 1 trhough 36) . If  the OAC is not looping over bunch gate configuration, than this parameter is meaningless but should be set to 999 to avoid confusion when analyzed later.  

The variable T:TUSPqn will be reserved for the spectra generated by the VSA or the tune fitter. They will be dimensioned to at least 401 floats. “q”is :
	R : raw fit, just a straight copy of what is in the memory of the VSA (logarithmic scale, in dbm). 
	S : the smooth spectrum. May not be generated, we do not know at this point in time such an algorithm will produce good results. 
	F: Fitted spectrum, also generated by the C++/ROOT fitting package. 

B Implementing of the interface between the Java OAC and the C++ Root Fitter. 

  Two implementations of this interface have been written: Java Native Interface and a UNIX Socket based communication.  The first one has not been thoroughly tested: we had trouble avoid clash of interrupt handlers between ROOT and the Java Virtual Machine for about a week. Thanks to Philippe Canal, we were able to fix this at the ROOT level, however, it shows how “”brittle” this interface could be.  The preferred choice is now the Socket based communication method.  The OAC acts as a client of a dedicated ROOT server. The Java class for this interface is RootFitsDirectCom  It is based on the java “new I/O” package, class Socket. The message passing is very rudimentary, based on simple command name followed by arguments, all ASCII. 
It is documented in the C++ main module named (for now) t2Fit.cc 

C.  The Root based Tune fitter. 

D. The GUI 

	A few picture is worth 1,000 words.  On figure 2 …  

The main panel for the GUI. 

In default mode, the GUI basically listens to the OAC, update the fitted values for each of the 4 channels. The user can plot the spectrum, raw and fitted on top of each others. 
The application can also be used to drive the OAC. For sub-panels can be instantiated from the top-level menu bar labeled “Options”.  They are : 

The “Scanning ofr Fixed” panel. With some English typos we’ll fix later ! 

 If the user actually decides to control the OAC, he then will configure the multiplexing to select a Beam, or a plane, by selecting the following panel: 

The Panel to select the beam or plane configuration OBSOLETE in version 2. 

Next, the user will set the bunch gates, for either one of the beam, of both, depending on the options he chose above:

By default all gates are activated, since we loop over all beams/bunches to get the tune for every bunch separately and sequentially. 

The user then resumes the OAC  DAQ processes and fitting procedures from the main panel (Green arrow in the Menu bar task).    

C. The Root-Fitter & VSA interface. 

	Already written, to a large extend.  Minimal functionality is there though..  

4.	Migration schedule & plan.   By mid-November, the OAC should be ready.  The GUI is likely to come up in the same time frame.  However, I am sure people will run the existing W101 and T122 application in the mean time.  This means that we will have agree on who has the token for controlling the physical devices (VSA, gate and switching box).  We plan to do this via gentleman agreement. That is, we do not plan to upgrade the W101 application to read the T:TU7ST3. 
 
5.	Final Note: Writing the OAC in C++ .  Not in the cards for now, I am afraid. The infrastructure for ACNET access is to there. May more important, we do not the “consolidation” nor security in place to throttle the ACNET request.  This will come in due time, if power at be decide to allow for a C++ implementation.