Back to PLS Helpjitter in reference scan
Posted on 11/25/08 22:00:58
Number of posts: 41
hi all ~ my question is, can any of the pls scripts/gui accommodate reference scans that vary in onset. in particular i have trials that need to be baseline normalized to the begining of an earlier event - however the duration between the start of that event and my time point of interest is jittered across trials.
this presents a problem b/c the typical PLS analysis allows for one reference scan per condition. in my case the reference scan offset (in negative time) varies by trial (within a subject).
any thoughts? i had previously found a very round-about way of handling this with a script i think - but i am wondering if there is perhaps an easier way.
all the best
agatha
this presents a problem b/c the typical PLS analysis allows for one reference scan per condition. in my case the reference scan offset (in negative time) varies by trial (within a subject).
any thoughts? i had previously found a very round-about way of handling this with a script i think - but i am wondering if there is perhaps an easier way.
all the best
agatha
Replies:
Untitled Post
I'm Online
Posted on 11/26/08 10:38:23
Number of posts: 291
We don't use reference scan for each onset. The reason to use reference onset is trying to offset the effect of low frequency noise. So it should be sufficient to only use the value at onset scan as the reference.
Untitled Post
Posted on 11/26/08 10:53:20
Number of posts: 394
Jimmy is correct, but, Agatha, can you give a bit more detail on exactly what you need to do? Perhaps an example with the vectors for onset and reference scans?
Untitled Post
Posted on 11/26/08 11:04:01
Number of posts: 41
Thank you both for the replies. Here are the details...
My experiment was designed as a seriees of two trial events (e.g., Task A followed by Task B). The interval between these trials was jittered. My experimental question is: What is the effect of Task A on Task B neural activity?
It turns out that there is some overlap in the hemodynamic responses from Task A to Task B and so it is more informative to look at Task B baseline-corrected to the beginning of the event (at Task A) rather than trial (at Task B). This is like the problem of looking at response related ERP's - following an earlier cue (there an effect of cue on baseline prior to response).
Sample vectors in TRs
Task A 0 0 0 0 0 0
Task B 4 6 8 6 8 4
Hence the reference onset value for each trial of Task B varies b/w -4 and -8 depending on trials...
Note - it may be that in the end Task B won't be analyzable due to overlap in hrf.
Cheers
Agatha
My experiment was designed as a seriees of two trial events (e.g., Task A followed by Task B). The interval between these trials was jittered. My experimental question is: What is the effect of Task A on Task B neural activity?
It turns out that there is some overlap in the hemodynamic responses from Task A to Task B and so it is more informative to look at Task B baseline-corrected to the beginning of the event (at Task A) rather than trial (at Task B). This is like the problem of looking at response related ERP's - following an earlier cue (there an effect of cue on baseline prior to response).
Sample vectors in TRs
Task A 0 0 0 0 0 0
Task B 4 6 8 6 8 4
Hence the reference onset value for each trial of Task B varies b/w -4 and -8 depending on trials...
Note - it may be that in the end Task B won't be analyzable due to overlap in hrf.
Cheers
Agatha
Untitled Post
I'm Online
Posted on 11/27/08 08:23:15
Number of posts: 229
Ok.. so this is crazy, but it is physically possible to do in the GUI... and makes some sense
Set your reference scan to be past the 'end' of your TaskB event, when you expect the TaskB HRF to be back to 'baseline' (put in 8,10,etc instead of zero). This will still give you a 'baseline' from which to estimate the signal change, that is 'not' linked to the preceeding event.
Whether this will work or not depends on how many TRs you have from TaskB to the next TaskA - if they are close, you may still have a confound from the overlap..
nancy
Set your reference scan to be past the 'end' of your TaskB event, when you expect the TaskB HRF to be back to 'baseline' (put in 8,10,etc instead of zero). This will still give you a 'baseline' from which to estimate the signal change, that is 'not' linked to the preceeding event.
Whether this will work or not depends on how many TRs you have from TaskB to the next TaskA - if they are close, you may still have a confound from the overlap..
nancy
Untitled Post
Posted on 11/27/08 11:00:44
Number of posts: 41
Hey Nancy ~ Thanks for the tip! That's actually what I ended up doing - and it actually works pretty well (at least it captures a fairly representative peak at Task B). In fact - it's pretty close to the peaks calculated with jitter accounted for (by hand).
All the best! Hope it's not too cold out there.
Agatha
All the best! Hope it's not too cold out there.
Agatha
Login to reply to this topic.
