ELOG 40m

Electronics

2 BNC Cables, 1 Tee

I'm not sure where Ward and Miller went to Analyzer school, but it was probably uncredited.
I turned it on and used 2 BNC cables and a T to hook up the source to the 2 inputs and measured the always-exciting TF of cable.

Score:  HP Analyzer  1
        Rob & John   0

I have left the analyzer on in this complicated configuration. RTFM boys.

Quote:

The HP 4195A network analyser may be broken, measurements below 150MHz are not reliable. Above 150MHz everything looks normal. This may be caused by a problem with its output (the one you'd use as an excitation) which is varying in amplitude in a strange way.

Analyzer

330

Fri Feb 22 02:51:20 2008

Accelerometer ITMX seems to be broken

As people probably know,

I am trying (for a long time) to create a computational program that calculates the evolution of accelerometer time-domain data through stacks and pendulum transfer functions to test masses, and calculate the RMS of differential arm lenght spectrum.

I noticed on Tuesday that time-domain signals from the two accelerometers (one is near ETMX, the other one is near ITMX) seem to have different amplitudes of fluctuations around the mean value. I suspected that this is the main reason why I cannot get the awaited result of minimum of RMS for equal values of Q-factors for ETMX and ITMX suspensions (because we subtract two very different numbers, so we cannot get anything close to zero). I took amplitude spectra of the accelerometer data (dttfft2), and they look very differently for ETMX and ITMX accelerometers. I believe that spectrum of ETMX accelerometer represents seismic noise, but accelerometer ITMX seems to provide us with irrelevant and wrong data. No peaks, just almost monotoneous decreasing curve, and 10 times smaller amplitude. Therefore, ITMX seems to be broken.

I will try tomorrow to clap my hands, shout, yell, near the broken accelerometer to confirm that the accelerometer is broken (more precisely, that either accelerometer itself is broken,
or cable connections, or DAQ channel, but something is wrong). Now it is very late, and I am going home.

See attached figures: time-scale is 10^(-1), 10^0, 10^1, 10^2 Hz.

331

Fri Feb 22 08:29:07 2008

Quote:

I put the amplifiers next to the monitor on the PSL table, layed the power and the RF SMA cables out to the rack. I'm powering the box and the amplifiers with the power supply, waiting for someone to show me tomorrow how to connect it to the Sorensen (Steve, Ben?).

I'm ready to hook up the channels into EPICS.

Me and Ben Abbot were plugging the cables that power that RF Monitor box into the PSL rack when inadvertently we made some arcs spark between the pins on the back of one of the ADC. Somehow that made the laser shut down although the MOPA stayed on. We also notice some smell of burn.

Later on, after several failed attempts, Rob, Ben and Steve could restart the laser. It took some times because the written procedure to start the chiller is not very precise.

332

Fri Feb 22 08:33:18 2008

Quote:

With Ben, we hooked up the RF Monitor box into the PSL rack and created 4 EPICS channels for the outputs:

C1:IOO_RF_STOC_MON_33
C1:IOO_RF_STOC_MON_133
C1:IOO_RF_STOC_MON_166
C1:IOO_RF_STOC_MON_199

The power cable bringing +15V to the preamplifier on the PSL table should be replaced eventually.

333

Fri Feb 22 11:11:00 2008

I used a network analyzer that actually works to find a problem in the REFLDD electronics chain. There was loose (=bad) SMA-BNC adaptor on the output of channel one of the HP RF Amplifier. It worked intermittently, so going onto the ISCT and fiddling with cables could sometimes temporarily fix the problem. The bad adaptor has been given to Andrey to discard.

334

Fri Feb 22 11:13:15 2008

Quote:

It took some times because the written procedure to start the chiller is not very precise.

It is actually very precise. Precisely wrong.

335

Fri Feb 22 14:45:06 2008

At the beginning of this 1000 days plot shows the laser that was running at 22C head temp
and it was send to LLO

The laser from LHO PA#102 with NPRO#206 were installed at Nov. 29, 2005 @ 49,943 hrs
Now,almost 20,000 hrs later we have 50% less PSL-126MOPA_AMPMON power

336

Fri Feb 22 15:16:33 2008

ITMX Accelerometer is NOT broken

As I wrote in message 330, there was a bad signal from ITMX accelerometer. I have found the reason: the BNC-cable which goes from the black board with switches for accelerometer gain (1,10,100) towards DAQ-tower was completely disconnected from that black board with gain-switches. The end of the long BNC-cable was on the floor. Therefore, it was totally impossible to see any accelerometer signal. The cable that I am writing about should transport the signal from ITMX_X accelerometer.

Now all the BNC-connections seem to be in good shape, and spectra of accelerometers near ITMX and ETMX , both of them are in x-directions, are very much similar.

337

Fri Feb 22 16:47:54 2008

Well I guess Rana didn't study too hard at Professor School, either. If he'd even bothered to actually read John's entry, he might have looked at the RF Out from the HP Analyzer. As it is, this experience so far has been like taking your car to a highly respected mechanic, telling him it's having acceleration problems, and then he takes a rag and wipes some dirt off the hood and then tells you "It's running fine. That'll be 500 bucks."

I make the current score:

Snarkiness: 2
Education:  0

I did RTFM, and it doesn't mention anything about crazy behaviour on the RF Output. So, I set up the analyzer to do a sweep from 500MHz to 1MHz, with output power of 0dBm, and plugged the output directly into the 300MHz scope with the input set to 50 Ohm impedance. The swept sine output looks totally normal from 500Mhz to 150MHz (measuring ~220mVrms below 300MHz -- 0dBm), where it abruptly transitions to a distorted waveform which the scope measures as having a frequency of ~25MHz and with 450mVrms (+6dBm). It then transitions again at some other part of the sweep to a cleaner-looking 25MHz waveform with ~1.2Vrms (+15dBm). See the attached Quicktime movie. The screeching in the background is the PSL door.

With this bizarre behaviour, it's actually possible that even someone who does everything carefully and correctly could break sensitive electronics with this machine. Let's get it fixed or get a new one.

Don't use the HP4195A anymore unless you want broken electronics.

Quote:

Score:  HP Analyzer  1
        Rob & John   0

I have left the analyzer on in this complicated configuration. RTFM boys.

Quote:

342

Wed Feb 27 22:05:03 2008

A summary of the status of the auxiliary arm locking effort.

To help with lock acquisition we are attempting to independently lock the Y arm using light injected through ETMY. At present this secondary light source is an NPRO laser situated on the SP table. The laser light is transported to the ETM using a single mode optical fibre. In the future we might pick off some PSL light and apply a frequency shift.

We have been able to successfully mode match the fibre beam into the cavity and have been attempting lock the cavity using standard PDH signals (phase modulation sidebands are added to the light before it enters the fibre).

As yet no acceptable error signals have been produced. The demodulated RF signal is showing a time varying, bipolar dc offset.

We have minimised the residual amplitude modulation of the EOM but we expect small signals due to the undercoupled nature of the system, it could be that whatever RFAM still present is varying with time and causing this behaviour. We are also able to produce similar offsets by stressing (i.e. bending, shaking) the fibre. Could it be that the fibre is somehow converting PM into AM? Are we seeing etalon effects in the fibre or elsewhere?

If we cannot make any further progress with the existing setup we shall move the NPRO to the ETM table and try again. We are also looking into purchasing some other types of fibre.

Other things to consider are injecting through POY or using some other wavelength - neither seems obviously better.

Fiber, behavior

344

Thu Feb 28 13:04:59 2008

rga logging working again

Quote:

The rga head and controller are running fine, but the data logging is not.

It should run tonight at 1:25 AM. To get the cron job to work properly on op340m, I had to make wrapper sh script which defines the perl library before calling the actual RGAlogger script.

347

Thu Feb 28 19:49:21 2008

Quote:

I changed the names of these channels to the more appropriate (and informative, as they're coming from the RFAMPD):

C1:IOO-RFAMPD_33MHZ
C1:IOO-RFAMPD_133MHZ
C1:IOO-RFAMPD_166MHZ
C1:IOO-RFAMPD_199MHZ

I also added them in an aesthetically sound manner to the C1IOO_LockMC.adl screen and put them in trends. Along the way, I also lost whatever Alberto had done to make these monitors read zero when there's no light on the diode. It doesn't appear to be written down anywhere, and would have been lost with a reboot anyway. We'll need a more permanent & automatable solution for this.

351

Mon Mar 3 09:25:33 2008

rga scan logging is working now

Quote:

The rga head and controller are running fine, but the data logging is not.

It should run tonight at 1:25 AM. To get the cron job to work properly on op340m, I had to make wrapper sh script which defines the perl library before calling the actual RGAlogger script.

Thanks to Rob, it is working !

The baked, calibrated rga head
model# M206M, s/n #c128035 was reinstalled at the 40m ifo on Feb. 8, 2008
Faraday mode dwell time was increased from 2 to 16 sec
Rga head temp at top silver gaskit 45.2 C
The noise floor is at 1E-12 Torr

There is more detail in logbook VMI-14 p 107

pd65-m-d119

352

Mon Mar 3 13:58:10 2008

The CODAQ_RFNETWORK are down, except C1SUSVME & AWG

353

Mon Mar 3 19:34:40 2008

Quote:

The CODAQ_RFNETWORK are down, except C1SUSVME & AWG

All of the FE machines were found to be down this afternoon. I called Alex and he suggested several
things which didn't work (restart EPICS tasks, power cycle RFM switch, etc.).

Then he suggested that I go around and power cycle every crate!!! And that sometimes the order of this
matters!!! I think he was just recording this conversation so that he could have a laugh by playing it on Youtube.

However, power cycling all of the FE crates seemed to work. Alex's theory is that 'something goes bad in the
RFM cards sometimes'.

Its all green now.

354

Tue Mar 4 00:42:51 2008

The framebuilder is still down. I tried restarting the daqd task and resetting the RFM
switch like it says in the Wiki but it still doesn't work right. The computer itself is
running (I can ssh to it) and the daqd process is running but there's a red light for
it on the RFM screen and dataviewer won't connect to it.

If Alex isn't over by ~10 AM, we should call him and ask for help.

355

Tue Mar 4 10:08:21 2008

green lights unreliable when c0daqctrl down

Computers

So far I've tried powering off the framebuilder, power-cycling the RAID (it was showing an error message about bad IDE channel #4), and rebooting the LSC (just for fun). When I reset the LSC, its green light on the RFM_NETWORK screen did not turn red, making all these lights suspect. The iscepics40m process is what controls these red/green lights, so maybe it's gone wonky. It appears to be running however, on c1dcuepics, and it also seems to be functioning correctly in other ways (it's communicating correctly with the LSC).

Update: Alex and Jay came by. The solution was to reset the c0daqctrl processor, which apparently was not done in Rana's rebooting spree. Or maybe it needed to be done last.

361

Wed Mar 5 17:35:24 2008

I used an ezcaservo command to adjust the offsets for Alberto's StochMon channels. They are all
at +2 V with no light on the RFAM PD (MC unlocked).

Then I looked at 5 minutes of second trend around when the MC locks. Since Alberto has chosen
to use +2V to indicate zero RF and a negative gain, there is a large RF signal when the StochMon
channels approach zero.

From the plot one can see that the RFAM for the 133 & 199 MHz channels is much worse than for the 33 and 166.
Its also clear that the turn on of the WFS (when the RFAMPD's DC light level goes up) makes the single demod
signals get better but the double demod get worse.

362

Thu Mar 6 00:17:37 2008

Got the DD (double demod) handoff scripts working tonight, with just the DRMI. So, now acquisition with the single demod signals is working well, and handoffs to all double demod signals using the input matrix ramping worked several times with the scripts. Up next will be more work with the DRM+ARMs.

364

Fri Mar 7 17:10:01 2008

Noise budget has been moved to the svn system. A checked out copy is in the directory caltech. From now on, I will try to use the work cycle as outlined in the svn manual. Changes made today include the following:
getNoiseBudget
/matlab/noise/NoiseBudget

Details of the modifications made may be found on the svn system. Please let me know if anyone has a suggestion or concern. Thank you - Max.

366

Mon Mar 10 02:05:08 2008

DRMI+2ARMs working better

Locking

Some encouraging progress on the locking front tonight. After the work on the DRM loops last week and a review of the settings for initial lock acquisition (loop gains, tickle amplitude, filter states, so on), the DRMI+2ARMS locking is working pretty well. That's to say, it takes from 5-15 minutes generally for the IFO to lock in the offset CARM state, with the arm powers at 0.5. It's then possible to raise the arm powers slightly, and handing off control of CARM to MCL works at low power, but engaging the AO path (using PO_DC as an error signal) is not working so well. Taking swept sines indicates that the PO_DC should be a good error signal. The next good thing to try might be just using PO_DC as an error signal for the length path, without using the AO path at all, to see if it's something in the hardware.

372

Wed Mar 12 23:05:44 2008

they are bad, somewhat

please fix

375

Thu Mar 13 12:11:58 2008

aivanov

Computer Scripts / Programs

routing PEM -> ASS -> SUS_MCL

on ASS RFM 1 has PEM signals at

float at 0x100000 has c0dcu1 first ICS110B chan 1
float at 0x100004 has chan 2
etc.

ASS sends to RFM 0

float at 0x100000 goes to PRM MCL
0x100004 to BS MCL
0x100008 to IMTX MCL
0x10000c to ITMY MCL
0x100010 to SRM MCL
0x100018 to MC1 MCL
0x10001c to MC3 MCL
0x100020 to ETMX MCL
0x100024 to ETMY MCL

376

Thu Mar 13 13:15:09 2008

aivanov

Computer Scripts / Programs

new sfotware intall, backup files

New:
op440m:40m>ls -alt /cvs/cds/caltech/target/c1susvme[12]/*.o
-rw-r--r-- 1 controls staff 57920 2008-03-13 13:11 /cvs/cds/caltech/target/c1susvme2/losLinux2.o
-rw-r--r-- 1 controls staff 57976 2008-03-13 13:11 /cvs/cds/caltech/target/c1susvme1/losLinux1.o
op440m:40m>ls -alt /cvs/cds/caltech/target/c1isce[xy]/*.o
-rw-r--r-- 1 controls staff 246861 2008-03-13 13:12 /cvs/cds/caltech/target/c1iscey/losEtmy.o
-rw-r--r-- 1 controls staff 246861 2008-03-13 13:12 /cvs/cds/caltech/target/c1iscex/losEtmx.o
op440m:40m>ls -alt /cvs/cds/caltech/target/c0dcu1/*.o
-rw-r--r-- 1 controls staff 63547 2008-03-12 14:57 /cvs/cds/caltech/target/c0dcu1/dcuDma.o

Backups:
op440m:40m>ls -alt /cvs/cds/caltech/target/c1susvme[12]/*.o.13mar08
-rw-r--r-- 1 controls staff 55960 2005-06-21 13:30 /cvs/cds/caltech/target/c1susvme2/losLinux2.o.13mar08
-rw-r--r-- 1 controls staff 55960 2005-06-21 13:30 /cvs/cds/caltech/target/c1susvme1/losLinux1.o.13mar08
op440m:40m>ls -alt /cvs/cds/caltech/target/c1isce[xy]/*.o.13mar08
-rw-r--r-- 1 controls staff 229793 2007-03-08 11:09 /cvs/cds/caltech/target/c1iscex/losEtmx.o.13mar08
-rw-r--r-- 1 controls staff 229793 2007-03-08 11:09 /cvs/cds/caltech/target/c1iscey/losEtmy.o.13mar08
op440m:40m>ls -alt /cvs/cds/caltech/target/c0dcu1/*.o.12mar08
-rw-r--r-- 1 controls staff 60810 2004-09-08 08:47 /cvs/cds/caltech/target/c0dcu1/dcuDma.o.12mar08

377

Thu Mar 13 18:20:29 2008

John

New Focus 4003 EOM 29.489MHz

General

I measured the modulation index as a function of drive power using an OSA. Agrees well with spec of 0.2 rad/V.

380

Fri Mar 14 15:06:24 2008

Computer Scripts / Programs

routing PEM -> ASS -> SUS_MCL

Quote:

You can differentiate between RFM 0 and RFM 1 in the simulink model by adding 0x4000000 to the offsets for RFM 1.

385

Thu Mar 20 15:28:20 2008

tp2 's drypump replaced

The fore pump of tp2 was replaced at fore line pressure 998m Torr

388

Fri Mar 21 09:02:03 2008

Small turbo #2 is the forepump of the maglev.
It failed last night, shut down the maglev and interlock closed V1
Ifo pressure is 20 mTorr now. The Yarm was still locked at 8am this morning.
The PSL beam to MC was blocked just before the output periscope.
The psl mechanial shutter did not work from epic screen.

389

Fri Mar 21 11:54:38 2008

Quote:

The PSL mechanical shutter actually did trip last night, greatly confusing me and Rana. Not realizing that the software vacuum interlock had tripped, we manually re-opened the shutter. I'll modify the relevant MEDM screens to indicate when the EPICS interlock trips.

396

Sun Mar 23 00:56:42 2008

We ended our last attempt at 3f locking concerned about the beam size on PD6. I investigated tonight. The beam was not obviously overfilling the diode and a quick tweak of the steering mirror revealed a decent plateaux. Nevertheless we decided to try a different approach to see if we found the same problems as before on a different diode.

This time our 3f diode was Refl 33. I put a splitter on the output of the diode at the LSC rack sending one half into the usual refl 33 board, the other into refl DD 199 (which is demodulating at 99Mhz).

I got as far as handing off PRC to the 3f signal in lock. More work needed.

398

Mon Mar 24 13:03:54 2008

Quote:

The swept sine output looks totally normal from 500Mhz to 150MHz (measuring ~220mVrms below 300MHz -- 0dBm), where it abruptly transitions to a distorted waveform which the scope measures as having a frequency of ~25MHz and with 450mVrms (+6dBm). It then transitions again at some other part of the sweep to a cleaner-looking 25MHz waveform with ~1.2Vrms (+15dBm).

The HP4195A is back from repair. At first, it exhibited exactly the same behaviour for which it was sent in for repair, and which is described above (pillage from entry 337). After speaking with the repair tech on the phone, who tried to imply that the digital scope was tricking us, I plugged the output into our HP8591E spectrum analyzer, just to have firm ammunition to combat the repair guy's looniness. This led to even weirder behaviour, like no output and overload signals on the inputs (with nothing connected). After turning the unit on and off several times, and firmly seating (and screwing in) the DB9 connectors in the back of the unit, it appears to be working properly. Except for a brief glitch as it passes through 150MHz, the swept sine signal now appears normal, both on the scope and in the spectrum analyzer.

Apparently the whole thing is due to a loose connection somewhere in the box, which wasn't actually fixed by the repair, but has at least been temporarily fixed by me stumbling around with a screwdriver and then pushing the power button a couple of times.

400

Tue Mar 25 10:44:24 2008

Quote:

c1susvme2 isn't behaving itself. It keeps getting out of sync and/or giving a red status light.

After going through the usual restart procedures a few times (unsuccessfully) we power cycled the c1susvme & c1sosvme crates. We think everything came back okay.

We still can't get the status and CRC (cyclic redundancy check) to return to normal on c1susvme2. If Alex is around tomorrow please ask him to take a look.

I rebooted it again this morning. The ASS machine is currently not running its process, for whatever reason (someone turn it off?). Let's leave it like this for a day and see how the c1susvme2 does. The other recent change is Steve's install of a cooling fan--maybe that's causing the problem.

401

Tue Mar 25 13:21:25 2008

c1susvme2 is not behaving itself again

Computers

402

Tue Mar 25 15:56:09 2008

Some pictures scavenged from the D40.

403

Tue Mar 25 16:34:47 2008

Quote:

Now c1susvme1 is joining the action. Since leaving the ASS off doesn't change anything, we can probably absolve it of blame. I now suspect the 4-pin LEMO cables going from the CLK DRIVER modules to the clock fanout modules. These cables are being squeezed/shaken by Steve's new fan setup, and may have been the culprit all along. John will do some testing to see if they are indeed the problem.

405

Wed Mar 26 22:26:15 2008

I removed the fan and tweaked the timing cables to see if they were the source of our problems. I saw no effect. I'm leaving the fan off for the moment to see if that helps. It is on top of the filing cabinet next to my desk.

406

Fri Mar 28 16:18:18 2008

c1susvme2 is getting worse and worse. it won't run for more than ~45 minutes without fatally de-syncing. for now I've turned off c1iovme (which sends the MCL signal) to see if that's causing the problem. next I'll swap the boards for c1susvme1 and c1susvme2 to see if it's the cpu (or maybe the RFM card) itself, rather than the timing/pentek systems.

408

Mon Mar 31 14:14:16 2008

Quote:

I swapped the processors for c1susvme1 and c1susvme2. So for now, to startup, you should ssh into c1susvme1 and run the startup.cmd for c1susvme2, and vice versa.

409

Wed Apr 2 15:03:51 2008

reflectivity of black glass

General

The reflectivity of black glass, shade 12 was supplied by Donald O'Shea
of Emerald Glass Inc., Westlake, OH 44145

The reflectivity of this glass was measured as shown

Old 1064 nm Crysta Laser with poor beam quality was the source.

416

Mon Apr 7 16:42:56 2008

Phil Ehrens restarted Dziban again this morning. Looks like its still crashing each Monday around 8 AM.

Here is the latest suspect:

http://open.itworld.com/5040/reboot-unix-nlsunix-071225/page_1.html

417

Mon Apr 7 18:58:49 2008

General

reflectivity of SS304

The reflectivity of stainless steel 304 super polished # 8 was measured the same way as elog entry 409

The reflectivity: 74 +- 1 % from incident angle 10 to 80 degrees

421

Wed Apr 16 10:20:01 2008

Quote:

There is a new computer in the control room -- its called Rosalba,
in keeping with our naming convention. Its a quad-core machine that
Dmass found for cheap somewhere; we've installed the CentOS on it
that Alex recommended.

Its a 64-bit Linux and so that may cause some problems. Alex has done this
before and so we have some confidence that we can get our regular tools (DTT, Dataviewer)
to run on it.

I have made a new apps tree for all of our future 64-bit Linux machines. So far, there is
a 64-bit firefox and a 64-bit matlab in there. As we start using this machine some more, we
will be forced to install more 64-bit Linux stuff.

We also didn't have enough network cables to run to both linux3 and rosalba. Andrey has decided that we
should not ditch linux3 and so he will run another cable for it tomorrow.

The ethernet cable for linux3 was installed on Wednesday morning. Now linux3 has Internet connection again.

423

Thu Apr 17 15:00:59 2008

vac controller computer to be replaced

Now that Rosalba is up and running someone should step forward to volunteer for this job.

Old desk top at the Vacuum Rack should be replaced by a functional less old computer so
the vacuum controller can count on an emergency situation. It's only has to be able to run medm
The existing one is dying.

424

Thu Apr 17 20:17:37 2008

Two issues with our weather station

I encountered two difficulties working with the "Weather Station".

(1) It turns out that there is no indication for "outside humidity" on the "weather monitor" (a small black box located on the north wall of the interferometer). I realized that "outside humidity" is absent in our system when I tried to see the Dataviewer trend and real-time value from the channel "C1: PEM-weather-outsideHumid". It shows impossible number 128%.

It follows from the "Davis" technical documentation that the outside sensor can be of two types: either "External Temperature Sensor" or "External Temperature/Humidity Sensor". I suspect (I do not know for sure) that we have the first type of sensor "external temperature only" and therefore we in principle cannot have information about outside humidity. I propose to Steve to climb to the roof on Friday to resolve this uncertainty looking at the sensor.

(2) I wanted to change the units of pressure from "Pascal" (force/area) to other units, "mbar" for example. For this purpose I need to edit the file "Weather.st" in the directory /cvs/cds/caltech/target/c1pem1 (this file is run on the VME processor "c1pem1"). Unfortunately, when I try to open the file with emacs, I get the message that the file exists but protected from modifications. I do not know how to unblock the file "Weather.st". I need some help with that.

I thought that switching-off the processor "c1pem1" could resolve the issue, so I switched-off the whole crate where the processor "c1pem1" is installed for about 5 minutes, turning the metallic key. As it did not make any difference for the accessibility of the file "Weather.st", I switched-on the crate after 5 minutes. There are other processors besides "c1pem1", so they were turned-off for several minutes earlier today.

Also, I created a new MEDM screen which has information about weather only, a smaller version of the "C0Checklist.adl" MEDM screen. Both screens are now located under the most top-left button "Checklist" of the main MEDM screen.

425

Fri Apr 18 16:02:58 2008

alex

end station sus front-end bug fix

SUS

installed and started new susEtmx.o and susEtmy.o to fix a problem with ETMY optical lever variables.

426

Fri Apr 18 16:27:04 2008

end station sus front-end bug fix

SUS

Quote:

installed and started new susEtmx.o and susEtmy.o to fix a problem with ETMY optical lever variables.

But where is the code?

427

Fri Apr 18 16:48:13 2008