PhysIO, Siemens, Manual Recording: Using MCPU Timer instead of MDH

[TomW92]

Dear Experts,

in my .puls and .resp recordings, the MDH Time seems to be out of sync. While it correctly tracks the elapsed time, the start and stop Time is inconsistently shifted, usually by several hours. MCPU and DICOM times are synced and look okay (correct time of day, etc).

I read here that the MDH Time is derived from the scanner clock and thus most in sync with the image files. It is also the timestamp that the PhsysIO toolbox uses, correct?

I was wondering how the MDH Timer can be off (and if it's indeed the scanner clock, shouldn't the DICOM files be equally off?) and what's the best fix to still make the PhysIO toolbox work.
Is there always a ~300ms gap between MDH and MCPU Start time, as in your example files in the wiki, and would a somewhat extrapolated (or even the plain) MCPU Time be sufficiently precise?

An example from one of the log files:
LogStartMDHTime: 31707445
LogStopMDHTime: 32006415
LogStartMPCUTime: 58682090
LogStopMPCUTime: 58981045

Attached a plot to show the inconsistent shifting of the MDH clock.

Thanks in advance for the feedback!

Best
Tom

[mrikasper]

Dear Tom,

Great you are trying out PhysIO!

Indeed, we are using the Measurement Data Header (MDH) clock as well (see our Wiki page), which was suggested by both Tim Verstynen and Chris Rorden's physiological noise packages as well, see for example:

https://github.com/neurolabusc/Part#usage
nipy/heudiconv#450 (comment)

The way I understand it is that while the actual physiological recording happens on the device with the MPCU clock, the MR scanning is controlled by the MDH clock that issues the creation and acquisition of each DICOM image volume. Therefore, the AcquisitionTime you find in the DICOM header of your first volume should be from the same clock as the LogStartMDHTime. Could you let us know what this AcquisitionTime is in your case for the first DICOM of your fMRI run related to the physiological logfile?

When you say that the DICOM times are off, what parameter are you looking at? I have noticed that in recent Siemens releases (e.g., XA30), there is no AcquisitionTime in the header, but a parameter AcquisitionDateTime that PhysIO tries to use, but I haven't fully tested it yet.

Finally, I had another thought: when do you start/stop your physiological logging? Separately for each fMRI run or only once for each subject or even day? If you started logging at the beginning of a scan day, there could be several hours of delay to the DICOM scan time stamp, of course.

Why MPCU and MDH clock are so different, I cannot really tell. This might be even something to tell Siemens service. But it shouldn't affect your relative timing to the scan time stamp, I agree.

I hope that helps.

All the best,
Lars

[mrikasper]

PS: If you want to look at the code in PhysIO where this timing is determined:

• DICOM time
• Logfile time MDH

Note that both MDH and MPCU times are written out by the 2nd function, named logFooter.LogStartTimeSeconds and ScanStartTimeSeconds, respectively (and somewhat confusingly, it should probably be the other way around).

But again, I believe MDH is the time that you should try to synchronize

[TomW92]

Dear Lars

Thanks a lot for the quick response.

Yes, I do have the parameter AcquisitionTime in my DICOM header.
For the example above, with the timestamps:

LogStartMDHTime: 31707445
LogStopMDHTime: 32006415
LogStartMPCUTime: 58682090
LogStopMPCUTime: 58981045

the DICOM AcquisitionTime is: '161848.250000'.

Which matches both the actual time of day we acquired the images and the LogStartMPCUTime (at least roughly) but not at all the LogStartMDHTime timestamp.

Sorry, I wasn't entirely clear in my description before. What surprised me was that the AcquisitionTime was indeed not off, and it is just the LogStartMDHTime that is out of sync, which is weird since they come from the same clock.

Yes, we started and stopped the acquisition of the physiological recordings manually for each run, using the ideacmdtool.

Thank you, we did already communicate this issue to Siemens. I was just hoping for a workaround with, for example, the MCPU clock, for the data that are already collected.

Something else I noticed: You don’t divide by 1000 here, even though the variable has "second" in its name. Is that on purpose?

Best
Tom

[mrikasper]

Dear Tom,

That's really interesting. Obviously, since the logging of the physiological recordings happens on the MPCU, it's the right "native" time of the recording for that device. But I was under the assumption that the DICOM file time stamps are issued by the MDH.

You are right, the AcquisitionTime would correspond to 1000*(16*3600+18*60+48)+250 = 58728250 ms since midnight, which is 46.16 seconds after the LogStartMPCUTime, which sounds reasonable, if you start logging before each run.

31707445 is about 08:48 am, which does not even correspond to an AM/PM 12h shift.

The only other suggestions I have, would be

1. Which Siemens software version are you using (e.g., VE11, XA30 etc)?
   • It should be mentioned also in the DICOM file as SoftwareVersions or ImplementationVersionName
   • Can you find other time stamps in the DICOM header and whether they correspond to similar values? I use the MicroDicom Viewer for that and search for "Time" in the DICOM Tags. That should give you things like InstanceCreationTime or StudyTime
2. Did you use an external trigger by any chance? If so, check the .ext file and whether it contains any non-zero values?
3. You could run a debugging experiment where you trigger your sequence to the cardiac phase. Then Siemens should write out the physiological data in the raw data .dat file alongside the scan data, and one could retroactively extract the curves and time stamps. Let me know if this is an option.

All the best,
Lars

[TomW92]

Dear Lars

Yes, unfortunately, it’s neither an AM/PM nor a timezone shift, which would be easier to fix.

From what I found in the DICOM Header, our version should be VE12:
Software Versions: syngo MR E12, and ImplementationVersionName: MR_VE12U.

Other timestamps I found:

Instance Creation Time: 161909.218000
Study Time: 153925.548000
Series Time: 161909.214000
Content Time: 161909.218000
Performed Procedure Step Start Time: 153925.679000

Which seems to fit with the Acquisition Time: 161848.250000

No, we didn't use an external trigger, we got both ext and ext2, which are empty/filled with zeros, besides the 5003 etc. tags.

Have you ever done a comparison of the timestamps? For instance the quality of the regressors derived from the MDH vs. regressors from the MCPU timestamps?

Thanks a lot for the help and the suggestions, I am going to look into the possibility of such a debugging experiment.

Best
Tom

[mrikasper]

Dear Tom,

Thank you for looking further into this, I am curious to hear what Siemens thinks about it.

Regarding a timestamp comparison between MPCU and MDH, I never checked this systematically, but just pulled out two runs from a recent experiment on our Prisma with XA30. These runs were just 10 min apart, but the differences in relative delay are considerable:

Run 1 (.puls file):
LogStartMDHTime:  52074670
LogStopMDHTime:   52206012
LogStartMPCUTime: 52075215
LogStopMPCUTime:  52206552 

delayStartMDHvsMPCU = -545 ms
delayStopMDHvsMPCU = -540 ms

Run 2 (.puls file):
LogStartMDHTime:  52853775
LogStopMDHTime:   53153767
LogStartMPCUTime: 52853657
LogStopMPCUTime:  53153637

delayStartMDHvsMPCU = 118 ms
delayStopMDHvsMPCU = 130 ms

So there is a small jitter (~10 ms) within a run of 5 min duration, but between the two runs, the delay varies by more than 600 ms and even changes sign.

I can tell you that a few 100 ms delay can have a significant impact on the phase-based regressors (RETROICOR), whereas for the slower response function-related models (HRV, RVT) it will not change a lot.

Sorry that I have no better news - and by the way, thank you for spotting the MPCU scaling bug, of course one has to divide by 1000. Probably didn't spot it, because we didn't use this time. I will fix it for the next release.

All the best,
Lars

[TomW92]

Dear Lars

Thanks for checking your runs. With this immense delay, and significant impact on the regressors at 100ms, I don’t see much hope for our recordings.

Yes, I figured your script would parse the MCPU time but not make use of it.

Thanks for all the help and the information, I’ll get back to you in case I have any updates, including those from Siemens.

Best
Tom

[mrikasper]

Dear Tom @TomW92,

I wondered whether you got any feedback from Siemens in the meantime. I am looking at the clocks again, and find more and more contradicting information:

• in favor of MDH time for logging:

  • HCP: https://wiki.humanconnectome.org/display/PublicData/Understanding+Timing+Information+in+HCP+Physiological+Monitoring+Files

• in favor of MCPU time:

  • Aguierre Lab: https://cfn.upenn.edu/aguirre/wiki/doku.php?id=public:pulse-oximetry_during_fmri_scanning#pulse-ox_data
  • original Physioload function from Siemens Magnetom forum (V. Desphande, J. Grinstead)

  LogStartMDHTime: %log start time
  LogStopMDHTime: %log stop time
  LogStartMPCUTime: %scan start time
  LogStopMPCUTime: %scan stop time
  % Remove the extra samples at the beginning of the log file: time between
  % log start time and scan start time.
  extra_samples = floor( ( (ScanStartTime - LogStartTime)/1000 ) * SamplingFrequency);
  

  These extra samples are then removed in that function. Basically, the argument I have heard is that MPCU is the same clock as the reconstruction computer (MARS), and that's why it should match the images better. But personally, I think there is more support for the MDH hypothesis out there...

Alternatively, I have heard about two venues to explore for your future scans:

1. If you have access to the raw Siemens data (.dat with the twix program), it seems the physiological recordings are stored in there as well. I am not sure how to extract them, but mapVBVD (originally by Phlilipp Ehses, but I didn't find his Matlab repo online, only the Python twixtools) might be your best bet
2. There is an "Advanced Physio Logging" WIP that you can request from Siemens (if you have a research agreement) that automatically logs all physiological recordings into nicely synchronized logfiles (PhysIO supports this natively as the "Siemens_Tics" format)

Let me know what you found out and

All the best,
Lars

[TomW92]

Dear Lars,

Sorry for the delayed answer and thank you for the thorough investigation.

Unfortunately, nothing new from Siemens so far, only that I also got the information that the MCPU clock should derive from the reconstruction computer.

The original physioload function is very interesting. One would think that something like this wouldn’t necessarily change from one version to the next, but I agree that there is much evidence for the MDH clock, especially since it works well for users of your toolbox.

Also, if I’m not mistaken, the link to the Aguierre Lab actually states that the MDH time is preferred:

The MDH values are time-stamps derived from the clock in the scanner, which is the same clock used to provide time-stamps for DICOM images. The MDH values are therefore preferred for synchronization of the DICOM images with the physiologic recording log

But it is not entirely clear, since right after this quote they continue with an example that makes use of the MCPU and DICOM time instead.

Thanks a lot about the suggestions for alternative ways to sync the physio files, I am going to ask about that.

Another idea was to record the fMRI trigger, either as a flag within the physio-recording or in a different channel (ext1 or 2 for example) to sync the files without any time stamps. What is your opinion about that option?

Thanks again!

Best wishes,
Tom

[Martamg16]

Dear Lars,

As Tom already discussed with you, the MDH clock in our .puls and .resp recordings does not seem to be synchronized. Therefore, we decided to record the fMRI trigger as ext to synchronize the files. I was wondering how we could synchronize the .ext file with the .resp and .puls files using PhysIO. Do you have any experience with this kind of setup?

Thank you very much in advance for your help!
Marta

[mrikasper]

Dear Marta,

I am not sure whether this already works out of the box, but it should be fairly simple to integrate. If you can send me an example dataset with all 3 files (.ext, .puls and .resp), I can adapt the Siemens VB read-in to accept a .ext file as log_files.scan_timing input.

You can either add the files here or send an e-mail to me via the address mentioned in the README.

All the best,
Lars