-
Notifications
You must be signed in to change notification settings - Fork 27
Defining conditions
There are 'two' ways to get your conditions imported: automatically using STUDY or importing .txt
or .mat
files.
If you have each event described in one or several channels and have this imported in EEGLAB. From the study menu, you should see those events as categorical or continuous variables. You can then 'create' a design, selecting the variables you want. The other way is to create text or .mat
files and through the LIMO interface, import those.
Let's say you have 3 conditions, then all you need is a text file describing those conditions in the order they were presented. The format is a single column with 3 different numbers for your conditions.
Cat.txt
1
1
2
3
2
1
2
3
1
Having some additional information about your stimuli (log word frequency, stimulus luminance, loudness, etc) these can be regressed out, so that any difference between conditions cannot be attributed to a difference in stimulus parameters. Of course you can also have a design with only such variables and no categories. In any cases, this will come as a text file with as many columns as regressors.
Cont.txt
125
187
252
243
142
581
852
333
187
The nice thing with this approach is that, in addition to regressing out variance, you can test if these parameters affect your EEG. Each regressor as a parameter associated to it and thus you can test if across all conditions there is an effect. What about differences in the way it affects conditions? well if you think that say stimulus luminance affects differently the response in each N conditions, simply split that regressor in N and add 0 in missing cells. This can also be done automatically for you using the limo_split_continuous function (in tools).
Cont.txt
125 0 0
187 0 0
0 252 0
0 0 243
0 142 0
581 0 0
0 852 0
0 0 333
187 0 0
What about having a nested design, say 2 x 2? Well, this is not different from N conditions, in a 2 x 2 you have 4 conditions, so you should create a single column with 4 conditions. Think about it as doing averages, if you were computing an ERP per subject, you would create 4 conditions and then test the factorial 2 x 2 at the group level, same here.
Cat.txt
1
2
3
4
4
3
2
1
Why not modelling the factorial design since it's 2 x2? if you create a model like this, you do not capture the variance related to each condition, but pool variances across conditions. For instance, a design with conditions A1, A2, B1, B2 can capture the variance of each condition (design above), the variance of each factor (A/B and 1/2), and the variance of each factor and interaction (full factorial). Assuming you go down the road of specifying factors rather than conditions, it means at the group level you can test for effects of factor using one-sample t-tests, and test if factors differ (e.g. A/B differs from 1/2) using paired t-test. It is however not possible to test the interaction since you do not have the 4 conditions. Similarly, if you also model the interaction per subject (full factorial), there is little chance you see anything at the group level in an ANOVA because you already took away factor effects at the subject level (i.e. per subject you have 9 parameters: A, B, 1, 2, A1, A2, B1, B2, constant - and A1,A2,B1,B2 are the 'simple' effects from which main effects are already explained). These types of model, are suitable if you want to look at results at the subject level. If you ever want to do this, simply create as many columns as factors. Taking again the 2 x 2 design, it means 2 columns, and specify full factorial in LIMO EEG if you want the interaction term.
Cat.txt
1 3
2 4
2 4
1 3
Downsampling or not before analyzing
Defining conditions defining
~ categorical.txt ~continuous.txt
EEGLAB-STUDY: run, session, condition and group
Basic Stats: LIMO tests and CI
Repeated measures ANOVA
Results in the workspace
Results in LIMO.cache
Checking data under the plots
Reordering plots
Compute & Plot conditions
Compute & Plot differences
Channel neighbourhood
Editing a neighbourhood matrix
Scripting 1st level
Debugging 1st level errors
Skip 1st level
Scripting 2nd level
Getting stats results with a script