EEG Functional Connectivity as a BCI Feature: Phase Coupling, Coherence, and Bayesian Decoding

Most BCI feature extraction pipelines focus on what happens within a channel — bandpower, spatial filtering, or embeddings from foundation models. But in many cognitive and affective paradigms, the discriminative signal is plausibly network-level: coordination across distributed regions rather than a localized oscillatory change.

That raises a pragmatic question: when do simple functional connectivity estimates add information beyond strong spectral/spatial baselines, and when are they mostly confounds?

This post focuses on two workhorse metrics (PLV and band-limited coherence), the assumptions they smuggle in, and a pragmatic way to operationalize them in Nimbus Studio — with the usual caveats around window length, dimensionality, and volume conduction. If you're also revisiting the fundamentals of windowing and event alignment, see Epoch Design and Trial Structure in BCI: How Your Protocol Shapes Your Decoder.

What Is Functional Connectivity?

Functional connectivity refers to statistical relationships between signals from spatially separate brain regions. Unlike structural connectivity (which asks are these regions physically connected?), functional connectivity asks are these regions co-activating?

The two most common metrics are:

• Phase Locking Value (PLV): measures phase synchrony between two channels at a given frequency. PLV = 1 means perfectly synchronized phases; PLV = 0 means random phase relationships.
• Coherence: measures frequency-domain correlation between two channels within each trial (Welch estimate averaged over your configured band). Amplitude-sensitive; complementary to PLV.

Both metrics produce a connectivity matrix — a channel × channel array of coupling strengths — that can be summarized into feature vectors for downstream classification.

When Connectivity Features Help

Standard spatial filters like CSP are optimal for capturing variance differences between motor imagery classes. Connectivity features are most plausible when the decoding problem involves network-level dynamics:

• Mental workload and cognitive load tasks: Frontal-parietal coherence in the alpha/theta band is a reliable correlate of working memory load.
• Error-related negativity (ERN): Fronto-central phase synchrony in the theta band tracks error monitoring, relevant for passive BCIs that detect mistakes.
• Resting-state classification: When there's no clear event structure, connectivity patterns can distinguish brain states where ERPs are absent.
• Multi-class tasks with subtle class boundaries: Combining connectivity with CSP or spectral features (e.g. via exported Python) can improve margin when within-class variance is high.

In practice, connectivity features work best as a complement to, not a replacement for, spatial or spectral features. Conversely, in paradigms where the effect is largely driven by localized sensorimotor rhythms (classic MI), connectivity can become a high-variance feature set that overfits unless you’re very aggressive about selection and validation.

Extracting Connectivity Features in Nimbus Studio

Nimbus Studio's Functional Connectivity node (connectivity) computes pairwise PLV or coherence from epoched EEG — one method and one frequency band per node instance. It slots naturally into the standard preprocessing pipeline:

custom_data → highpass_filter → bandpass_filter → epoching → connectivity → feature_selection → NimbusLDA → results_output

The node outputs a features vector per trial and the full connectivity_matrix artifact for inspection and graph-theoretic summaries.

A few practical notes:

Epoch length matters. PLV and coherence require enough data to estimate stable phase relationships. Short windows (< 500 ms) yield noisy estimates; aim for 1–2 second epochs minimum. If your paradigm requires shorter windows, consider averaging connectivity matrices across repeated trials before classification.

Feature dimensionality scales quadratically with channels. A 64-channel EEG yields 2,016 pairwise features per band (upper triangle of a 64 × 64 matrix). The node also exports the full connectivity_matrix artifact for inspection (UI charts downsample beyond 32 channels). The kernel supports up to 128 channels. Always pair the Functional Connectivity node with the Feature Selection node downstream (F-score or mutual information) to keep feature count tractable and avoid overfitting. If you do feature selection, treat it as part of the model and run it inside cross-validation (nested CV if you’re tuning the number of features), otherwise you’ll overestimate performance. (For more on how window length and overlap decisions interact with downstream model stability, see this deep dive on epoch design.)

Volume conduction is a confound. Nearby channels share signal due to the resistive spread of current through the skull — this inflates apparent coupling even when no true synchrony exists. Applying a Laplacian re-reference via Nimbus Studio's Re-referencing node before computing connectivity suppresses volume conduction and produces more interpretable network features. Laplacian helps, but it doesn’t “solve” the problem; if connectivity is central to the claim, consider metrics designed to suppress zero-lag coupling (e.g., imaginary coherence / wPLI) or moving to source space.

Bayesian Decoding on Connectivity Features

Once you have a compact, well-selected connectivity feature vector, you can treat it like any other tabular feature set, and use the Nimbus Python SDK classifiers in the usual way:

• NimbusLDA is the natural first choice when connectivity features are roughly Gaussian per class — especially after feature selection reduces dimensionality.
• NimbusQDA is worth trying when class-specific covariance structure differs meaningfully — for example, when one mental state shows tight coupling and another shows scattered phase relationships.
• NimbusSoftmax handles multi-class problems where you need to distinguish three or more connectivity states.

All three expose calibrated posterior probabilities on every prediction. This matters especially for connectivity features, which tend to be noisier than CSP features on small datasets — the posterior lets you threshold predictions and abstain on uncertain trials rather than committing to a noisy label. The SDK's evaluate_rejection_policy function makes it straightforward to tune this tradeoff empirically.

If you want a practical framework for turning posteriors into a deployable “act vs abstain” decision rule, Confidence-Gated BCI: How Entropy and Rejection Policies Keep Decoders Reliable in the Real World walks through entropy thresholds, calibration, and ITR tradeoffs.

A Note on Graph-Theoretic Summaries

The raw connectivity matrix isn't the only representation available. Graph theory offers interpretable summaries that compress the full matrix into a handful of scalars:

• Clustering coefficient: how densely connected a channel's neighbors are
• Global efficiency / path length: average shortest path between nodes, inversely related to integration
• Hub strength: which channels dominate the network's topology

These features reduce dimensionality without necessarily losing discriminative information. Nimbus Studio's Functional Connectivity node outputs the full connectivity_matrix artifact, which you can post-process in Python — for example using NetworkX — before passing summarized graph features into the SDK.

Putting It Together

A practical connectivity-based pipeline for a cognitive load BCI in Nimbus Studio might look like:

1. Hardware Device or Custom Data for EEG input
2. Highpass Filter (0.5 Hz) + Notch Filter (50/60 Hz) + Bandpass Filter (4–30 Hz)
3. Re-referencing (Laplacian) to reduce volume conduction
4. Epoching (1.5 s windows locked to task events)
5. Functional Connectivity (connectivity, PLV, theta band 4–8 Hz — add a second node or exported script for alpha if you need both bands)
6. Feature Selection (mutual information, top 50 features)
7. NimbusLDA or NimbusQDA with calibrated posterior — optional Decision Policy before deploy
8. Results Output for accuracy, confusion matrix, confidence statistics, and κ/ITR

This stack uses documented Nimbus Studio nodes at every step. To combine connectivity with CSP or bandpower features, concatenate feature vectors in exported Python (there is no built-in feature-merge node today). Pipelines with Evaluation Plan must keep a single epoching → feature → classifier path — parallel fitted branches (e.g. two CSP nodes) are rejected at validation. No shipped template uses connectivity yet; wire the graph yourself or start from a nearby MI template and swap the feature node.

If you're building an end-to-end workflow (live capture → structured export → training → deployment), BCI Calibration with Nimbus Studio: From Hardware to Trained Decoder outlines the full graph and how to carry priors across sessions.

Conclusion

Connectivity features are attractive because they operationalize a network-level hypothesis, but they are also easy to misinterpret: windowing choices, referencing, and common-source effects matter. If you’re exploring them, it’s worth (i) validating estimator stability vs. window length, (ii) controlling dimensionality with leakage-safe feature selection, and (iii) using session-wise evaluation when possible. In the best case, connectivity becomes a complementary feature family—not a replacement for strong spectral/spatial baselines. If you see performance degrade over long sessions, Neural Drift and Why It Breaks Your BCI Classifier (And How Adaptive Bayesian Models Fix It) is a useful companion read.