What Is Actually in Our One-Second Vertical Channel

Every GeoShake station streams one continuous channel, LNZ, at one sample per second. Until 10 September 2026 its samples were not what the channel code says. This post explains what they were, what they are now, how the value is computed, and where the definition still has soft edges.

What the name promises, and what it used to deliver

In SEED channel naming, L is the ~1 sample/s band, N an accelerometer, Z the vertical axis. Read literally, LNZ promises a vertical acceleration series at 1 sps.

Until the fleet transition at 2026-09-10T14:24Z, each sample was the one-second peak of the three-axis vector magnitude, √(x²+y²+z²), of the demeaned acceleration. That quantity has no direction: it is the same whether the ground moves up, sideways or diagonally. The Z was a claim the data did not keep.

The reason is mechanical. A T1 can be mounted on a floor or on a wall, so the sensor package’s own z axis points up in one installation and sideways in the other: station G274Y, the one in the figure, is wall-mounted, with its body z axis tilted 89.74° from vertical. A definition based on body axes would give a different quantity for every mounting. The vector magnitude avoided that by discarding direction altogether, so it was not a vertical channel either.

The device reports which it is. The same window-mean gravity vector is published with every health and trigger packet, and from its angle to the body z axis we classify the mounting: flat when that axis is within 20° of vertical, wall between 70° and 110°, tilted otherwise. The class is recomputed with every packet, so nobody has to tell us how a unit was installed, and if it is moved the next packet says so. No gyroscope is involved: the LSM6DSO has one, and the firmware switches it off.

The algorithm, step by step

Since firmware 0.9.28 the device computes the value like this, once per one-second window:

1. Sampling. The four LSM6DSO accelerometers on the board are read at about 109 Hz and averaged sample by sample: one three-axis acceleration vector per sample, nothing rotated or filtered.
2. Gravity estimate. The mean acceleration vector of the window is taken as the gravity direction ĝ for that window. There is no long-term filter; each second estimates its own ĝ from its own hundred-odd samples.
3. Demeaning. The window mean is subtracted from every sample.
4. Projection. Each demeaned sample is projected onto ĝ: one signed scalar per sample, the vertical component of ground acceleration in the gravity frame.
5. Peak. The largest absolute value of that projection in the window is the reported sample. The sign is discarded.
6. Output. One sample per second, in integer counts, nominally 1,000,000 counts per m/s², so one count is 1 µm/s².

Because the axis comes from gravity rather than from the enclosure, the result does not depend on mounting: a unit on a wall and a unit on a shelf compute the same quantity. That is what the Z now stands for: gravity-referenced vertical, estimated each second from the window-mean gravity vector.

We no longer call this an envelope, although our own documentation did until recently. An envelope in the signal-processing sense, Hilbert or RMS, is a smooth function bounding a waveform. This is one number per second, the largest |vertical acceleration| seen in that second: a one-second peak absolute vertical-acceleration series. It is non-negative, has no phase, and never crosses zero.

The figure, and how to read it

The figure above is a real record. Station GW.G274Y, Fiordland, New Zealand, triggered on 2 September 2026 at 06:13:40 UTC on a magnitude 5.3 earthquake 77 km away. The cyan trace is the triggered burst, ENZ, at about 108 samples per second: six seconds before the trigger, six after, gravity-referenced vertical, signed. The white step is the one-second peak |vertical| computed from that trace with the algorithm above.

Two things about provenance. On 2 September the live LNZ was still the vector magnitude, so the white series is not what the archive holds for that minute; it was derived afterwards from the burst, which has been published in the gravity frame since 5 August 2026. And the burst is a twelve-second window, so this is the P arrival only: the catalogue origin time is 13.0 s before the trigger, the P residual +0.05 s, and the S wave, expected about nine seconds after P, falls outside the record.

Two things to read off the step. The peak in the record is 0.039 m/s². And the step rises in the window before the trigger line, not at it: the detector needs a few samples above threshold before it fires, so the window holding the first P energy is already high while the trigger timestamp lands slightly later. If you time an arrival from LNZ, expect it to lead the trigger by up to one window, quantised to a second.

Limitations, stated plainly

• The scale is nominal. Counts convert to m/s² with the datasheet sensitivity; there is no per-unit calibration, no shake-table test, no poles and zeros, and level=response returns that nominal figure. Amplitudes are indicative, not metrologically traceable.
• The gravity estimate can be pulled by strong shaking. ĝ is the window mean and nothing else. In weak motion that is a good estimate of gravity; in strong motion, if the shaking within a window is asymmetric, the mean tilts away from gravity and the projection axis with it. We have not quantified this.
• Timing is NTP, not GNSS. The device clock is set by SNTP from pool.ntp.org, once an hour; there is no GNSS receiver and no PPS. The ingest server records its own receive time alongside the device timestamp.
• Some stations are still on the old definition. At the time of writing, 12 September 2026, eleven of the fourteen listed stations produce the new series. Three, QA2HF on 0.9.27 and BZAZP and G8M8U on 0.9.14, still produce the vector magnitude; their LNZ carries a TRANSITIONAL comment in StationXML until they update over the air.
• The archive before 10 September is the old definition. Treat any LNZ sample timestamped before 2026-09-10T14:24Z as a vector magnitude. The channel code did not change across that boundary; the StationXML history comment states the date.

How to read it

Anchor your processing to the channel <Description> in StationXML, not to the code. The description is the contract; its wording today is older than this post, but it describes the algorithm above, and the comments under it carry the date boundary and, where relevant, the TRANSITIONAL flag.

from obspy.clients.fdsn import Client

client = Client(base_url="https://api.geoshake.org")
inv = client.get_stations(network="GW", station="G274Y", level="channel")
for cha in inv[0][0]:
    print(cha.code, "-", cha.description)

For the live stream:

from obspy.clients.seedlink.easyseedlink import create_client

def on_data(trace):
    print(trace.id, trace.stats.starttime, trace.data.max())

client = create_client("seedlink.geoshake.org:18000", on_data)
client.select_stream("GW", "G274Y", "LNZ")
client.run()

Do not rotate LNZ with the horizontals and do not treat it as a signed component. The signed three-component set is ENZ, EN1, EN2, published only while a station is triggered.

On the name

By SEED, the three letters are right: 1 sps band, accelerometer, vertical. But the quantity is a derived product, a peak over a window rather than a sampled waveform, and SEED has no letter for that. An archive taking this channel in may prefer a different code under its own conventions; if so, the code will change and the description will not.

The network is GW, permanent and FDSN-registered, DOI 10.7914/ft1b-4x43; the data centre is GEOSHAKE. If you use the data, cite the network as the FDSN issued it:

GeoShake (2026): GeoShake Global Seismic Network. International Federation of Digital Seismograph Networks. Dataset/Seismic Network. https://doi.org/10.7914/ft1b-4x43