I've made quite a few changes in the software as well as the hardware of the digital frequency counting setup.
Eric helped me test the new setup by doing an arm scan through an IR resonance by ramping the ALS offset from -3 to +3 with a ramp time of 45 seconds. The data was acquired with the window size of the moving average set to 4096 clock cycles, and a 2 Hz low pass IIR filter before the frequency readout. Attachment 1 shows a plot of the data, and a fit with a function of the form trans = a/(1+((x-b)/c)^2), where a = normalization, b = center of lorentzian, and c = linewidth (FWHM) of the peak (the fitted parameter values, along with 95% confidence bounds are also quoted on the plot). In terms of the data acquisition, comparing this dataset to one from an earlier scan Eric did (elog11111) suggests that the frequency counting setup is working reasonably well - at any rate, I think the data is a lot cleaner than before implementing the moving average and having a 20Hz lowpass IIR filter. In any case, we plan to repeat this measurement sometime next week during a nighttime locking session. It remains to calculate the arm loss from these numbers analogous to what was done earlier for the X arm.
Calculation of loss:
Fitted linewidth = 10.884 kHz +/- 11Hz (95% C.I.)
FSR of Y arm (from elog 9804) = 3.9468 MHz +/- 1.1 kHz
=> Y arm Finesse = FSR/fitted linewidth = 362.6 +/- 0.5
Total round trip loss = 2*pi/Finesse = 0.0173
It is a nice scan. I'm still thinking about the equivalence of the moving average and the FIR low pass that I have mentioned in the meeting.
I'm confused by the plot. The bottom axis says "green beat frequency".
If you scan the IR laser frequency by df, you get 2*df shift of the green beatnote. You need to have this factor of two somewhere.
If you are looking at the IR beat freq, just the label is not correct. (I believe this is the case.)
Accepting the rather-too-low finesse of 363 (nominally 450), the total round trip loss is said to be 0.0173.
If we subtract the front transmission of 1.38% (and ignoring the transmission loss from the ETM),
the round trip loss is 3500ppm. Is this compatible with the following elog?
In fact, I'm afraid that the loss number in the above elog 11111 was not correct by a factor of 10.
Then, if so, can we believe this high loss number? (Nominally we expect ~100ppm loss per round trip...)
Sorry for the confusion - I did mean Green beat frequency, and I had neglected the factor of 2 in my earlier calculations. However, the fit parameter "c" in my fit was actually the half-width at half maximum and not the full width at half maximum. After correcting for both these errors (new fit is Attachment #1, where I have now accounted for the factor of 2, and the X axis is the IR beat frequency), I don't think the numbers change too much. It could be that the frequency counter wasn't reading out the frequency correctly, but looking at a time series plot of the frequency counter readout (Attachment #2), and my earlier trials, I don't think this is the case (38 MHz is a frequency at which I don't expect much systematic error - also, the offset was stepped from -3 to 3 over 45 seconds).
The revised numbers:
Fitted linewidth = 2*c = 10.884 kHz +/- 2 Hz (95% C.I.)
I made some changes to the c1tst model running on c1iscey in order to test my algorithm for frequency counting. I followed the steps listed in elog 8909 to make, install and start the model.
I need to debug a few things and run some more diagnostics so I am leaving the model in its edited version (Eric had committed it to the svn before I made any changes).
I have been working on setting up a frequency counting module that can give us a readout of the beat frequency, divided by a factor of 2^14 using the Wenzel frequency dividers as described here. This is a summary of what I have thus far.
The algorithm, and simulink model
The basic idea is to pass the digitized signal through a Schmitt trigger (existing RCG module), which provides some noise immunity, and should in theory output a clean square wave with the same frequency as the input. The output of the Schmitt trigger module is either 0 (for input < lower threshold value) and 1 (for input greater than the high threshold value). By differencing this between successive samples, we can detect a "zero-crossing", and by measuring the time interval between successive zero crossings, we can take the reciprocal to get the frequency. The last bit of this operation (i.e. measuring the interval) is done using a piece of custom C code. Initially, I was trying to use the part "GPS" from CDS_PARTS to get the current GPS time and hence measure intervals between successive zero-crossings, but this didn't work out because the output of GPS is in seconds, and that doesn't give me the required precision to count frequency. I tried implementing some more precision timing using the clock_gettime() function, which is capable of giving nanosecond precision, but this didn't work for me. So I am now using a more crude way of measuring the interval, by using a counter variable that is incremented each time a zero-crossing is NOT detected, and then converting this to time using the FE_RATE macro (=16384). In any case, the ADC sampling rate limits the resolution of frequency counting using zero-crossing detection (more on this later). Attachment 1 shows the SIMULINK block diagram for this entire procedure.
Testing the model
I implemented all of this on c1tst, and followed the steps listed here to get the model up and running. I then used one of the DB37 breakout boards to send a signal to the ADC using the DS345 function generator. Attachment 2 shows some diagnostic plots - input signal was a 2.5Vpp (chosen to match the output from the Wenzel dividers) square wave at 2kHz:
The right column pointed me to the limitations of frequency counting using this method - even though the input frequency was constant (2kHz), the counter variable, and hence the frequency readout, was neither accurate nor precise. But this was to be expected given the limitations imposed by ADC sampling? We only get information of the state of the input signal once within each sampling interval, and hence, we cannot know if a zero crossing has occurred until the next sampling interval. Moreover, we can only count frequency in discrete steps. In attachments 3 and 4, I've plotted these discrete frequencies which can be measured - the error bars indicate the error in the frequency readout if the counter variable is 1 more or less than the "true" value - this can (and does) happen if the high and low times of the Schmitt trigger are not equal over time (see top left plot in Attachment 2, its not very obvious, but all the "low" times are not equal, and so, the interval between detected zero crossings is not equal). This becomes a problem for small values of the counter variable, i.e. at high input frequencies. I was having a look at the elogs Aidan wrote some years ago for a different digital frequency counting approach, and I guess the conclusion there was similar - for high input frequencies, the error is large.
I further did two frequency sweeps using the DS345, to see if I could recover this in the frequency readout. Attachments 5 and 6 show the results of these sweeps. For low frequencies, i.e. 100-500 Hz, the jitter in the readout is small (though this will be multiplied by a factor of 2^14), but by the time the input frequency gets up to 2kHz, the jitter in the readout is pretty bad (and gets worse for even higher frequencies.
Some refinements can be made to the algorithm, perhaps by introducing some averaging (i.e. not reading out frequency for every pair of zero crossings, but every 5) which may improve the jitter in the readout, but I would think that the current approach is not very useful above 2kHz (corresponding to ~30MHz of pre-divider frequency), because of the limitations shown in attachments 3 and 4.
I definitely think lowpassing the output is the way to go. Since this frequency readback will be used for slow control of the beatnote frequency via auxillary laser temperature, even lowpassing at tens of Hz is fine. The jitter doesn't mean its useless, though.
If we lowpass at 16Hz, we're effectively averaging over 1024 samples, bringing, for example, a +-2kHz jitter of a 6kHz signal as you post down to 2kHz/sqrt(1024) ~ 60Hz, which is 1% of the carrier. This seems ok to me.
I was going to suggest using a software PLL, but perhaps averaging gives the same result. The same ADC signal can be fed to multiple blocks with different averaging times and we can just use whichever ones seems the most useful.
I'm working on setting up a moving-average in the custom C code block that counts the zero crossings to see if this approach is able to mitigate the glitchy frequency readout due to mis-counting by one clock cycle between successive zero crossings. I'm storing an array the size of the moving average window of frequency readouts at each clock cycle, and then taking the arithmetic mean over the window. By keeping a summing variable that updates itself each clock cycle, the actual moving average process isnt very intensive in terms of computational time. The array does take up some memory, but even if I perform the moving average over 1 second with 16384 double precision numbers stored in the array, its still only 130 kB so I don't think it is a concern. Some tests I've been doing while tuning the code suggest that with a moving average over 16384 samples (i.e. 1 second), I can eliminate glitches at the 1Hz level in the frequency readout for frequencies up to 5 kHz (generated digitally using an oscillator block). Some tuning still needs to be done, and the window could possibly be shortened. I also need to take a look at the systematic errors in this revised counting scheme, preferably with an analog source, but this is overall, I think, an improvement.
On a side note, I noticed some strange behaviour while running the cds average command - even though my signal had zero fluctuations, using z avg 10 -s C1:TST-FC_FREQUENCY_OUT gave me a standard deviation of ~1 kHz. I'm not sure what the problem is here, but all the calibration data I took in earlier trials were obtained using this so it would be useful to perform the calibration again.
Earlier today, the front panels for the 1U chassis I obtained to house the Wenzel dividers + RF amplifiers arrived, which meant that finally I had everything needed to complete the assembly. Pictures of the finished arrangement attached.
Summary of the arrangement:
Once I figure out the problem with this amplifier/replace it, the box is ready to be installed.
I carried out some more tests on the digital frequency counting system today, mainly to see if the actual performance mirrors the expected systematic errors I had calculated here.
Setup and measurement details:
I used the Fluke 6061A RF signal generator to output an RF signal at various frequencies, one at a time, between 10 and 70 MHz. I split the signal (at -15 dBm) into two parts, one for the X-channel and one for the Y-channel using a mini-circuits splitter. I then looked at the input signal using testpoints I had set up within the model, to decide what thresholds to set for the Scmitt trigger. Finally, I averaged the outputs of the X and Y channels using z avg -s 10 C1:ALS-FC_X_FREQUENCY_OUT and also looked at the standard deviation as a measure of the fluctuations in the output (these averages were taken after a low-pass filter stage with two poles at 20Hz, chosen arbitrarily).
I carried out some further diagnostics and found some ways in which I could optimize the zero-crossing-counting algorithm, such that the error in the measured frequency is now entirely within the expected range (due to a +-1 clock cycle error in the counting). We can now determine frequencies up to ~60 MHz with less than 1 MHz systematic error and <10 kHz statistical error (fluctuations after the 20 Hz lowpass). This should be sufficient for slow control of the end-laser temperatures.
The conclusion from my earleir tests was that there was possibly an improvement that could be made to setting the thresholds for the Schmitt trigger stage in the model. In order to investigate this, I wanted to have a look at the 64K sampled raw input to the ADCs. Yesterday Eric helped me edit the appropriate .par file for viewing these channels for c1x03, and for an input frequency of 70MHz (after division, ~4.3 kHz square wave), the signal looked as expected (top left plot, attachment #1). This prompted me to check the counting algorithm again with the help of various test points I had setup within the model. I found that there was a tendency to under-count the number of clock-cycles between zero-crossings by more than 1 clock cycle, due to the way my code was organized. I fixed this and found that the performance improved dramatically, compared to my previous trials. With the revised counting algortihm, there was at most a +-1 clock cycle error in the counting, and the systematic error between the measured and requested RF frequencies is now completely accounted for taking this consideration into account. The origin of this residual error can be understood by looking at the top right plot in Attachment #1 - presumably because of the effects of some downsampling filter, the input signal to the Schmitt trigger isnt a clean square wave (even at 4kHz) - specifically, the time spent in the LOW and HIGH states of the Schmitt trigger can vary between successive zero crossings because of the shape of the input waveform. As a result, there can be a +-1 clock cycle error in the counting process. Attachment #2 shows this - the red and blue lines envelope the measured frequency for the whole range investigated: 10-70MHz. Attachment #3 shows the systematic error as a function of the requested frequency.
If there was some way to bypass the downsampling filter, perhaps the high-frequency performance could be improved a little.
The new ZKL-1R5 RF amplifier that Steve ordered arrived yesterday. I installed this in the frequency divider box and did a quick check using the Fluke RF signal generator and an oscilloscope to verify that both the X and Y paths were working.
I've now installed the box in the 1X2 rack where the olf "RF amplifiers for ALS and FOL" box used to sit (I swapped that out as I needed the L brackets on that chassis to mount mine, see Attachment #1 for the new layout). The power cable that used to power the old chassis was available, but the connector was of the wrong gender, so I had to switch this out. After verifying that I was getting the correct voltage (+15V), I connected it to the chassis.
I then did a quick check with the Fluke generator to make sure that all was working as expected - Eric had set up some ADC channels for me earlier today in the C1ALS model, and I copied over my frequency counting module from C1TST into C1ALS, and recompiled the model. The RF generator was set to generate a 25MHz signal at -20dBm, which I then split using an RF power splitter between the X and Y arms. I then checked the output using dataviewer - I recovered an output frequency of ~27.64 MHz with a jitter of ~0.02 MHz with a 20Hz low-pass filter in place (see Attachment #2), which looks consistent with the systematic error inherent in the zero-crossing counting algorithm and random fluctuations I had observed in my earlier trials, discussed here. But a more systematic investigation needs to be carried out in this regard. The interfacing between the hardware and software seems to be working alright though. I've left the RF generator near the 1x2 rack for now, though its powered off.
The mode cleaner unlocked quite a few times while I was working but looks stable now.
One of the main draw backs of the measurement was the polarisation was not aligned properly in the setup. So, then the next step was to identify the polarisation at different locations in the beam path and to maximise the polarisation to either S or P component.
So, we introduced HWP at the input beam path after isolator as shown in attachment #1. Also, the polarisation was tested at positions P1, P2, P3, and P4 shown in attachment #1 by placing a polarisation beam splitter at these locations and then by observing the transmitted (P component) and reflected light (S component) using power meter.
The observations at different locations are as the follows
These observations show that the P and S components are almost equal, and this is not a good polarisation arrangement. At this point, we also had to check whether the incoming beam is linearly polarised or not.
To test the same, the PBS was placed at position P1 and the P and S components were observed with power meter as the HWP is rotated.Attachment # 2 shows the results of the same, that is the variation in P and S component as the HWP is rotated.
This result clearly shows that the input beam is linearly polarised. The HWP was then adjusted such that the P component is maximum and coupled to the MZI. With this orientation of HWP, the polarisation observed at different positions P1, P2, P3, and P4 are as follows.
This shows that the polarisation is linearly polarised as well as it is oriented along the P direction (parallel to the optical table).
We have the polarisation maintaining fiber (PM 980) as the delay fiber. The polarisation of the light as it propagates through a PM fiber depends on how well the input beam is coupled to the axis (slow or fast) of the fiber. So, the next task was to couple the light to one of the axes of the fiber.
The alignment key on the fiber is a good indication of the axis of the fiber. In our case, the alignment key lines up with the slow axis of the fiber. We decided to couple the light to the fast axis of the fiber. Since the incoming beam is P polarised, the output fiber coupler was aligned such that the fast axis is parallel to optical table as possible.
A PBS was then introduced after the fiber output collimator . There is a HWP (marked as HWP2 in attachment 1) in front of the input coupler of the fiber as well. This HWP was then rotated and observed the P and S component from the PBS that is now placed after the output coupler with a power meter.The idea was , when the light is coupled to the fast axis of the fiber, we will see the maximum at the P componet at the output
Attachment # 3 shows the observation.
In this way I tried to find the orientation of the HWP2 such that the P component is maximum at the output. But I was not succeeded in this method and observed that the output was fluctuating when the fiber was disturbed. One doubt we had was whether the fiber is PM or not . Thus we checked the fiber end with fiber microscope and confirmed that it is PM fiber.
Thus, we modifed the setup as shown in attachement # 4.The photodetector (PDA55) was monitoring the S component and the output of the detector was observed on an oscilloscope. We rotated the HWP2 such that the S component is almost minimum. At the same time, we were disturbing the fiber and was observing whether the output is fluctuating. The HWP2 angle was tweaked around the minimum of S component and observed the output with disturbing the fiber. This way we found the orientation of HWP2 such that the light is coupled to the fast axis of the fiber and the output was not fluctuating while we disturb the fiber. We tested it by heating the fiber with a heat gun as well and confirmed that the output is not fluctuating and thus the light is coupled to the fast axis of the fiber.
The alignement was disturbed after the replcement of the beam splitter. We tried to get the alignment back . But we are not succeeded yet in getting good interfernce pattern. This is mainly because of poor mode matching of two beams. We will also try with the spooled fiber.
From the earlier results with homodyne measurement,the Vmax and Vmin values observed were comparable with the expected results . So in the time interval between these two points, the MZI is assumed to be in the linear region and I tried to find the frequency noise based on data available in this region.This results is not significantly different from that we got before when we took the complete time series to calculate the frequency noise. Attachment #1 shows the time domain data considered and attachment #2 shows the frequecy noise extracted from that.
As discussed, we will be trying the heterodyne method next. Initialy, we will be trying to save the data with two channel ADC with 16 kHz sampling rate. With this setup, we can get the information only upto 8 kHz.
We repeated the homodyne measurement to check whether we are measuring the actual frequency noise of the laser. The idea was to repeat the experiment when the laser is not locked and when the laser is locked to IMC.The frequency noise of the laser is expected to be reduced at higher frequency (the expected value is about 0.1 Hz/rtHz at 100 Hz ) when it is locked to IMC . In this measurement, the fiber beam splitter used is Non PM. Following are the observations
1. Time domain output_laser unlocked.pdf : Time domain output when the laser is not locked. The frequency noise is estimated from data corresponds to the linear regime. Following time intervals are considered to calculate the frequency noise (a) 104-116 s (b) 164-167 s (c) 285-289 s
2. Frequency_noise_laser_unlocked.pdf: Frequency noise when the laser is not locked. The model used has the functional form of 5x104/f as we did before. Compared to our previous results, the closeness of the experimental results to the model is less from this measurement. In both the cases, we have the uncertainty because of the fiber length fluctuation. Moreover, this measurement could have effect of polarisation fluctuation as well.
3.Time domain output_laser locked.pdf :Time domain output when the laser is locked. Following time intervals are considered to calculate the frequency noise (a) 70-73 s (b) 142-145 s (c) 266-269 s.
4. Frequency_noise_laser_locked.pdf : Frequency noise when the laser is locked
5. Frequency noise_comparison.pdf : Comparison of frequency noise in two cases. The two values are not significantly different above 10 Hz. We would expect reduction in frequency noise at higher frequency once the laser is locked to IMC. But this result may indicate that we are not really measuring the actual frequency noise of the laser.
The frequency source was fixed. The IMC LO level was adjusted.
IMC is locked => OLTF measured UGF 144kHz PM 30deg.
The trouble we had: the 29.5 MHz source had an output of 6 dBm instead of 13 dBm.
The cause of the issue: A short cable inside had its shield cut and had no connection of the return.
- The frequency source box was dismantled.
- The power supply voltages of +28 and +18 were provided from bench supplies.
- The 29.5 MHz output of 5~6 dBm was confirmed on the work bench.
- The 11 MHz OCXO out (unused) had an output of 13 dBm.
- Once the lid was opened, it was immediately found that the output cable for the 29.5 MHz source had a sharp cut of the shield (Attachment1).
- OK. This cable was replaced. The output of 13 dBm was recovered.
- But wait. Why is the decoupling capacitor on the 29.5 MHz OCXO bulging? The polarity of the electrolytic capacitor was wrong!
- OK. This capacitor was replaced. It was 100 uF 35 V but now it is 100 uF 50 V.
- I further found some cables which had flaky shields. Some of them were twisted. When the panel cable s connected, the feedthroughs were rotated. This twists internally connected cables. Solder balls were added to the connector to reinforce the cable end.
- When the box was dismantled, it was already noticed that some of the plastic screws to mount the internal copper heat sinks for ZHL-2's were broken.
They seemed to be degraded because of the silicone grease. I didn't try to replace all as it was expected to take too much time, so only the broken screws
were replaced with steel screws with shoulder washers at the both side of the box.
- After confirming the circuit diagram, the box was returned to the rack. The 29.5 MHz output of 13 dBm there was confirmed.
The schematic of the homodyne configuration is shown below.
Following are the list of components
One set of fiber is now kept along the arm of the interferometer
Fiber coupled (3 No's)
Free space ( 2 No's)
Below are revised design parameters for the Stewart platform based on ground motion measurements.
The goal is that the actuators should be able to exceed ground motion by a healthy factor (say, two decades in amplitude) across a range from about .1 Hz to 500 Hz. I would like to stitch together data from at least two seismometers, an accelerometer, and (if one is available) a microphone, but since today this week I was only able to retrieve data from one of the Guralps, I will use just that for now.
The spectra below, spanning GPS times 1010311450--1010321450, show the x, y, and z axes of one of the Guralps. Since the Guralp's sensitivity cuts off at 50 Hz or so, I assumed that the ground velocity continues to fall as f-1, but eventually flattens at acoustic frequencies. The black line shows a very coarse, visual, piecewise linear fit to these spectra. The corner frequencies are at 0.1, 0.4, 10, 100, and 500 Hz. From 0.1 to 0.4 Hz, the dependence is f-2, covering the upper edge of what I presume is the microseismic peak. From 0.4 to 10 Hz, the fit is flat at 2x10-7 m/s/sqrt(Hz). Then, the fit is f-1 up to 100 Hz. Finally, the fit remains flat out to 500 Hz.
Outside this band of interest, I chose the velocity requirement based on practical considerations. At high frequencies, the force requirement should go to zero, so the velocity requirement should go as f--2 or faster at high frequencies. At low frequencies, the displacement requirement should be finite, so the velocity requirement should go as f or faster.
The figure below shows the velocity spectrum extended to DC and infinite frequency using these considerations, and the derived acceleration and displacement requirements.
As a starting point for the design of the platform and the selection of the actuators, let's assume a payload of ~12 kg. Let's multiply this by 1.5 as a guess for the additional mass of the top platform itself, to make 18 kg. For the acceleration, let's take the maximum value at any frequency for the acceleration requirement, ~6x10-5 m/s2, which occurs at 500 Hz. From my previous investigations, I know that for the optimal Stewart platform geometry the actuator force requirement is (2+sqrt(3))/(3 sqrt(2))~0.88 of the net force requirement. Finally, let's throw in as factor of 100 so that the platform beats ground motion by a factor of 100. Altogether, the actuator force requirement, which is always of the same order of magnitude as the force requirement, is
(12)(1.5)(6x10-5)(0.88)(100) ~ 10 mN.
Next, the torque requirement. According to <http://www.iris.edu/hq/instrumentation_meeting/files/pdfs/rotation_iris_igel.pdf>, for a plane shear wave traveling in a medium with phase velocity c, the acceleration a(x, t) is related to the angular rate W'(x, t) through
a(x, t) / W'(x, t) = -2 c.
This implies that |W''(f)| = |a(f)| pi f / c,
where W''(f) is the amplitude spectral density of the angular acceleration and a(f) of the transverse linear acceleration. I assume that the medium is cement, which according to Wolfram Alpha has a shear modulus of mu = 2.2 GPa and about the density of water: rho ~ 1000 kg/m3. The shear wave speed in concrete is c = sqrt(mu / rho) ~ 1500 m/s.
The maximum of the acceleration requirement graph is, again, 6x10-5 m/s2 at 500 Hz.. According to Janeen's SolidWorks drawing, the largest principal moment of inertia of the SOS is about 0.26 kg m2. Including the same fudge factor of (1.5)(100), the net torque requirement is
(0.26) (1.5) (6x10-5) (100) pi (500) / (1500) N m ~ 2.5x10-3 N m.
The quotient of the torque and force requirements is about 0.25 m, so, using some of my previous results, the dimensions of the platform should be as follows:
radius of top plate = 0.25 m,
radius of bottom plate = 2 * 0.25 m = 0.5 m, and
plate separation in home position = sqrt(3) * 0.25 m = 0.43 m.
One last thing: perhaps the static load should be taken up directly by the piezos. If this is the case, then we might rather take the force requirement as being
(10 m/s2)(1.5)(12 kg) = 180 N.
An actuator that can exert a dynamic force of 180 N would easily meet the ground motion requirements by a huge margin. The dimensions of the platform could also be reduced. The alternative, I suppose, would be for each piezo to be mechanically in parallel with some sort of passive component to take up some of the static load.
I have been experiencing frequent crashes of DTT on pianosa in the past few weeks. This is pretty annoying to deal with when trying to characterize the interferometer loops. I attach the error log dumped to console. The error has to do with some kind of memory corruption. Recall that we aren't using a GDS version that is packaged with the SL7 lscsoft packages, we are using a pretty ancient (2.15) version that is built from source. I have been unable to build a newer version from source (though I didn't spend much time trying). pianosa is the only usable workstation at the moment, but perhaps someone can make this work on donatella / rossa for general improvement in quality of life.
Kira informed me that she was having trouble accessing past data for her PID tuning tests. Looking at the last day of data, it looks like there are frequent EPICS data dropouts, each up to a few hours. Observations (see Attachment #1 for evidence):
It is difficult to diagnose how long this has been going on for, as once you start pulling longer stretches of data on dataviewer, any "data freezes" are washed out in the extent of data plotted.
Multiple realtime processes on c1sus are suffering from frequent time outs. It eventually knocks out c1sus (process).
Obviously this has started since the fiber swap this afternoon.
gautam 10pm: there are no clues as to the origin of this problem on the c1sus frontend dmesg logs. The only clue (see Attachment #3) is that the "ADC" error bit in the CDS status word is red - but opening up the individual ADC error log MEDM screens show no errors or overflows. Not sure what to make of this. The IOP model on this machine (c1x02) reports an error in the "Timing" bit of the CDS status word, but from the previous exchange with Rolf / J Hanks, this is down to a misuse of ADC0 Ch31 which is supposed to be reserved for a DuoTone diagnostic signal, but which we use for some other signal (one of the MC suspension shadow sensors iirc). The response is also not consistent with this CDS manual - which suggests that an "ADC" error should just kill the models. There are no obvious red indicator lights in the c1sus expansion chassis either.
We had another crash of c1sus and Gautam did full power cycling of c1sus. It was a sturggle to recover all the frontends, but this solved the timing issue.
We went through full reset of c1sus, and rebooting all the other RT hosts, as well as daqd and fb1.
Gautam will soon follow up with detailed analysis, but here is a brief summary of some of our activities and findings.
Please note that there is a long BNC cable still laid out from the IOO rack area to the X end table; watch your step!
I took several measurements today using the revised PLL scheme of using the Marconi just as an LO, and actuating on the Laser PZT to keep the PLL locked (I will put up a sketch soon). On the evidence of the attached plots (spectra of PLL control signal), I guess we can conclude the following:
Attachment #2: Measured OLG of PLL for the PSL+X and PSL+Y combinations. The UGF in both cases looks to be above 100 kHz, so I didn't do any calibration for the spectra attached. The gain on the SR560 was set to 200 for all measurements.
Attachment #3: Measured spectra of PLL control signal for various diode currents, with one reading from the PSL+Y combination plotted for comparison. When we took some data last night, Eric noted that there was a factor of ~6 increase in the overall frequency spectrum level at higher currents, I will update the plots with last night's data as well shortly. I found it hardest to keep the PLL locked at a diode current of 2.00 A across all measurements.
Attachment #4: Measured spectra of PLL control signal at two different crystal temperatures. There does not seem to be any significant dependance on temperature, although I did only do the measurement at two temperatures.
Attachment #4 Attachment #1: All the data used to make these plots (plus some that have yet to be added to the plots, I will update them).
Unrelated to this work:
When I came in this afternoon, I noticed that the PMC was unlocked. The usual procedure of turning the servo gain to -10dB and playing around with the DC output adjust slider on the MEDM screen did not work. Eric toggled a few buttons on the MEDM screen after which we were able to relock the PMC using the DC output adjust slider.
[Rana / Kiwamu]
Last Friday we did several things for MC :
- aligned the incident beam to MC
- increased the locking gain by 6 dB and modified the auto-locker script accordingly
- improved the alignment of the beam on the MC_REFLPD photo diode
In the beginning of the work, we wanted to know what RF frequency components are prominent in the reflection from MC.
Since the WFS circuits are capable for two RF notches, we wanted to determine which frequencies are appropriate for those notches.
So for the purpose we tried searching for unwanted RF components in the reflection.
However during the work, we found several things that needed to be fixed, so we spent most of the time for improving the MC locking.
- Alignments of the incident beam
At the beginning, the reflection from MC was about 2.2 in C1:IOO-REFLDC and the lock of MC had been frequently unlocked.
This situation of high reflection seemed to be related to a work done by Suresh (#4880).
Rana went to the PSL table and tweaked two input steering mirrors in the zig-zag path, and finally the reflection went down to ~ 0.8 in C1:IOO-REFLDC.
This work made the lock more robust.
- Change of the locking gain
After the alignment of the incident beam, we started looking at the time series of the MC_REFLPD signal with an oscilloscope as a start point.
What we found was a significant amount of 30 kHz components. This 30 kHz oscillation was thought be a loop oscillation, and indeed it was so.
We increased the loop gain by 6 dB and then the 30 kHz components disappeared successfully.
So the nominal locking gain of MC is now 11 dB in C1:IOO-MC_REFL_GAIN. The auto locker script was also modified accordingly.
- RF components in the MCREFL signal
After those improvements mentioned above, we started looking at the spectrum of the MCREFL PD using the spectrum analyzer HP8590.
The 29.5 MHz component was the biggest components in the spectrum. Ideally this 29.5 MHz signal should be zero when MC is locked.
One possible reason for this big 29.5 MHz signal was because the lock point was off from the resonant point.
We tweaked the offset in the MC lock path using a digital offset, C1:IOO-MC-REFL_OFFSET.
We found an offset point where the 29.5MHz signal went to the minimum, but didn't go to zero.
(works to be done)
So it needs some more works to investigate the cause of nonzero 29.5 MHz signal as well as investigation of what RF components should be notched out.
A good start point would be writing a GPIB interface script such that we can get the spectra from HP8590 without any pains.
I wanted to try common/differential ALS Friday evening. I tried ALS using the LSC servo but this was not successfull.
The usual ALS servo in the ALS model works without problem. So this might be coming from the shape of the servo filter.
The ALS one has 1:1000 filter but the LSC one has 10:3000. Or is there any problem in the signal transfer between
ALS and LSC???
Slow offset -0.302V
TRX=1.18 / TRY=1.14, XARM Servo gain = 0.25 / YARM Servo gain = 0.10
- Green Xarm:
GTRX without PSL green 0.562 / with PSL green 0.652 -> improved upto 0.78 by ASX and tweaking of PZTs
Beat note found at SLOW OFFSET +15525
Set the beat note as +SLOW OFFSET gives +BEAT FREQ
- Green Yarm:
GTRY without PSL green 0.717 / with PSL green 1.340
Beat note found at SLOW OFFSET -10415
Set the beat note as +SLOW OFFSET gives -BEAT FREQ
- BEAT X -10dBm on the RF firstname.lastname@example.orgMHz / Phase tracker Qout = 2300 => Phase tracking loop gain 80 (Theoretical UGF = 2300/180*Pi*80 = 3.2kHz)
- BEAT Y -22dBm on the RF email@example.comMHz / Phase tracker Qout = 400 => Phase tracking loop gain 300 (Theoretical UGF = 2.1kHz)
Transfer function between ALSX/Y and POX/Y11I @560Hz excitation of ETMX
POX11I/ALSX = 54.7dB (~0deg)
POY11I/ALSY = 64.5dB (~180deg)
ALSX[cnt]*19230[Hz/cnt] = POX11I[cnt]/10^(54.7/20)*19230[Hz/cnt]
= 35.4 [Hz/cnt] POX11I [cnt] (Hz in green frequency)
35.4 [Hz/cnt]/(2.99792458e8/532e-9 [Hz]) * 37.8 [m] = 2.37e-12 [m/cnt] => 4.2e11 [cnt/m] (c.f. Ayaka's number in ELOG #7738 6.7e11 cnt/m)
ALSY[cnt]*19230[Hz/cnt] = POY11I[cnt]/10^(64.5/20)*19230[Hz/cnt]
= 11.5 [Hz/cnt] POX11I [cnt] (Hz in green frequency)
11.5 [Hz/cnt]/(2.99792458e8/532e-9 [Hz]) * 37.8 [m] = 7.71e-13 [m/cnt] => 1.3e12 [cnt/m] (c.f. Ayaka's number in ELOG #7738 9.5e11 cnt/m)
Elog re: Friday's work
Adjusted PZT2 so we're hitting the center of PR2.
Noticed that the beam centering target is too low by a few mm, since the OSEM set screw holes that it mounts to are lower than the center line of the optic. This meant that while we were hitting the center of PR2, the beam was half clipped by PRM's centering target. We removed the target to confirm that the beam is really centered on PR2.
Checked the beam on PR3 - it looked fine. There had been concern last week that PR2 was severely pitched forward, but this turns out to be an effect of the PRM centering target being too low - shoot the beam downward to go through the hole, beam continues downward to hit the bottom of PR2, so beam is falling of the bottom of PR3. But when we actually centered the beam on PR2, things looked fine on PR3.
Checked that the beam approximately goes through the beam splitter. Again, the targets are too low, and these 45 deg targets' holes are smaller than the 0 deg targets, so we don't see any beam going through the target, since the beam is hitting the target higher than the hole. The beam looked left/right like it was pretty close to the hole, but it was hard to tell since the angle is bad, and I'm not infinitely tall. We should check again to make sure that the beam is going through properly, and we're not clipping anywhere. I'll need help from a height-advantaged person for this.
Checked that the beam is hitting the center of the ITMY, as best we can see by using an IR card at the back of the optic. We didn't try reaching around to put a target on the front side.
We were debating whether it would be worth it to open ETMY this week, to check that the beam transmitted through the BS hits the center of ETMY.
We also took a quick look around the AS optics, but since that depends on BS/ITMX alignment, we weren't sure how to proceed. We need a plan for this part. All suspended optics were restored to their last good alignment, but we haven't tried locking MICH or anything to confirm that the alignment.
To do list: Check no clipping on ITMY table of beam between BS and ITMY, clipping on POY optics. Also, oplev is clipping on cable holder thing on the table - this needs to be moved. .....other?
I was able to measure the sensing matrix in the PRMI configuration.
The results will be posted later.
1. DataViewer did not work for the LSC channels (liek TRX)
2. Rebooted LSC. There was no instruction for the reboot on Wiki. But somehow the rebooting automatically launched the processes.
3. However, rebooting LSC stopped C1SUS processes working
4. Rebooted C1SUS. Despite the rebooting description on wiki, none of the FE processes coming up.
5. Probably, I was not enough patient to wait for the completion of dorphine_wait? Rebooted C1SUS again.
6. Yes. That was true. This time I wait for everything going up automatically. Now all of c1pemfe,c1rfmfe,c1mcsfe,c1susfe,c1x02fe are running.
FB status for c1sus processes all green.
7. burtrestored c1pemfe,c1rfmfe,c1mcsfe,c1susfe,c1x02fe with the snapshot on Jan 25 12:07, 2010.
8. All of the OSEM filters are off, and the servo switches are incorrectly on. Pushing many buttons to restore the suspensions.
9. I asked Suresh to restore half of the suspensions.
10. The suspensions were restored and damped. However, c1lsc is still freezed.
11. Rebooting c1lsc freezed the frontends on c1sus. We redid the process No. 5 to No.10
12. c1x04 seems working. c1lsc, however, is still frozen. We decided to leave C1LSC in this state.
Looking at dmesg on c1lsc, it looks like the model is starting, but then eventually times out due to a long ADC wait.
[ 114.778001] c1lsc: cycle 45 time 23368; adcWait 14; write1 0; write2 0; longest write2 0
[ 114.779001] c1lsc: ADC TIMEOUT 0 1717 53 181
I'm not sure what caused the time out, although there about 20 messages indicating a failed time stamp read from c1sus (its sending TRX information to c1lsc via the dolphin connection) before the time out.
Not seeing any other obvious error messages, I killed the dead c1lsc model by typing:
sudo rmmod c1lscfe
I then tried starting just the front end model again by going to the /opt/rtcds/caltech/c1/target/c1lsc/bin/ directory and typing:
sudo insmod c1lscfe.ko
This started up just the FE again (I didn't use the restart script because the EPICs processes were running fine since we had non-white channels). At the moment, c1lsc is now running and I see green lights and 0x0 for FB0 status on the C1LSC_GDS_TP screen.
At this point I'm not sure what caused the timeout. I'll be adding some more trouble shooting steps to the wiki though. Also, c1scx, c1scy are probably in need of restart to get them properly sync'd to the framebuilder.
I did a quick test on dataviewer and can see LSC channels such as C1:LSC-TRX_IN1, as well other channels on C1SUS such as BS sensors channels.
This is definitely a nice magic to know as the rebooting causes too much hustles.
Also, you and I should spend an hour in the afternoon to add the suspension swtches to the burt requests.
I killed the dead c1lsc model by typing:
I then tried starting just the front end model again by going to the /opt/rtcds/caltech/c1/target/c1lsc/bin/ directory and typing:
This started up just the FE again
We have no record of how long the CPUs are taking to perform a cycle's worth of computation
I added the following channels to the various slow DAQ configuration files in /opt/rtcds/caltech/c1/chans/daq/
To restart the daqd code, simply kill the running process. It should restart automatically. If it appears not to have started, check the /opt/rtcds/caltech/c1/target/fb/restart.log file and the /opt/rtcds/caltech/c1/target/fb/logs/daqd.log.xxxx files. If you made a mistake in the DAQ channels and its complaining, fix the error and then restart init on the fb machine by running "sudo /sbin/init q"
I modified the core/advLigoRTS/Makefile to once again place the startc1SYS and killc1SYS scripts in the scripts/FE/ directory.
It had been reverted in the SVN update.
c1sus, c1ioo, c1iscex and c1iscey were down. Why? I was trying to lock the arm and I found that around this time, several computers stopped working mysteriously. Who was working near the computer racks at this time???
I did an ssh into each of these machines and rebooted them sudo shutdown -r now
But then I forgot / neglected/ didn't know to bring back some of the SLOW Controls computers because I am new here and these computers are OLD. Then Rana told me to bring them back and then I ignored him to my great regret. As it turns out he is very wise indeed as the legends say.
So after awhile I did Burtgooey restore of c1susaux (one of the OLD & SLOW ones) from 03:07 this morning. This brought back the IMC pointing and it locked right away as Rana foretold.
Then, I again ignored his wise and very precious advice much to my future regret and the dismay of us all and the detriment of the scientific enterprise overall.
Later however, I was forced to return to the burtgooey / SLOW controls adventure. But what to restore? Where are these procedures? If only we had some kind of electronics record keeping system or software. Sort of like a book. Made of electronics. Where we could LOG things....
But then, again, Rana came to my rescue by pointing out this wonderful ELOG thing. Huzzah! We all danced around in happiness at this awesome discovery!!
But wait, there was more....not only do we have an ELOG. But we also have a thing called WIKI. It has been copied from the 40m and developed into a thing called Wikipedia for the public domain. Apparently a company called Google is also thinking about copying the ELOG's 'find' button.
When we went to the Wiki, we found a "Computer Restart Procedures" place which was full of all kinds of wonderous advice, but unfortunately none of it helped me in my SLOW Controls quest.
Then I went to the /cvs/cds/caltech/target/ area and started to (one by one) inspect all of the targets to see if they were alive. And then I burtgooey'd some of them (c1susaux) ?? And then I thought that I should update our 'Computer Restart Procedures' wiki page and so I am going to do so right now ??
And then I wrote this elog.
I made a tentative front panel design for the newly installed amplifier box. I used this chassis diagram to place the holes for attaching it. I just made the dimensions match the front of the chassis rather than extending out to the sides since the front panel doesn't need to screw into the rack; the chassis is mounted already with separate brackets. For the connector holes I used a caliper to measure the feedthroughs I'm planning to use and added ~.2 mm to every dimension for clearance, because the front panel designer didn't have their dimensions built in. Please let me know if I should do something else.
The input and coupled output will be SMA connectors since they are only going to the units directly above and below this one. The main output to the EOM is the larger connector with better shielded cables. I also included a hole for a power indicator LED.
EDIT: I added countersinks for 4-40 screws on all the screw clearance holes.
Johannes, if you're going to be putting a front panel order in soon, please include this one.
Also, Steve, I found a caliper in the drawer with a dead battery and the screws to access it were in bad shape- can this be fixed?
I installed the front panel today. While I had the box out I also replaced the fast decoupling capacitor witha 0.1 uF ceramic one. I made SMA cables to connect to the feedthroughs and amplifier, trying to keep the total lengths as close as possible to the cables that were there before to avoid destroying the demod phases Gautam had found. I didn't put in indicator lights in the interest of getting the mode cleaner operational again ASAP.
I turned the RF sources back on and opened the PSL shutter. MC REFL was dark on the camera; people were taking pictures of the PD face today so I assume it just needs to be realigned before the mode cleaner can be locked again.
I've attached a schematic for what's in the box, and labeled the box with a reference to this elog.
The alignment wasn't disturbed for the photo-taking - I just re-checked that the spot is indeed incident on the MC REFL PD. MC REFL appeared dark because I had placed a physical beam block in the path to avoid accidental PSL shutter opening to send a high power beam during the photo-taking. I removed this beam block, but MC wouldn't lock. I double checked the alignment onto the MC REFL PD, and verified that it was ok.
Walking over to the 1X1, I noticed that the +24V Sorensen that should be pushing 2.9A of current when our new 29.5MHz amplifier is running, was displaying 2.4A. This suggests the amplifier is not being powered. I toggled the power switch at the back and noticed no difference in either the MC locking behaviour or the current draw from the Sorensen.
To avoid driving a possibly un-powered RF amplifier, I turned off the Marconi and the 29.5MHz source. I can't debug this anymore tonight so I'm leaving things in this state so that Lydia can check that her box works fine...
I pulled out the box and found the problem: the +24 V input to the amplifier was soldered messily and shorted to ground. So I resoldered it and tested the box on the bench (drove with Marconi and checked that the gain was correct on scope). This also blew the fuse where the +24 power is distributed, so I replaced it. The box is reinstalled and the mode cleaner is locking again with the WFS turned on.
Since I tried to keep the cable lengths the same, the demod phases shouldn't have changed significantly since the amplifier was first installed. Gautam and I checked this on a scope and made sure the PDH signals were all in the I quadrature. In the I vs. Q plot, we did also see large loops presumably corresponding to higher order mode flashes.
An update on recent progress in the lab towards building and testing the new FEs.
The previously reported problem with the IOPs losing sync after a few minutes (16130) was resolved through a change in BIOS settings. However, there are many required settings and it is not trivial to get these right, so I document the procedure here for future reference.
The CDS group has a document (T1300430) listing the correct settings for each type of motherboard used in aLIGO. All of the machines received from LLO contain the oldest motherboards: the Supermicro X8DTU. Quoting from the document, the BIOS must be configured to enforce the following:
• Remove hyper-threading so the CPU doesn’t try to run stuff on the idle core, as hyperthreading simulate two cores for every physical core.
• Minimize any system interrupts from hardware, such as USB and Serial Ports, that might get through to the ‘idled’ core. This is needed on the older machines.
• Prevent the computer from reducing the clock speed on any cores to ‘save power’, etc. We need to have a constant clock speed on every ‘idled’ CPU core.
I generally followed the T1300430 instructions but found a few adjustments were necessary for diskless and deterministic operation, as noted below. The procedure for configuring the FE BIOS is as follows:
After completing the BIOS setup, I rebooted the new FEs about six times each to make sure the configuration was stable (i.e., would never hang during boot).
With the timing issue resolved, I proceeded to build basic user models for c1bhd and c1sus2 for testing purposes. Each one has a simple structure where M ADC inputs are routed through IIR filters to an M x N output matrix, which forms linear signal combinations that are routed to N DAC outputs. This is shown in Attachment 1 for the c1bhd case, where the signals from a single ADC are conditioned and routed to a single 18-bit DAC. The c1sus2 case is similar; however the Contec BO modules still needed to be added to this model.
The FEs are now running two models each: the IOP model and one user model. The assigned parameters of each model are documented below.
The user models were compiled and installed following the previously documented procedure (15979). As shown in Attachment 2, all the RTS processes are now working, with the exception of the DAQ server (for which we're still awaiting hardware). Note that these models currently exist only on the cloned copy of the /opt/rtcds disk running on the test stand. The plan is to copy these models to the main 40m disk later, once the new FEs are ready to be installed.
I installed several new AA and AI chassis in the test stand to interface with the ADC and DAC cards. This includes three 16-bit AA chassis, one 16-bit AI chassis, and one 18-bit AI chassis, as pictured in Attachment 3. All of the AA/AI chassis are powered by one of the new 15V DC power strips connected to a bench supply, which is housed underneath the computers as pictured in Attachment 4.
These chassis have not yet been tested, beyond verifying that the LEDs all illuminate to indicate that power is present.
Here is an update and status report on the new BHD front-ends (FEs).
The changes to the FE BIOS settings documented in  do seem to have solved the timing issues. The RTS models ran for one week with no more timing failures. The IOP model on c1sus2 did die due to an unrelated "Channel hopping detected" error. This was traced back to a bug in the Simulink model, where two identical CDS parts were both mapped to ADC_0 instead of ADC_0/1. I made this correction and recompiled the model following the procedure in .
For lack of a better name, I had originally set up the user model on c1sus2 as "c1sus2.mdl" This week I standardized the name to follow the three-letter subsystem convention, as four letters lead to some inconsistency in the naming of the auto-generated MEDM screens. I renamed the model c1sus2.mdl -> c1su2.mdl. The updated table of models is below.
Renaming an RTS model requires several steps to fully propagate the change, so I've documented the procedure below for future reference.
On the target FE, first stop the model to be renamed:
controls@c1sus2$ rtcds stop c1sus2
Then, navigate to the build directory and run the uninstall and cleanup scripts:
controls@c1sus2$ cd /opt/rtcds/caltech/c1/rtbuild/release
controls@c1sus2$ make uninstall-c1sus2
controls@c1sus2$ make clean-c1sus2
Unfortunately, the uninstall script does not remove every vestige of the old model, so some manual cleanup is required. First, open the file /opt/rtcds/caltech/c1/target/gds/param/testpoint.par and manually delete the three-line entry corresponding to the old model:
If this is not removed, reinstallation of the renamed model will fail because its assigned DCUID will appear to already be in use. Next, find all relics of the old model using:
and manually delete each file and subdirectory containing the "sus2" name. Finally, rename, recompile, reinstall, and relaunch the model:
I used a tool developed by Chris, mdl2adl, to auto-generate a set of temporary sitemap/model MEDM screens. This package parses each Simulink file and generates an MEDM screen whose background is an .svg image of the Simulink model. Each object in the image is overlaid with a clickable button linked to the auto-generated RTS screens. An example of the screen for the C1BHD model is shown in Attachment 1. Having these screens will make the testing much faster and less user-error prone.
I generated these screens following the instructions in Chris' README. However, I ran this script on the c1sim machine, where all the dependencies including Matlab 2021 are already set up. I simply copied the target .mdl files to the root level of the mdl2adl repo, ran the script (./mdl2adl.sh c1x06 c1x07 c1bhd c1su2), and then copied the output to /opt/rtcds/caltech/c1/medm/medm_teststand. Then I redefined the "sitemap" environment variable on the chiara clone to point to this new location, so that they can be launched in the teststand via the usual "sitemap" command.
Currently, we are missing five 18-bit DACs needed to complete the c1sus2 system (the c1bhd system is complete). Since the first shipment, we have had no luck getting additional 18-bit DACs from the sites, and I don't know when more will become available. So, this week I took an inventory of all the 16-bit DACs available at the 40m. I located four 16-bit DACs, pictured in Attachment 2. Their operational states are unknown, but none were labeled as known not to work.
The original CDS design would call for 40 more 18-bit DAC channels. Between the four 16-bit DACs there are 64 channels, so if only 3/4 of these DACs work we would have enough AO channels. However, my search turned up zero additional 16-bit DAC adapter boards. We could check if first Rolf or Todd have any spares. If not, I think it would be relatively cheap and fast to have four new adapters fabricated.
DAQ network limitations and plan
To get deeper into the signal-integrity aspect of the testing, it is going to be critical to get the secondary DAQ network running in the teststand. Of all the CDS tools (Ndscope, Diaggui, DataViewer, StripTool), only StripTool can be used without a functioning NDS server (which, in turn, requires a functioning DAQ server). StripTool connects directly to the EPICS server run by the RTS process. As such, StripTool is useful for basic DC tests of the fast channels, but it can only access the downsampled monitor channels. Ian and Anchal are going to carry out some simple DAC-to-ADC loopback tests to the furthest extent possible using StripTool (using DC signals) and will document their findings separately.
We don't yet have a working DAQ network because we are still missing one piece of critical hardware: a 10G switch compatible with the older Myricom network cards. In the older RCG version 3.x used by the 40m, the DAQ code is hardwired to interface with a Myricom 10G PCIe card. I was able to locate a spare Myricom card, pictured in Attachment 3, in the old fb machine. Since it looks like it is going to take some time to get an old 10G switch from the sites, I went ahead and ordered one this week. I have not been able to find documentation on our particular Myricom card, so it might be compatible with the latest 10G switches but I just don't know. So instead I bought exactly the same older (discontinued) model as is used in the 40m DAQ network, the Netgear GSM7352S. This way we'll also have a spare. The unit I bought is in "like-new" condition and will unfortunately take about a week to arrive.
The channels on both the C1BHD and C1SUS2 seem to be frozen: they arent updating and are holding one value. To fix this Anchal and I tried:
I wonder if Jon has any ideas.
Anchal and I ran tests on the two systems (C1-SUS2 and C1-BHD). Attached are the results and the code and data to recreate them.
We connected one DAC channel to one ADC channel and thus all of the results represent a DAC/ADC pair. We then set the offset to different values from -3000 to 3000 and recorded the measured signal. I then plotted the response curve of every DAC/ADC pair so each was tested at least once.
There are two types of plots included in the attachments
1) a summary plot found on the last pages of the pdf files. This is a quick and dirty way to see if all of the channels are working. It is NOT a replacement for the other plots. It shows all the data quickly but sacrifices precision.
2) In an in-depth look at an ADC/DAC pair. Here I show the measured value for a defined DC offset. The Gain of the system should be 0.5 (put in an offset of 100 and measure 50). I included a line to show where this should be. I also plotted the difference between the 0.5 gain line and the measured data.
As seen in the provided plots the channels get saturated after about the -2000 to 2000 mark, which is why the difference graph is only concentrated on -2000 to 2000 range.
Summary: all the channels look to be working they all report very little deviation off of the theoretical gain.
Note: ADC channel 31 is the timing signal so it is the only channel that is wildly off. It is not a measurement channel and we just measured it by mistake.