Cleaned the chamber in the washing machine at 40m and started 48 baking at 120 C

Some progress on the cleam room: bar fixed to the wall, some more structure built, filters in place. We had to (literally) work around a corner of the low ceiling that we haven't noticed before. More contruction will follow tomorrow. We also had to order some additional parts (more extrusions, brackets, screws, etc...) 

The clean room frame is built and secured to the floor and wall. Panels are being installed on the ceiling and back. Also, the optical table has been leveled.

Ceiling, back and side panels are installed. The air filters have been cabled and connected to the power supply.

Samples #433 (annealed and cleaned) and #438 (as received from Mark Optics) are now with GariLynn for deep cleaning.

Sample #438 was broken during annealing.

Mon May 13 18:37:37 2019

Entered CRIME lab to borrow 4x hair nets and face masks. Can you please advise on what I should order for clean lab equipment? There are more options on techmart than I anticipated. We're in the process of increasing the cleanliness of the SiQ experiment.

Aaron,

There is a buy list of approved clean room supplies posted here https://dcc.ligo.org/LIGO-E1300399. This list is used by designated people to keep clean rooms supplies stock at each site including LIGO labs in Downs, 40m and the CRIME lab. Not sure what lab you are working in and what regulations you have there. Typically we study the list of the approved supplies, figure out what budget can be used for supplies for a particular experiment. Depending on what your project is, you may be able to just take what you need from the existing LIGO stock (I believe there is one for Downs and one for Bridge and 40m) or work with Liz, Bob or Chub on ordering it for your via approved channels.

For the optical levers we are going to use the same QPD that are used in aLIGO optical levers (see T1600085 and D1100290): Hamamatsu S5981

Based on the aLIGO design, I put together a design fof the QPD boards, see the first attached PDF file. Some comments:

• I'm using a quad opamp to implement the transimpendance and a doubel stage of whitening for the readout of each quadrant. I haven't decided yet which is the right whitening
• The bias to the QPD is just coming from the +15V with a capacitor to ground, as in the aLIGO setup. However, I allowed the possibility of supplying a lower noise bias if needed, by removing R0 and connecting an external circuit
• There is no sum or difference computation, each quadrant is sent directly to the ADC with a differential driver (DRV135)
• Each board hosts one QPD, and it is interfaced with a 14 pin header (we're going to use twisted cables for the signals)

The stable power supply will be provided by an additional board, which will also interface 8 QPD boards to the ADC connector, see the second attached PDF. The ADC signal grounds can be connected directly to the power supply ground, left floating, or connected with a RC filter, depending on what we find to be the best solution.

Total cost estimated for PCB manufacturing and components, including the QPDs is less than 3k$, for a total of 12 boards (we need 8, plus some spares)

Koji, Rich, and I recently came up with a new QPD design which is better for general lab use than the aLIGO ones (which have a high-noise preamp copied from iLIGO). 

https://dcc.ligo.org/LIGO-D1500467

This page has the mechanical drawing only, but perhaps Rich can tell us if he's ready to make the first version for you or not. I think you can get by with the old design, but this new one should be lower noise for low light levels.

After a very useful discussion with Rich this morning, I think the circuit based on aLIGO optical levers design should be good for our applications.

It uses a LT1125 as input stage, which has

• (maximum) current noise of 1e-12 A/rHz @ 100 Hz and 0.4e-12 A/rHz @ 1 kHz
• (maximum) voltage noise of 4e-9 V/rHz @ >100 Hz

We expect to send about 5 mW into the disk, getting back a 4% reflection, which would correspond to 200 uW on the QPD. Let's say we lose half of this power in reflections through viewports and such, so we have a total of 100 uW on the QPD, or 25 uW on each quadrant. From the QPD datasheet the repsonse is about 0.4 A/W, so we have a photocurrent of 10 uA. The corresponding shot noise limit is about 1.8e-12 A/rHz.

Using a transimpendace of 200k, the noise at the output of the transimpendance is

• shot noise = 3.6e-7 V/rHz
• voltage noise = 4e-9 V/rHz
• current noise = 2e-7 V/rHz @ 100 Hz, 0.8e-7 V/rHz @ 1 kHz

So in the worst case the current noise will be about half of the shot noise. This seems good enough.

The circuit design sent out for fabrication is available in the DCC: D1600196

A preliminary design of the ESD board is available on the DCC: D1600214

The PCBs for the QPD circuit and ADC interface are here and look ok. All electronics components are also here (except for the ADC connector which should be ordered separately from Mouser, after confirming that the ADC we're going to use have the same cable as the one we use in the Crackling Noise experiment). The QPD will be shipped on 06/17.

Instructions on how to setup a workstation are available here:

https://nodus.ligo.caltech.edu:8081/Cryo_Lab/1135

I'll copy them here and integrate once I got the C.Ri.Me. workstation up and running

** libmotif4 >> libxm4 : sudo apt-get install libxm4

** all .sh files in etc must be modified to point to the correct version of the downloaded software

** add the following line to the end of the ligoapps-userv-end.sh file to get medm and striptool working

PATH="/ligo/apps/ubuntu12/epics-3.14.12.3_long/extensions/bin/linux-x86_64:$PATH"

** to fix diaggui problem, create a symbolic link in /usr/lib/x86_64-linux-gnu/

sudo ln -s libtiff.so.5 libtiff.so.4

Between yesterday and today I populated one QPD board (based on D1600196), and started testing it. The transimpedance stages seems to work fine (they show about 5-6 V in ambient light). However the whitening stages show a large ~100 kHz oscillation. While trying to fix it I probably burnt one of the output drivers.

I'll continue the investigations and debugging on Monday.

Transimpendance and whitening are working properly. I can't get useful signal out of the differential stages yet. I replaced the channel 1 DRV134 that was burnt (very hot when powered on). But the new one got hot too after powring on, so there might be something else wrong there. I'm also wondering if it's ok to use an oscilloscope to look at the differential stage output. The scope will ground one of the two outputs: according to the DRV134 datasheet this should be ok, but I'll check better later on.

Today I gave up trying to fix the first board I populated, and built a second one. The good news is that it's working as expected.

With 27.5 uW incident on each quadrant, I measure about 4.5 V, which is in line with the transimpedance of 200k, a responsivity of about 0.4 A/W and ad additional gain of two coming from the differential driver.

I also measured the noise with a SR785 (it wasn't connected to a GPIB interface and I couldn't find any, so all I have are the following numbers and the attached screenshots). 

At low frequency we are dominated by 60 Hz harmonics (probably coming from the laser). At high frequency there are some large peaks of unknown origin. I can't acquire digitally the signals to compute the difference, so I don't know if the noise we see is, for example, laser intensity noise. As soon as the cymac is up and running, I'll run some more tests.

I got two new ADC and DAC boards from Rolf, with the correct PCIe interface. I installed them into the cymac and checked that the system could boot. The cymac is now sitting in the rack. As requested by Jamie I installed Debian 8.5

I turned out that all the noise I was seeing in the QPD spectrum was due to ambient light. I covered the QPD with a box and switched off all the light. As shown in the following plot the noise is lower.

Considering that in the final setup we'll have a beam spot radius of 0.5mm, the sensitivity to beam motion on the QPD will be 23e6 V/m. The following plot shows the resulting beam motion sensitivity, if limited by electroninc noise:

It's at a level of 6e-15 m/rHz at all frequencies above 120 Hz.

To mitigate the issue of ambient light pulluting the QPD signal, I mounted the prototype into a custum built box. This helps a lot. My plan is to add a short piece of black pipe in the front, to further shield from incident light.

The new box also provides a clean way to mount the QPD.

In the last days Jamie installed the patched kernel to run the real time system (RTS) on the new CyMAC. Today (with Jamie's remote advices) I managed to get a IOP (input output process) model compiled and running. There is still no timing input (to be fixed at the beginning of the netx week, I'm presently missing a connector which is on order).

Running the x1iop model gives:

controls@cymac3:/opt/rtcds/tst/x1/scripts$ ./startx1iop 

x1iopepics: no process found

Number of ADC cards on bus = 1

Number of DAC16 cards on bus = 1

Number of DAC18 cards on bus = 0

Specified filename iocX1.log does not exist.

x1iopepics X1 IOC Server started

controls@cymac3:/opt/rtcds/tst/x1/scripts$ awg_server Version $Id: awg_server.c 2917 2012-05-22 22:33:39Z alexander.ivanov@LIGO.ORG $

channel_client Version $Id: gdschannel.c 4170 2016-04-05 21:24:46Z jonathan.hanks@LIGO.ORG $

testpoint_server Version $Id: testpoint_server.c 3303 2013-03-05 23:33:45Z alexander.ivanov@LIGO.ORG $

/opt/rtcds/tst/x1/target/gds/bin/awgtpman -s x1iop -4 -l /opt/rtcds/tst/x1/target/gds/awgtpman_logs/x1iop.log started on host cymac3 hostid ffffffffd783d97b 

awgtpman Version $Id: awgtpman.c 4170 2016-04-05 21:24:46Z jonathan.hanks@LIGO.ORG $

I copy here parts of an email from Jamie with instructions on how to run the RTS on the cymac:

I had to change the site/ifo to be "caltech/x3" to avoid EPICS
collisions with other cymacs.  You'll need to update your models to
reflect this change (change names, site/ifo parameters in the model,
etc.).  So for instance, change x1iop -> x3iop, and update the params
block inside.

daqd is installed and running, although I haven't really stress tested
it yet (no models/channels/etc).  It's running under systemd, which is
the Debian service management system.  You can control daqd with the
following commands:

# systemctl restart daqd
# systemctl stop daqd
# systemctl start daqd
# systemctl status daqd
# journalctl --unit=daqd

controls@cymac3:~ 0$ systemctl status daqd
● daqd.service - Advanced LIGO RTS daqd service
  Loaded: loaded (/etc/systemd/system/daqd.service; enabled)
  Active: active (running) since Sat 2016-07-09 11:22:38 PDT; 23h ago
Main PID: 20827 (daqd-standiop)
  CGroup: /system.slice/daqd.service
          └─20827 /usr/bin/daqd-standiop -c /etc/advligorts/daqdrc
controls@cymac3:~ 0$ sudo journalctl --unit=daqd
...

Remember to restart daqd ("systemctl restart daqd") after you add/change
models.

I've gotten all the RCG components working, but not without some small
kinks.  The RCG currently expects a specific EPICS install, different
than the system install we're using right now.  I've hacked a way to
make this work seemlessly for model builds, but it requires sourcing the
following file before *starting* models:

/opt/rtapps/epics/etc/epics-user-env.sh

So in the mean time, you can start/stop models via the following:

$ . /opt/rtapps/epics/etc/epics-user-env.sh
$ /opt/rtcds/caltech/x3/scripts/startx1iop
 

This afternoon I completed the assembly of the electronics boards to interface the ADC and DAC. The ADC is interfaced with a new custom board, which accepts up to eight QPD inputs, the syncronization signal, and it's connected to the ADC:

For the DAC I used one spare board from the Crackle experiment. However, that board had a wrong pinout for the DAC side connector, so I had to implemented again the same hack I did for the crackling noise experiment. 

All boards are connected to the ADC and DACs, and to the syncronization signal generated with a SR DS345. No boxes for the moment being, I'll figure out a better organization of the boards in the future if needed. I still haven't tested if the real time system is able to communicate properly with the new interfaces.

We played around a bit with the cymac, in efforts to make things better.

• We disabled some more fancy-sounding options in the machine's BIOS
• I created safe.snap files for the x3iop and x3tst models 
  • x3iop's was created by booting the model while mashing the EPICS command to set the burt restore bit, and then saving the EPICS database to file via the SDF screen
  • x3tst's was created by copying an existing .snap file 
• I gave the controls user ownership of /frames via sudo chown controls:controls /frames
• I then created the following folders (which the daqd log was complaining about not finding_
  • /frames/full
  • /frames/trend/minute
  • /frames/trend/minute_raw
  • /frames/trend/second
• I also created the folder /opt/rtcds/tst/x3/target/fb, since that is listed in the daqd config as the nds job dir. (However nds does not seem to be running. Is it needed? I couldn't compile it in the rtbuild directory)

As I see it, the main problems that persist are:

• daqd crashes over and over again every few seconds
  • The logs seem to be complaining about EPICS server problems. Is the related to whatever situation made the epics-env script neccessary?
• The IOP seems to be taking too much time: 8-9 usec
  • This is especially problematic as Gabriele actually wants to run the IOP at an even faster rate than the current 64k, which isn't possible with the current timing

The laboratory workstation is coatings.ligo.caltech.edu

The RTS is cymac3.ligo.caltech.edu

I set up a ssh-mount of the /opt/rtcds/userapps folder in the workstation. I also created shared ssh keys for the controls user, so we can ssh into the cymac3 without password

Using the already installed high voltage feedthrough, I cabled one of the electrostatic actuators (1mm gap between electrodes) and installed it into the chamber. One of the electrodes is connected to the feedthrough cenral pin, the other is grounded on the bottom of the chamber.

The electrostatic actuator is mounted at about 1 mm above the disk, see pictures.

As a preliminary test, I checked that switching the HV amplifier on and off with about 1.5kV produces a visible motion (~2-3 mm) of the optical lever beam. So the actuator is working.

The QPD quadrants are wired accoridng to the following convention

[EricQ, Gabriele]

The real time system seems to be working properly, except for the excitations: we can't activate any excitation using awggui or diaggui

Eric rebuilt the workstation from scratch installing Debian 8.5. All CDS software seem to be working. We setup a ssh-key for ssh'ing into cymac3 and configured the automatic mount of the remote /opt/rtcds.

The glitches I saw in the data happens roughly every second, even though not exactly on the second. They are suddend jumps on the signal values over one sample, so of clear digital origin

Not so sure anymore...

• those glitches do not happen at regular times
• I tried to send a sinusoid into another ADC channel, and I couldn't see any jump
• using DTT and zooming into the jumps, they don't seem a clean one-sample jump anymore... There might be a bit of ringing before and/or after the jump
• The jumps have different sizes and directions, and they seems to happen at the same time in all four quadrants, but not in the same direction or with the same amplitude

I was suspecting dust crossing the beam, so I build a very rough enclosure, that should help with dust. I don't think I saw any change in the glitches. 

Also:

• glitches are there even with the HeNe off, with ambient light only. So it's not the laser.
• I tried sending a sinusoid into one of the same ADC channels used to acquire the QPD signals. I couldn't see any glitch

So one might conclude that the glictches are produced by the analog QPD electronics. However, I plugged in a scope and I couldn't see any in the analog signal. But I checked only before the DRV135 stages. I'll need some sort of breakout board to test the output of the DRV135.

So here's the final proof that the glitches I see are digital:

• There is a positive jump (of random size) every second, every time 0.45s after the beginning of the second. There is a negative jump at a less constant time, but between 0.65s and 0.8s after the beginning of each second
• I moved my whole setup to the crackle lab. This included: HeNe laser with power supply, QPD with cable, interface board and power supply. I don't see any glitch there

I swapped the ADC board with a second one in the new cymac, but no change: glitches are still there.

[Rolf, Ben, Rich, Gabriele]

Rolf couldn't find any good explanation on the software side for the signals jumps. He investigated a bit the reason why IOP takes a long execution time, without success. It's still mysterious why it ran with low time for a while.

One effect of Rolf activity is that now the signal jumps happen at ~0.8 seconds (after the start of each second) instead that ~0.45. This is suspiciously pointing to a software issue...

Ben and I spent a few hours trying to better understand the origin of the glitches. Finally, we plugged in a function generator to the four ADC channels, and we could find the glitches again, at the expected time. So we could rule out completely that it's a problem of the QPD analog electronics.

Some more ivnestigations:

• swapped the SR DS345 with an Agilent 33210A for the timing signal. No change: jumps are still there
• rebooted and powered off the cymac many time, this never changed the glitches or the position in time
• swapped the ADC interface board (D1600196) with a new one similar to that of the crackle lab (D1500402): no change, jumps are still there
• switched off the roughin pump to reduce ambient acoustic noise. Not surprisingly, no change, still jumps
• according to the motherboad manual, PCIe slots 4 and 6 are PCI-EX16, while the other are PCI-EX8. I moved the ADC and DAC to those those slots. Guess what? No change, still jumps

On a bright side, Rolf recompiled the awgman software, and now excitation channels are working.

Here are two more tests I did this morning

• removed the DAC card from the cymac and the models, and restarted everything: signal jumps are still there
• move the cymac2 from the crackling noise lab to the CRIME lab, ans set it up with all the same hardware I was using with the cymac3: there are no jumps, signals look perfect (see plots at the end)

So in conclusion: the problem is in the cymac3 computer, either software or hardware. I tend to excluse an I/O hardware problem, since I used two different ADCs and removed the DAC, without improving the situation.

I measured the noise sources limiting the QPD sensitivity. Unfortunately, I had to do some MATLAB tricks to get rid of the glitches: basically I load the data directly from the raw frames (NDS access to data is not working yet) and remove all jumps in the signals that happen in one single sample and are larger than a manually tuned threshold. This is not perfect, but it's enough to give us a rough idea of the spectrum of the QPD signal. The following plot shows the QPD_X signal (in units of disk motion, radians) in a few situations:

• Blue: normal (laser on, room lights on)
• Orange: laser on, room lights off (including the vacuum gauge)
• Yellow: laser and room light off
• Purple: same as above, but I switched off the PC monitors too
• Green: QPD electronics off (this is the ADC noise)

The total power on the QPD is 30 uW, which correspond to a shot noise limited sensitivity of 4.3e-12 W/rHz. Considering that the signal is the quadrant asymmetry normalized by the total power, the shot noise limited sensitivity is sqrt(2) * SN / Power which once calibrated corresponds to 1.1e-10 rad/rHz.

The following plot shows that shot noise is the dominant source, followed closely by the electronics dark noise. The total agrees perfectly with the measured background noise above 2 kHz. Below that we have some leakage due to the large turbopump peak: this is due to FFT limitations but mostly to unsuppressed glitches.

From the QPD datasheet (Hamamatsu S5981) I learn that the noise equivalent power should be of the order of 2e-14 W/rHz at the sensitivity peak, so probably a factor of two or so worse at the HeNe frequency. It's still much lower than the measured dark noise. 

This sensitivity is already pretty good, but we can improve it by increasing the power on the diode. Indeed, 30 uW corresponds to about 2.7 V after the transimpedance, so we could increase the power by a factor 4 and win a factor 2 in the shot noise to dark noise ratio. Probably not worth it, since it will give us only a 30% gain in high frequency noise.

Just to confirm that my noise estimates make sense, here's a plot of the not-normalized QPD signal that gives the X motion (sum and difference of all four quadrants):

This is the signal after compensating for the whitening filter. If I remove this compensation, the following plot gives the noises in terms of the voltage directly in input to the ADC (or in output of the analog board):

So the total "dark" electronic noise is about 13 uV/rHz.

I did a roughly estimate of the sources of electronic noise:

• QPD dark current noise, from datasheet, at the peak sensitivity is equivalent to 2e-14 W/rHz, or 2 nV/rHz at the output of the TI stage
• First stage: Johnson-Nyquist noise of the TI resistor: 58 nV/rHz
• First stage: output voltage noise of the LT1124: 3 nV/rHz
• First stage: input curent noise of the LT1124, converted to the output: 60 nV/rHz

So the total noise at the outoput of the first stage is about 84 nV/rHz. The second stage adds a gain of 30 at high frequency, and negligible noise. So at the output of the whitening we have 2.5 uV/rHz. The DRV135 adds another gain of 2 and a neglegible output noise. 

So the total electronic noise at the output of each quadrant is 5 uV/rHz. Since we are combining four of them, the total expected electronic noise is 10 uV/rHz, which is not too far from the measured value. 

We are basically dominated equally by the Johnson-Nyquist noise of the TI resistor and by the input current noise of the LT1124. No gain to be obtained by changing the whitening.

The old channel X3:CR1-PRESSURE_LOGTORR does not exist anymore. The new channel is now directly in torr and it is called X3:CR1-PRESSURE_TORR.

I had to write a C function to compute the 10^x operation, since it is not included in the RCG routines. Also it's not possible to include library functions, so I had to write an ad-hoc function, which first compute the integer part of the exponent, and then approximate the fractional part with linear interpolation and a look-up table. Code is in /opt/rtcds/userapps/release/models/pow10.c

This plot shows a signal which is generated purely digitally inside a code that I was testing.

Jumps are present even in this case.

Another addition: I was testing some simple code I was writing. Forget about OUT1 and OUT2, but OUT3 and OUT4 should be simple counters. Here's what I get by running the code on cymac3:

Since it didn't make any sense, I ran the same code on cymac2. Here's the (correct) result:

So there's something wrong even when all-digital signals are generated.

Installed the ADC and DAC boards into a proper box. Also, swapped the temporary DAC board (with cale hack) with the final one. Schematics and PCB are in the DCC: D1600196 and D1600301

The box is sitting on top of the cymac computer, on the back, since I don't have any long cable to connect the ADC. 

Today I populated four more QPD boards. All components are installed, except for the QPD themselves.

I finished populating the new four QPD boards, and fixed the first one I populated weeks ago. I tested all five new boards: the output of the transimpendance respond correctly to the ambient light; the output of the whitening also respond correctly and has increased high frequency noise; the differential driver stages are all functional and balanced.

In summary, we have six QPD circuits ready: serial 02 is installed into the box and it has been used for the previous tests. Serial number 01, 03, 04, 05, 06 are not yet into a box, but fully functional. Boxes are ready.

For testing purposed, I also built another ADC interface board: it's complete with the exception of the connector that goes to the ADC.

So I’m sending a 1.123 Hz sinusoid into the ADC, and generating 3.123 Hz sines and cosines in the model. Frequencies are reasonably incommensurable with one second.

Yesterday I cloned the cymac2 disk and installed it into the cymac3.

Jamie tweaked a few things (I can't really give more details) and now cymac3 is up an running with the same software as cymac2.

I compiled and installed the CR1 model, to readout the QPD. No more jumps in the signals!

To be able to access testpoints and have AWG working I had to follow the hack explained here: Cryo_Lab/781

I tested the following features:

• the model is running and signals look good
• I can access test points and DQ channels in real time with both dataviewer and DTT
• I can access old data with dataviewer, using NDS
• awggui is working and I can inject noise, that is properly going to the DAC channel (I check with a scope in the analog world)
• I can upload filters using foton

The plot below shows the spectrum of the QPD. For the moment being I'm just sending a straight HeNe beam into the QPD, since the test setup with the disk is no more available. Units are arbitrary

Compiled and installed an updated real time model. It acquires the four QPD segments, compute sum and differences, and normalize. I also added three experimental peak tracking components, that will be used to track in real time the amplitude and frequency of the disk modes.

I also created a summary medm screen that can be used to control all the QPD readout. It can be opened from any terminal with the command 'cr1'. I haven't added the peak tracking parts yet.

The X_NORM_OUT and Y_NORM_OUT signals are high passed at 500 Hz, to get rid of low frequency stuff that can affect the peak tracking.

I cross checked the calibration of the sum channel with a  power meter. Now all quadnant signals X3:Q?_OUT and the sum signal X3:CR1-SUM_OUT are correctly calibrated in microwatts.

Installed two new 2TB disks into the cymac3. Also, the main disk has a 1TB partition with the operating system, so I created a new 1TB partition. I created a logic volume that spans the three partitions, for a total of about 5TB. This partition is mounted in /mnt/data and linked to the /frames folder. Frames are written to this new logic volume.

Today I wrote some auxiliary functions that will be useful for the measurement system:

• noise.py: set of functions to generate band-limited noise (using inverse FFT) and multiple band noise. Using the awg python interface I can also start and stop the noise injection. Some examples of the result:
  
   
• readdata.py: read data online, compute a spectrum, and additionally a function that find peaks in a whitened spectrum. All peaks above a minimum SNR are returned: the central frequency is computed by an average of the bin SNR:
  
   
• diskmodel.py: reads a list of mode frequencies from txt files. In each file, the first row is the disk diameter in mm, the second is the disk thickness in mm, all other rows are the modes are computed by COMSOL. I also produced a whole bunch of such files, with diameters within 75 +- 0.1 mm and thickness within 1 +- 0.1 mm

Some progress on writing the user interface:

Now the user can open a file that defines the nominal mode frequencies (from COMSOL simulations) and select which modes to search for:

The plan is that the automation will then inject band limited noise around each nominal frequency, to excite the mode, and then find the exact frequency. The user can set some additional parameters like

• the duration of the excitation (I plan to use this as a maximum: if the mode rings up with large enough SNR after a shorter time, the injection will stop earlier)
• the amplitude of the excitation (units to be determined)
• the bandwitdh, otr in other words how many Hz the noise will be spread around the nominla frequency to search for the mode.
• the minimum SNR to detect a peak (here the automation will get a spectrum before any excitation, to be used as the baseline to whiten all further spectra)

The cymac3 internal clock was off by about 10 seconds. When I tried to start the NTP service, I found out that the cymac3 couldn't reach any external server. It turned out that the gateway in /etc/network/interfaces was set to the wrong address. I fixed it and rebooted. Now NTP is working and the time is correct.

This fixed a small issue with diaggui, which always complained about a data receiving error when starting a measurement (although after the complian the measurement could continue)

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:

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

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.

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