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:
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.
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.
It is hard to guess why you are seeing this. One thing that might worth checking in your extra python script is whether the DICOM files are fully populated. But still, Dimon should be whining if many time points go by without any new data.
You might consider setting AFNI_REALTIME_SHOW_TIMES (either as an env var or via the GUI). There is also a -show_comm_times option in realtime_reciever.py.
Are you using realtime_receiver.py from the AFNI distribution, or are you using the functionality from Vinai’s PsychoPy-NeuroFeedback-Demo, which has a forked version of it, but which is mostly tracking changes to the AFNI version?
Thank you for this advice! I am using realtime_receiver.py from the AFNI distribution, installed in a NeuroDebian virtual machine running on a Windows machine (my institution won’t let us use a non-Windows computer). I haven’t heard of Vinai’s version before. I tried setting AFNI_REALTIME_SHOW_TIMES as an env var and also used the -show_comm_times option in realtime_reciever.py. (Didn’t realize I could do that!) The output shows the same strange lag, which tells me this is happening very early in the process, probably before it even gets to my python script (which is only checking the txt output from realtime_receiver. Here’s a snippet from the Terminal below. Notice that TRs 1517-1519 are about 1 second off from each other, as one would hope, but then TR 1520 is happening 18 seconds after TR 1519. This lag goes away at the next TR, and recurs every 40 TRs exactly. I think the 40 TRs might be less important than the fact that the recurrence is periodic. I’ve now settled on using the same parameters and code every single time I run this and it’s always 40 TRs. I think the past periodicity of 13-14 TRs had to do with me running slightly different code, though I have no idea why it does that.
Anyway, does this all collectively suggest that whatever is happening is happening at the AFNI part of the process?
This output was from running the script on archival data, not an active scan collection, so I assume the DICOMs should all be theoretically readable by Dimon. Not sure if that addresses your thought about DICOMs being “fully populated”?
– comm time for TR 1517 @ 2021-04-12 18:45:15 (offset 1968.405)
++ recv motion: -0.00382 -0.11792 -0.12733 -0.14060 -0.04923 0.26249
++ recv 2 extras: 10034 10839.1
– comm time for TR 1518 @ 2021-04-12 18:45:16 (offset 1969.205)
++ recv motion: -0.00621 -0.14899 -0.11283 -0.18226 -0.05892 0.27353
++ recv 2 extras: 10025.5 10828.3
– comm time for TR 1519 @ 2021-04-12 18:45:17 (offset 1970.004)
++ recv motion: -0.00009 -0.16126 -0.12406 -0.15230 -0.05375 0.26467
++ recv 2 extras: 10046.1 10834.1 – comm time for TR 1520 @ 2021-04-12 18:45:35 (offset 1988.388)
++ recv motion: -0.01088 -0.11837 -0.11698 -0.16080 -0.05985 0.26724
++ recv 2 extras: 10038.4 10826.7
– comm time for TR 1521 @ 2021-04-12 18:45:36 (offset 1989.195)
++ recv motion: -0.00532 -0.12996 -0.12133 -0.15647 -0.05469 0.26561
++ recv 2 extras: 10018.6 10820
– comm time for TR 1522 @ 2021-04-12 18:45:37 (offset 1989.993)
++ recv motion: -0.00790 -0.14649 -0.11460 -0.16861 -0.05968 0.26739
++ recv 2 extras: 10021.7 10796
The
National Institute of Mental Health (NIMH) is part of the National Institutes of
Health (NIH), a component of the U.S. Department of Health and Human
Services.
