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.
Now EPICS values are saved to frames, but they are all zero! I noticed that we always had the same problems with the cymac2 too.
So for the moment being I set up daqd to save X_NORM_IN1 and Y_NORM_IN1 at 32 Hz. In this way I can monitor the QPD centering.
I was looking at some past trend data and discovered that EPICS values were not written to the frames. I added the following two lines to /opt/rtcds/tst/x3/target/fb/master to fix this:
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:
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...
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
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.
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.
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
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.