firmm
5 Subscribers 
firmm > Volume arrival delay
Showing 1-6 of 6 posts
Sep 27, 2018 06:09 PM | Ian Ballard - University of California, Berkeley
Volume arrival delay
Hello FIRMM community,
I had an issue on our Siemens Trio. We were able to successfully install FIRMM. However, our images arrive at a delay of 4-8 seconds, usually in packets of 2 or 3 volumes. Although this is not an issue with the FIRMM software, I was hoping someone in the community had encountered a similar problem.
The reconstruction is running real time, and the Inline Display displays images in real time, but the subsequent writing to the database happens only periodically, with a delay of what usually amounts to a TR or two for EPI. We have a Trios running VB17 software.
Any help would be greatly appreciated,
Ian
I had an issue on our Siemens Trio. We were able to successfully install FIRMM. However, our images arrive at a delay of 4-8 seconds, usually in packets of 2 or 3 volumes. Although this is not an issue with the FIRMM software, I was hoping someone in the community had encountered a similar problem.
The reconstruction is running real time, and the Inline Display displays images in real time, but the subsequent writing to the database happens only periodically, with a delay of what usually amounts to a TR or two for EPI. We have a Trios running VB17 software.
Any help would be greatly appreciated,
Ian
Sep 28, 2018 04:09 PM | Eric Earl - National Institute of Mental Health
RE: Volume arrival delay
Ian, what is your TR? Is it about 2 seconds (just guessing
based on your delay and volume counts there)?
Sep 28, 2018 05:09 PM | Ian Ballard - University of California, Berkeley
RE: Volume arrival delay
Originally posted by Eric Earl:
Yes the TR is 2 seconds. Thanks!
Ian, what is your TR? Is it about 2
seconds (just guessing based on your delay and volume counts
there)?
Hello Eric,Yes the TR is 2 seconds. Thanks!
Sep 28, 2018 06:09 PM | Eric Earl - National Institute of Mental Health
RE: Volume arrival delay
Ian,
At that TR I can't imaging why your reconstruction computer would take that long to get DICOMs over your network to the FIRMM computer. I guess you could investigate your network speed bgetween the scanner and the firmm PC and maybe evaluate your scanner's reconstruction speed separately?
~Eric
At that TR I can't imaging why your reconstruction computer would take that long to get DICOMs over your network to the FIRMM computer. I guess you could investigate your network speed bgetween the scanner and the firmm PC and maybe evaluate your scanner's reconstruction speed separately?
~Eric
Sep 28, 2018 08:09 PM | Ian Ballard - University of California, Berkeley
RE: Volume arrival delay
Hi Earl,
A suggestion from the real-time fMRI list fixed the problem. I thought I would let you know in case it interests you.
It turns out that the default is for the computer to write data every 5 seconds on older systems, which is why scans appeared in alternating packets of 2 or 3 (at a 2s TR). You can change this to write every 500ms by setting "SendBuffered" to False using ideacmdtool and xbuilder and scans arrive in regular intervals of one TR +- a handful of ms.
Thank you,
Ian
A suggestion from the real-time fMRI list fixed the problem. I thought I would let you know in case it interests you.
It turns out that the default is for the computer to write data every 5 seconds on older systems, which is why scans appeared in alternating packets of 2 or 3 (at a 2s TR). You can change this to write every 500ms by setting "SendBuffered" to False using ideacmdtool and xbuilder and scans arrive in regular intervals of one TR +- a handful of ms.
Thank you,
Ian
Oct 1, 2018 02:10 PM | Eric Earl - National Institute of Mental Health
RE: Volume arrival delay
Originally posted by Ian Ballard:
Nice discovery! Thanks for the info cross-posting to our forum.
~Eric
Hi Earl,
A suggestion from the real-time fMRI list fixed the problem. I thought I would let you know in case it interests you.
It turns out that the default is for the computer to write data every 5 seconds on older systems, which is why scans appeared in alternating packets of 2 or 3 (at a 2s TR). You can change this to write every 500ms by setting "SendBuffered" to False using ideacmdtool and xbuilder and scans arrive in regular intervals of one TR +- a handful of ms.
Thank you,
Ian
A suggestion from the real-time fMRI list fixed the problem. I thought I would let you know in case it interests you.
It turns out that the default is for the computer to write data every 5 seconds on older systems, which is why scans appeared in alternating packets of 2 or 3 (at a 2s TR). You can change this to write every 500ms by setting "SendBuffered" to False using ideacmdtool and xbuilder and scans arrive in regular intervals of one TR +- a handful of ms.
Thank you,
Ian
Nice discovery! Thanks for the info cross-posting to our forum.
~Eric