1D convolutions and temporal pooling

"They gave me a bank of tiny filters and told me to find whatever repeats. Turns out a footstep repeats. So does a failing bearing. So does an atrial flutter."

A Pattern-Matching AI Agent

This section assumes you can already picture a sensor window as a tensor of shape (channels, time), which Section 13.1 laid out. It leans on the convolution and filterbank intuition from classical signal processing in Chapter 6, and it treats sampling rate and the causal constraint as given from Chapter 3. We keep the book's notation: a window is \(x \in \mathbb{R}^{C \times T}\) with \(C\) channels and \(T\) time steps, and a layer produces feature maps \(z \in \mathbb{R}^{C' \times T'}\).

The 1D convolution as a learned, sliding matched filter

A 1D convolution slides a small weight kernel along the time axis and, at each position, takes an inner product between the kernel and the window of input beneath it. For an input with \(C\) channels, a single output channel \(o\) computes

where \(K\) is the kernel size (its length in samples), \(w_{o,c}\) are the learnable weights, and \(b_o\) is a bias. The what is a bank of \(C'\) such kernels, each learning to respond to a different local shape. The why is three properties the sensor setting rewards heavily. First, weight sharing: the same kernel is applied at every \(t\), so a heel-strike detector trained on one stride generalizes to every stride in the recording, and the parameter count depends on \(K\), not on \(T\). Second, locality: each output looks only at a short span, matching the fact that discriminative sensor events are short relative to the window. Third, translation equivariance: shift the input in time and the output shifts identically, so the network does not have to relearn a pattern for every possible arrival time. This is the matched-filter idea from Chapter 6 with the pencil handed to gradient descent: the same sliding inner product, except the template is learned from labeled examples rather than designed by hand (the tradeoff between the two is the subject of Section 13.4).

Sizing the layer: kernels, stride, padding, and receptive field

Three hyperparameters set the geometry, and getting them right is most of the practical skill. Kernel size \(K\) is a duration once you multiply by the sample period: at 50 Hz a \(K=15\) kernel spans 0.3 seconds, roughly one footstep, which is why you size kernels in milliseconds of physics rather than in abstract taps. Stride \(S\) is how many samples the kernel hops between evaluations; \(S=1\) keeps full temporal resolution, while \(S=2\) skips every other position outright, cheaper than convolving every step and pooling, but risking aliasing if a transient falls inside a skipped gap. Padding \(P\) adds \(P\) zero-valued samples to each end of the input before the kernel slides over it; without it, a valid convolution shrinks the output by \(K-1\) samples per layer, eroding the window's edges as layers stack. Padding is therefore the choice of whether a layer shrinks the sequence ("valid", \(P=0\)), preserves its length ("same", \(P=(K-1)/2\) for odd \(K\)), or grows it; same-padding is the default in sensor stems because it keeps a later prediction's time index aligned with the timestamp that produced it. In general, the output length is

The quantity that ultimately decides what the network can see is the receptive field: the span of input samples that influence one output value. Stacking \(L\) convolutions of kernel \(K\) and stride 1 grows the receptive field to \(1 + L(K-1)\), which is linear in depth and often too slow to reach the seconds-long context a sensor task needs. That limitation is exactly what motivates dilation and multiresolution stacks, taken up in Section 13.3, and the long-context temporal convolutional networks of Chapter 14. One more choice matters for deployment: a causal convolution pads only on the left so \(z[t]\) never reads \(x[t{+}1]\), preserving the online constraint that a streaming model must obey.

Temporal pooling: from a stream of responses to a decision

A convolution turns one stream into many streams of detector responses, but a classifier usually needs a fixed-size vector, and it should not care where in the window a gesture happened. Temporal pooling supplies both. Max pooling over a length-\(m\) region reports the strongest response, answering "did this pattern appear at all?" and granting tolerance to small time shifts. Average pooling reports the mean, preserving how sustained a pattern was, which suits energy-like features. The most useful variant for windowed sensor classification is global pooling, which collapses the entire time axis to a single value per channel, so a variable-length or long window becomes a fixed \(C'\)-vector regardless of \(T\). This is the neural echo of the summary statistics you computed by hand in Chapter 8, now learned end to end. When to use which: max for sparse, transient events (a fall, an arrhythmic beat); average for diffuse, ongoing states (walking versus standing); and strided convolutions when you want the network, not a fixed rule, to decide how to downsample.

The code below builds exactly that stem in PyTorch and confirms how the tensor shape marches from (3, 128) down to a single vector per window. The shapes it prints are the receptive-field and pooling arithmetic above, made concrete.

import torch, torch.nn as nn

class HARStem(nn.Module):
    def __init__(self, in_ch=3, width=32, n_classes=6):
        super().__init__()
        self.features = nn.Sequential(
            nn.Conv1d(in_ch, width, kernel_size=15, stride=2, padding=7),  # 0.3 s kernels
            nn.BatchNorm1d(width), nn.ReLU(),
            nn.Conv1d(width, width, kernel_size=9, stride=2, padding=4),
            nn.BatchNorm1d(width), nn.ReLU(),
            nn.Conv1d(width, 2 * width, kernel_size=5, padding=2),
            nn.BatchNorm1d(2 * width), nn.ReLU(),
        )
        self.pool = nn.AdaptiveAvgPool1d(1)          # global temporal pooling
        self.head = nn.Linear(2 * width, n_classes)

    def forward(self, x):                            # x: (batch, 3, 128)
        z = self.features(x)                         # -> (batch, 64, 32)
        z = self.pool(z).squeeze(-1)                 # -> (batch, 64)
        return self.head(z)                          # -> (batch, 6)

x = torch.randn(8, 3, 128)
print(HARStem()(x).shape)                            # torch.Size([8, 6])

What the filters learn, and how to keep it honest

Because the first-layer kernels operate directly on the raw signal, they are interpretable: trained on periodic motion they tend to converge to band-limited, oscillatory shapes that behave like a learned filterbank, a phenomenon we return to in Section 13.7 on inspecting learned filters. That interpretability is a gift and a trap. A convolution shares weights across time but not across channels or amplitude, so if one accelerometer axis is scaled differently or a channel drifts, the learned filters bake in that idiosyncrasy. This is why normalization and augmentation (Section 13.5) are not optional garnish but part of making convolutional features transfer across units. It is also why evaluation must respect the arrow of time: pooling and striding do not excuse you from subject-wise, chronological splits; skip the leakage-safe discipline of Chapter 5 and it will hand you an accuracy the field never reproduces.

What's Next

In Section 13.3, we confront the receptive-field bottleneck head on: stacking plain convolutions to reach seconds of context is slow and parameter-hungry, so we introduce dilated convolutions and multiresolution stacks that grow the receptive field exponentially with depth, letting a compact network see both a single heartbeat and the rhythm it belongs to at once.