Attachment #1 shows the ALS noise measurement today. Main differences from the spectrum posted last week is that

1. I have tried to align the input polarization axis (p-pol) to the fast axis of the fiber, and believe I have done it to ~75dB.
2. Steve and I installed some protective tubing for the vertical lengths of fiber going into the beat mouth.
3. Today, I decided to measure the noise at the differential rear panel outputs rather than the single-ended front panel outputs. For the test, I used a DB25 breakout board and some pomona mini-grabber to BNC clips to connect to the SR785.

For comparison, I have plotted alongside today's measurement (left column) the measurement from last week (right column).

Conclusions:

• The clear daylight between red and green traces in the left column give me confidence that I am measuring real laser frequency noise in the red trace. It even has the right shape considering the bandwidth of the EX PDH servo.
• The installation of protective tubing doesn't seem to have reduced the heights of any of the peaks in the red traces. I hypothesize that some of these are acoustic coupling to the fiber. But if so, either the way we installed the protective tubing doesn't help a whole lot, or the location of the coupling is elsewhere.
• Judging by the control room analyzer, there doesn't seem to be as large drifts in the RF beat amplitude tonight () as I saw the last couple of times I was testing the BeatMouth®. For a more quantitative study, I'm gonna make a voltage divider so that the ~10V output I get at the rear panel power monitor output (for a LO level of ~0dBm, which is what I have) can be routed to some ADC channel. I'm thinking I'll use the Y ALS channels which are currently open while ALS is under work.
• Still have to make preamp prototype daughter board with the right whitening shape... This test suggests to me that I should also make the output differential sending...

I thought a little bit about the design of the preamp we want for the demodulated ALS signals today. The requirements are:

1. DC gain that doesn't cause ADC saturation.
2. Audio frequency gain that allows the measured beat signal spectrum to be at least 20dB the ADC noise level.
3. Electronics noise such that the measured beat signal spectrum is at least 20dB above the input-referred noise of this amplifier.
4. Low pass filtering at the input to the differential receiving stages, such that the 2f product from the demodulation doesn't drive the AD829 crazy. For now, I've preserved the second-order inductor based LPF from the original board, but if this proves challenging to get working, we can always just go for a first-order RC LPF. One challenge may be to find a 2.2uH inductor that is compatible with prototype PCB boards...
5. Differential sending, since this seems to be definitively the lower noise option compared to the single-ended output (see yesterday's measurement). The plan is to use an aLIGO AA board that has differential receiving and sending, and then connect directly to the differential receiving ADC.

Attachment #3 shows a design I think will work (for now it's a whiteboard sketch, I''ll make this a computer graphic tomorrow). I have basically retained the differential sending and receiving capabilities of the existing Audio I/F amplifier, but have incorporated some whitening gain with a pole at ~150Hz and zero at ~15Hz. I've preserved the DC gain of 10, which seems to have worked well in my tests in the last week or so. Attachments #1 and #2 show the liso modelled characteristics. Liso does not support input-referred noise measurements for differential voltage inputs, so I had to calculate that curve manually - I suspect there is some subtlety I am missing, as if I plot the input referred noise out to higher frequencies, it blows up quite dramatically.

Next step is to actually make a prototype of this. I am wondering if we need a second stage of whitening, as in the current config, we only get 20dB gain at 150Hz relative to DC. Yesterday's beat spectrum measurement shows that we can expect the frequency noise of the ALS signal at ~100Hz to be at the level of ~1uV/rtHz, but this is is around the ADC noise level? If so, 20dB of whitening gain may be sufficient?

*Side note: I was wondering why we need the differential receiving stage, followed by a difference amplifier, and then a differential sending stage. After discussing with Koji, we think this is to suppress any common-mode noise from the mixer outputs.

Summary of my tests of the demod boards, post gain modification:

• DC tests (supply voltage, DC offsets at I and Q outputs, power LEDs etc)
• RF tests
  • Back panel RF and LO power level monitor calibration
  • Coupling factor from RFinput to RFmon channel
  • Conversion loss as a function of demodulated beat frequency
  • Orthogonality and gain balance test
  • Linearity of unit as a function of RF input level
  • Electronics oise in the 1-10kHz band at the IF outputs.

Everything looks within the typical performance specs outlined in E1100114, except that the measured noise levels don't quite line up with the LISO model predictions. The measurement was made with the scheme shown in Attachment #1. I didn't do a point-by-point debugging of this on the board. I have uploaded the data + notebook summarizing my characterization to the DCC page for this part. I recommend looking at the HTML version for the plots.

*I'd put up the wrong attachment, corrected it now...

gautam 9 Feb 2018 9pm: Adding a useful quote here from the LISO manual (pg28). I think if I add the Johnson noise from the output impedance of the mixer (assumed as 50ohms, I get better agreement between the measured and observed noises (although the variance between the 4 channels is still puzzling). The other possible explanation is small variations in the voltage noise at the various mixer output ports. Could we also be seeing the cyclostationary shot noise difference between the I and Q channels? 

In any case, I am happy with this level of agreement, so I am going to stick this 1U chassis back in its rack with the primary aim of measuring a spectrum of the beatnote, so that I have some idea of what kind of whitening filter shape is useful for the ALS signals. May need to pull it out again for actually implementing the daughter board idea though... I have updated DCC page with LISO source, and also the updated python notebooks.

I effected the change to the Audio IF preamp stage on channels 3 and 4 (Xarm and Yarm respectively) using the resistors Steve ordered (the ones Rana ordered don't have any labeling on them, and I couldn't tell the 50ohm and 500ohm ones apart except by looking at the label on the ziplock bag they came in, so I decided against using them). I've started a DCC page to collect photos, characterization data, and marked up schematic etc for this part. Characterization is ongoing, more to follow soon. Note that for the photo-taking, I disconnected all the on-board SMA connectors so that the cabling wouldn't block components. I have since restored them for testing purposes, and was careful to use the torque-limited SMA tightening tool when restoring the connections.

In order to test various things like conversion loss etc, I figured it would be useful to have two RF signal sources, so I scavenged the Fluke RF generator that Johannes was using from under the PSL table. In the process, I accidentally bumped the PSL interlock on the southeast corner of the PSL table. I immediately turned the NPRO back on, and relocked PMC/IMC. Everything looks normal now. Acromag may even have caught my transgression.

I saw some interesting behaviour of the Audio IF amplifier stage on the demod board today, by accident. I was testing the board for I/Q orthogonality and gain balance, when I noticed a large gain imbalance between the I and Q channels for both Board #3 and #4, which are the ones we use for the IR ALS demodulation. This puzzled me for some time, but then I realized that I had only reduced the gain of this stage from x100 to x10 for the I channel, and not for the Q channel! The surprising thing though was that the output waveform still looked like a clean sinusoid on the o'scope, and there was no evidence of the voltage clipping that is characteristic of an op-amp being driven beyond its voltage rails. The conversion factor with a preamp gain on x10 was measured today to be 2V IF / 1V RF. But this means that for a preamp stage gain of x100, we expect 20V IF / 1V RF, which is well in the saturation regime of the AD829, since the Vcc is only +/-15V. I'm guessing the diodes D2 and D3 are for overvoltage protection, but given that the pre-amp gain is x100, the input signal at the inverting input of the AD829 is only 0.2V at DC, which isn't above the forward bias voltage for the switching diode BAV99. Perhaps there is some interaction between the pre-amp and the FET demodulator that I dont understand, or I am missing something about the differential to single-ended topology that would explain this behaviour. 

I found it puzzling why the large preamp stage gain didn't hurt us with the green beat - even though the green optical beat signal was smaller than the current IR beat, a back-of-the-envelope calculation suggested that it would still have saturated the ADC with a x100 gain on the preamp. Perhaps this observation is part of the story, and there is also the unpredictable behaviour of the D990694 board for an input signal with large DC levels...

I did the following tests on this board today:

• Check +/-15V supplies, power reg board.
• Check DC offset on I and Q front panel output with LO driven at +10dBm, RF input terminated. Found it to be 0.
• Checked calibration of back-panel DSUB connector monitors for LO and RF powers. Data to be uploaded, looked quite linear.
• Checked conversion gain from RF input to IF output for two sets of LO/RF powers.
• Measured conversion gain as a function of the IF frequency (i.e. frequency offset between LO and RF inputs, out to ~700kHz, 8 datapoints)
• Checked orthogonality and gain balance of the I and Q outputs.
• Measured the noise of the I and Q outputs in the audio frequency range using the SR785.

I didn't really measure the transfer function of the preamp stage after the modification because there wasn't a convenient test point and I couldn't find the high impedance FET probe for the Agilent - I wonder if somebody in WB has it? Anyways, all the tests suggested the board is operating as expected, and I now have calibrations for the back panel DSUB for LO/RF power levels, and also the conversion gain from RF to IF. I will put together a python notebook with all my measurements and upload it to the DCC page for this part. I need to double check expected noise levels from LISO to match up to the measurement.

I will now proceed to the next piece (#3?) of this puzzle, which is to understand how the D990694 which receives the signals from this unit reacts to the expected DC voltage level of ~4Vpp.

After discussion with Koji, I have also decided to look into putting together a daughter board for an alternative Audio IF preamp stage. The motivation is that for the ALS application, we expect a high DC signal level all the time (because the loop does not suppress the beat note amplitude). So we would like for the preamp stage to have the usual shape of some zero around 4Hz, a pole around 40Hz, and then the LowPass profile of the existing preamp stage (to cut out the 2f frequency product, but also to minimize the possibility of the fast AD829 going into some unpredictable regime where it oscillates). So, the desired features are:

• Whitening (z,p) at (4Hz,40Hz) or (15Hz,150Hz) so that we have frequency dependent gain that can handle the large DC signal level expected. Need to measure noise of the actual IR beat signal to determine what the appropriate whitening shape is.
• Low-pass above a few 100kHz to cut out 2f modulation product
• Low-passing at input of AD829 (or just use OP27?)

I picked up a unit of D1900068 SR785 accessory box from Dean's office at Downs. 

I decided to try doing the THD measurement with a function generator. Did some quick trials tonight to verify that the measurement plan works. Note that for the test, I turned off the z=15,p=150 whitening filter - I'm driving a signal at ~100Hz and should have plenty of oomph to be seen above ADC noise.

1. Checked for ground loops - seem to be fine, see black trace on Attachment #1 which was taken with the FnGen hooked up to the input, but not putting out any signal
2. Spectrum with 1Vpp sine wave @ ~103Hz. The various harmonic peaks are visible, and though I've not paid attention to bin width etc, the largest harmonics are ~1000x smaller than the main peak, and so the THD is ~1ppm, which is in the ballpark of what the datasheet tells us to expect around 100Hz for a gain of ~10 (=20dB). The actual gain was set at 0dB (so all opAmps in the quad bypassed)

I'm going to work on putting together some code that gives me a quick readback on the measured THD, and then do the test for real with different amplitude input signal and whitening gain settings.

**Matlab has a thd function, but to the best of my googling, can't find a scipy.signal analog.

To remind myself of the problem, summarize some of the discussion Koji and I had on the actual problem via email, and in case I've totally misunderstood the problem:

1. The "Variable Gain" feature on the D990694 boards is achieved by 4 single gain stages cascaded together in series, with the ability to engage/bypass each stage individually.
2. The 4 gain stages are constructed using the 4 OpAmps in a quad LT1125 IC, each in standard non-inverting configuration.
3. The switches unfortunately are on the output side of each op-amp. This means that even if a stage is bypassed, the signal reaches the input pin of the OpAmp.
4. For proper operation, in closed-loop, the differential voltage between the input pins of the OpAmp are 0.
5. But this may require the OpAmp to source more current than it can (just using Ohms law and the values of the resistors in the feedback path).
6. As a result, a large differential voltage develops between the input pins of the OpAmp.
7. The LT1125 is not rated to operate in such conditions (this is what Hartmut was saying in the ilog linked earlier in this thread).
8. Part of the internal protection mechanism to prevent damage to the IC in such operating conditions is a pair of diodes between the input pins of the OpAmp.
9. When a large differential voltage develops between the input pins of the OpAmp, the diodes act to short the two to bring them to the same potential (minus whatever small drop there is across the diodes). Actually, according to the datasheet, when the differential voltage between the input pins exceeds 1.4V, the input current must be limited to 25mA, to avoid damaging the protection diodes? If so, we may already have damaged a bunch of these amplifiers.
10. While the LT1125 IC is protected in this condition, the infinite input impedance of the OpAmp is reduced to the resistance between the inverting input and ground. The output voltage may still be saturated, but the output current draw is within what the IC can supply.
11. As a result, Ohms law means that the preceeding stage is overdrawn for current. This is clearly not ideal.
12. Another possible problem is that there is some sort of interaction between the 4 opamps in the quad IC, which means that even if one stage is overdrawn for current, all of them may be affected.
13. The Advanced LIGO version of this board addresses #11 and #12 by (i) placing a series resistor between the input signal and the non-inverting input of the opamp, and (ii) using single opamp ICs instead of a quad, respectively.

So my question is - should we just cut the PCB trace and add this series resistance for the 4 ALS signal channels, and THEN measure the THD? Since the DC voltage level of the ALS signal is expected to be of the order of a few volts, we know we are going to be in the problematic regime where #11 and #12 become issues.

> So my question is - should we just cut the PCB trace and add this series resistance for the 4 ALS signal channels, and THEN measure the THD?

GO A HEAD

Correcting a mistake in my earlier elog: the D990694 is NOT differential receiving, it is single ended receiving via the front panel SMA connectors. The aLIGO version of the whitening board, D1001530 has an additional differential-to-single-ended input stage, though it uses the LT1125 to implement this stage. So the possibility of ground loops on all channels using this board will exist even after the planned change to install series resistance to avoid current overloading the preceeding stage.

After labeling all cables, I pulled out one of the D990694s in the LSC rack (the one used for the ALS X signals, it is Rev-B1, S/N 118 according to the sticker on it).

Took some photos before cutting anything. Attachments #1-3 are my cutting plans (shown for 1 channel, plan is to do it for both ALS channels coming into this board). #1 & #2 are meant to show the physical locations of the cuts, and #3 is the corresponding location on the schematic. These are the most convenient locations I could identify on the board for this operation.

I don't know what the purpose of resistors R196, R197, R198 are. I'm assuming it has something to do with the way the ADG333ABR switches. The aLIGO board uses a different switch (MAX4659EUA+), and doesn't have an analogous resistor (though from what I can tell, it too is a CMOS SPDT switch just like the ADG333ABR, just has a lower ON resistance of 25ohm vs 45ohm for the ADG333ABR).

As for the actual resistance to be used: Let's say we don't have signals > 5V coming into this board. Then using 301ohms (as in the aLIGO boards) in series means the peak current draw will be <20mA, which sounds like a reasonable number to me. Larger series resistance is better, but I guess then the contribution of the current noise of the OpAmp keeps increasing.

This is proving much more challenging than I thought - while Cut #1 was easy to identify and execute, my initial plan for Cut #2 seems to not have isolated the input of the second opamp (as judged by DMM continuity). Koji pointed out that this is actually not a robust test, as the switches are in an undefined state while I am doing these tests with the board unpowered. It seems rather complicated to do a test with the board powered out here in the office area though - and I'd rather not desolder the 16 and 20 pin ICs to get a better look at the tracks. This PCB seems to be multilayered, and I don't have a good idea for what the hidden tracks may be. Does anyone know of a secret place where there is a schematic for the PCB layout of this board? The DCC page only has the electrical schematic drawings, and I can't find anything useful on the elog/wiki/old ilog on a keyword search for this DCC document number. The track layout also is not identical for all channels. So I'm holding off on exploratory cuts.

*I've asked Ben Abbott/Mike Pedraza about this and they are having a look in Dale Ouimette's old drives to see if they can dig up the Altium/Protel files.

Suspension Actuator noise:

There are 3 main sources of electronics noise which come in through the coil driver:

1. Voltage noise of the coil driver.
   1. The input referred noise is ~5 nV/rHz, so not a big issue.
   2. The Johnson noise of the output resistor which is in series with the coil is sqrt(4*k*T*R) ~ 3 nV/rHz. We probably want to increase this resistor from 200 to 1000 Ohms once Gautam convinces us that we don't need that range for lock acquisition.
2. Voltage noise of the dewhitening board.
   1. In order to reduce DAC noise, we have a "dewhitening" filter which provides some low passing. There is an "antiDW" filter in the digital part which is the inverse of this, so that when they are both turned on, the result is that the main signal path has a flat transfer function, but the DAC noise gets attenuated.
   2. In particular, ours have 2 second order filters (each with 2 poles at 15 Hz and 2 zeros at 100 Hz).
   3. We also have a passive pole:zero network at the output which has z=130, 530 Hz and p = 14, 3185 Hz.
   4. The dewhitening board has an overall gain of 3 at DC to account for our old DACs having a range of +/-5 V and our coil drivers having +/- 15 V power supplies. We should get rid of this gain of 3.
   5. The dewhitening board (and probably the coil driver) use thick film resistors and so their noise is much worse than expected at low frequencies.
3. DAC voltage noise. 
   1. The General Standards 16-bit DACs have a noise of ~5 uV/rHz.
4. the satellite box is passive and not a significant source of noise; its just a flaky construction and so its problematic.

I've removed the SOS coil driver (D010001-B, S/N B151, labelled "SRM") + Universal Dewhitening Board (D000183 Rev C, S/N B5172, labelled "B5") combo for SRM from 1X4, for photo taking + inspection.

I first shutdown the SRM watchdog, noted cabling between these boards and also the AI board as well as output to Sat. Box. I also needed to shutdown the MC2 watchdog as I had to remove the DAC output to MC2 in order to remove the SRM Dewhitening board from the rack. This connection has been restored, MC locks fine now.

I believe the ETMs and ITMs are different from the others.

  Summary:

The pin-outs for the DAC interface board have been determined.

Details:

• I used a temporary break-out cable (pic attached) and connected the 40pin IDC connector on this to the DAC interface board at 1Y4.
• I had a hypothetical pin-out map which was to be verified. So I connected pairs of ribbon wire to an oscilloscope in the configuration which I believed to be correct, and then used awggui to send a 3Hz, 10000 count sine-wave to the corresponding channel via the excitation points set up earlier.
• I verified that the correct waveform showed up on the scope screen. I then tried sending the same signal to another DAC channel and verified that there were no accidental shorts/bad connections. The signal was fairly noisy, but this was probably because of the makeshift connections.
• Repeated the above for all 8 channels in the bank marked 9-16 on the DAC interface board.

Turns out that my deductions using the D0902496 wiring diagram, a spare D080303 DAC to IDC adaptor and a multimeter were correct! The pin outs as determined by this test are sketched in the graphic below.

To Do:

•  Now that the pin-outs have been determined, I need to go about making the custom ribbon that will connect the 40pin IDC on the DAC interface board to the 10-pin IDC on the PZT driver board. Because there is a pair of wires that will have to be 'skipped' while going from the 40-pin to the 10 pin IDC (corresponding to the pair not-connected between two DAC channels on the 40-pin IDC), this may be tricky.

Misc:

The excitation points added to the simulink model are still there, I plan on keeping it as such till I finish installation of the boards as they will be useful for testing purposes.

Pin-Outs of the DAC to IDC Adaptor (D080303) inside the "DAC Interface Box at 1Y4":

Makeshift break-out ribbon cable:

 I did just this, and it looks okay to me:

 I redid the measurement with the appropriate units set on the SR785. Power spectral density plots for no output (top), 500Hz, 1000 counts amplitude sine wave (middle) and 2000Hz, 1000 counts amplitude (bottom) are attached, with the right unit on the Y-axis.

Those 'peaks' for the oscillations seem ridiculously broad.  I think you should look again, really quickly, with smaller bandwidth at, say, the 2kHz oscillation, to make sure it looks reasonable.

 Summary:

I measured the maximum output of the DAC at 1Y4 as well as its power spectrum. The results are as follows (plots below):

• Maximum amplitude of differential output: + 10V.
• Power spectrum has a peak at 64 kHz.

Therefore, the gain of the high-voltage amplification stage on the PZT driver boards do not need to be changed again, as the required output range of 0-100V from the DAC board was realised when the input voltage ranged from -10V to +10 V w.r.t ground. The AI board converts the differential input to a single ended output as required by the driver board.

I will now change some resistors/capacitors on the AI board such that the position of the notches can be moved from 16k and 32k to 64k and 128k.

Procedure:

 Max. amplitude measurement

My previous measurement of the maximum output amplitude of the DAC was flawed as I made the measurement using a single channel of the oscilloscope, which meant that the negative pin of the DAC channel under test was driven to ground. I redid the measurement to avoid this problem. The set up this time was as follows:

• Positive pin of DAC connected to channel 1 of oscilloscope using break out cable and mini-grabber probe
• Negative pin of DAC connected to channel 2 of oscilloscope
• Grounds of channels 1 and 2 connected (I just hooked the mini-grabbers together)
• Measurement mode on oscilloscope set to channel 1 - channel2
• Used excitation points set up earlier to output a 3 Hz sine wave with amplitude of 32000 counts from channel 9 of the DAC. 

The trace on the oscilloscope is shown below;

So with reference to ground, the DAC is capable of supplying voltages in the range [-10V 10V]. This next image shows all three traces: positive and negative pins of DAC w.r.t ground, and the difference between the two.

 Power spectrum measurement

I used the SR785 to make the measurement. The set up was as follows:

• Positive pin of DAC to A-input of SR560
• Negative pin of DAC to B-input of SR560
• A-B output to Channel 1 input A of the SR785
• SR785 configured to power spectrum measurement

Initially, I output no signal to the DAC, and obtained the following power spectrum. The peak at 65.554 kHz is marked.

I then re-did the measurement with a 200 Hz (left) and 2000 Hz(right), 1000 counts amplitude (I had to change the Ch1 input range on the SR785 from -18dBm to -6dBm) sine wave from channel 9 of the DAC, and obtained the following. The peaks at ~64 kHz are marked.

Now that this peak has been verified, I will work on switching out the appropriate resistors/capacitors on the AI board to move the notches from 16k and 32k to 64k and 128k. 

We need the unit of the voltage power spectrum density to be V/sqrt(Hz).
Otherwise we don't understand anything / any number from the plot.

The first picture shows that there is indeed a DAC next to the ADC in the LSC IO chassis. The second picture shows how there are two cables, each one carrying 8 channels of DAC. The third one shows how these come out of the coil drivers to handle the Tip/Tilt mirrors which point the beam from the IMC into the PRC. It should be the case that the second Dewhitening filter board can give us access to the next 8 channels for use in driving an audio signal into the control room or an ISS excitation.

The DAC was fine.  I realized tonight that the digital filter bank outputs were off, so I wasn't actually sending signals out.  Oooops. 

Gautam and I looked into the DAC noise contribution to the noise budget for homodyne detection at the 40m. DAC noise is currently the most likely limiting source of technical noise.

Several of us have previously looked into the optimal SRC detuning and homodyne angle to observe pondermotive squeezing at the 40m. The first attachment summarizes these investigations and shows the amount of squeezing below vacuum obtainable as a function of homodyne angle for an optimal SRC detuning including fundamental classical sources of noise (seismic, CTN, and suspension thermal). These calculations are done with an Optickle model. According to the calculations, it's possible to see 6 dBvac of squeezing around 100 Hz.

The second attachment shows the amount of squeezing obtainable including DAC noise as a function of current noise in the DAC electronics. These calculations are done at the optimal -0.45 deg SRC detuning and 97 deg homodyne angle. Estimates of this noise are computed as is done in elog 13146 and include de-whitening. It is not possible to observe squeezing with the current 400 Ω series resistor which corresponds to 30 pA/rtHz current noise at 100 Hz. We can get to 0 dBvac for current noise of around 10 pA/rtHz (1.2 kΩ series resistor) and can see 3 dBvac of squeezing with current noise of about 5 pA/rtHz at 100 Hz (2.5 kΩ series resistor). At this point it will be difficult to control the optics however.

So it seems reasonable to reduce the DAC noise to sufficient levels to observe squeezing, but we will need to think about the controls problem more.

Gautam and I redid our calculations, and the updated plot of squeezing as a function of DAC current noise per coil is shown in the attachment. The current noise is calculated as the maximum of the filtered DAC noise and the Johnson noise of the series resistor. The total noise is for four optics with four coils each.

The numbers are worse than we quoted before: according to these calculations we can get to 0 dBvac for current noise per coil of about 2.4 pA/rtHz at 100 Hz.

1. Should not count the ITMs. On those we can use big resistors / filters to cut out the noise.
2. For the initial LIGO, we used 7 K resistors and the mass was 10 kg. But...the output driver went +/- 150 V.

So we had a max F/m = (20 mA * 0.064 N/A)/(10 kg) = 0.0001. For the 40m, to get the same thing, we would need 40x less current (~0.5 mA). At the moment we have (12 V / 400 Ohm) = 30 mA.

We need to get a spectrum and times series of the required coil current for acquiring and holding the DRMI, and also the single arm. Then we can see where to make noise reductions to allow this drastic force reduction. 

Coil Driver Upgrade wiki here.

Summary:

I've spent the last week investigating various parts of the DAC -> OSEM coil signal chain in order to add these noises to the MICH NB. Here is what I have thus far.

Current situation:

• Coils are operated with no DAC whitening
• So we expect the DAC noise will dominate any contribution from the electronics noise of the analog De-Whitening and Coil Driver boards
• There is a factor of 3 gain in the analog De-Whitening board

DAC noise measurement:

• I essentially followed the prescription in G1401335 and G1401399
• So far, I only measured one DAC channel (ITMX UL)
• The noise shaping filter in the above documents was adapted for this measurement. The noise used was uniform between DC and 1kHz for this test.
• For the >50Hz bandstops, I used 1 complex pole pair at 5Hz, and 1 compelx zero pair at 50Hz to level off the noise.
• For <50Hz bandstops, I used 1 compelx pole pair at 1Hz and 1 complex zero pair at 5Hz to push the RMS to lower frequencies
• I set the amplitude ("gain" = 10,000 in awggui) to roughly match the Vpp when the ITM local damping loops are on - this is ~300mVpp (measured with a scope). 
• The elliptic bandstops were 6th order, with 50dB stopband attenuation.
• The SR785 input auto-ranging was disabled to allow a fair comparison of the various bandstops - this was fixed to -20 dBVpk for all measurements, and the SR785 noise floor shown is also for this value of the input range. Input was also AC coupled, and since I was using the front-panel LEMO for this test, the signal was effectively single-ended (but the ground of the SR785 was set to "floating" in order to get the differential signal from the DAC) 
• Attachment #1 shows the results of this measurement - I've subtracted the SR785 noise from the other curves. The noise model was motivated by G1401399, but I use an f^-1/2 model rather than an f^-1 model. It seems to fit the measurement alright (though the "fit" is just done by eye and not by systematic optimization of the parameters of the model function).

Noise budget:

• I then tried to translate this result into the noise budget
• The noises for the 4 face coils are added in quadrature, and then the contribution from 3 optics (2 ITMs and BS) are added in quadrature
• To calibrate into metres, I converted the DAC noise spectral density into cts/rtHz, and used the numbers from this elog. I thought I had missed out on the factor of 3 gain in the de-white board, but the cts-to-meters number from the referenced elog already takes into account this factor.
• Just to be clear, the black line for DAC noise in Attachment #2 is computed from the single-channel measurement of Attachment #1 according to the following relation: , where G_act is the coil transfer function from the referenced elog, taken as 5nm/f^2 on average for the 2 ITMs and BS, the factor of 2 comes from adding the noise from 4 coils in quadrature, and the factor of sqrt(6) comes from adding the noise from 3 optics in quadrature (and since the BS has 4 times the noise of the ITMs)
• Using the 0.016N/A number for each coil gave me an answer than was off by more than an order of magnitude - I am not sure what to make of this. But since the other curves in the NB are made using numbers from the referenced elog, I think the answer I get isn't too crazy...
• Attachment #2 shows the noise budget in its current form, with DAC noise added. Except for the 30-70Hz region, it looks like the measured noise is accounted for.

Comments:

• I have made a number of assumptions:
  • All DAC channels have similar noise levels
  • Tried to account for asymmetry between BS and ITMs (BS has 100 ohm resistance in series with the coil driver while the ITMs have 400 ohms) but the individual noises haven't been measured yet
  • This noise estimate holds for the BS, which is the MICH actuator (I didn't attempt to simulate the in-lock MICH control signal and then measure the DAC noise)
• But this seems sensible as a first estimate
• The dmesg logs for C1SUS don't tell me what DACs we are using, but I believe they are 16-bit DACs (I'll have to restart the machine to make sure)
• In the NB, the flattening out of some curves beyond 1kHz is just an artefact of the fact that I don't have data to interpolate in that region, and isn't physical.
• I had a brief chat with ChrisW who told me that the modified EEPROM/Auto-Cal procedure was only required for 18-bit DACs. So if it is true that our DACs are 16-bit, then he advised that apart from the DAC noise measurement above, the next most important thing to be characterized is the quantization noise (by subtracting the calculated digital control signal from the actual analog signal sent to the coils in lock)
• More details of my coil driver electronics investigations to follow...

I've been working on setting up some scripts for measuring the DAC noise.

In all the DRMI noise budgets I've posted, the coil-driver noise contribution has been based on this measurement, which could be improved in a couple of ways:

• The measurement was made at the output of the AI board - we can make the measurement at the output of the coil driver board, which will be a closer reflection of the actual current noise at the OSEM coils.
• The measurement was made by driving the DAC with shaped random noise - but we can record the signal to the coils during a lock and make the noise measurement by using awg to drive the coil with this signal, with elliptic bandstops at appropriate frequencies to reveal the electronics noise.

1. The IN1 signals to the coils aren't DQ-ed, but ideally this is the signal we want to inject into the coil_EXC channel for this measurement - so I re-locked the DRMI a couple of nights ago and downloaded the coil IN1 channel data for ~5mins for the ITMs and BS.
2. AWGGUI supposedly has a feature that allows you to drive an EXC channel with an arbitrary signal - but I couldn't figure out how to get this working. I did find some examples of this kind of application using the Python awg packages, so I cobbled together some scripts that allows me to drive some channels and place elliptic bandstop filters as I required. 
3. I wasted quite a bit of time trying to implement these signals in Python using available scipy functions, on account of me being a DSP n00b . When trying to design discrete-time filters, of course numerical precision errors become important. Initially I was trying to do everything in the "Transfer function (numerator-denominator)" basis, but as Rana pointed out, the way to go is using SOSs. Fortunately, this is a simple additional argument to the relevant python functions, after which elliptic bandstop filter design was trivial.
4. The actual test was done as follows:
   • Save EPICS PIT/YAW offsets, set them to 0, disable Oplev servos, and then shut down optic watchdog once the optic is somewhat damped. This is to avoid the optics getting a large kick when disconnecting the DB15 connector from the coil driver board output.
   • Disconnect above-mentioned DB15 connector from the appropriate coil driver board output.
   • Turn off inputs to coils in filter module EPICs screens. Since the full signal (local damping servo output + Oplev servo output + LSC servo output) to the coil during a DRMI lock will be injected as an excitation, we don't need any other input. 
   • Use scripts (which I will upload to a git repo soon) to set up the appropriate excitation.
   • To measure the spectrum, I used a DB15 breakout board with test-points soldered on and some mini-grabber-to-BNC adaptors, in order to interface the SR785 to the coil driver output. We can use the two input channels of the SR785 to simultaneously measure two coil driver board output channels to save some time.
   • Take a measurement of the SR785 noise (at the appropriate "Input Range" setting) with inputs terminated to estimate the analyzer noise floor.
   • Just for kicks, I made the measurement with the de-whitening both OFF/ON.

I only managed to get in measurements for the BS and ITMX today. ITMY to be measured later, and data/analysis to follow.

The ITMX and BS alignments have been restored after this work in case anyone else wants to work with the IFO.

Some slow machine reboots were required today - c1susaux was down, and later, the MC autolocker got stuck because of c1iool0 being unresponsive. I thought we had removed all dependency of the autolocker on c1iool0 when we moved the "IFO-STATE" EPICS variable to the c1ioo model, but clearly there is still some dependancy. To be investigated.

Attachment #1: Summary of results of measurements made on Friday. There is a lot in this plot, here is a breakdown:

• I drove the excitation points of the coil output filter banks with raw time-series data downloaded during a DRMI lock with pyawg. Today during the meeting, Rana pointed out that we could just acquire median (as opposed to mean since the former is more immune to glitches during the averaging process) spectra during a lock, and then do the ifft in python to generate time series data for pyawg. Another advantage of doing it this way is that we don't need to store a large (~200MB in my case) file of 16k data for numerous channels. But since I already had this file, I decided against changing the methodology for this round of tests. Time series plots of the signals do not show any large glitches.
• The SR785 was used in dual channel mode to acquire spectra from 2 coil driver outputs simultaneously, in the interest of saving time. Input range was set to -32dbVpk, AC coupled, which was the smallest value that worked for the given signal profile. Spectra were taken from DC-200Hz, with 801 points, 25 averages. The DB15 output of the coil driver board was connected to a DB15 breakout board, and then a BNC->Pomona mini-grabber adapter was used to connect to the SR785 input. The newly acquired linear power supplies for the GPIB box mean that spurious 60Hz harmonics were not present. 
• Initially, I had planned to enable various bandstops from 20Hz-200Hz, to get a more complete profile of the noise. But in the end, I only used two elliptic bandstops (6th order, 60dB stopband attenuation): 60-90Hz, for which data is plotted in red and 90-200Hz, for which data is plotted in green. 
• I've used the same noise model as I used here, plotted in dashed grey (summed with SR785 noise at the above input range, with input terminated via 50ohm terminator) - but had to tweak the parameters to get the curve to line up with the measurement. It looks like there is considerable variation between DAC channels, and certainly between the ITMX channels and the BS channels as groups.
• I took the measurement in two conditions - with the coil de-whitening off (left column) and coil de-whitening on (right column). Note that the input to the excitation was acquired at the IN1 of the relevant filter bank, and since the de-whitening happens downstream of this, we don't have to do anything special.
• In the right column, I have also plotted the LISO modelled noise, which was shown to match well with the measured curve, admittedly only for one channel (for the coil driver alone, so I am not taking into account the noise of the de-whitening board - I will fix this once I dig up that data).

Some remarks:

1. According to this measurement, the de-whitening filters are the same on the ITMX channels and BS channels. So I don't understand the difference in the right column for BS and ITMX channels.
2. While there is considerable variation between channels and also between ITMX and BS, there is certainly >6dB of reduction in the DAC noise when the de-whitening is engaged. However, no improvement was seen in the MICH error signal spectrum between 60-300Hz. So we have to continue to investigate other noises that can explain the noise in that band.
3. Also, the realized improvement in DAC noise by turning on the coil de-whitening seems marginal - the low pass has gain of ~-80dB at 100Hz, but we seem to be hitting some sort of electronics noise in all channels at the level of ~100nV/rtHz (assuming the actual DAC noise doesn't degrade significantly when the digital simulated de-whitening filter is engaged).
4. It remains to do the test for the ITMY channels.
5. It would be useful to visualize the incoherent sum of all these channels - this is what should go into the MICH displacement NB. To be added.
6. I'm currently loading pyawg from my user directory. Need to figure out a place to put this and add it to $PATH.

Data + code for this plot will be attached later.

Since you're monitoring two channels simultaneously, you could try subtracting them, as an alternative to carving out bandstops.

1. Drive both channels with the same time series
2. Tweak the filter module gains if needed to equalize the analog outputs
3. Apply SR785 user math to subtract the two channels (or A-B mode of a single input, if you're not using that already?)
4. Measure the residual, which should be the incoherent part containing DAC + coil driver noise

Subtraction can conceal certain annoying effects (like numerical noise or level crossing glitches) that remain coherent for two identical outputs. It might be worth experimenting with a differential offset or sinusoid, to try to break up that kind of coherence if it exists.

I am running some more measurements of the DAC noise, for which I've shut down the BS watchdog. Some of the cables on the coil driver side have been disconnected.

I will restore these tomorrow.

As Rana pointed out to me, one important fact to keep in mind w.r.t. DAC noise is that it can be non-linear. So the RMS of the DAC noise in a higher frequency band (say 60-100Hz) can be affected by the RMS of the requested DAC signal in some lower frequency band (say 10-20Hz). One test to see if this hypothesis can explain the difference @100Hz between the ITMX channels and BS channels I observed a couple of days ago is to see if the noise around 100Hz becomes lower when I enable a 20-40Hz bandstop in the digital signal chain.

BS connections and damping restored.

 [Alex, Gautam]

The signal chain from the DAC output to the output of the PZT driver board (including the HV supply) has been verified. 

I had installed the two boards in the eurocrate yesterday and laid out the cables from 1X9 to the endtable. The output of the AI board had been verified using the monitor port on the front panel, but the output from the PZT driver board was yet to be checked because I had not connected the HV supply yesterday.

When I tried this initially today, I was not getting the expected output from the monitor channels on the front panel of the PZT driver board, even though the board was verified to be working. Alex helped debug the problem, which was identified as the -15V supply voltage not making it onto the board.

I changed the slot the board was sitting in, and used a long screw to bolt the board to the crate. Both the AI board and the PZT driver board seem to be slightly odd-sized, and hence, will not work unless firmly pushed into the eurocrate and bolted down. This would be the first thing to check if a problem is detected with this system. 

In any case, I have bolted both boards to the eurocrate, and the output from the PZT driver board is as expected when I sent a 10Vp sine wave out from the DAC. I think the cables can now be hooked up to the PZTs once we are pumped down.

 Since we had a similar trouble with the DAC at CLIO, I checked if this problem comes from the same origin.

The origin of the problem we had was that although the board was sold as 16 channel DAC, the firmware was set to use only 8ch.

To see if this problem exist in the DAC boards of c1sus, I added the following code to the /cvs/cds/caltech/cds/advLigoRTS/src/fe/map.c

printk("DAC ASSC = 0x%x\n",dacPtr[devNum]->ASSC);

in the definition of mapDac() function.

This code prints the information of the ASSC (Assembly Configuration) register of the PMC66-16AO16 board as a kernel message at the start up time of the realtime code. You can check the message with dmesg command.

After the modification, I recompiled the c1sus and installed it.

make c1sus; make install-c1sus

After starting c1sus, I checked the dmesg. Then found that the ASSC register was set to 0x130006. To decipher this magic number, you have to consult with the manual of the DAC, which is available online.

http://www.generalstandards.com/view-products.php?product=pmc66-16ao16

The manual says the 17th and 18th bits of this number set the number of channels. Those bits are 11 for 0x130006. According to the manual, 11 means 16 channels are present. So it seems that the ASSC register is correctly set. In the case of CLIO, the ASSC register was 0x110003, meaning only 8 channels are present.

Unfortunately, the ASSC register was not the cause of the problem, but at least this possibility was checked.

Summary: I am implementing digital audio filtering on various interferometer signals in order to listen to the processed audio which will help in characterizing and noise reduction in the interferometer. following is a summary of the gui i have made towards a general purpose DAF module linked to the LSC. 

Details:  attachment 1 shows the top level overview of the daf module.

The "INPUTS" button shown redirects to the medm screen shown in attachment 2, which is a collection of inputs going into the module.

Each of the buttons shown in "C1DAFI_INPUTS.png" is further linked to various i/o boxes like adc1, adc2, lsc signal and exitation. An example is shown in attachment 3. This is the specific I/O box for the LSC signal.

The field labelled "INPUT_MTRX" is linked to a matrix which routes these 4 inputs to various DSP blocks. Similarly, the "OUTPUT_MTRX" tab is useful for choosing which output goes to the speaker. 

Time and computational load monitoring is done in the "GDS_TP" tab which links to the medm screen shown in attachment 4.

Currently the AGC is successfully implemented as one of the DSP block. The details of the AGC implementation were given in a previous elog: https://nodus.ligo.caltech.edu:8081/40m/12159

I need to make a few changes to the code for Frequency Shifting and Whitening before uploading them on the FE. I will put the details soon.

Some more things that I think need to be added: 

1) "Enable" buttons for each of the DSP blocks.

2) Labels for each of the matrix elements.

3) Further headers and other description for each of the tabs 

I have added Enable buttons for each of the DSP blocks, and labels for the matrix elements. The input matrix takes inputs from each of the 4 channels: ADC1, ADC2, LSC and EXC, and routes them to the audio processing blocks (attachment 2). The output matrix (attachment 3) takes the outputs of the various DSP blocks and routes them to the output and then to the speakers. 

1) I have added the status summary of the DAFI block to the main FE status overview screen in the c1lsc cloumn. (attachment 1)

2) I have edited all the kissel matrix buttons appropriately, and given them appropriate lables. (attachment 2)

I found the DAFI screen as a button inside of the LSC screen - I think its more logically found from the sitemap, so I'll move it into there as well.

Gautam and I noticed a 60 Hz + harmonics hum which comes from the DAFI. Its the noisiest thing in the control room. It goes away when we unplug the fiber coming into the control room FiBox receiver, so its not a ground loop on this end. Probably a ground loop at the LSC rack.

Upon further investigation we notice that the Fibox at the LSC rack had its gain turned all the way up to +70 dB. This seemed too much, we reduced it to ~20 (?) so that we could use more of the DAC range.  Also, it is powered by a AC/DC converter plugged in to the LSC rack power strip. We cannot use this for a permanent install - must power the FiBox using the same power supplies as are used for the LSC electronics. Probably we'll have to make a little box that takes the fused rack power of 15 V and turns it into +12 V with a regulator (max current of 0.15 A). Making sure that the FiBox doesn't pollute the rest of the LSC stuff with its nasty internal DC-DC converters.

We also put a high pass in the output filter banks of DAFI. For the PEM channels we put in a 60 Hz comb. WE then routed the Y-end Guralp in through the boxes and out the output, mostly bypassing the frequency shifting and AGC. It seems that there is still a problem with GUR2.

Does anyone know which one is GUR1 and which one is GUR2? I don't remember the result of the Guralp cable switching adventures - maybe Koji or Steve does. According to the trend it was totally dead before March and in March it became alive enough for us to see ~30 ADC counts of action, so way smaller than GUR111 or GUR snoopy or whatever its called.

Summary: I have added an arbitrary math block to the DAFI model, which takes two inputs, say X and Y, and can perform various unary and binary operations on them:

Details:

• Unary Operations:

1. Delay - There exists a text-based input to specify the amount of delay to be given to a particular signal.
2. sin()
3. cos()

• Binary Operations:

1. Weighted addition and multiplication: The output is calculated according to the relation: A*X + B*Y + C*X*Y. A, B, C are constant inputs, which can be given through text-based inputs in the GUI.
2. MAX{X,Y}
3. MIN{X,Y}

Attachment 1 shows the existing DAFI gui, updated with cascading of various DSP blocks, upto three levels, button-based ENABLE and DISABLE controls for all blocks except arb. math (the control on arb. math. is achieved by clicking on the block.) On clicking the arb. math block one is taken to the dedicated arb. math screen, which has enable buttons for all the processes listed above. A screenshot of this screen is in attachment 2. There is one control input, which controls all the unary operations on X and the binary operations on X and Y, and another control input which controls the unary operations on Y. switching on a particular arb. math process gives a particular control input, which choses the appropriate section of the code. At a time, only one process from the top grey block (corresponding to unary operations on X and binary operations on X and Y) and one process from the bottom grey block (corresponding to unary operations on Y) can be selected. Thus, the outputs which go from the arb. math block to the intermediate matrices (MATRIX1L or MATRIX2L) are:

a) Either an output of unary operation on X or a binary operation on X and Y, the specific one depending upon the control input,

    and

b) Output of a unary operation on Y, again the specific one depending upon the control input

Thus there is apparent asymmetricity in the action of the arb. math block on the two inputs. However, this is done in order to reduce to total number of outputs and control signals, and this can be easily taken care of by interchanging the inputs before the block. 

While compiling this code, the c1lsc machine had crashed once, it was found that this was due to a stray "printf()" command in the c code. This glich in the code now stands rectified  There is a possibility that the previous incidents of the code crashing could also be due to the existence of a printf() command. 

Preliminary Testing: I have done a preliminary testing of the arb math block, i.e. verified that on enabling the sin and cos processes, the output is less that 1, on swithching on the process of weighted avarage and multiplication, the output looks like it is right, for a few simple values of A, B, C, like 0, 1, etc. The delay block however is giving zero output for delay of more than 6 samples.

I have added the PEM signals mentioned in the previous elog as DAF inputs through PCIE IPC, and compiled and restarted the c1pem and c1daf models. 

Attached are the pictures of the simulink diagram of the addition in the PEM and the DAF. 

Since the signals are moving from a 2kHz clock rate machine to a 16kHz clock rate machine, some imaging effects are possible, which I have to look into.

I have added the control signals DARM_CTRL, MICH_CTRL, PRCL_CTRL, SRCL_CTRL, CARM_CTRL, XARM_CTRL, YARM_CTRL, MC_CTRL to the DAFI model from the LSC model via IPC commn.

The changes done to the LSC model include addition of an extra block going to DAFI (attachment 2, red rectangle in attachment 1), and addition of an extra overall output from the LSC, called DAFI_OUT2, which goes to DAFI through IPC link C1:LSC-DAF_2 (attach. 3). Now two distinct inputs can be given to the DAFI, whose intended purpose is to act as two distinct audio signals in the stereo output, but can also be used for arbitrary math. 

I am going to add the following PEM channels as DAF inputs subsequently, in a similar 2 input fashon.

SEIS_GUR1_X_OUT
SEIS_GUR1_Y_OUT
SEIS_GUR1_Z_OUT
SEIS_GUR2_X_OUT
SEIS_GUR2_Y_OUT
SEIS_GUR2_Z_OUT
SEIS_STS_1_X_OUT
SEIS_STS_1_Y_OUT
SEIS_STS_1_Z_OUT
ACC_MC1_X_OUT 
ACC_MC1_Y_OUT
ACC_MC1_Z_OUT
ACC_MC2_X_OUT
ACC_MC2_Y_OUT
ACC_MC2_Z_OUT

The DAFI block was reviewed by Rana yesterday. The following changes/improvements were suggested: (Updated on 20th July 2016 with tasks taat remain in red)

1) include all the various channels like PEM, LSC, ASC, SUS, SEI, etc. as the inputs. Currently the inputs are only the LSC.
2) include all the control signals.
3) create a very detailed diagram of the entire signal flow and plan tasks accordingly.
4) Enable cascading of various DSP processes.
5) Adjusting the gain of the AGC such that the amplitude of the output signal comes to about half the peak amplitude offered by the ADC. This will help taking advantage of the entire dynamic range of the ADC.
6) change the enable button styles from a text input based controller to a button controller.
7) Currently, disabling a particular signal terminates the signal. Instead, it should turn into a unity gain block on disabling.
8) Check if the Fibox does AC coupling or not. If not, add an AC coupling arrangement in the DAFI.
9) Check the nature of the ADC1 and ADC2 inputs to the DAFI. I checked them yesterday, and they are channels 25 and 26 of ADC0, which are empty.

[Jordan, gautam]

We did the following:

• Route the fiber from the control room to 1Y2.
• Plug fiber in to FiBox at either end, turned FiBoxes ON.
• Tested the optical connection by driving a 1Vpp 440 Hz sine wave from a function generator - Yehonathan hears it loud and clear in the control room.
• Tested that both CH1 and CH2 work - only CH1 is connected to the speakers in the control room at the moment.
• There is some cross-coupling between the channels - not sure if this is happening in the multi-mode fiber or in the electroncis, but I estimate the isolation to be >30dB.
• Connected CH8 and CH9 of DAC0 in the c1lsc expansion chassis to CH1 and CH2 respectively of the FiBox in 1Y2. 
• Restarted the c1daf model on c1lsc, came up smooth.
• Routed the POY11 error signal through the various matrices in c1daf, and we could 👂 the Y-arm cavity 🔐 😎 
• Channels are muted for now - I'll give this a whirl while doing the PRFPMI locking.

Wrote and tested a phase vocoder, with two of its applications:

1) Time scaling: This enables change of time duration without affecting the pitch.

2) Frequency warping: This changes the pitch of the sound without affecting the time duration.

1 & 2 tested offline with cavity transmission signal. 1) gives speedup of 2, and 2 gives frequency warping (pitch lowering by a factor of 2)

codes uploaded on github repo

Tried to implement AGC on FE. Had some trouble bringing the code into the correct form. It looks okay now. However, this agc code as well as idenntity code (input = output) doesnt seem to build on the c1lsc FE. Have not tried too many debugging steps yet, will come and check the problem tomorrow. 

-Varun

Summary: I am implementing digital audio filtering on various interferometer signals in order to listen to the processed audio which will help in characterizing and noise reduction in the interferometer. Following is an implementation of an Automatic Gain control (AGC) block on an LSC input signal.

Details of AGC: Currently, the AGC code implemented on FE takes input to fill a frame, then calculates the power in each frame and gives an appropriate gain to it, so that the new power content is to the required level. It is then written to the output, frame by frame. The frame is currently a rectangular window. The frame length and hop size can be adjusted. Current values are as follows:

frame length is 512 samples

hop length is 128 samples.

The input and output are delayed by 1 frame.

Details of testing: Attachment 1 shows a simulink diagram of the DAF system. Eric made this and I modified it later on. Testing was done using signal from the "LSC1" channel. Attachments 2 and 3 show aquired input and output of the AGC respectively. Gain of the preamp of the LSC input signal was varied over a total time span of 200 s. Each gain value was kept for a duration of about 20 seconds. The varying power levels can be seen in the input plot.

The output shows a uniform power level throughout.

Attached is a diagram, showing the entire (planned) signal flow of the DAF model. Some thoughts on the implementation after discussion with eric:

1) Since the LSC control signals and ASC signals are running on the c1lsc FE at the same rate as DAFI (16kHz), it would be wise to start from these.

   Current implementation: has a matrix at the end of the LSC PD signals, which selects one of the PD signals and outputs it to the DAFI via IPC communication.

    Proposed Changes: Add another matrix at the end of the LSC PD signals, to give to the second stereo output. Similarly, add two matrices each at the end of the LSC control signals and     the ASC signals. Each matrix must select one of the signals and output it to the DAF via IPC.

2) The PEM running on the c1sus FE system will have to be brought to DAFI in a similar fashon. However, since c1sus runs at 2kHz, there is a possibility of imaging while the signal is    transfered to the DAFI. This could be taken care of by an anti imaging filter, or inserting zeros between two samples coming at to the 16 kHz system from the 2kHz system and then low-passing it to remove the aliased parts. (similar to upsampling)

3) For the SUS control signals, input can be given from a matrix prepared for each optic seperately.

The code for frequency warping contained a "printf()" command, which had caused the system to crash in one another instance (refer elog 12320) . Hence, I tried running the code tody by removing this line. Unfortunately, this did not work. the model still crashed. Attached is the screenshot of the FE status.

Summary: I am trying to implement frequency warping/pitch shifting on the real time FE. Here is a description long overdue:

Description: The overall idea is as follows:

The DFT of a frame   is given by . A matrix W containing all for k, n = 1, 2, ..., m can be calculated and predefined in the code. The input arrival rate is 16384 Hz, i.e. once in every 60 $\mu$s time window. Hence, the fourier coefficients can be updated cumulatively in each cycle using the current value of the input, previous value of the fourier coefficient and the components of the W matrix. This will distribute the computational load of the FFT into all the time windows. Similar operations can be carried out for the inverse STFT.

I have written and run a pseudo-real time code on my CPU. The following is the essence:
 Let the frame-length be M, and the intended scale factor of the frequency warping be 'r'. The frame overlap is 50%. At each clock cycle, the following tasks are performed:  (1 to 3 are routine tasks performed at every clock cycle, 4 is a special task performed only when a frame is filled.)
 1) Take input and apply hanning window to it.
 2) Cumulate for every k using the value of x_i[n] (the input) at that particular instant. Also start to cumulate X_{i+1}[k], which will be later transfered to X_i[k].
 3) Because of 4), we now have 'r+1' filled frames corresponding to output fft. Now take the ifft using two consecutive frames corresponding to only two time series points. The computations required for this task are the same as the computations required for calculation of the fourier coefficients iteratively, since the entire time series ifft is not computed.
 4) Do these special tasks after each frame gets filled:
      At this point, the ffts of the current frame and a previous frame is ready. Let us call them X1 and X2.
      Calculate phase difference between the two.
      Calculate all the interpolated |Y_i| in between these two frames depending upon the scale factor.
      Assign phase of X1 to first Y frame and assign increasing phase to all the other Y frames.
      and also do all the usual non-special tasks.

This code takes about 9-10 microseconds for a cycle with special tasks, and 5-6 microseconds for a cycle with routine tasks on my laptop (brought down from 100 microseconds peak time in the earlier offline implementation due to elemination of explicit dft and reduction in fft size), for a frame size of 32 samples. However, when fed into the c1lsc FE, it crashes, as it has done once again today evening, in the same fashon as yesterday. There could be 2 possible reasons:

1) Size of the array containing the matrix elements is too large for the FE memory,

2) the computations are taking up more than 60 microseconds.

Since there are already a few codes with similar array sizes, I am more inclined to think that 2) is more likely.

Another problem that I am anticipating is that for a 32 point dft and a sampling rate of 16kHz, the frequency resolution achieved is about 500 Hz, which is not sufficient if we need to represent seismic signals. The only way I can think of, for representing such signals with a small number of fft points, is to reduce the effective sampling rate, i.e. do DSP on inputs at a much lower rate than 16kHz (say 1kHz, which will give a resolution of ~30 Hz, or 2kHz giving a resolution of ~60Hz). Another advantage of this method is that it frees up more clock cycles for computation, thus the computational load can be further distributed.  The problem in this implementation is that it will increase the delays.