afni.nimh.nih.gov

Hello,

I'm setting up real-time fMRI neurofeedback using a 3T Skyra scanner where the data is going from scanner=>shared folder the Dimon is pointing to=>realtime_receiver which is writing specific ROI values to a txt file (rtdata.txt)=>a python program is checking rtdata.txt for updates and then displaying a neurofeedback stimulus to the participant, and simultaneously writing the timestamp of when this new stimulus was presented to final_record.txt.

When looking at final_record.txt, I notice the time interval between successful data points (presumably each TR) keeps growing in a characteristic pattern (see attached). Basically it hums along for a reasonable inter-TR interval of 0-2 seconds, and then every 13-14 TRs there's a BIG lag that starts around 3 seconds but eventually grows to be ~10 seconds over time. The big lag occurs every 13-14 TRs and then the intervening TRs are back to normal, but can anyone tell me why is this happening?

When I run everything on an archival folder of pre-saved DICOMs, I do not get this big, gradually growing lag*. This makes me think the big growing lag has to do with when a scan is being actively collected. Maybe there's something to fix with how frequently AFNI/realtime_receiver checks the shared folder when new DICOMs are coming in? I was thinking maybe something is somehow triggering afni to sleep when a scanner is actively collecting, if it doesn't see a new dicom at exactly the moment it is checking?

*actualy I get another weird quirk (see second image), which is that every interval is 0-2 seconds except there is a Consistent big lag of 18-25 seconds that occurs every 40 TRs exactly, and it doesn't grow with time, it's just a "random" lag length somewhere between 18-25 seconds long.

Notes:
1. I checked the creation time of the DICOMs to see if it's a problem with the scanner and not AFNI, and the interval between successive DICOMs ranges strictly from 0-4s, it is NEVER more than 4s, so it doesn't explain the big growing lag.
2. I've also checked to see if the final_record.txt file is actually picking up every new entry in the rtdata,txt file, i.e. is my python script just sleeping too long between checking rtdata.txt, and it is picking up pretty well, misses very few (like ~1% or fewer of the TRs), and there are long stretches of TRs where it is picking up everything rtdata.txt is putting out, but there's STILL these big lags happening. So the big lag must happen at some point prior to the data getting written to rtdata.txt by realtime_receiver.py, but AFTER the DICOMs have been deposited into the shared folder by the scanner.


Thank you so much,
Gen



Edited 1 time(s). Last edit at 03/24/2021 04:40PM by mindfrombrain.