fNIRS pre-scan offset: It's pretty easy to factor this into your E-Prime studies
- Create a new procedure in your E-Prime called "beginETG"
- Insert an InLine script called "StartETG" with code to start ETG-4000 data acquisition
- Insert a text display named "initialization" with a display text that says "Please wait..." or something to that effect after the StartETG script. Set the duration of this text display to ~10000ms (you will have to play around with various times to see when exactly the ETG-4000 begins to record versus when your E-Prime begins the first stimulus after initialization -- to the extent of 0 - 800ms.)
- OPTIONAL: begin your experiment with a new procedure that includes a 30s rest with an onset marker occurring after this rest. You should see an onset marker on exported HB files at sample 300. Again, your mileage may very -- adjust your initialization screens accordingly in order to ensure a correct first onset marker time. Subsequent markers may vary, but the differences reported between markers by E-Prime and also ETG-4000 are correct (which I explain further below).
Hitachi ETG-4000 pre-scan offset, E-Prime, and accounting for all the potential latency
On a Hitachi ETG-4000, there exists a "pre-scan" function -- generally set up to create a baseline for recording. The default setting -- and most frequently reported prescan time -- is 10s. Prescan is recorded as data in the measurement (MES) data files, which exists as the first 100 lines of data in any MES file. For the raw oxygenated/deoxygenated concentration (HB) data files, prescan is used and incorporated into the subsequent data -- in other words, there in no 10s prescan data for HB files.
So what does this all mean? If you aren't aware of a 10s prescan at the beginning of your experiment and you don't "get away" from the 10s prescan, then you may be recording data IN the prescan time, and therefore not capturing it in the HB files. This would present a problem if you are using HB files as your data source. "Getting away," or starting your experiment after the 10s prescan, is not difficult to do.
fNIRS guru Xu Cui recommends a 20s rest at the beginning of your experiment -- where 10s of this rest is prescan and the other 10s would be rest at the beginning of your experiment. Although this is a very "easy" way to get away from the baseline, it becomes an extra step to analyze the correct times of your onsets. If you use a single 20s rest after your fNIRS begins to record, your E-Prime data would say the beginning of your first stimulus started at 21s, whereas your fNIRS data will say your first stimulus started at 11s.
And depending on your time sensitivity, even a difference of 1s (which is 10 samples of fNIRS data) is critical.
I recommend accounting for your pre-scan time as a single ~10s slide, followed by a 30s resting state as another slide. Currently, for an experiment I recently designed, the exact prescan "buffer time" (as I am calling it) is 10550ms. I'm not exactly sure where the other 550ms comes from (seems really high for computer-to-computer and/or program-to-program latency), but with this, the onset of the 30s rest begins at 0s for fNIRS data. The first stimulus occurs in my project 4s after the rest (34s) and the marker data for fNIRS is also shown to begin at 34s. This effectively side-steps the onset time correction.
Comparing fNIRS marker onset times to E-Prime onset times, there is accuracy to the 0.1s, where there is a +/- 0.1s, depending on rounding time up or down on fNIRS. As seen in a marker test experiment I designed, the onscreen time series for a marker to be placed at 34s appears at 34.1s where the exported HB files show the marker onset to be placed at sample 340, which is equivalent to 34s. The latency recorded by E-Prime suggests the offset time of the rest (at 30s) and the onset time of this marker (34s) difference to be 4049ms. This accounts for the +/- 0.1 discrepancy between the native ETG-4000 software and the HB file output.
The bottom line is that you should account for this 10s prescan time, even if your experiment may be designed "away" from the prescan. A simple way to do that is to create a tiny procedure that only includes a ETG-begin-recording script and a ~10s "Please wait..." screen. This effectively accounts for that 10s in your experimental design functionally the same way as it is accounted for on the ETG-4000: as its own portion of the data acquisition. You can use different methods to get away from the pre-scan so long as you can account for the onset time latency during data preprocessing, but limiting human error is a tool very simply done by this ~10s initialization screen.