ASCT manual
  • About ASCT
  • Getting Started
    • Installation
    • Introduction
  • Manual
    • Run Control
    • Data import
    • Preprocessing
    • Experimental design
    • Sensor space AR (AR1)
    • ICA decomposition
    • ICA-based AR (AR2)
    • ICA2 and classification
    • Source localization
  • Signal Reconstruction
  • Connectivity estimation
  • Statistics, visualization, and data export
  • Appendix
Powered by GitBook
On this page
  • Directed Transfer Function
  • Connectivity settings

Connectivity estimation

PreviousSignal ReconstructionNextStatistics, visualization, and data export

Last updated 1 month ago

Directed Transfer Function

A theoretical introduction to the connectivity estimation based on the Directed Transfer Function (DTF) can be found elsewhere. Shortly, the method uses multivariate autoregressive modelling (MVAR) to predict the future of a given S1 signal based on its own past. If this prediction is improved when also including the past of another signal, S2, we may conclude that S2 is causal for S1. This is an application of the Granger causality principle. DTF is a multivariate method that estimates causal relationships in a set of signals at once, without pairwise comparisons.

Connectivity should be estimated based on reconstructed signals.

Both uncorrected signals and leakage-corected signals results are saved. In normal experimental practice, please consider the laeagage correction results only. Uncorrected may be plagued with spurious effects.

Connectivity settings

It is possible to create multiple versions of connectivity with different settings, which are named using con.conName parameter and stored in the 8_CONN/[conName] subdirectory.

MVAR settings include model order, con.mvarOrd, which determines the number of samples that are included in the prediction of model coefficients. Model order is dependent on the actual sampling rate; for the recommended sampling (125-128 Hz), the order should be set around 7 samples.

By default, connectivity is estimated using all defined ROIs and using the full epoch as defined by seg settings. To limit these, con.chanSel can be used to define ROIs to analyze (for all, set it to '1-'). This parameter can be used if you want to analyze a subset of ROIs only, when for example ROI from different functional networks are defined, but only one network is currently in the scope.

When con.useRange is set to 1, only a fraction of defined epochs will be taken into account during connectivity estimation, as provided by con.timeRangeStart and con.timeRangeEnd parameters, that define the start and end of the relevant data relative to epoch start (in seconds). When disabled, the whole epoch is analyzed, as defined in the seg section.

Saving files

The results of connectivity estimation are saved in matrices in 8_CONN/[con.conName]/lc/DC.. separately for all defined DSs (data configurations). The 'multin' files are the source files, and 'multout' contain connectivity data for a given dataset. Inside these file, all the settings used for connectivity estimation can be found in the mv array. The NDTF matrix that contains connectivity DTF values has three dimensions: destination ROI index, origin ROI index, and frequency (from 0 to 50 Hz in 0.5 Hz bins).

Sample connectivity results with simulated data, where ground truth connectivity was limited to LMPF -> LAG and RAG -> PCC connections (SRC). Results without leakage correction (MNE unc) show not only the true connections, but also spurious ones. After leakage correction (MNE lc) the DTF estimations are similar to the original connectivity.