 |
 |
> One more question regarding the model setup: in SPM99 I defined the 6 > runs of my experiment as one session so that the onsets of run 2 didn't > start at 0 but after the onsets of run1. I would not advise doing this. If the scanner stopped and restarted between runs, yet you modelled your conditions as a single session, then your data no longer represent a continuous timeseries, and several aspects of SPM will be disrupted, eg highpass filtering, temporal autocorrelation estimation, grand-mean scaling, session-meaning. > In SPM2 this doesn't really work: I either get error messages or a > rather strange looking design matrix. When setting up a FIR model is > there any reason not too model each run as a separate session? There is no reason not to - model each run as a separate session. Rik >>> I've been trying to obtain the time course of activation. First of >>> all I'm >>> not sure, if the length of my time bins should equal the TR (3 sec) >>> or if it >>> would be wiser to choose shorter bins of, lets say, 2 sec? Time bins >>> should >>> cover the period from 5 time points before to 5 time points after the >>> onset >>> of the condition so that the whole time course should cover 30sec. >>> Since SPM 2 no longer offers the distinction beween "event related" and >>> "epoch related" designs I'm not quite sure how to specify the design >>> if I do >>> not want to convolve my data with the canonical HRF. Which basis set >>> should >>> I choose for the model setup? FIR model? If so what about the window >>> length >>> (30?), order (10?) and duration (0?)? >> >> >> Yes, yes, yes! (if you want a bin size of 3s). >> >> The first FIR bin will start with the event onset, so if you want to >> start >> 5 timepoints before the "true" event, then subtract 15s (5 TRs) from your >> onset vectors (but note that SPM2 will not handle negative onsets less >> than -2 TRs, so you may have problems for the first event). >> >> There is no point having FIR bin sizes less than your TR unless you have >> achieved a higher effective sampling rate by jittering your event >> onsets with respect to the scan onsets, either randomly or by ensuring >> that your >> SOA is not a simple multiple of your TR. (So if you locked your event >> onsets to scan onsets, then there's no point having a bin size less >> than 3s >> in your case). >> >> HTH >> Rik >> > > >