Weekly trend plots.

Still need to work on the (non-auto) scales for the various plots.

The power noise measurement looks okay.  Noisier than the reference measurement between 10 Hz and about 3 kHz.  The diffracted power whilst averaging around 3% is wandering around a little - normally it's relatively flat.

Whilst the frequency noise scan was being done, the reference cavity transmission was around 2.05 V, common gain 27 dB, fast gain 15 dB.  It had been locked for ~10 hours.  The frequency noise spectrum again has these "step" like features at low frequencies.  This is about the 3rd or 4th week that this feature has been present.  I suspect it will take more than the customary 4 hour Tuesday morning maintenance period to address this issue.  It looks like we're not getting much bandwidth as the control and error signals intersect below 100 Hz.

The beam pointing looks nominal.

The mode scan looks nominal, higher order mode count 56, higher order mode power 4.6%.

The relative power noise is noticeably worse than the previous measurement.  A check of the diffracted power after the scan was done showed that the diffracted power was oscillating between 1% and 10%.  Not obvious why.  Environmentally there is a lot of seismic noise in the 1 - 3 Hz band.  A screen shot of the ISS MEDM screen is attached.

no restart reported

J. Kissel

I was warned that -- though all the GND STS channels are mapped from the instrument to the frames correctly now (see LHO aLOG 14072) -- what actually gets fed into the sensor correction filter banks is a total mess in the corner station. I've scoured the front-end simulink models, toggled some switches at the racks in the EE bay, and stomped on the ground near the STSs themselves trying to map it out, and all I can say is WOW do I agree. I'll work with the SEI and CDS groups to clean up.

Here're the facts, as they stand now, in order of my discovery:
(1) In reality, we want the following seismometer-location-to-channel map for all 17 digital instances of the signals in the corner (6 HAM HPIs, 5 HAM ISIs, 3 BSC HPIs, 3 BSC HPIs):
       Just +X of HAM2    => STS A
       In the Beer Garden => STS B
       Just +Y of HAM5    => STS C
as determined by D1002704, revised due to Integration Issue 45, and DCN E1400111.
(2) I've confirmed that the above mapping is correct for ITMY (the "master" front-end model responsible for storing these STSs and "GND" channels in the frames) by performing my finest hill-billy hoe-down near the respective STS, and watching the ISI-GND channels on a CDS laptop. 
(3) Because of the STS-2 analog distribution chassis, and that the SEI BSC wiring diagram (D0901301), and SEI HAM wiring diagrams (D1101584, D1101576, and D1000298) were written before the ABC convention was established and not addressed in E1400111, there're 17-choose-3 = 680 possible combinations, and I'm pretty sure we used all of them.

Front end models:
(4) ALL HAM-ISIs use the library part, ${userapps}/release/isi/common/models/isihammaster.mdl. There is another library, isiham236master.mdl, that looks deceiving in the same directory, but it's unused according to the tar balls of source code for what's actually running on the IFO. This should be removed from the repo.
(5a) The HAM-ISIs  are reasonably consistent, in that, 
       ADC_0 or ADC_2 Channels 24-26 => STS A XYZ
       ADC_0 or ADC_2 Channels 28-30 => STS B XYZ
       ADC_1 or ADC_3 Channels 24-26 => STS C XYZ
where it's ADC_0/1 on the "first" HAM-ISI in the I/O chassis, and ADC_2/3 on the "second" HAM-ISI (HAM2, HAM4, and HAM6 are the "firsts," HAM3 and HAM5 are the "seconds."). 
(5b) EXCEPT HAM2, who has ADC_0 channels 24-26 mapped into BOTH STS A and STS B. 
(6) Because of an RCG "feature" even though different ADC *card* numbers are used between the seconds and firsts, the block name is always ADC 0 or ADC 1. 
(7) The HAM-HPIs all use the same library part, ${userapps}/release/hpi/common/models.
(8a) HPIs HAM2-5 have GND STSs hooked up, also, reasonably consistent in that they all use
       ADC_0 or ADC_2 Channels 24-26 => STS A XYZ
all piped into STS A, with STS B and STSC terminated. Again, the "firsts" use ADC0, and the "seconds" use ADC 2. 
(8b) EXCEPT HAMs 1 & 6 have all STS inputs terminated.
(9) The BSC ISIs and the BSC-HEPIs are consistent, but consistently bonkers.
       BSC1 ITMY ADC_3   23-25 => STS A
                         26-28 => STS B
                         29-31 => STS C
       BSC2 BS   ADC_3   29-31 => STS A
                         23-25 => STS B
                         26-28 => STS C
       BSC3 ITMX ADC_3   26-28 => STS A
                         29-31 => STS B
                         23-25 => STS C
That's right -- the channels have been cyclically rotated between BSC chambers.

Electronics Chain:
To test out which STS chassis maps to which GNDSTSINF (for ISIs) or STSINF (for HPIs), just in case the STS distribution chassis had been used to rectify the front-end badness, I toggled the period switch on the front of each of the three chassis, in consecutive order, and followed which channels showed the characteristic flip to (more) AC coupled signal (1 [sec] period) and then drove off into tilt land after switching back to the low-frequency mode (120 [sec] period). Since I didn't want to disconnect any cables, and couldn't simultaneously look at all the channels needed with the tiny laptop while zydeco dancing, all I could determine which which *rack* affected which GNDSTSINf or STSINF channel.
(10) BSC 1 (ITMY) ISI and HPI on-board sensors are read out in rack SEI-C4, BSC2 (BS) ISI and HPI are read out in rack SEI-C5, and BSC3 (ITMX) ISI and HPI are read out by rack SEI-C6. As such, I'll refer to the STS chassis that I switch as C4, C5, and C6, after the rack in which they're mounted, since I was unable to determine which was HAM2 (STS A), Beer Garden (STS B), or HAM5 (STS C).
(11) For the BSC-ISIs, the matrix of channels affected by the switching is as follows:
          ITMY     BS      ITMX
     C4     A       A       A
     C5     B       B       B
     C6 (bonkers)   C       C
This indicates that, even though the ADC to model mapping is some crazy, cyclic thing, the cables from the STS distribution chassis have been arranged such that what goes into the ADC is "normal." The ITMY STS C channel doesn't make any sense to me. It didn't respond to any of the period-switch toggles, but still showed live tilt-full signals. Need to debug that one.
(12) For the BSC-HPIs, it's different:
          ITMY     BS      ITMX  
     C4    A        B       C
     C5    B        C       A
     C6    C        A       B
This indicates, that the cabling matches the crazy-bonkers front-end mapping.
(13) For the HAM-ISIs, it's different:
           HAM2     HAM3     HAM4     HAM5     HAM6
     C4    A&B       A      (dead)   (dead)      A
     C5 (no change)  B      (dead)   (dead)      B
     C6     C        C      (dead)   (dead) (no change)
HAM2 is weird, but is consistent with the model layout described in (5b). HAMs 4 and 5 are receiving only ADC noise -- maybe this means the channels aren't hooked up? I didn't check.
(14) And finally, the HAM-HEPIs, they're the worst off:
           HAM1     HAM2     HAM3      HAM4      HAM5     HAM6
     C4   (n/c)      A        B       (dead)    (dead)    (n/c)
     C5   (n/c)     (n/c)    (n/c)    (n/c)      (n/c)    (n/c)
     C6   (n/c)     (n/c)    (n/c)    (n/c)      (n/c)    (n/c)
where "n/c" is not connected in the front-end model as described in (7a). Still no help as to why HAM4 and HAM5 are reading out ADC noise.
And that's the anti-climactic end of the list. We've got some work to do!

Step-one will be to update the SEI wiring diagrams to clearly define how each STS gets into each front-end via an ADC channel list. Next, change the top-level front end models to match the convention in the drawings. Third, change the cabling at the racks around so we get the expected behavior. At the moment, although it's don't in an icky way, the BSC-ISIs are our best case.

Alexa, Gabrielle, Kiwamu, Sheila

This morning we moved PRMI to the 3F sensors, we used a gain of 3 in the input matrix to move PRCL from REFL 9 I to REFL 27 I, and a gain of 15 to move MICH from REFL 45 Q to REFL 135 Q.  This was locked from about 22:26:55 UTC (september 22) to 22:33:20. 

We then tried to move on to DRMI but have struggled most of the day to get it locked.  We locked it a few times this morning, (21:00 UTC) but haven't been able to recently. 

Also, as is typical recently, the anthropogenic noise is higer durring the evenings than durring the day, there must be an evening shift of hanford work.  Screen shot of the last week is attached. This pattern started in mid august and has been true since then.

On Sunday I took advantage of the interferometer downtime to make some improvements to the OMC scripts:

• The script to offload the OMC alignment outputs to the OM bias sliders has been re-written in python and now uses the outputs of the DRIVEALIGN matrix as the control signals.  This has the advantage of using the control signals *after* they have gone through the angle-to-angle decoupling.  (Sad thing: since the DRIVEALIGN matrix only decouples the ISC signals, some residual A2A coupling will reappear after the ISC signals are offloaded to the sliders.)
• The sensing matrix for the OMC dither alignment loops was re-measured.  This was done using DC offsets in the POS and ANG filters while the QPD alignment was engaged.  The matrix was inverted and plugged into the dither SenseMat.  With the dither loops engaged we gain about 5% in DCPD SUM, but the loops have a time constant of a few seconds and don't suppress the motion around 1Hz.  I didn't have a chance to measure the loop shape or take another mode scan, or investigate the OMC length noise.  These are on the to-do list.
• Before measuring the sensing matrix I spent a little time checking the amplitude of the dither lines and the goodness of the demodulated signals.  I adjusted the amplitudes so that all four dither lines are about a factor of two lower than the saturation point of the tip-tilt DACs.  I'm not sure how to optimize these amplitudes (same goes for the SINE and COSINE gains in the oscillator controls), but things are working, and they have some headroom.  There was a lot of noise in the dither error signals above 10Hz, and I found that the OM DACs would saturate from the dither control signals.  Since these loops are unlikely to have a UGF above 1Hz, I inserted some filters to suppress the control signals above 10Hz (see OM1_dither_sat, attached).  This kept the DACs from saturating, but it's a hacky fix and we should take a closer look.
• I rotated the demodulation signals so that the signal from a DC offset in POS or ANG is maximized in the I-phase.  The yaw loops needed some rotation, not sure why these would be different from pitch?

Also, last week I investigated a few bugs in the OMC PZT driver board:

• Previously we had observed the HV readback from the OMC PZT driver was hitting the rail at about 90V.  This was due to the driver hitting the current limit in the HV supply; the current limit was set at 1.010mA and the board needs about 1.025mA to deliver the full 100V to PZT2.  In consultation with Koji and Rich, Richard and I increased the current limit to 4mA.  (In an abundance of caution, I checked that the PZTs were not shorted [and only capacitvely coupled] by measuring their resistance at the vacuum flange.  They're fine.)
• Currently the PZT1 and PZT2 readbacks are flipped in EPICS; PZT1_MON should be the LV drive and the length dither, PZT2_MON should be the HV drive and the length control signal.  It looks like the flip is because the readback cables are plugged into the wrong place on the breakout panel, and we'll need to make longer cables to get them into the right place.  {sigh}
• The LV DC monitor channel (readback for PZT1) is railed at -20V and doesn't respond to changes of the input.  It looks like this is due to a hardware problem in the PZT driver board, we'll have to pull the board and see what's up.

One more thing: when I came in on Sunday the PZT HV supply was tripped.  According to the EPICS readbacks this happened around 6:15am local time on Sunday (see attached).  Not sure why this HV supply would trip by itself, but if you try to move the PZT and nothing happens, go check the HV...

J. Kissel, K. Izumi, S. Biscans (Remotely)

Through various back-channels, searching for reasons as to why the IFO is particularly noisy this evening, HAM2 and HAM3 ISI sensor correction came up in conversation. While we all thought the Sebastien had commissioned HAM2-ISI X sensor correction (see LHO aLOG 13964), yet we found that HAM2-ISI X sensor correction was OFF, and HAM3-ISI X sensor correction was ON, and has been ON with a gain of -0.5 since Thursday at ~3:30p PDT (1095114256, Sep 18 2014 22:24:00 UTC). 

Totally confused, we tried turning ON the the HAM2-ISI sensor correction, with the suggested gain of -10 from LHO aLOG 13964. This immediately caused the IFO to start shaking; clearly bad news. Naturally, given the level of confusion, we tried turning OFF HAM3 X sensor correction. 

I took long enough to write the above that Seb got back to us.
(1) HAM2-ISI -- the correct gain is -1, not -10. Though -10 was originally correct, and what he used to get the performance measurments in LHO aLOG 13964, it was errant because the GNDSTSINF Cal filters, a gain of ~10, had not been installed on the HAM-ISIs. Unfortunately, he reported this info in the SEI aLOG, and didn't cross reference, so we didn't catch it.
(2) HAM3-ISI -- Seb was teaching Jim and Hugh how to commission sensor correction using HAM3, and simple left what they had ON after Seb left Thursday afternoon. Seb is pretty confident that this correction is making things worse, so he recommends turning it OFF, and we have done so.

PLEASE PLEASE PLEASE -- If you're working on ANYTHING to do with the IFOs at the sites, information should be reported first and foremost in that site's aLOG. You're more than welcome to link the entry to any other aLOG, or send it out on an email list, or send it it in a post card to your mom, but it MUST go in the site aLOG first.

Sadly, after all the hub-bub, the IFO isn't working noticeably better. The investigation continues...

All automated except HEPI watchdogs.

Peter, Sudarshan, Gabriele

Today we installed the ISS second loop servo board and connected all the cables to the board itself and to the photodiodes. 
After some tweaks, we could get all the eight photodiodes showing some reasonable signals.

The attached plot shows the signals measured on the eight photodiodes, still calibrated in counts. PD1-4 shows similar signals, although the gains seem to be different up to a factor 2. The same is true for PD5-8: they are quite similar one to the other. However, it seems that the signals on PD1-4 are a bit different from the signals on PD5-8. 

We also checked that the ISS QPD is cabled and working. As shown in the attached file, the QPD signals show some resonances at 1, 3.4 and 16 Hz, which are likely coming from motion of some optics. It is interesting to note that the same peaks are very well visible in all eight photodiodes. We don't know yet if the beam entering the ISS box is already intensity modulated at those frequencies, or if we have some jitter to intensity coupling at the ISS level. It seems that all PDs see the jitter peaks at a similar level, so the coupling should be in the common path.

There is also very good coherence of all PDs with the QPD signals, at all frequencies below 10 Hz.

We started investigating the transfer function of the transimpedance and whitening, to properly calibrate the signals in terms of dP/P. To be continued.

In preparation of opening the X-arm tomorrow

Restarted X-end rotating pumps -> John W. says that Richard M. had an indication of a power "blip" at the X-end at the time the pumps shut down

J. Kissel, J. Warner

Now that Jim has discovered and fixed my blunder at ETMY recovering the missing factor of ~10 (see 14066), all STSs on site* are functional, well-calibrated, and stored correctly in the frames. Indeed, with the knowledge of the sensor noise (from T0900450) and the plethora of sensitive instruments at End X telling us ground rotation (see LHO aLOG 14047), I think we understand the signals over the entire frequency band where we intend to use them (~10 [mHz] - 10 [Hz]). Well, at least at the X-end.

*used for ISI sensor correction. The vault STS2 which is still out for repair (c.f. )

Several interesting points along the way:
(1) ETMX T240 X and ETMX BRS RY are coherent between 20-80 [mHz], as expected. ETMX T240 Y and Z are *not* coherent, also as expected. This implies that we've well-aligned the X axis of the T240 with the sensitive axis of BRS. Good.
(2) Comparing the coherence between EX RY ground motion with the corner and EY stations' translation DOFS show no coherence. It's not totally crazy to interpret this as meaning the source of ground *tilt* is entirely local to each building. The only way to tell for sure, of course, is to build more BRSs (*hint*hint*).
(3) Each station also varies in the Z DOF, therefore obviously not tilt. Another potential source of noise that might explain this at these low-frequencies is the aging STS2s. Remember EX has a brand new T240, and the remaining GND seismometers are > 10 yr old STS2s. Of course, this could also be thermal drifts, as none of the translational ground motion sensors are as thermally well-isolated as the BRS (HAM2 and HAM5 aren't even a T240 Igloo).
(4) Jim has warned me that, in the corner station, each front-end model reads out HAM2 STSA, Beer-Garden STSB, and HAM5 STSC differently. Further, comparing coherence between each of the corner station STSs, it looks like each could use an alignment tweak-up.

I spent today trying to sort out more sensor correction issues. Over the weekend I realized that sensor correction not working could be explained by bad blends. I looked at ETMY and sure enough, there are 2 T750 blends, one of which is an old version, not to be used. Additionally I found that the calibration filters for the STS weren't turned on. I also noticed that the 8hz peak that comes from HEPI looks a bit bigger than the same peak at ETMX, something Hugh had noticed in August(?) and we thought had been addressed. I tried a number of configurations, shown in the attached pictures. The first is how I found the chamber this morning, with bad blends, HEPI running and basically no sensor correction (there was a gain of .5, with the cal filter off that becomes  ~.05). The second is how I'm leaving it tonight, with the right blends, STS cal filters engaged and sensor correction on. I wouldn't really call it better. The sensor correction seems to be re-injecting noise at ~1 hz, but cutting some at .1-.2 hz. This is not what I've found on E/ITMX, where sensor correction seems to cut more noise between .1-1hz and reinjects some below. Not sure what is going on there.

B. Weaver, T. Sadecki, D. Sellers

Today we laced reaction chain cables and plugged in UIM and PenRe OSEMs.  We then began another round of R0 TFs.  TF results pending.  Offsets and gains for the lower stages are as follows:

L1UL 19173 1.565  -9586
L1LL 27412 1.094 -13706
L1UR 24370 1.231 -12185
L1LR 23612 1.271 -11806
L2UL 22949 1.307 -11474
L2LL 24546 1.222 -12273
L2UR 24855 1.207 -12428
L2LR 23608 1.271 -11804

These have been loaded to MEDM.

J. Kissel

The Message: I've cross-checked the calibration of all the ground sensors at the X End-Station, and used that knowledge to gain further confidence in their assessment of ground motion and ground tilt (second attachment). With these confirmed sensors, I tried to figure out why no one can find coherence between the ISI T240 X and either the GND BRS RY or GND T240 X (first attachment). My conclusion is that the ISI ST1 X DOF is limited by re-injected noise from ISI ST1 RY DOF between 20 and 200 [mHz], because we've copied and pasted our X T240 blend filter to RY without being conscious of this tilt-horizontal-coupling path (fourth attachment). I *think* this noise, is T240 sensor noise in this 20 to 200 [mHz] frequency band (see fifth attachment). This can be solved by sacrificing unneeded higher-frequency performance in RY (say between 1-10 [Hz]), and moving the RY blend up a bit, and making the T240 high-pass roll-off more aggressive, or "faster," as a function of frequency (third attachment is current X / RY blends).

%%%%%%%%
% The Deets %
%%%%%%%%
Calibration:
------------
In the second attachment, 2014-09-18_H1EXGND.pdf, I've calibrated everything into translational acceleration units. I summarize here, then explain the details after.
Summary: 
(1) H1:ISI-GND_STS_ETMX_X_DQ                 1e-9 [(m/s) / ct] --> Let DTT differentiate once to acceleration units
(2) H1:ISI-ETMX_ST1_BLND_X_T240_CUR_IN1_DQ   1e-9 [(m/s) / ct] --> Let DTT differentiate once to acceleration units
(3) H1:ISI-GND_BRS_ETMX_RY_OUT_DQ            1.568e-8 [(m/s^{2}) / ct]
(4) H1:PEM-EX_SEIS_VEA_FLOOR_X_DQ            7.9e-9   [(m/s) / ct] --> Let DTT differentiate once to acceleration units
(5) H1:PEM-EX_TILT_VEA_FLOOR_X_DQ            5.5e-8   [(m/s^{2}) / ct]
(6) H1:PEM-EX_TILT_VEA_FLOOR_T_DQ            5.39e-7  [(m/s^{2}) / ct]

For (1) and (2), myself and the SEI group have graciously calibrated these channels into 1 [(nm/s) / ct] in the front end, following the electronics chain as described in D1001575. So I merely have to convert to (m/s), and let DTT handle the differentiation by requesting m/s^{2} / Hz^{1/2} on the units menu.
For (3), Krishna and I have installed a similarly dead-reckoned calibration that we believe is in 1 [nrad/ct]. However, converting to translational acceleration by multiplying by g = 9.8 [m/s^{2}/rad] and by 1e-9 [m/nm], leaves a discrepant factor of 1.6 between the GND T240 and the GND BRS (see pg 1 of 
2014-09-18_H1EXGND.pdf), where there is great coherence, between 10 and 100 [mHz] and we expect the signals to be the same. Also notice the how the harmonics is the 8 [mHz] resonance pollute the spectrum (the BRS has been rung up to +/- 200 [ct] during this measurement period). That's when I invoked the PEM sensors, hoping they would be coherent enough between the sensors to cross-check, but alas, in the 10 to 100 [mHz] region, they're too noisy to really tell if the GND BRS or GND T240 are "right," so I added in the extra factor of 1.6 assuming the T240s were correct, hence 1.6 * 9.8 * 1e-9 = 1.568e-8 [(m/s^{2}) / ct]
For (4), I used the pem.ligo.org prescribed 7.6e-9 [(m/s) / ct], it matched the GND T240 very well (within the 22% quoted precision) in the frequency region where we expect them both to be sensitive to translation, i.e. above 100 [mHz].
For (5) and (6), since the instrument has not yet been successfully calibrated (see LHO aLOG 13623) I assumed the that GND T240 and GND PEM Guralp were correct, and simply scaled the PEM TILT X channel to match them above 100 [mHz], ending up with 5.5e-8 [(m/s) / ct] (and let DTT do the differentiation). I then blindly assumed that the Tilt channel uses the same calibration value, but for rotational displacement, i.e. 5.5e-8 [rad/ct]. Scaling by g = 9.8 [m/s^{2} / rad] that yeilds the above 5.39e-7  [(m/s^{2}) / ct]. It seems to match up reasonably well, and it's not hard to imagine that the electronics chain is the same for both channels, but the sensor appears to be limited by some noise incoherent with the GND BRS in the 10 to 100 [mHz] region.

The Tilt-Horizontal Coupling Model:
-----------------------------------
On the final page of 2014-09-18_H1EXGND.pdf, I plotted the ISI performance against all of the ground sensors, and noted the hump between 10 and 100 [Hz] that looked suspiciously like a blend filter bump. Going on a hunch I've had for a while Similar to what I did in my thesis, knowing that we've thus far only copied and pasted our X blend filters to the RY DOF, I used the same 1-stage, MISO model (e.q. 5.3 on pg 80) to predict how much the residual platform tilt (RY) motion is coupling into the X DOF,
                     G_x         g        x
x              =  -------   *  ----- *  F          * res RY
  from res RY      1 + G_x      w^2       T240 HP
Thankfully, at these low frequencies (f < 1 [Hz]), the ISIs have loop gain, G_x, much much greater than 1, the closed loop gain (the first term) is well-approximated by unity, and I only have to know the blend filter F^{X}_{T240 HP}.

This model shows varying degrees of success.
(1) Between 50 and 300 [mHz], this predicts the X ST1 motion exactly. ISI T240 RY doesn't show coherence, however, but I'm confident that's because it's incoherent sensor noise of the RY loop in this band -- at least up until 100 [mHz]. I'm still confused why the double-peaked microseism (100-200 [mHz]) in ISI X is very coherent with GND X, but (a) doesn't show up in nor is it coherent with the GND RY spectrum, and (b) perfectly matches the shape of the ISI RY motion projected into ISI X. 
(2) The model WAY over predicts the X displacement between 10 and 60 [mHz]. I've triple-checked my blend-filter-multiplication-via-DTT-calibration, and I'm confident I'm doing it right -- see third attachment. Steps:
    - Grab a matlab version of the blend filter from ${SeiSVN}/seismic/BSC-ISI/Common/Complementary_Filters_BSC-ISI/aLIGO/TSheila.mat
    - Ask matlab for its poles and zeros via [Z,P,K]=zpkdata(High_Pass_Filters(1)), where X is the first DOF
    - Turn them from [rad/s] into [Hz], by dividing by -2*pi
    - Copy them into foton, bode plot, and find the correct normalization factor such that the filter asymptotes to 1 at high-frequency (-160.202 [dB])
    - Copy the normalization gain, poles and zeros into DTT and multiply the correct displacement calibration, 
         gain: 1/(2*pi) [rad / (rad/s)] * 1e-9 [rad/nrad] * 9.8 [(m/s^2) / rad] * 1 / (2*pi)^2 [m / (m/s^2)]
         poles: 0, 0, 0
         zeros: [none]
(3) Independent of the model's confusion, at least it shows lots of room for improvement with GND X to ISI X in this region (100 - 700 [mHz]).