Issue with regressors

[luca-tur]

Dear Lars

I’m writing as I have problems using the Physio Toolbox with our cortico-spinal data. We acquired brain and spinal cord fMRI data simultaneously (Finsterbusch 2013). I tried to solve it by myself, but I don’t understand if it is a problem with my physiological data, if it is related to the sequence itself or a combination of the two.
We have a Siemens Prisma with Syngo VE11C and we use the ideaCmdTool to collect respiratory and pulse oximetry data. I use the latest version of the Physio toolbox (Release 2022a, v8.1.0) and SPM version 7487.
I started from the example (\Siemens_VB\PPU3T_Sync_Last) and adapted the batch file for my data as this was the most similar example. This is how it looks like.

• matlabbatch{1}.spm.tools.physio.save_dir = {'D:\example_physio'};
• matlabbatch{1}.spm.tools.physio.log_files.vendor = 'Siemens';
• matlabbatch{1}.spm.tools.physio.log_files.cardiac = {'D:\example_physio\data.puls'};
• matlabbatch{1}.spm.tools.physio.log_files.respiration = {'D:\example_physio\data.resp'};
• matlabbatch{1}.spm.tools.physio.log_files.scan_timing = {'D:\example_physio\1.3.12.2.1107.5.2.43.166073.2024070513430928508462667.DCM'};
• matlabbatch{1}.spm.tools.physio.log_files.sampling_interval = 0.0025;
• matlabbatch{1}.spm.tools.physio.log_files.relative_start_acquisition = [];
• matlabbatch{1}.spm.tools.physio.log_files.align_scan = 'last';
• matlabbatch{1}.spm.tools.physio.scan_timing.sqpar.Nslices = 52;
• matlabbatch{1}.spm.tools.physio.scan_timing.sqpar.NslicesPerBeat = [];
• matlabbatch{1}.spm.tools.physio.scan_timing.sqpar.TR = 3;
• matlabbatch{1}.spm.tools.physio.scan_timing.sqpar.Ndummies = 0;
• matlabbatch{1}.spm.tools.physio.scan_timing.sqpar.Nscans = 154;
• matlabbatch{1}.spm.tools.physio.scan_timing.sqpar.onset_slice = 26;
• matlabbatch{1}.spm.tools.physio.scan_timing.sqpar.time_slice_to_slice = 0.0575;
• matlabbatch{1}.spm.tools.physio.scan_timing.sqpar.Nprep = [];
• matlabbatch{1}.spm.tools.physio.scan_timing.sync.scan_timing_log = struct([]);
• matlabbatch{1}.spm.tools.physio.preproc.cardiac.modality = 'PPU';
• matlabbatch{1}.spm.tools.physio.preproc.cardiac.filter.no = struct([]);
• matlabbatch{1}.spm.tools.physio.preproc.cardiac.initial_cpulse_select.auto_matched.min = 0.4;
• matlabbatch{1}.spm.tools.physio.preproc.cardiac.initial_cpulse_select.auto_matched.file = 'initial_cpulse_kRpeakfile.mat';
• matlabbatch{1}.spm.tools.physio.preproc.cardiac.initial_cpulse_select.auto_matched.max_heart_rate_bpm = 90;
• matlabbatch{1}.spm.tools.physio.preproc.cardiac.posthoc_cpulse_select.off = struct([]);
• matlabbatch{1}.spm.tools.physio.preproc.respiratory.filter.passband = [0.01 2];
• matlabbatch{1}.spm.tools.physio.preproc.respiratory.despike = false;
• matlabbatch{1}.spm.tools.physio.model.output_multiple_regressors = 'multiple_regressors.txt';
• matlabbatch{1}.spm.tools.physio.model.output_physio = 'physio.mat';
• matlabbatch{1}.spm.tools.physio.model.orthogonalise = 'none';
• matlabbatch{1}.spm.tools.physio.model.censor_unreliable_recording_intervals = false;
• matlabbatch{1}.spm.tools.physio.model.retroicor.yes.order.c = 3;
• matlabbatch{1}.spm.tools.physio.model.retroicor.yes.order.r = 4;
• matlabbatch{1}.spm.tools.physio.model.retroicor.yes.order.cr = 1;
• matlabbatch{1}.spm.tools.physio.model.rvt.no = struct([]);
• matlabbatch{1}.spm.tools.physio.model.hrv.no = struct([]);
• matlabbatch{1}.spm.tools.physio.model.noise_rois.no = struct([]);
• matlabbatch{1}.spm.tools.physio.model.movement.no = struct([]);

As we use a cortico-spinal sequence, I adopted the strategy you suggested in the past (#120). I adopted the second method. This is the reason behind the discrepancy between the number of slices in the dicom header and the one in the batch. In each TR, the sequence acquires brain data and then spine data, so there are 2 set of dicoms for each TRs.

I couldn’t find my specific setup in the examples (https://gitlab.ethz.ch/physio/physio-doc/-/wikis/MANUAL_PART_READIN#siemens).
So, in the batch, I assumed a sampling frequency of 400 hz (0.0025 ms), as the PMU sampling frequency is 400 Hz and running the code without a value in sampling interval gave me the same sampling rate (checked via debugging). Maybe this is the problem with my data as I understand that resp and puls might have different sampling rates and not 400 Hz.

When I tried to use another sampling frequency (e,g, 200 Hz) I don’t have the same error and the toolbox manages to estimate the regressors, but the heart rate and the respiratory cycles do not look realistic.

I attach the puls, resp files and the last DICOM of my acquisition. Maybe you could help me figuring out what is wrong.

I thank you very much for your support.

Kind regards,

Luca

example_physio.zip

[mrikasper]

Dear Luca,

I tried to run your example and also ran into some issues. Let's unpack this:

1. In general, the matlabbatch you pasted above looks correct and should reflect your situation well.
2. For Siemens, you don't have to set the sampling frequency manually. If you just choose [], PhysIO should be able to detect it automatically.
3. The toolbox is able to load in the raw data fine, see the screenshots below for both cardiac and respiratory trace
4. The relative time of the first scan (0s) to the start of the physiological logging also makes sense (see tooltip on the left in first plot): you started the recordings via ideaCmdTool about 16.4s before the first EPI volume was acquired. This indicates that DICOM image file to *.resp/puls synchronization worked correctly
5. However, your logfile does not seem long enough, i.e., it acquired only about 300 seconds, or 5 minutes of data (281.86s+16.41s = 298.27s). This is very suspicious, since you should have (with TR=3s and nScans=154) at least 462s of data after t=0s (the first volume).
6. 5 min is an ominous number for the ideaCmdTool. In fact, if the ECG is not connected, but its logging was not manually turned off, the Physiological Monitoring Unit (PMU) will stop logging after exactly 5 minutes.
7. Therefore, can you describe how you used the ideaCmdTool? What we typically do here at our site is to
   • first choose 12 - startHostLogAll and
   • then 5 - stopHostLogEcg. This way, the ECG trace is not collected (all zeros) and the PMU happily tracks pulse and resp data for as long as you want.
   • Finally, you stop by 13 - stopHostLogAll

This is my best guess of what went wrong here.

I hope that helps!

All the best,
Lars

[luca-tur]

Dear Lars,

first of all, thank you very much for taking the time to go through my issue. I really appreciate it.

I checked with the support staff at the MR scanner. We didn't know about the bug with ideaCmdTool, so we didn't use the command 5 - stopHostLogEcg. I guess this was the problem. Next time we will implement the exclusion of ECG data, thank you very much.

In addition, I checked a couple of other subjects and they all have around 300 s (5 minutes) data. Moreover, all the physio data files I collected have exaclty the same size so it is likely that they stopped after the same time.

I guess I will try the Physio toolbox in my next study :)

Kind regards,

Luca