FYI - Picket Fence data server comment - all good

Brian, Edgard, TJ Shaffer,

I got a group email from the USGS letting people know about an update to their data services. We checked and this does not impact the picket fence. I'm putting some email here for documentation

-Brian

 ---

 

From: Edgard Luis Bonilla <edgard@stanford.edu>
Subject: Re: [Data Announcements] EarthScope fdsnws-dataselect service has moved to service.earthscope.org
Date: January 5, 2026 at 5:01:56 PM PST
To: Brian Thomas Lantz <blantz@stanford.edu>
Cc: TJ Shaffer <thomas.shaffer@LIGO.ORG>, "michael.thomas@ligo.org" <michael.thomas@ligo.org>

Confirmed. The picket fences work. 

Please let me know if anyone sees any issues and we will address them.

(... and ...) 

I don't think this will be an issue. We don't use any restricted data for the Picket Fence. 

I will go down to the lab before end of day to confirm we can still run it. 

Best,
Edgard Bonilla

From: Brian Thomas Lantz <blantz@stanford.edu>
Sent: Monday, January 5, 2026 4:11 PM
To: Edgard Luis Bonilla <edgard@stanford.edu>
Cc: TJ Shaffer <thomas.shaffer@LIGO.ORG>; michael.thomas@ligo.org <michael.thomas@ligo.org>
Subject: Fwd: [Data Announcements] EarthScope fdsnws-dataselect service has moved to service.earthscope.org
 
Edgard - 
I got this notice about the seismic network over the break. Do we need to do anything about this?
-Brian

Begin forwarded message:

From: Chad Trabant <chad.trabant@earthscope.org>
Subject: [Data Announcements] EarthScope fdsnws-dataselect service has moved to service.earthscope.org
Date: January 1, 2026 at 11:47:37 AM PST
To: data-announcements@earthscope.org
Reply-To: data-announcements+managers@earthscope.org

Happy new year!

EarthScope's fdsnws-dataselect web service, the primary source of miniSEED data from our seismological repository, has moved from service.iris.edu to service.earthscope.org as part of our cloud transition.

Details are below and documented on the service documentation page:
https://service.earthscope.org/fdsnws/dataselect/1 

We've worked to make this transition seamless, but if you encounter issues please contact help@earthscope.org.

Action required for restricted data users: You will need new credentials. Visit https://www.earthscope.org/user, create an account (if you do not already have one), then:

navigate to the
 Credentials tab

click "REVEAL MY
 CREDENTIALS," and then "CREATE FDSNWS CREDENTIALS" if none exist.  These credentials are specific to you and should be kept private.

Redirects from the old service to the new

The old service location (at service.iris.edu) continues to operate, but instead of providing data redirects to the new location.  The vast majority of web software follow these redirects automatically or can be configured to do so.

New HTTPS (TLS v1.2+) requirement

The service now requires secure HTTPS, specifically TLS 1.2 or later. Requests to the un-secure HTTP endpoint will be redirected to the HTTPS endpoint according to current best practices.

Some older software may not follow redirects from unsecure HTTP to secure HTTPS.  Configure the software, if possible, to use the direct URL to the service https://service.earthscope.org/fdsnws/dataselect/1

Some older software may not support TLS 1.2+.  As this standard was defined in 2008 and became default on most client and server software by 2016, we do not anticipate this causing many problems.

More details for client developers and power users
Changes in the new service:

Some output formats are not yet supported: SAC and text. These will be added later.

The
 following parameters are being permanently retired: quality,
minimumlength,
longestonly,
repository,
szsrecs.

With the removal
 of the szsrecs
 parameter the service will no longer remove zero-sample records (as was the previous default), which matches the behavior of all other data center implementations.

There are limits
 on the volume of data that will be returned. We recommend limiting requests to one station for a 24-hour period at the most.

Some HTTP response codes for errors have changed to be more precise, but they remain
 broadly recognized codes.

Please reach out to help@earthscope.org if you have any questions or run into trouble with this new service.

Thanks,
The EarthScope Data Services team

 

-- 
More info on EarthScope mailing lists: https://www.earthscope.org/news/mailing-lists/
--- 
You received this message because you are subscribed to the Google Groups "Data Announcements" group.
To unsubscribe from this group and stop receiving emails from it, send an email to data-announcements+unsubscribe@earthscope.org.
To view this discussion visit https://groups.google.com/a/earthscope.org/d/msgid/data-announcements/CAGJXgS5UnSPZOAt5fw8YUOTTSfHJbMJoS6SDC_LgW4ZVjv91PA%40mail.gmail.com.

Workstations updated

Workstations were updated and rebooted.  This was an os packages update.  Conda packages were not updated.

OMC HV Power Supply

WP 12953

I was notified of a buzzing/whistling sound coming from the CER mezzanine. The HV power supply for the OMC PZT was found with audible alarm on and LCD screen not displaying correctly. Power supply was power cycled. Unit tripped immediately. With unit off, the field cabling going to LVEA was disconnected. Unit tripped when powered on. Unit was replaced with spare.

F. Clara, R. McCarthy, M. Pirello

h1ascimc model change and DAQ restart

Jennie, Erik, Dave:

Jennie's new h1ascimc model was installed at 13:30 Mon 05Jan2026. This required a DAQ restart to add 2 slow channels.

At 13:32 we restarted the 1-leg, followed by the 0-leg at 13:37. GDS1 did not need a restart.

Following this DAQ restart we had 3 sponaneous restarts of FW1 after it had ran for 27:48, 8:02 and 6:22 minutes respectively. At the time of writing it has been running with no further restarts for an hour.

 

 

OPS Monday Day shift start

TITLE: 01/05 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 12mph Gusts, 6mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.31 μm/s 
QUICK SUMMARY:

• HAM1 and HAM7 work today
• Picket fence IOC seems to not be running (CDS)

Earthquake tripped both end station SWWDs Fri 02Jan2026 06:22 PST

Both end station test mass Software Watchdogs tripped around 06:22 during an earthquake. The Seismic systems also tripped for ETMX and ETMY. The TMS suspensions did not trip.

At 10:30 I reset these SWWDs, end station SUS and SEI are driving again.

VACSTAT detected EX vacuum glitch 03:39:34 Thu 01Jan2026 PST

VACSTAT detected a small beamtube vacuum gas release originating at the EX BT-IonPump which is located at approx -300m from EX.

Pressure trend shows the pressure at PT527 increased from its baseline of 1.9e-09 to a max of 1.4e-08 Torr. Several seconds later the EX gauges showed a minimal increase when the dispersed molecules reached them.

PT527 had pumped back down to its baseline by 04:30, +50 minutes after the glitch.

VACSTAT raised a single-gauge alarm for PT527, its rate-of-rise did not trip (reached 40% of trip level) but its Delta-P did trip (reached130% of trip level).

At 08:39 I restarted the vacstat_ioc.service on cdsioc0 to clear this alarm. As before, HAM1's gauge is currently set to disabled.

Need model restart in week of Jan 5th to correct JAC/IMC models

Jennie W, Dave B,

 

Jeff and I put in a bypass in the h1ascimc model (see alog #88465) so we could put in the simulink infrastructure to switch between using the PSL periscope PZT as part of the IMC control or as part of the JAC control.

At the moment the switch 'H1:ASC-IMCJAC_PZTOUTSW' is set to ON which should let the IMC servo use the PZT.

However the logic I put in will not switch the feedback to take inputs from the JAC servo if I turn the switch off.

This is because Choice 2 and 3 in the picture are set to pass their first input if the switch output is '>= 0', so whichever state it is in the IMC PZT output will be sent to the DAC.

I have changed these choices to >0 so that the top input (IMC PZT output signal) will be sent to the DAC if the switch is 1 and the bottom input (JAC PZT output signal) will be sent to the periscope otherwise.

I committed the changed /opt/rtcds/userapps/release/asc/h1/models/h1ascimc.mdl to the svn.

Mechanical Room Zeks Dryer Skid Cameras Linked on CDS web page

I have added a link to the Vacuum section of the CDS web page which opens the latest Zeks dryer skid camera images. These images are running on the virtual FOM cdsws12, display=5. They are updated every minute.

Gerardo has placed a clock on top of the skid to give a timestamp.

link to image is:

cdsws12_5-1.png

 

fire pump alarms bypassed for churn testing

Bypass will expire:
Mon Dec 22 01:07:27 PM PST 2025
For channel(s):
    H0:FMC-CS_FIRE_PUMP_1
    H0:FMC-CS_FIRE_PUMP_2
 

Camera install in Mechanical Room viewing Zeks Air Dryer

Gerardo, Richard, Erik, Dave:

Over the holiday break we need to remotely view the operation of the Zeks Eclipse air dryer skid in the mechanical room to ensure no moisture gets into the LVEA chambers.

I initially setup a fisheye camera (a repurposed gate-cam), which gave a good view of the panel's LEDs and the mechanical gauges, but lacked the resolution to view the LCD display screen to see the Dew Point signal.

I then installed an Axis 214PTZ camera, which was able to zoom into the LCD display and read the values.

So we are now running both cameras side-by-side. 

sw-mech-aux was configured to have both ports 13 and 14 on the VID-LAN (10.106.0/24).

I ran two 60-foot cat5e ethernet cables from the vacuum rack (where the switch is located), over to the front of the Zeks skid, using the overhead mezzanine railing to provide a temporary "cable tray". 

Camera	name/ip	ethernet connection
fish-eye (POE)	wincam (10.106.0.243/24)	long run to POE injector on top of vac rack, short run to switch port14
PZT cam	mechcam (10.106.0.244)	direct to switch port13

Because the Axis camera is AC powered, we ran an extension cable from the vac rack to the base of the skid, passing it under the stairs to prevent it being a trip hazard.

Frontend Network Switch Failure, 12:04 Friday 19th December 2025

Erik, Tony, TJ, Jonathan, Dave:

at 12:04 Fri 19dec2025 PST we had a MSR network switch failure which took down the network for all the front ends, the /opt/rtcds NFS server and Guardian.

The Brocade Ruckus Network Switch SW-MSR-H1FE-STK (1/3) was found to be powered off (no LEDs illuminated). This is a ICX7150-48-4X10GR-RMT3 48port unit with firmware version 08.0.95g.

This unit is being powered by a Geist power distribution box, which itself is UPS powered, so all power cords are ORANGE. A second switch is also being powered by the Geist, and both it and the Geist were powered up.

We disconnected the failed switch's power cord (as found it seemed to be well connected, not loose) and plugged it back in, the switch did not light up. We then ran a longer power cord to the main rack power strips, again the switch did not light up. We then returned to the original power cord from the Geist.

While we were scratching our heads planning the next move we noticed the switch was lit up. We think it took at least a few minutes to show signs of life after its power cord was inserted.

We then let it boot up, which took a suspiciously long time, we expected something like 5 minutes but it was actually close to 15 minutes. At that point the network was returned to all the systems attached to this switch.

At this point all the front ends had returned in their running state, except h1sush12 and h1asc0 which had persistent DAQ errors. We restarted these frontends.

Many Guardian nodes were disconnected from the frontends, so we elected to reboot h1guardian1. It came back up with no problems.

Currently we do not know why this switch powered down. If it happens again our options are:

1) power it directly from the UPS rack power strip (i.e. not from the Geist) and give it plenty of time to show it is powering up

2) replace it with a spare switch

HAM1: JM3 (JAC) and PM1 Satamps replaced (in LVEA), JM2 and JM3 cables swapped (in CER)

Fil, Rahul

This morning we replaced the unmodified Satamps for JM3/PM1 (both TT suspension) with the modified version - as per alog 88584. Given below are the details,

Old satamp s/n - S1200173

New Satamp s/n - S2500407

The adc counts of the bosems on JM3 and PM1 have dropped by 25% approximately due to the above change, hence we will have to compensate that on the filter side (Oli is currently on it). 

Also, we have swapped the cables for JM2 (mount) with JM3 (SUS TT) in the CER - as per alog 88584, this is now consistent with the wiring diagram.

JM1 and JM3 filter banks populated to align with current electronics

Fil, Oli

The JM1 and JM3 filter banks were populated, with some things that need updates found along the way.

JM1 and JM3 were populated based on PM1's filter banks. The only banks that aren't the same as PM1 are the OSEMINF and WD_OSEMAC_BANDLIM satamp compensation filter modules and the COILOUTF filter modules.

First, I filled out all the filter banks as a direct copy of PM1 using python3 /ligo/home/oli.patane/Documents/WIP/copySUSfilters.py PM1_M1 JM1_M1 (then replacing JM1 with JM3). This script copies over the filter modules in OSEMINF, COILOUTF, WD_OSEMAC_BANDLIM, WD_OSEMAC_RMSLP, LOCK, and DAMP filter banks. However, the OSEMINF,  WD_OSEMAC_BANDLIM, and COILOUTF filter banks are not the same as PM1, so those need to be updated.

OSEMINF and WD_OSEMAC_BANDLIM filter banks
In November (88162) the JAC electronics were installed and the satamps that were suppposed to be installed were S2500406 for JM1 and S2500407 for JM3 / PM1. Both of these are modified satamps per ECR E2400330. JM1 had the correct satamp installed but JM3 / PM1 had S1200173 installed instead, which is not modified and has a different frequency response. 
JM1 - JM1 has the correct updated satamp, which Jeff measured the frequency response for each chassis' channels for, so I updated the compensation filters for JM1 with the exact compensation based on the measurements for each channel. I ran python3 sustrunk/Common/PythonTools/satampswap_bestpossible_filterupdate_ECR_E2400330.py -o JM1 to fill out each OSEMINF FM1 and WD_OSEMAC_BANDLIM FM6.
JM3 / PM1 - On the flip side, the compensation filters for JM3 and PM1 are the same as what PM1's have been - 10:0.4: zpk(10:0.4:1) in OSEMINF FM1 and WD_OSEMAC_BANDLIM FM6.

COILOUTF filter banks
The coil driver for JM1 is S1106042, and the coil driver for JM3 is S2500411.
The PM1 coil drivers have had ECR E2200307 done, which affects the filter in FM6, and I've been searching to see if I can verify whether the JM coil drivers have had this (or the expansion ECRs, E2200307 or E2400048) done to them.
JM1 - The e-traveler doesn't mention it having been modified, just that it was taken out of production and replaced with a modified one (64166). I haven't been able to find anything anywhere that mentions that it ended up getting modified, so I am inclined to think that it might not have this modificiation. Thus, for now I am installing the filters that work for the unmodified driver. These filters are:
    - AntiLPM1: zpk([0.9;211.883],[9.99999;20.9999],1,"n")
JM3 - The e-traveler for the driver says that it's been modified per T2100410, which is the modification that is done as part of the ECRs mentioned above, so JM3 coil driver is modified and thus has the same AntiLPM1 filters as PM1. These filters are:
    - AntiLPM1: zpk([0.5;3174],[52.32;50.77],1,"n")

JM1 OSEMINF, WD_OSEMAC_BANDLIM, and COILOUTF filter banks, COILOUTF AntiLPM1 foton

JM3 OSEMINF, WD_OSEMAC_BANDLIM, and COILOUTF filter banks, COILOUTF AntiLPM1 foton

All of these filters have been loaded in and commited to svn as r34277.
We are hoping that the modifications they are supposed to have will be able to be done soon.

h1susham1 model edit and restart

Erik, Rahul, Jeff, Fil, Oli

Earlier today we realized that the JM3 model ADC inputs did not match up with the cabling documentation. The documentation lists the order of the OSEM PD inputs into the AA chassis as JM1: CH 0-3, JM2: CH 4-7, JM3 CH 8-11. However, the h1susham1 model had the inputs for JM3 as CH 4-7, accidentally forgetting to leave room for the maybe-one-day JM2. This resulted in a bit of confusion until we figured this out. We temporarily moved the JM3 OSEM PD to AA chassis cable into the CH 4-7 inputs to match with the model so installation work could proceed, but once they were done we wanted to change the model to match up with all the documentation we had. To do this I just edited the h1susham1.mdl file and changed the JM3 ADC numbers from 1_4,1_5,1_6,1_7 to 1_8,1_9,1_10,1_11 and committed the model as r34274 (before, after). I then also updated susjm3_overview_macro.txt to have those adc number match and that was committed as r34275.

Erik restarted the h1susham1 model and everything came back fine (88581). Since earlier we had swapped the OSEM PD cable for JM3, the JM3 readouts currently look like nothing because we still need to swap that cable back to its correct spot tomorrow.