VELA Charge Measurements – Update Alex Brynes

Recap Introduced existing methods of measuring charge (WCM, ICT, FCUP, BPM, screen). Scope “Hardware controller” (naming convention TBD). Some software development considerations. Type Function void monitorTracesForNShots monitorNumsForNShots std::vector<std::vector<double>> getScopeTrace std::vector< double > getScopeNums getMinOfTraces getMaxOfTraces getAreaUnderTraces getAvgNoise double getScopeP1-4 getWCMQ/ICTQ/FCUPQ/EDFCUPQ std::vector< std::string > getScopeNames

How do we measure charge? WCM: first minimum of waveform. ICT: area under waveform. SP1 FCUP: peak-to-peak voltage. (Use this measurement to calibrate other devices.) Dark current: area under WCM waveform in AC 1MΩ mode. ED-FCUP and BA1/2 FCUPs: first peak of waveform.

Since Last Time Acquired a scope for testing (velascope03). Put in a “fake” signal. Tried to figure out what we can do in terms of control and monitoring, and to find an optimal solution.

Considerations What do we, as AP operators, want to use the oscilloscopes for? Measuring the charge (inc. jitter). Anything else? (NB Timing / RF signals etc., are for the experts.) How do we take measurements? Remote desktop in to the scope, look at waveforms, use measured data. How do we make sense of the data? With a calculator?? Through EPICS? …. With a Hardware controller?

Dynamic Shared Objects (DSOs) Essentially the same as a DLL. In this case: a library that can be loaded into VBS, c++, python etc. to access data from the LeCroy scope. (ALICE buncher zero-cross software used this method). This allows the user to write scripts to systematically take data. There are a huge variety of ways that the scope data can be accessed: http://teledynelecroy.com/support/softwaredownload/home.aspx?capid=106&mid=533&smid= - 18 software downloads for this purpose! I tested 2 of these – ActiveDSO and XStreamDSO – using Python.

Direct Interface with Scope (Remote Desktop) Pros: Allows complete functionality. (Relatively) easy to interpret. Fast saving of data to files / memory. Cons: Only one point of contact. (?) Too many options may lead to unsaved changes. Requires unification of scope data with data from other sources. Outside of the EPICS system. Can only record waveforms from 1 channel at a time – we can record all the measured values (P1 – P6), however.

Scripting with a DSO Pros: Cons: Same functionality available as when using scope software (easiest with remote desktop to scope). Allows writing of scripts to automate data-taking. Can write data to EPICS. Cons: Remote control (ActiveDSO) can be slow, and only 1 instance can exist. Whatever the method, it can’t go much faster than 10Hz when reading data from all 4 channels: “A 10Hz update rate is quite typical for any DSO…. Unless you were using a high speed digitiser, I can't suggest any other way of improving the update rate.” LeCroy Field Applications Engineer

DSO Control Prototype program exists on velascope03 for logging charge. Bare-bones, as it is expected that most people would rather interface with the scope directly to do more complex measurements, save and recall setups, etc. Any other desired features?

Further Work We need a sensible naming convention for scope setups based on what is being measured (after establishing the best way to take measurements for each diagnostic). Consider how to interface this with the multiplexer. Prototype software to calibrate devices. Find a different solution! This method is barely suitable for 10Hz operation, let alone 100Hz.