Apparently, there was a mismatch in the configuration, and DAQD was adding a wonderful 16 Hz comb all over the spectrum.

I stopped the processes, but couldn't restart x3cr1. It turned out that I can't save a channel to frames with a sampling frequency lower than 256 Hz. I changed the model, recompiled and restarted. Now the 16 Hz is gone.

/opt/rtcds/tst/x3/chans/daq/X3EDCU_CR1.ini
/opt/rtcds/tst/x3/chans/daq/X3EDCU_TST.ini

I removed the low pass filter in the QPD SUM signal, used for normalization. This reduced a lot the bump at ~20kHz due to laser intensity noise.

I also switched off the 500 Hz high pass filters in the X_NORM and Y_NORM signals.

This morning I found the cymac and the workstation rebooted, so I suspected a power cut in the last days. However, the function generator and the power supply for the QPD were off. So somebody must have turned them off.

Please write those actions in the elog!

Removed the peak meter lock from the model, since it's not used

Added and EPICS binary bit to control the autocenter, added corresponding buttons to the MEDM screen.

Now the GUI stops the autocentering when acquiring the reference spectrum.

The auto_excite.py also stops the autocentering 35 seconds before the excitation and until 35 second after the excitation, to provide for two reference quiet periods.

To be used to automate the laser polishing.

Last night measurements didn't work well: even without exciting the modes, the ADC was saturating because of the low frequency signal, particularly a 58 Hz peak:

When the modes were rang up, thing got clearly even worse:

Modification of whitening filter

So I modified the whitening filter, changing C6 from 2.2u to 220nF. The old and new whitening filters are shown below. We have the same amount of whitening at high frequency, but less amplification of the junk at ~50-100 Hz

With this modification, there's no more saturation, even when the modes are excited.

I modified four more QPD boards to implement the new whitening filters detailed in elog 207.

For a long time I had problems with the GPS time in frames being different from the real one.

This morning I rebooted the cymac3 and swapped the function generator with a new one.

I tested the GPS time in frames by switching on teh ESD noise at a given GPS time and checking the frames. The times are aligned.

I'll have to wait and see if this remains stable over time (in the past i saw an acculation of few seconds per day)

EDIT: I checked the two SR DS345 one against the other. Indeed, when bpth set to generate 65536 Hz, there is a continuos drift in the relative phase, accounting for one cycle over about 3.9 seconds. This would sum up to one second over ~256000 seconds, or about 3.5 days. It seems more or less comparable with the amount of GPS time mis-syncronization I saw. I'll have to wait a few days to see if the new clock is stable.

We want to be able to drive any combination of the four samples in the new setup, by using only one HV amplifier.

So I designed and built a remotely controlled relay box: one HV input and four HV outputs, controlled by four relais. The relais can be switched using a logic signal coming from DAC channels.

The system is finished, tested and working. Details in D1600456

Things seems to be worse now. This morning I injected noise at GPS 1165078533 (real time, as obtained from the python command line, and consistent with what displayed in the MEDM screen) and found the injection in the data at GPS 1165078555, so 22 seconds later...

UPDATE:

Now the time difference is about 30 seconds. It seems that the real time model is about 29 seconds advanced with respect to the GPS time one gets from a python script command running on the cymac3

The GPS time I get from python is the same I get from a shell script on the workstation or on the cymac3. I checked that it is also consistent with the GPS time on cymac2.

I moved the picomotors at precise times and looked at the data in the frames. Indeed the data has the wrong time stamp.

I swapped the SR signal generator with an Agilent 33210A. Shut down and restarted the cymac3. Now the command line GPS and the IOP model GPS are aligned within one second. Let's see if it stays this way.

Update at 5pm, GPS times are still in sync.

Unfortunately, this morning the model time is again wrong...

I modified the autocenter script. Now while the picomotor is moving, the variable X3:CR1-AUTOCENTER takes the value 1, otherwise it is 0.

I put back the Stanford Reserch signal generator. On a scope, the timing signal looks good. There is a small ripple and some noise in the flat parts. I found that when I unplug the DAC timing cable, the ripple and the noise goes away. 

I'm leaving the DAC timing unplugged for the night, and I'm using a script to track the difference between the machine time and the front-end time.

For the last ~day the difference between the frontend GPS time and the machine GPS time remained constant between -1 and -2 seconds

I reconnected the DAC timing cable at

PST: 2016-12-08 09:23:06.934999 PST
UTC: 2016-12-08 17:23:06.934999 UTC
GPS: 1165253003

After that, the timing started to drift at a rate of about 1 second every 2300 seconds (4.35e-4). So the conclusion is that the culprit for the timing issue is on the DAC connection side.

My previous test showed that the timing drift was somehow related to the output of the signal generator being connected to the DAC.

Some more findings follow. When the CyMAC is powered down, the timing sent to the DAC is highly distorted. It stays the same even when I power the CyMAC up again, and it gets better only after the IOP process is started. My guess is this has something to do with the DAC board initialization. In the following: first trace is the timing signal with CyMAC off; second with the CyMAC powering on, but IOP not yet started; third when the IOP process is running.

A small residual distortion around the transitions is visible. This is not present on the original signal, or even if the ADC only is connected to the timing.

To try to debug the problem, I set up a second signal generator (not locked to the first one) and used it to provide the DAC timing. In this way ADC and DAC get their timing from two different signal generators.

I still see the same small distortion on the DAC timing. More important, I noticed that the signals generated by the DAC (here a 1kHz sinusoid) are very noisy: there is a very large glitch at every clock transition. Is this a sign that tha DAC is malfunctioning? I don't recall seeing anything like that in any other case. In both screeshots, the purple trace is the DAC output (1 kHz sinusoid) and in the second screenshot the blue trace is the DAC timing. It's clear that there is a glitch every time the clock signal transitions.

I swapped the DAC with another one, but I see the same behavior in the output signal. Here's a spectrum of the DAC output, with and without output.

I find sometimes that the probe configuration can give these distorted signals. For the Tektronix probes, its best to use a 500 MHz probe instead of the BNC clip leads. The probe also should be compensated by attaching to the gold fingers square wave generator on the scope front and adjusting the capacitor in the probe with a little screwdriver until the square wave becomes perfect.

• changed the name of the test chamber real time model from CR1 to CR0. Updated all MEDM screens and scripts (autocenter.py, auto_excite.py, crime.py)
• created new real time models CR1, CR2, CR3, CR4 to be used for the new chamber system. Created MEDM screens and updated all EPICS values
   

I added to the model CR0 an additional bias path for the ESD driver:

Some funny RGC idiosyncrasy: if you have a filter bank named "SUM", you can't add a summation block: if you do you get a name conflict at compilation time. That's why I used a matrix

Updated the MEDM screen accordingly

A quick test shows that working with a bias does not improve the ability to excite the modes. The DAC saturates at +-32k, which corresponds to +-10V out of the ADC, matched to the input range of the HV amplifier. The largest excitation of high frequency modes is obtained by using white noise, no bias, and maximum amplitude.

• Changed the library Picomotor8752.py to add a third axis 'r' that will allow moving the in-vacuum retaining ring. The controller remains connected to the workstation through a serial cable
• Tested a new NewFocus 8741 controller with USB and ethernet. The USB driver works only on Windows, so I tested it by running a Windows virtual machine. I used this trick to get the IP address of the controller. Then I wrote another library Picomotor8742.py that uses TCP/IP sockets to communicate with the driver via ethernet. Tested and working. Each driver can control up to four axis, so the user can choose which QPD centering mirror to move (1/2 or 3/4) and which axis (x or y)

This morning I installed in the clean room the high voltage amplifier and the high voltage relays. Everything is cabled as planned. No way to test it yet, since there's nothing in the chamber!

I wrote an autocenter script for the four QPD in the new setup (autocenter14.py) and renamed the script for the old chamber (autocenter0.py).

Tested and working properly, with network connection to the picomotor controllers. Be aware that if the picomotor controllers are switched off, their IP address might change.

This morning Larry set up a network switch to create a local network for the power strip and the two Newport picomotor controllers. The laboratory workstation serves as gateway between the networks.

I still have to configure the power strip and the picomotor controllers to use the new static IP address.

Removed, since iit was not useful to improve the actuation authority.

I reconfigured the powerstrip and the two Newport controllers to use static IP address in the new 10.10.10.X network, using the workstation as gateway. All scripts updated and working

1. created a single interface to move the picomotors in front of QPD1 ... QPD4
   • the command qpdcenter will open an interactive python shell to control the picomotors
2. two scripts for automatic excitations are saved in /opt/rtcds/userapps/CyMAC/src/auto_excite*.py
   • they must run on the cymac. But they can be started from the control station using the commands autoexcite0 and autoexcite14
   • before starting the commands, set the parameters in the file. The two commands edit_autoexcite0 and edit_autoexcite14 will open the correct files
   • a log file of the excitation times will be saved
   • the scripts will check if there is an excitation going
3. the two commands noise0 and noise14 can be used to start awggui to inject the correct noise
4. updated the autocentering scripts, so that only one instance can run at a time.
   • launch them with the commands autocenter0 and autocenter14

2017-06-21

• 4:30 pm- Installed COMSOL, began modeling current ESD by creating parameters and the first arm of the comb

2017-06-22

• Created the geometry of the ESD by creating blocks and joining them with Unions. I then created a block to serve as the domain and added air to that region
• This plot is a combination of a Surface plot of the potential and a Streamline plot of the electric field
• I created another model of the ESD with more accurate measurements to the real thing and added the silica disc to the model
• 

2017-06-23

• I created plots of the E field and potential from my rough model of the ESD. This model has 1mm electrode arm widths and spacings, the length of each arm is 16 mm, and the resulting total size is 38mm x 20 mm x 0.1 mm. One comb has ten arms while the other has nine to match the actual ESD currently in use in the lab. 
• I set the ten arm comb to a potential of 100 V and the other to ground. I then used physics controlled mesh with an extremely fine element size to computer the simulations. With mesh sizes larger than extra fine, there was clearly non-physical error in the electric field and potential graphs that appeared as inexplicable field lines, spikes, and coarseness in the plots. 
• To create readable plots of the potential I created a Cut Plane in the center of the ESD perpendicular to both the arms and the plane of the device. The plots are attached with a milimeter length scale. I created a filled contour plot of the potential that is very clean, I tried a couple of different options for the electric field because it is harder to represent well. I created a contour plot for the norm of the electric field as well as superimposing a streamline plot of the field lines over that. Everything behaves generally as expected though I do suspect the spikes in electric field at the edges of each electrode are due to the fact that they are sharp corners and not smooth edges.

2017-06-27

• I built a new model of the ESD to determine whether or not the spikes in the electric field at the corners was affecting the results enough that it had to be accounted for in further models. To create the model, I created a 2D profile of the arm used in my original model and filleted the corners at a radius of .05 mm, since the electrode model is .1 mm thick, this made completely rounded edges. In creating this model I caught an earlier mistake in the original one, I only set one half of the surface of the electrodes to have a potential or to ground, the "bottom" was left with no charge. I fixed this mistake and then compared the two models at a potential of 1000 V. For speed of computation I ran both models with a finer mesh size and then calculated the electric field at approximately the middle of the ESD, 1mm above the fourth electrode arm. For the rounded electrodes the field had a value of 84024 V/m and for the rectangular electrodes the field had a value of 80728 V/m, which is less than a 4% difference in field magnitude. Furthermore, the field shapes appear nearly indistinguishable; I am confident from this test that I can proceed modelling the arms of the ESD as rectangles.

2017-06-29

• I created a much more accurate model of the current ESD setup from the technical drawings. My resulting ESD has dimensions of 21.3x24.3x.1mm with 1 mm spacings and 17.5 mm long electrode arms. The sample has a diameter of 75 mm and thickness of 1mm, the ESD is 1mm below the sample in the current model. I still have to compare the technical drawings to confirm that is the actual distance in the current lab setup.
• I was able to calculate the force profile on the disk from the ESD. COMSOL struggled to resolve the data with a small mesh size over the whole domain, so I created a region of extremely fine mesh around the ESD and the disk and then made the rest of the mesh size normal sized. Over the domain near the ESD my mesh size ranges from 2.5*10^-3 to .25 mm and over the rest of the domain it's automatically setup at the normal size.
• The force on a single dipole is given as , since fused silica is isotropic it's polarization is proportional to E so . The electric suscepitibility of fused silica is 1.09, I plotted the profile of the force perpendicular to the plane of the disk and exported data files of the full vector quantity of the force for use with Matlab.

2017-06-30

• I adjusted the plot parameters slightly so that it only showed the actual force profile on the sample in the direction perpendicular to the sample surface. Additionally I compared the two methods of computing the force, as  and as . The profile of the force in both instances appear equal, but they differ in magnitude by exactly a factor of 2, I plotted the force computed with the explicit polarization doubled and the force magnitudes matched exactly. I'm still not entirely sure where this factor of two could be coming from.

2017-06-30

• In order to confirm the accuracy of my model I checked some easily computable quantities between what real values and what COMSOL produced. My expected electric field magnitude between the electrodes is 10⁶ V/m and COMSOL reads out 1.015*10⁶ which is less than a 2% error. When I went to compute the electric field gradient however, I discovered that I had been calculating my derivatives wrong, I was calculating full derivatives when I needed partial derivatives. Due to some subtleties of the numerics involving curl calculations are the order of the variables, in order to calculate a partial I belive that I have to map the results of the electric field to Lagrange elements.

2017-07-05

• I sorted out my mathematical lapse in logic and computed the correct force profiles in the perpendicular direction in both disks. The issue is that now the force profiles don't match up. The fact that there is a measured force distribution for the E^2 case outside the disk is only an artifact of the numerics because it is being calculated only from the electric field data which is defined outside the sample. It can be easily removed for final plots once the force distributions are matched by either redefining the cut plane or putting a data filter specifically on the E^2 plot. The jumps in the E^2 plot suggest that the meshing is still too large, I will try to fix this first, hopefully it will help resolve the difference.

2017-07-05

• In order to improve my data I shrunk the region of the finer meshing slightly and made the mesh even smaller and then recalculated the force profiles. This time I tried sampling regions inside the disc rather than immediately at the surface. The attached graphs were sampled at the center of the disc. These two techniques vastly improved the data, now the profiles appear the same, but the magnitudes differ by a factor of 2 again. Previously this was due to an error in my calculation of the force, now I do not believe this to be the case. I will leave my work here for the purposes of my first report, it is an interesting result. I also restricted my data set to the finely meshed box which resolved the earlier data display issue. 

2017-07-06

• I compared the electric field and the polarization to make sure that those calculations made sense. Since  due to the linear dielectric, I plotted the electric field and the polarization divided by the proportionality constant and they match exactly.
• This confirms both the constant value and the polarization distribution but gets me no closer to resolving the factor of two

2017-07-06

I resolved the factor of two from Griffiths' discussion of dipoles in non-uniform electric fields. The force on a dipole in a non-uniform field is  where  is the difference in the field between the plus end and the minus end. Component wise,  where d is a unit vector. This holds for y and z, the whole thing can also be written as . Since p=qd, we can write . 

Jackson derives it differently by deriving the electrostatic energy of a dielectric from the energy of a collection of charges in free space. He then derives the change in energy of a dielectric placed in a fixed source electric field to derive that the energy density w is given by . This explicity explains the factor of two and is an interesting alternative explanation.

2017-07-12

• I am attaching the first fully functioning model of the actuator and sample. I cleared both meshes and solutions to make the file a reasonable size, but they can quickly be built/solved again. 

2017-07-14

• I have completed a rough, but functioning script that calculates the modal force profiles. The force values are still coming out incorrect (on the order of 10^14) but the script can take in my model as a .m file and return an array with a force value per mode. I am attaching both the .m file and the matlab script
• I have done very little work with the numerical integration itself, based on the 2D numerical integration code I received I just appended a z component and left it at that so when I return from Livingston I will  fix that component

2017-07-20

• I believe my MATLAB script successfully calculates the force distribution into each of the modes specified by the parameters. My previous error was caused by my neglecting the proportionality factor of . Now the force order of magnitude is on the order of 10³. I am currently unclear how to think about the units of the mode shapes from the disk_frequencies script, but I will pick it apart more carefully and try to figure that out. Then it will be a matter of converting units so that it matches with the N/m^3 from the COMSOL script and then comparing with real lab results. It seems to me that the error in force distribution should be inversely proportional to the number of modes calculated, in which case it would be useful to determine an appropriate number of modes to calculate. 

2017-07-24

• I wrote a MATLAB script that is capable of sweeping parameters, the code is attached. The next step is to create nested loops so that I can sweep multiple parameters in a single run. I also should add a function in the script to eliminate the modes that cannot be measured by the experimental setup.
• My first sweep was for the gap between electrodes and swept from 1 to 2 mm. In the plot the gap grows from steps 1 to 6 and the only obvious effect in the plot is a decrease in force from the highest mode. Intuitively it makes sense that a wider gap would decrease the force because the electric field is diminished by spreading out the electrodes.
• I would like to add a parameter for the overlap of the electrodes, but this would require substantial redesigning of the COMSOL model due to the multilevel dependency on parameters. 

2017-07-25

• I completed a short sweep of the gap between the drive and the sample, between .5 and 1 mm in .1 mm increments. It appears that a 1 mm distance is the ideal distance by approximately a factor of two. I will next sweep larger distances and see how the force profile behaves at greater distances.

2017-07-26

• I ran a sweep of the gap between the ESD and the sample, first from .5 mm to 1 mm. That sweep suggested that there is a significant jump in force across almost all of the modes at 1 mm. To confirm this I double checked the geometry and it appears that COMSOL is building everything as expected when changing the spacing parameter. Then I ran a finer sweep in .02 mm increments for the spacing between .9 and 1.1 mm. Once again it appears there is a large jump as the gap approaches 1 mm, but the behavior does not seem to be symmetric about that point, the force appears to diminish linearly as the gap increases beyond 1 mm. I will run a sweep of the ESD arm spacing along with the vertical gap to confirm that the jump occurs when the gap between the ESD and the sample is equivalent to the spacings between the ESD arms.

2017-07-26

• I resolved the major bugs in the parametric sweep scripts and ran low resolution sweeps of the gap between the ESD and sample (Gap Sweep) and the spacing between the ESD arms (ESD Arm Gap Sweep).
• The arm gap sweep largely behaved in a reasonable way with a maximum excitation at a 1.25 mm gap. However modes 14, 19, and 25 did not follow the general trends and had sharp drops and increases compared to the other modes.
• The sample gap sweep had less intuitive behavior, all of the modes followed the same general double peak trend that drops to zero when the gap is 1.5 mm. I cannot explain exactly why it is behaving that way, I will run a higher resolution sweep and examine the geometry in greater detail.

2017-07-27

• I resolved a couple more data processing bugs and calculated a sweep of the ESD-Sample gap from a distance of .5 mm to 1.5 mm. The resulting data behaves far more like I would expect from a force generated by an electric field, it seems to drop off like distance squared. This is a very strong correlation with a good intuitive explanation, and would suggest that it is prudent to place the ESD as close to the sample as possible.
• I also computed a higher resolution sweep of the gap between the arms of the ESD. It did not resolve the strange behavior at all, so I will investigate coupling into the mode pairs as a possible source.

2017-07-27

• I ran a low resolution sweep of the offset in the arms of the ESD, the space between the end of the arm and base of the opposite combs. The trends are much more subtle and are not coherent across as many of the modes. The lower frequency modes decrease slightly, while the force in the higher frequency modes increase more drastically. This is an interesting parameter, I will definitely run another sweep once I have written code that accounts for the mode pairs. Assuming the apparent trends are physically accurate, this could be a useful parameter because a greater offset gives a greater relative increase to the higher order modes while still leaving a substantial force on the lower order modes that are excited more easily anyway.

2017-08-01

• I completed an improved sweep of the gap between the ESD arms. I resolved some code issues, since it was passing the maximum value not the most extreme, smaller magnitude positive values were being included rather than the strongest force calculation.
• There are still three modes that show unique behavior relative to the others: 14, 19, and 25. Mode 14 is the (2,2), mode 19 is the (2,3) and mode 25 is (3,2).
• Plots of the mode shapes are included for reference. The black rectangle represents the region covered by the ESD.