40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 8 of 337 Not logged in
ID Date Author Type Category Subject
15116   Fri Jan 10 19:48:46 2020 yehonathanUpdatePSLAssembly underway for c1psl upgrade

{Yehonathan, Jon}

I finished pre-wiring the PSL chassis. I mounted the Acromags on the DIN rails and labeled them. I checked that they are powered up with the right voltage +24V and that the LEDs behave as expected.

15118   Mon Jan 13 16:05:18 2020 yehonathanUpdatePSLAssembly underway for c1psl upgrade

{Yehonathan, Jon}

I configured the Acromag channels according to the Slow Controls Wiki page.

We started testing the channels. Almost at the beginning we notice that the BIO channels are inverted. High voltage when 0. 0 Voltage when 1. We checked several things:

1. We checked the configuration of the BIOs in the windows machine but nothing pointed to the problem.

2. We isolated one of the BIOs from the DIN rail but the behavior persisted.

3. We checked that the voltages that go into the Acromags are correct.

The next step is to power up an isolated Acromag directly from the power supply. This will tell us if the problem is in the chassis or the EPICs DB.

15120   Tue Jan 14 17:16:43 2020 yehonathanUpdatePSLAssembly underway for c1psl upgrade

{Yehonathan, Jon}

I isolated a BIO Acromag completely from the chassis and powered it up. The inverted behavior persisted.

Turns out this is normal behavior for the XT1111 model.

For digital outputs, one should XT1121. XT1111 should be used for digital inputs.

Slow machines Wiki page was updated along with other pieces of information.

I replaced the XT1111 Acromags with XT1121 and did some rewiring since the XT1121 cannot get the excitation voltage from the DIN rail.

I added an XT1111 Acromag for the single digital input we have in this system.

15262   Tue Mar 10 14:30:16 2020 yehonathanUpdateSUS

ETMX was grossly misaligned.

I re-aligned it and the X arm now locks.

7:00PM with Koji

Both the alignment of the X and Y arms was recovered.

~>z avg 10 C1:LSC-TRX_OUT C1:LSC-TRY_OUT C1:LSC-TRX_OUT 0.9914034307003021 C1:LSC-TRY_OUT 0.9690877735614777

We are running ass for the X arm to recover the X arm alignment.

Meanwhile, i want to block the Y arm trans PD (Thorlabs). To do it, the PD<->QPD thresholds were changed from 5.0/3.0 to 0.5/0.3.

15263   Tue Mar 10 19:58:16 2020 yehonathanUpdateSUS

I returned the triggering threshold to normal values (5/3).

 Meanwhile, i want to block the Y arm trans PD (Thorlabs). To do it, the PD<->QPD thresholds were changed from 5.0/3.0 to 0.5/0.3.
15614   Tue Oct 6 07:37:20 2020 yehonathanUpdateWikiNew TIS measurements of 40m Optics

LiYuan has kindly done some Total Integrating Sphere (TIS) measurements on ITMU01 and ITMU02. A summary of the measurement is attached. I uploaded the measurements and some analysis script to nodus at /home/export/home/40m_TIS. I created a Wiki page for the measurements and linked to it from the core optics page.

These TIS measurements look very similar to the TIS of the LIGO optics. Further analysis shows that the scatter loss is 10+/-1.7 ppm for ITMU01 and 8.6+/-0.4 ppm for ITMU02.

In this calculation, a gaussian beam the same size bouncing off the 40m ITMs is assumed to scatter from the mirrors. The error is calculated by moving the beam around randomly with STD of 1mm.

In LiYuan's setup, TIS is measured for scattering angles between 1 and 75 degrees. If we go further and assume that the scatter is Lambertian we can extrapolate that the total loss is 10.9+/-1.9 ppm for ITMU01 and 9.2+/-0.5 ppm for ITMU02.

These measurements complete the loss budget nicely since with the 6ppm loss predicted from the phase maps, the total loss in the arm cavities would be 6+10+10=26ppm which is very close to the 28ppm loss that was measured after the arm cavity optics were cleaned.

15788   Tue Feb 2 17:09:17 2021 yehonathanUpdateBHDSOS assembly

I set up a working area on the table next to the south flow bench (see attachment). I also brought in a rolling table for some extra space.

I covered all the working surfaces with a foil from the big roll between 1x3 and 1x4.

I took the SOSs, SOS parts and the OSEMS from the MC2 table to the working area.

I cleaned some LN Allen keys with isopropanol and put them on the working table, please don't take them.

15816   Thu Feb 18 15:15:12 2021 yehonathanUpdateSUSOSEM testing for SOSs

I am setting up a testing rig for the OSEMs we recently obtained. I found the schematic for the OSEM assembly from which the pin assignment can be read.

I connected the OSEM's pin plate to a female DB15 on a breakout board. I find the pin assignment (attachment 1, sorry for the image quality) to be:

 1 PD Cathode 2 LED Anode 3 Coil end 4 PD Anode 5 LED Cathode 6 Coil Start

There are several things that need to be done for each OSEM.

1. Measuring inductance of the coils. I checked that the measurement wires don't add any measurable inductance.

2. Check that the PDs and LEDs are alive (e.g. check forward voltage drop with fluke)

3. Energize the LED and PD.

4. Check PD DC level. For this, I might need the satellite box amplifier.

5. Check LED spot position on the PD.

6. Re-engrave OSEM S/N if needed.

 OSEM # Coil Inductance (mH) Coil resistance (ohm) PD forward voltage (V) LED forward voltage (V) 280 2.87 14.1 0.63 1.1

I still need to figure a sensible scheme for points 3-5.

15837   Wed Feb 24 10:09:16 2021 yehonathanUpdateSUSOSEM testing for SOSs

Yes, my phone camera mirrored the image. Sorry for the confusion.

 Quote: I can't obtain a consistent view between the existing drawings/photographs and your pin assignment. Please review the pin assignment again to check if yours is correct. Looking from the back side and the wires are going down, the left bottom pin is "Coil Start" and the upper right adjacent pin is "Coil End". (See attachment) So in your picture 1 should be the coil start and 4 should be the coil end, but they are not according to your table.

16062   Wed Apr 21 11:09:57 2021 yehonathanUpdatePSLLaser amplifier

I went to the TCS lab to take a look at the chillers lying around. I spotted two chillers:

1. Thermoflex1400 (attachment 1,2). Spec sheet.

2. Polyscience Recirculator 6000 series (attachment 3,4). Manual.

The Thermoflex has various communication ports. The Recirculator doesn't have any communication ports, but it is connected to a flow meter with what seems to be an electronic readout (attachment 5). Manual.

Both chillers have similar capacity ~ 4 gallons/minute. Thermoflex has 2 times more reservoir capacity than the Recirculator.

None of them seem to be Bechkoff-ready.

I guess we can have interlock code handling mixed signals Beckhoff+Non beckhoffs?

16253   Wed Jul 21 18:08:35 2021 yehonathanUpdateLoss MeasurementLoss measurement

{Gautam, Yehonathan, Anchal, Paco}

We prepared for the loss measurement using DC reflection method. We did the following changes:

1. REFL55_Q was disconnected and replaced with MC_T cable coming from the PD on the MC2 table. The cable has a red tag on it. Consequently we lost the AS beam. We realigned the optics and regained arm locks. The spot on the AS QPD had to be corrected.

2. We tried using AS55 as the PD for the DC measurement but we got ratios of ~ 0.97 which implies losses of more than 100 ppm. We decided to go with the traditional PD520 used for these measurements in the past.

3. We placed the PD520 used for loss measurements in front of the AS55 PD and optimized its position.

4. AS110 cable was disconnected from the PD and connected to PD520 to be used as the loss measurement cable.

5. In 1Y2 rack, AS110 PD cable was disconnected, REFL55_I was disconnected and AS110 cable was connected to REFL55_I channel.

So for the test, the MC transmission was measured at REFL55_Q and the AS DC was measured at REFL55_I.

We used the scripts/lossmap_scripts/armLoss/measArmLoss.py script. Note that this script assumes that you begin with the arm locked.

We are leaving the IFO in the configuration described above overnight and we plan to measure the XARM loss early AM. After which we shall restore the affected electrical and optical paths.

We ran the /scripts/lossmap_scripts/armLoss/measureArmLoss.py script in pianosa with 25 repetitions and a 30 s "duty cycle" (wait time) for the Y arm. Preliminary results give an estimated individual arm loss of ~ 30 ppm (on both X/Y arms) but we will provide a better estimate with this measurement.

16371   Fri Oct 1 14:25:27 2021 yehonathanSummarySUSPRM and BS Angular Actuation transfer function magnitude measurements

{Paco, Yehonathan, Hang}

We measured the sensing PRMI sensing matrix. Attachment 1 shows the results, the magnitude of the response is not calibrated. The orthogonality between PRCL and MICH is still bad (see previous measurement for reference).

Hang suggested that since MICH actuation with BS and PRM is not trivial (0.5*BS - 0.34*PRM) and since PRCL is so sensitive to PRM movement there might be a leakage to PRCL when we are actuating on MICH. So there may be a room to tune the PRM coefficient in the MICH output matrix.

Attachment 2 shows the sensing matrix after we changed the MICH->PRM coefficient in the OSC output matrix to -0.1.

It seems like it made things a little bit better but not much and also there is a huge uncertainty in the MICH sensing.

16779   Thu Apr 14 11:52:57 2022 yehonathanSummaryBHDPart IIa of BHR upgrade - POY11 debugging

{JC, Paco, Yehonathan, Ian}

POY lens was moved to infront of the POY steering mirror to make the POU beam focused on the POY11 RFPD. We measured the DC output with an oscilloscope and optimized it with the steering mirrors. We get ~ 16.5mV.

The new lens position blocked the BS OpLev ingoing beam, so we repositioned the OpLev mirrors to make the beam path not hit the lens.

We went to the control room to observe the PDH signal. We observed a series of PDF osscillation and then the signal died infront of our eyes! There is just noise.

We go and check the +/-15V powering the RFPD and we find that the V- is ~ 14V which is good but the V+ was ~ 2.7V which is not.

We went to the PD interface and measure the POY11 output oltages using a breakout board and got the same result.

The PD interface was taken out for inspection. All the OP27 on channel 3 were replaced with new ICs (without need turns out)...

The PD interface card turned out to be OK. What happened is that one of the Kepcos in the RF rack died because its fan crumbled as seen in Attachment #2 (could this be the source of burning smell?). In response, the rack was drawing from the other Kepco (connected in parallel) way too much current  (4A) and the current limiter dropped its voltage from 15V to 2.7V.

The Kepco pair was removed and replaced with a single Sorensen. The POY PDH signal was restored (see attachment).

16799   Thu Apr 21 18:18:42 2022 yehonathanUpdateBHDPOX Alignment

{Yehonathan, Paco}

BS, ITMX and ETMX were aligned to get flashing in the X arm.

I aligned the POX beam on the ITMX table using a mixture of the old POP and POX optics. The beam was stirred to the POX11 RFPD. We measure the DC power using a scope but we see nothing. We went and saw that the POX11 cable was not connected to RF rack so we connected it along with some other RFPD cables.

We return but there is still no DC. We ndscope C1:LSC-POX11_I_ERR_DQ C1:LSC-POX11_Q_ERR_DQ and maximize the signal (attachment). The readout is very weak though. It should be as strong as POY which we already observed to have good SNR.

We also noticed that the one of the beam dumps for the POX RFPD is not glued and easily falls down.

14193   Wed Sep 5 10:59:23 2018 wgautamUpdateCDSCDS status update

Rolf came by today morning. For now, we've restarted the FE machine and the expansion chassis (note that the correct order in which to do this is: turn off computer--->turn off expansion chassis--->turn on expansion chassis--->turn on computer). The debugging measures Rolf suggested are (i) to replace the old generation ADC card in the expansion chassis which has a red indicator light always on and (ii) to replace the PCIe fiber (2010 make) running from the c1lsc front-end machine in 1X6 to the expansion chassis in 1Y3, as the manufacturer has suggested that pre-2012 versions of the fiber are prone to failure. We will do these opportunistically and see if there is any improvement in the situation.

Another tip from Rolf: if the c1lsc FE is responsive but the models have crashed, then doing sudo reboot by ssh-ing into c1lsc should suffice* (i.e. it shouldn't take down the models on the other vertex FEs, although if the FE is unresponsive and you hard reboot it, this may still be a problem). I'll modify I've modified the c1lsc reboot script accordingly.

* Seems like this can still lead to the other vertex FEs crashing, so I'm leaving the reboot script as is (so all vertex machines are softly rebooted when c1lsc models crash).

 Quote: c1lsc crashed again. I've contacted Rolf/JHanks for help since I'm out of ideas on what can be done to fix this problem.
6   Sat Oct 20 11:54:13 2007 waldmanOtherOMCOMC and OMC-SUS work
[Rich, Chub, Pinkesh, Chris, Sam]

Friday the 18th was a busy day in OMC land. Both DCPDs were mounted to the glass breadboard and the OMC-SUS structure was rebuilt to the point that an aluminum dummy mass is hanging, unbalanced. The OSEMs have not be put on the table cloth yet, but everything is hanging free. As for the DCPDs, if you recall one beam is 3mm off center from the DCPD tombstone. Fortunately, one DCPD is nearly 3mm offcenter from the case in the right direction, so the errors nearly cancel. The DCPD is too high, so the beam isn't quite centered, but they're close. We'll get photos of the beam positions in someday. Also, the DC gain between the two PDs is, at first glance, different by 15%. DCPD1, the one seen in transmission has 315 mV of signal while DCPD2 has 280 mV. Not sure why, could be because of beam alignment or tolerances in the Preamp or the angle incident on the diode or the QE of the diodes. The glass cans have *not* been removed.
14   Thu Oct 25 17:52:45 2007 waldmanOtherOMCOMCs with QPDs
[Rich, Chub, Pinkesh, Sam]

Yesterday we got the QPD, OTAS, and PZT cabling harness integrated with the OMC. We found a few things out, not all of them good. The QPDs went on no problem and could be fairly well aligned by hand. We "aligned" them by looking at all four channels of the QPD on the scope and seeing that there is signal. Since the beam is omega = 0.5 mm, this is a reasonable adjustment. We then connected the OTAS connector to the OTAS and found that the heater on the OTAS was bonded on about 30 degrees rotated from its intended position. This rotated the connector into the beam and caused a visible amount of scattering. This wasn't really a disaster until I removed the connector from the heater and broke the heater off of the aluminum parts of the OTAS. Two steps backwards, one step forward. After the OMC, OMC-SUS integration test we will re-bond the heater to the aluminum using VacSeal. In the meantime, the OMC has been moved to Bridge 056 for integration with the OMC-SUS. More on that as we make progress.
16   Thu Oct 25 23:35:36 2007 waldmanOtherOMCHang the OMC!
[Pinkesh, Sam]

We tried, convicted and hung the OMC today. The OMC was found guilty of being overweight, and unsymmetrically balanced. The unsymmetry was kind of expected and was corrected with a hefty stack of counterweights positioned over the counterweighting holes. The stacks will be measured at some future date and correctly sized objects machined. The overweightness showed up when the level hanging breadboard was about 5 mm low. This showed up in the board height above the table as well as the OSEM flag positions within their holes. The problem was remedied with a liposuction of the intermediate mass. We removed both small vertical cylinder weights that Chris added, and then we removed the heavy steel transverse weight that can be used to adjust the tip around the long axis (I forgot what its called).

The top of the breadboard ended up about 154 mm off the table. The breadboard is 39 mm thick, and the optics are centered (30 - 12.7) = 17.3 mm below the surface for a as hanging beams height of 154 -39 - 17.3 = 97.7 mm or about an 0.150 inches lower than we were aiming for. Can I get a refund?

We screwed up in multiple ways:
• The slotted disks that capture the wires do not have the alignment bore used to center the wire in the hole
• We didn't correctly route the far field QPD cable so it runs funny
• We didn't have a tool which could be used to get two of the DCPD preamp box mounting screws (which are M3's chub!)
• We don't have the cable clamps to tie off the electrical cables to the intermediate mass
• We don't have any of the cabling from the OMC-SUS top to the rack so we can't test anything
• We haven't uploaded pretty pictures for all to see

We left the OMC partially suspended by the OMC-SUS and partly resting on the installation lab jacks which are currently acting as EQ stops. After we fix the cabling we will more permanently hang it. PS, It looks like the REFL beam extraction will be tricky so we need to get on that....
19   Fri Oct 26 17:34:43 2007 waldmanOtherOMCOMC + earthquake stops

[Chub, chris, Pinkesh, Sam]

Last night we hugn the OMC for the first time and came up with a bunch of pictures and some problems. Today we address some of the problems and, of course, make new problems. We replaced the flat slotted disks with the fitted slotted disks that are made to fit into the counterbore of the breadboard. This changed the balance slightly and required a more symmetric distribution of mass. It probably did not change the total mass very much. We did find that the amount of cable hanging down strongly affected the breadboard balance and may also have contributed to the changing balance.

We also attached earthquake stops and ran into a few problems:

• The bottom plate of the EQ stops is too thick so that it bumps into the tombstones
• The vertical member on the "waist" EQ stops is too close to the breadboard, possibly interfering with the REFL beam
• The "waist" EQ stops are made from a thin plate that doesn't have enough thickness to mount helicoils in
• Helicoil weren't loaded in the correct bottom EQ stops
• The DCPD cable loops over the end EQ stop looking nasty but not actually making contact

However, with a little bit of jimmying, the EQ stops are arrayed at all points within a few mm of the breadboard. Meanwhile, Chub has cabled up all the satellite modules and DCPD modules and Pinkesh is working on getting data into the digital system so we can start playing games. Tonight, I intend to mount a laser in Rana's lab and fiber couple a beam into the 056 room so we can start testing the suspended OMC.
20   Fri Oct 26 21:48:40 2007 waldmanConfigurationOMCFiber to 056
I set up a 700 mW NPRO in Rana's lab and launched it onto a 50m fiber. I got a few mW onto the fiber, enough to see with a card before disabling the laser. The fiber now runs along the hallway and terminates in rm 056. Its taped down everywhere someone might trip on it, but don't go out of your way to trip on it or pull on it because you are curious. Tomorrow I will co-run a BNC cable and attenuate the NPRO output so it can only send a few mW and so be laser safe. Then we can try to develop a procedure to align the beam to a suspended OMC and lock our suspended cavity goodness.

Notes to self: items needed from the 40m
• ND10 and ND20 neutral density filter
• EOM and mount set for 4 inch beam height
• Post for fiber launch to get to 4 inch
• Mode matching lens at 4in
• 3x steering mirror at 4in
• RF photodiode at 4in
• Post for camera to 4in
• Light sheild for camera
• Long BNC cable
Some of these exist at 056 already
21   Sat Oct 27 19:00:44 2007 waldmanConfigurationOMCHanging, locked OMC with REFL extracted.
I got the OMC locked to the fiber output today. It was much more difficult than I expected and I spent about 30 minutes or so flailing before stopping to think. The basic problem is that the initial alignment is a search in 4-dimensional space and there is naturally only one signal, the reflected DC level, to guide the alignment. I tried to eyeball the alignment using the IR card and "centering" the beams on mirrors, but I couldn't get close enough to get any light through. I also tried to put a camera on the high reflector transmission, but with 1.5 mW incident on the cavity, there is only 1.5 microwatts leaking through in the best case scenario, and much, much less during alignment.

I resolved the problem by placing a high reflector on a 3.5 inch tall fixed mount and picking off the OMC transmitted beam before it reaches the DC diodes. I took the pickoff beam to a camera. The alignment still sucked because even though the beam cleanly transmitted the output coupler, it wasn't anywhere close to getting through the OTAS. To resolve this problem, I visually looked through the back of M2 at M1 and used the IR card to align the beam to the centers of each mirror. That was close enough to get me fringes and align the camera. With the camera aligned, the rest was very easy.

I restored the PDH setup we know and love from the construction days and locked the laser to the OMC with no difficulty. The laser is in Rana's lab so I send the +/- 10V control signal from the SR560 down a cable to 058E where it goes into the Battery+resistor box, the Throlabs HV amplifier, and finally the FAST channel of the NPRO. BTW, a simple experiment sows that about 35 +/- 3 V are required to get an FSR out of the NPRO, hence the Thorlabs HV. The EOM, mixer, splitter, etc is on the edge of the table.

With this specific OMC alignment, ie. the particular sitting on EQ stops, it looks like all of the ghost beams have a good chance of coming clear. I can fit a 2 inch optic in a fixed mount in between the end of the breadboard and the leg of the support structure. A picture might or might not be included someday. One of the ghost beams craters directly into the EQ stop vertical member. The other ghost barely misses M2 on its way down the length of the board. In its current configuration, the many REFL beam misses the leg by about 1.5 inches.
25   Mon Oct 29 11:07:22 2007 waldmanSoftware InstallationOMCSoftware install on OMS
[Alex, Sam]

We spent a little time this morning working on OMS and getting things restarted. A few changes were made. 1) We put openmotif on OMS so that the burtrb doesn't throw that crappy libXm any more. 2) We upgraded OMS to a 32 kHz sampling rate from 2 kHz. All the filters will have to be changed. We also added a PDH filter path to maybe feedback PDH signals cuz that will be cool. Maybe someday I will write up the very cool channel adding procedure.
26   Mon Oct 29 12:20:15 2007 waldmanConfigurationOMCChanged OMS filters
I changed the OMS configuration so that some of the OMC-SUS LED channels go to a breakout box so that we can input the PDH error signal. After lunch, we will try to lock the cavity with a PDH error signal and digital filters. Then its on to dither locked stuff. Note that this LED business will have to be changed back some day. For now, it should be extremely visible because there are dangling cables and a hack job interface lying around.
27   Mon Oct 29 23:10:05 2007 waldmanConfigurationOMCLost in DAQspace
[Pinkesh, Sam]

In setting up a Digital based control of the hanging OMC, we naively connect the Anti-Imaging filter output to an Anti-Aliasing input. This led to no end of hell. For one thing, we found the 10 kHz 3rd order butterworth at 10 kHz, where it should be based on the install hardware. One wonders in passing whether we want a 10 kHz butter instead of a 15 kHz something else, but I leave that for a later discussion. Much more bothersome is a linear phase shift between output and input that looks like ~180 microseconds. It screams "What the hell am I!?" and none of us could scream back at it with an answer. I believe this will require the Wilson House Ghost Busters to fully remedy on the morrow.
37   Wed Oct 31 09:45:28 2007 waldmanOtherOMCResolution to DAQland saga
[Jay, Sam]

We did a rough accounting for the linear delay this morning and it comes out more or less correct. The 10 kHz 3rd order butterworth AA/AI filter gives ~90 degrees of phase at 6 kHz, or 42 microseconds. Taken together, the two AA and AI filters are worth 80 microseconds. The 1.5 sample digital delay is worth 1.5/32768 = 45 microseconds. The remaining 160 - 125 = 35 microseconds is most likely taken up by the 64 kHz to 32 kHz decimation routine, assuming this isn't accounted for already in the 1.5 sample digital delay.

It remains to be seen whether this phase delay is good enough to lock the laser to the OMC cavity
42   Wed Oct 31 23:55:17 2007 waldmanOtherOMCQPD tests
The 4 QPDs for the OMC have been installed in the 056 at the test setup. All 4 QPDs work and have medm screens located under C2TPT. The breadboard mounted QPDs are not very well centered so their signal is somewhat crappy. But all 4 QPDs definitely see plenty of light. I include light and dark spectra below. QPDs 1-2 are table-mounted and QPD 2 is labeled with a bit of blue tape. QDPs 3-4 are mounted on the OMC. QPD3 is the near field detector and QPD4 is the far field. In other words, QPD3 is closest to the input coupler and QPD4 is farthest.

Included below are some spectra of the QPDs with and without light. For QPDs 1 & 2, the light source is just room lights, while 3&4 have the laser in the nominal OMC configuration with a few mWs as source. The noise at 100 Hz is about 100 microvolts / rtHz. If I recall correctly, the QPDs have 5 kOhm transimpedance (right Rich?) so this is 20 nanoamps / rtHz of current noise at the QPD.
43   Thu Nov 1 01:28:04 2007 waldmanOtherOMCFirst digital lock of OMC
[Pinkesh, Sam]

We locked a fiber based NPRO to the suspended OMC tonight using the TPT digital control system. To control the laser frequency, we took the PZT AI output and ran it on a BNC cable down the hallway to the Thorlabs HV box. The Thorlabs is a singled ended unit so we connected the AI positive terminal only and grounded the BNC to the AI shield. We could get a -6 to 1.5 V throw in this method which fed into the 10 k resisotr + 9 V battery at the input of the HV box. The HV out ran to the NPRO PZT fast input.

We derived our error signal from a PDA255 in reflection with a 29.5 MHz PDH lock. The signal feeds into one of the unused Tip/Tilt AA channels and is passed to the PZT LSC drive through the TPT_PDH1 filter bank. In the PZT_LSC filter we put a single pole at 1 Hz which, together with the phase we mentioned the other night (180 degrees at 3 kHz) should allow a 1 kHz-ish loop. In practice, as shown below, we got a 650 Hz UGF with 45 degrees of phase margin and about 6 dB of gain margin.

The Lower figure shows the error point spectrum with 3 settings. REF0 in blue shows lots of gain peaking at 1.5 kHz-ish, just where its expected - the gain was -40. The REF1 has gain of -20 and shows no gain peaking. The current trace in red shows some gain peaking cuz the alignment is better but it also has included a 1^2:20^2 boost which totally crushes the low frequency noise. We should do a better loop sweep after getting the alignment right so we can see how much boost it will really take.

Just for fun, we are leaving it locked overnight and recording the PZT_LSC data for posterity.
58   Fri Nov 2 12:18:47 2007 waldmanSummaryOMCLocked OMC with DCPD
[Rich, Sam]

We locked the OMC and look at the signal on the DCPD. Plots included.
59   Sat Nov 3 16:20:43 2007 waldmanSummaryOMCA good day's work

I followed up yesterday's test of the PZT with a whole mess of characterizations of the PZT control and finished the day by locking the OMC with a PZT dither lock and a 600 Hz loop. I haven't analyzed any of the data yet, so its not calibrated in physical units and etc. etc. etc. Since a lot of the sweeps below are of a "drive the PZT, look at the PDH signal" nature, a proper analysis will require taking out the loop and calibrating the signals, which alas, I haven't done. Nonetheless, I include all the plots because they are pretty. The files included below are:

• DitherLock_sweep: Sweep of the IN2/IN1 for the dither lock error point showing 600 Hz UGF
• HiResPZTDither_sweep: Sweep of the PZT dither input compared to the PDH error signal. I restarted the front end before the sweep was finished accounting for the blip.
• HiResPZTDither_sweep2: Finish of the PZT dither sweep

More will be posted later.
60   Sun Nov 4 23:22:50 2007 waldmanUpdateOMCOMC PZT and driver response functions
I wrote a big long elog and then my browser hung up, so you get a less detailed entry. I used Pinkesh's calibration of the PZT (0.9 V/nm) to calibrate the PDH error signal, then took the following data on the PZT and PZT driver response functions.:

• FIgure 1: PZT dither path. Most of the features in this plot are understood: There is a 2kHz high pass filter in the PZT drive which is otherwise flat. The resonance features above 5 kHz are believed to be the tombstones. I don't understand the extra motion from 1-2 kHz.
• Figure 2: PZT dither path zoom in. Since I want to dither the PZT to get an error signal, it helps to know where to dither. The ADC Anti-aliasing filter is a 3rd order butterworth at 10 kHz, so I looked for nice flat places below 10 KHz and settled on 8 kHz as relatively harmless.
• Figure 3: PZT LSC path. This path has got a 1^2:10^2 de-whitening stage in the hardware which hasn't been digitally compensated for. You can see its effect between 10 and 40 Hz. The LSC path also has a 160 Hz low path which is visible causing a 1/f between 200 and 500 Hz. I have no idea what the 1 kHz resonant feature is, though I am inclined to point to the PDH loop since that is pretty close to the UGF and there is much gain peaking at that frequency.
63   Mon Nov 5 14:44:39 2007 waldmanUpdateOMCPZT response functions and De-whitening
The PZT has two control paths: a DC coupled path with gain of 20, range of 0 to 300 V, and a pair of 1:10 whitening filters, and an AC path capacitively coupled to the PZT via a 0.1 uF cap through a 2nd order, 2 kHz high pass filter. There are two monitors for the PZT, a DC monitor which sniffs the DC directly with a gain of 0.02 and one which sniffs the dither input with a gain of 10.

There are two plots included below. The first measures the transfer function of the AC monitor / AC drive. It shows the expected 2 kHz 2d order filter and an AC gain of 100 dB, which seems a bit high but may be because of a filter I am forgetting. The high frequency rolloff is the AA and AI filters kicking in which are 3rd order butters at 10 kHz.

The second plot is the DC path. The two traces show the transfer function of DC monitor / DC drive with and with an Anti-dewhitening filter engaged in the DC drive. I fit the antidewhite using a least squares routine in matlab constrained to match 2 poles, 2 zeros, and a delay to the measured complex filter response. The resulting filter is (1.21, 0.72) : (12.61, 8.67) and the delay was f_pi = 912 Hz. The delay is a bit lower than expected for the f_pi = 3 kHz delay of the AA, AI, decimate combination, but not totally unreasonable. Without the delay, the filter is (1.3, 0.7) : (8.2, 13.2) - basically the same - so I use the results of the fit with delay. As you can see, the response of the combined digital AntiDW, analog DW path is flat to +/- 0.3 dB and +/- 3 degrees of phase.

Note the -44 dB of DC mon / DC drive is because the DC mon is calibrated in PZT Volts so the TF is PZT Volts / DAC cts. To calculate this value: there are (20 DAC V / 65536 DAC cts)* ( 20 PZT V / 1 DAC V) = -44.2 dB. Perfect!

I measured the high frequency response of the loop DC monitor / DC drive to be flat.
79   Wed Nov 7 14:01:31 2007 waldmanOmnistructureOMCFrequency and Intensity noise
One of the biggest problems I had using the PZT to lock was excessive noise. I did a little noise hunting and found that the problem was the cable running from the rack to the laser fast input. As a reminder, the laser has a 4 MHz / volt fast input. We require about 300 MHz to go one FSR, so there is a Thorlabs HV box between at the NPRO fast input which takes 0-10 V -> 0-150 V. The 150 V HV range is worth about 600 MHz of NPRO frequency.

OLD SETUP: Single side of DAC differential (10 Vpp) -> 9V in series with 10 kOhm -> 10 kOhm input impedance of Thorlabs HV -> NPRO

We used the single side of the DAC differential because we didn't have a differential receiver. This turned out to be a bad idea because the cable picks up every 60 Hz harmonic known to man kind.

NEW SETUP: Digital conditioning -> DAC differential (digitally limited to 0 - 1 V) -> SR560 in A-B mode gain 10 (0 - 10 V output)-> Thorlabs HV -> NPRO.

This has almost no 60 Hz noise and works much, much better. Moral of the story, ALWAYS USE DIFFERENTIAL SIGNALS DIFFERENTIALLY !

Note that I may be saturating the SR560 with 10 V output, Its spec'd for 10 Vpp output with 1 VDC max input. I don't know whether or not it can push 10 V out....
86   Fri Nov 9 00:01:24 2007 waldmanOmnistructureOMCOMC mechanical resonances (Tap tap tappy tap)
[Pinkesh, Aidan, Sam]

We did a tap-tap-tappy-tap test of the OMC to try to find its resonances. We looked at some combination of the PDH error signal and the DCPD signal in a couple of different noise configurations. The data included below shows tapping of the major tombstone objects as well the breadboard. I don't see any strong evidence of resonances below the very sharp resonance at 1300 Hz (which I interpret as the diving board mode of the breadboard). If I get free, I 'll post some plots of the different breadboard resonances you can excite by tapping in different places.

(The "normalized" tapping response is abs(tap - reference)./reference.)
179   Fri Dec 7 11:33:24 2007 waldmanOmnistructureOMCPZT wiring
The 2 pin LEMO connector has got an unmarked pin and a pin marked by a white half-circle.
The unmarked pin is connected to the side of the PZT attached to the mirror.
The marked pin is connected to the side of the PZT attached to the tombstone.
206   Thu Dec 20 19:05:34 2007 waldmanHowToOMCHOWTO build front ends
For instance, to build the TPT front end code.

• go to /cvs/cds/advLIGO on the TPT machine
• do make clean-tpt tpt install-tpt
• do rm /cvs/cds/caltech/chans/daq/C2TPT.ini (this step is needed because the DAQ install code isn't quite right at the time of this writing.
• do make install-daq-tpt
• run starttpt to restart the tpt computer.

Enjoy.
207   Thu Dec 20 19:10:03 2007 waldmanUpdateOMCStressful reattachment of heater
Photos may follow eventually, but for now here's the rundown. I scraped the heater clean of the thermal epoxy using a clean razor blade. Then I stuffed a small piece of lint free cloth in the OTAS bore and wrapped the OMC in tin foil. With a vacuum sucking directly from the face of the OTAS, I gently scraped the glue off the OTAS aluminum. I wiped both the OTAS and the heater down with an isoproponal soaked lint-free cloth. I put a thin sheen of VacSeal on the face of the heater, wiping off the excess from the edges with a cloth. Then I clamped the heater to the OTAS using 2" c-clamps from the tombstone back to the heater front, making sure the alignment of the OTAS was correct (connector on the absolute bottom, concentric with the OTAS outer diameter). I added a second clamp, then beaded the outside of the joint with a little bit extra VacSeal, just for kicks. I'll leave it covered at least overnight, and maybe for a day or two.

sam
12169   Fri Jun 10 18:16:59 2016 varunUpdatePSLRealignment of pre mode cleaner

The mode cleaner was misaligned probably due to the earthquake (the drop in the MC transmitted value slightly after utc 7:38:52 as seen in the second plot). The plots show PMC transmitted and MC sum signals from 10th june 07:10:08 UTC over a duration of 17 hrs. The PMC was realigned at about 4-4:15 pm today by rana. This can be seen in the first plot.

12173   Mon Jun 13 20:01:30 2016 varunUpdateCDSDAFI GUI update

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

12180   Tue Jun 14 20:10:19 2016 varunUpdateCDSDAFI GUI update

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.

12185   Wed Jun 15 22:12:55 2016 varunUpdateCDSDAFI update: stereo output

I wish to have stereo audio output for the DAF module. Hence, there needs to be a second output from the DAF. I added this second output to the model. Following are the details:

FiBox: It consists of two analog inputs which are digitized and multiplexed and transmitted optically. (only 1 fiber is needed due to multiplexing). Attachment 1 shows the fibox with its 2 analog inputs (one of which, is connected), and 1 fiber output. The output of the DAF goes to the FiBox. Until today, the Fibox recieved only 1 analog input. This analog signal comes from the DAC-8 (count starting from 0), which is located at "CH 1 OUT" SMA output in the "MONITORS" bin on the racks (attachment 2).

I have added another output channel to the DAF model both in software and in hardware. The DAF now also uses DAC-9 analog output which goes to the second analog input of the FiBox. The DAC-9 output is located at "CH 2 OUT" SMA output in the "MONITORS" bin on the racks (attachment 4).

After making the changes, the Fibox is shown in attacment 3.

Testing: The LSC input on passing through the DAF block is given through two different DAC outputs, to the same Fibox channel (one after the other), and the output is heard. More concrete testing will be done tomorrow. It will be as follows:

1) Currently, I need to search for a suitable cable that would connect the second channel of the output fibox to the audio mixer. After doing this, end to end testing of both channels will be done.

2) I could not access the AWG, probably because the DAQ was offline today afternoon. Using a signal from the AWG will give a more concrete testing of the stereo output.

3) After this, I will separate the two channels of the stereo completely (currectly they are seperated only at the DAF output stage)

4) I also will edit the medm gui appropriately.

 Quote: 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.

12207   Tue Jun 21 11:26:42 2016 varunFrogsCDSmedm command not working

"medm: command not found" error when run through command line both in pianosa and rossa in both editing and execution modes. It however gets executed and edited through the sitemap button. Don't know the source of the problem. Gautam did check the .bashrc file. aliases for SITEMAP and m40m are intact in the .bashrc file.

12211   Wed Jun 22 10:15:45 2016 varunUpdateCDSDAFI update: stereo output

I have updated the DAFI with the following changes:

1) Separated both the channels of stereo output completely, as well as in the GUI.

2) Added text monitors for the inputs and outputs.

The stereo output is now ready except for a cable going from the second channel of the output fibox to the audio mixer.

Attached is the main DAF_OVERVIEW screen and its link button from the LSC screen labelled "DAFI"

Quote:

I wish to have stereo audio output for the DAF module. Hence, there needs to be a second output from the DAF. I added this second output to the model. Following are the details:

FiBox: It consists of two analog inputs which are digitized and multiplexed and transmitted optically. (only 1 fiber is needed due to multiplexing). Attachment 1 shows the fibox with its 2 analog inputs (one of which, is connected), and 1 fiber output. The output of the DAF goes to the FiBox. Until today, the Fibox recieved only 1 analog input. This analog signal comes from the DAC-8 (count starting from 0), which is located at "CH 1 OUT" SMA output in the "MONITORS" bin on the racks (attachment 2).

I have added another output channel to the DAF model both in software and in hardware. The DAF now also uses DAC-9 analog output which goes to the second analog input of the FiBox. The DAC-9 output is located at "CH 2 OUT" SMA output in the "MONITORS" bin on the racks (attachment 4).

After making the changes, the Fibox is shown in attacment 3.

Testing: The LSC input on passing through the DAF block is given through two different DAC outputs, to the same Fibox channel (one after the other), and the output is heard. More concrete testing will be done tomorrow. It will be as follows:

1) Currently, I need to search for a suitable cable that would connect the second channel of the output fibox to the audio mixer. After doing this, end to end testing of both channels will be done.

2) I could not access the AWG, probably because the DAQ was offline today afternoon. Using a signal from the AWG will give a more concrete testing of the stereo output.

3) After this, I will separate the two channels of the stereo completely (currectly they are seperated only at the DAF output stage)

4) I also will edit the medm gui appropriately.

 Quote: 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.

12215   Mon Jun 27 15:12:09 2016 varunUpdateCDSDAFI update: stereo output

Using an RC to BNC connector from the inner drawer, I have added a second output cable going from the output Fibox in the control room to the audio mixer.

Quote:

I have updated the DAFI with the following changes:

1) Separated both the channels of stereo output completely, as well as in the GUI.

2) Added text monitors for the inputs and outputs.

The stereo output is now ready except for a cable going from the second channel of the output fibox to the audio mixer.

Attached is the main DAF_OVERVIEW screen and its link button from the LSC screen labelled "DAFI"

Quote:

I wish to have stereo audio output for the DAF module. Hence, there needs to be a second output from the DAF. I added this second output to the model. Following are the details:

FiBox: It consists of two analog inputs which are digitized and multiplexed and transmitted optically. (only 1 fiber is needed due to multiplexing). Attachment 1 shows the fibox with its 2 analog inputs (one of which, is connected), and 1 fiber output. The output of the DAF goes to the FiBox. Until today, the Fibox recieved only 1 analog input. This analog signal comes from the DAC-8 (count starting from 0), which is located at "CH 1 OUT" SMA output in the "MONITORS" bin on the racks (attachment 2).

I have added another output channel to the DAF model both in software and in hardware. The DAF now also uses DAC-9 analog output which goes to the second analog input of the FiBox. The DAC-9 output is located at "CH 2 OUT" SMA output in the "MONITORS" bin on the racks (attachment 4).

After making the changes, the Fibox is shown in attacment 3.

Testing: The LSC input on passing through the DAF block is given through two different DAC outputs, to the same Fibox channel (one after the other), and the output is heard. More concrete testing will be done tomorrow. It will be as follows:

1) Currently, I need to search for a suitable cable that would connect the second channel of the output fibox to the audio mixer. After doing this, end to end testing of both channels will be done.

2) I could not access the AWG, probably because the DAQ was offline today afternoon. Using a signal from the AWG will give a more concrete testing of the stereo output.

3) After this, I will separate the two channels of the stereo completely (currectly they are seperated only at the DAF output stage)

4) I also will edit the medm gui appropriately.

 Quote: 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.

12242   Tue Jul 5 14:12:56 2016 varunUpdateElectronicsAntialiasing Filter Update

I am trying to design an antialiasing filter, which also has two switchable whitening stages. I have designed a first version of a PCB for this.

The board takes differential input through PCB mountable BNCs. It consists of an instrumentaiton amplifier made using quad opamp ADA4004, followed by two whitening blocks, also made using ADA4004, which can be bypassed if needed, depending upon a control input. The mux used for this purpose is Maxim MAX4158EUA. These two whitening blocks are followed by 2 the LPF stages. A third LPF stage could be added if needed. These use AD829 opamps. After the LPFs are two amplifiers for giving a differential output through two output BNCs. The schematic is shown in attachment 1: "AA.pdf". The top layers of the layout are shown in attachment 2 (AAtop.pdf), the bottom layers in attachment 3 (AAbottom.pdf), and the entire layout in attachment 4 (AAbrd.pdf).

The board has 6 layers (in the order from top to bottom):

1) Top signal layer;

2) Internal plane 1 (GND),

3) Internal plane 2 (+15V),

4) Internal plane 3 (-15V),

5) Internal plane 4 (GND),

6) Bottom signal layer.

Power: +15, -15 and GND is given through a 4 pin header connector.

The dimensions of the board are 1550 mil $\times$ 6115 mil (38.1mm$\times$155.3mm) and the overall dimensions including the protruding BNC edges are 1550 mil $\times$ 7675 mil (38.1mm$\times$194.9mm)

I would like to have inputs on the layout telling me if any component/trace needs to be changed/better placed, any other things about the board need to be changed, etc.

P.S.: I have also added a zipped folder "AA.zip" containing the schematic and board files, as well as the above pdfs.

12266   Thu Jul 7 12:44:52 2016 varunUpdateCDSDAFI update

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.

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.

12282   Fri Jul 8 22:26:03 2016 varunUpdateCDSDAFI Update: Changes in LSC model

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

12287   Sun Jul 10 20:08:44 2016 varunUpdateCDSDAFI Update: Changes in LSC and PEM models

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.

12303   Thu Jul 14 23:38:59 2016 varunUpdateCDSc1lsc FE unresponsive

Today, at around 10:30, c1lsc machine froze and stopped responding to ping and ssh after I compiled and restarted c1daf. I think it is due to a large array in one of my codes. The daqd.log file shows the following:

..................................................................
CA.Client.Exception...............................................
Warning: "Virtual circuit unresponsive"
Source File: ../tcpiiu.cpp line 945
Current Time: Thu Jul 14 2016 22:27:42.102649102
..................................................................

I think the c1lsc FE may need a hard reboot.

12304   Fri Jul 15 12:21:28 2016 varunUpdateCDSc1lsc FE unresponsive

c1lsc is up and running, Eric did a manual reboot today.

 Quote: Today, at around 10:30, c1lsc machine froze and stopped responding to ping and ssh after I compiled and restarted c1daf. I think it is due to a large array in one of my codes. The daqd.log file shows the following: .................................................................. CA.Client.Exception...............................................     Warning: "Virtual circuit unresponsive"     Context: "c1lsc.martian.113.168.192.in-addr.arpa:5064"     Source File: ../tcpiiu.cpp line 945     Current Time: Thu Jul 14 2016 22:27:42.102649102 .................................................................. I think the c1lsc FE may need a hard reboot.

12307   Sat Jul 16 00:30:42 2016 varunUpdateCDSDAFI update: Frequency warping | c1lsc unresponsive

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 $x_i[n]$  is given by $X_i[k] = \sum_{n=0}^{m-1}x_i[n]e^{-j2\pi \frac{kn}{m}}$. A matrix W containing all $W_{kn} = e^{-j2\pi \frac{kn}{m}}$ 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 $X_i[k]$ 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 $W_{kn}$ 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.

ELOG V3.1.3-