1. Collimator BPM Discussion 14/3/2014

2.  DOROS agents produce position data at 25Hz  Also need to be sent settings at 1Hz  Settings need to arrive at all agents at exactly the same time  Total number of DOROS agents is ~100  ~20 are involved in the collimation system  Rest are placed elsewhere (before experiment IPs for example)  The solution we come up with for the collimator BPMs should be generic  So we should try to use same solution for all agents…  Is this in conflict with the topology already proposed?

3. (a) DOROS with standard BPMs(b) DOROS with collimator BPMs Figure 10 – The DOROS architecture, with standard and embedded collimator BPMs (DC = DOROS Controller; CC = Collimator Concentrator; OFC = Orbit Feeback Controller; DB = Database).  Problem might arise in OFC algorithm with added latency for standard BPMs?

4.  DOROS agents communicate with a new FESA class ( BPMDOROSLHC) and OFC directly – Collimator control class gets data via new FESA class  Collimator class has higher latency due to proxying by BPMDOROSLHC class  BLM UDP data already passes through a proxy  Position data more time-critical though…  Not a problem (?)  For the OFC, optimum in terms of performance – No proxying involved  Can be treated as reliable as standard BPM data  Conversion factors need to be maintained by BPMDOROSLHC class but also forwarded to the OFSU which will in turn forward to the OFC  OFSU would subscribe to Settings@BPMDOROSLHC over CMW  OFC can treat the data arrival like standard BPM data (i.e. very low latency, respecting the time window set by orbit trigger)

6.  DOROS agents communicate with only BPMDOROSLHC class  BPMDOROSLHC class acts as a proxy and forwards packets to OFC and collimator control system after applying factors  Factors only maintained and used by BPMDOROSLHC class  Proxying adds more than double latency to OFC reception  Can also be disturbed by server actions and general FESA jitter  Could be a problem if used in OFC correction  Doesn’t affect the collimation DOROS agents though

8.  Existing feedback loop  Wait for an orbit trigger packet (or timeout)  Wait for 1 of  Orbit trigger (B1/B2)  BPM  QQP  COD  Treat data appropriately  Data accepted between acceptance window from BPMs  Asynchronous treatment of data from COD / QQP  Send corrections  Send to OFSU over Tinterlink DOROS /DOROS

9.  New code required to receive and handle the DOROS data  How do we handle the data  1) Data is synchronous (like BPM data)  Implying that it has to arrive within n milliseconds of orbit trigger  We could examine the UDP packet to distinguish between a DOROS packet or classis BPM packet  Extend existing C++ handler for BPM data  Allows incorporation into the OFC feedback in the future  2) … or asynchronous data (like data from the CODs)  Requires a new C++ class : DOROSHandler.cpp  Data arrives and is processed  Fine for instrumentation via the OFSU (-> YASP)  Can’t be used in the OFC feedback  In the case of the ~20 collimation DOROS agents option 2) is OK, but will we need option 1) in the future for the other DOROS agents?  Re – Generic solution covering future needs of other DOROS measurements

10.  Decide which approach we take ASAP  Hardware team can’t give us final details of UDP packet structure until later 2014  But they agree to send UDP packets of some data soon  So we should deliver the bulk of the new FESA server soon (early summer)  We then add the details later in the year  Data might look like this…?  typedef struct {  char packetType[10]; // unique name, e.g. “DOROS.1.x\0"  char authorisationKey[8]; // reserved(future safety option)  int sourceHostNumber; // reserved  unsigned long sendTime_s; // reserved  unsigned long sendTime_us; // reserved  unsigned long long acqStamp; // reserved (used with synchronization enabled)(micro-seconds from first synchronization pulse (*3.2 time normalization into Seconds))  unsigned long seqNumber; // 0, 1,... - detects packet loss  unsigned short ADCsampleNum; // number of ADC samples  unsigned short Average_Factor; // averaging factor  unsigned int adcData[NUM_FRAMES*8];  } PacketStruct_DiodeBPM;