Long form physio trace from Siemens machine

[HeardMatthew]

Hello,

Thanks so much for maintaining such an excellent toolbox, I think this project is the perfect solution for in my current dataset. I wanted to verify that this toolbox can handle my current obstacle, or if I need to process my data before feeding it into the toolbox.

I have a physio trace (breathing belt and pulse oximeter) collected from a Siemens Prisma 3T and saved using the VB (.resp and .puls) file format. The scanning technician started physio recording as soon as the participant was put inside the scanner, and let the script run for the duration of the entire scan (~30 minutes). In particular, I would like to create a physiological regressor for a resting state scan acquired about 10 minutes into the scan, and lasted for 10 minutes.

Can I feed the "long form", raw physio trace into the toolbox and instruct it to create a physio regressor for the specific scan? Or do I need to break the physio trace into smaller chunks?

Thanks!
Matthew

[mrikasper]

Dear Matthew,

Thank you for your positive feedback regarding PhysIO!

I believe you can (and should) use the "long form" trace out of the box. It might take PhysIO a bit longer to process a larger file, but splitting it up the Siemens VB format is not so easy, because the trace is "sandwiched" between a header and a footer part in the files (See here for a description).

But what you do have to get right is the temporal synchronization of your 10 min resting state scan within this long trace. There are basically two options here

1. You have a DICOM (header) file for the first volume of your resting-state scan. In this case, you can just set it as the log_files.scan_timing file and log_files.align_scan = 'first', so PhysIO will match the timestamps of log file and DICOM, similar to what I describe here for a slightly different issue.
2. You have an external TTL trigger from the scanner connected to your physiological recording box, so the .ext files are populated with trigger traces (instead of all 0, you can check the file content with a text editor). I am working on a solution to support these files as log_files.scan_timing input as well (inspired by this issue that shows the DICOM header solution is not always reliable, in particular for very long trace files). If you also have a need for this, it will bubble up my priority list of new feature implementations.

All the best,
Lars

[HeardMatthew]

That makes sense. I do have the DICOM information from the scan and no external TTL, so I plan on using the former. However, my understanding from the documentation was that aligning to the 'last' scan was preferred--I can easily use either the first or last, which would you suggest? Matthew

…

On Fri, Feb 17, 2023 at 8:03 AM Lars Kasper ***@***.***> wrote: Dear Matthew, Thank you for your positive feedback regarding PhysIO! I believe you can (and should) use the "long form" trace out of the box. It might take PhysIO a bit longer to process a larger file, but splitting it up the Siemens VB format is not so easy, because the trace is "sandwiched" between a header and a footer part in the files (See here <https://gitlab.ethz.ch/physio/physio-doc/-/wikis/MANUAL_PART_READIN#manual-recording> for a description). But what you do have to get right is the temporal synchronization of your 10 min resting state scan within this long trace. There are basically two options here 1. You have a DICOM (header) file for the first volume of your resting-state scan. In this case, you can just set it as the log_files.scan_timing file and log_files.align_scan = 'first', so PhysIO will match the timestamps of log file and DICOM, similar to what I describe here <#218 (comment)> for a slightly different issue. 2. You have an external TTL trigger from the scanner connected to your physiological recording box, so the .ext files are populated with trigger traces (instead of all 0, you can check the file content with a text editor). I am working on a solution to support these files as log_files.scan_timing input as well (inspired by this issue <#201> that shows the DICOM header solution is not always reliable, in particular for very long trace files). If you also have a need for this, it will bubble up my priority list of new feature implementations. All the best, Lars — Reply to this email directly, view it on GitHub <#227 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE6RHG7JPHUW2MKZGHHNR4TWX6AMRANCNFSM6AAAAAAU622LAU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mrikasper]

Dear Matthew,

I agree with your choice for synchronization. Regarding using the first or last scan volume for synchronization, in your case (Siemens) it's fine to use either, as long as you know which DICOM file pertains to the first and last volume you want to use in your fMRI analysis (Sometimes people prefer the first one, because then they have to change less in their scripts, because the number of volumes might vary between subjects or runs).

The general recommendation for the last scan volume comes from the fact that on some scanner vendors, it's not always clear whether certain scan preparation modules (shimming/frequency adjustment) or dummy scans (to facilitate T1 equilibration) elicit a trigger signal, so you might end up with a wrong synchronization using the first trigger.

On the other hand, the only time I wouldn't recommend using the last volume is if you manually stop the sequence and there could be incomplete volumes (only a few slices) at the end of a run and the related logfile. But again, not an issue on Siemens usually, because you manually start/stop the logging.

I hope that clarifies the issue.

All the best,
Lars