Hi Greg/all,
It turns out the "bad" PULS.log time stamps are off by 24 hours.
Subtracting 24 hours worth of ticks from the time stamps solves the problem
for those runs.
Andrew
On Thu, Oct 6, 2016 at 1:45 PM, Burgess, Gregory <gburg...@wustl.edu> wrote:
> We have not had enough experience with these yet. You may want to check
> the CMRR MB support page, or post an issue
> https://github.com/CMRR-C2P/MB/issues
>
> --Greg
>
>
> Greg Burgess, Ph.D.
> Staff Scientist, Human Connectome Project
> Washington University School of Medicine
> Department of Psychiatry
> Phone: 314-362-7864
> Email: gburg...@wustl.edu
>
> > On Oct 6, 2016, at 12:42 PM, Andrew Bock <bock.and...@gmail.com> wrote:
> >
> > Hi Greg,
> >
> > Thanks for your reply, I was not aware of the 'readCMRRPhysio.m'
> function or that repo. That code is similar to mine, and I'm glad to see
> that the ACQ_START_TICS are indeed 2.5 ms / tic. My first concern was that
> I was misinterpreting the time stamp values.
> >
> > The issue is that the window of time stamps for some PULS.log files do
> not correspond to the window of time stamps for any of our dicom files for
> that session. To add to the problem, this is not always these case, but
> rather only occurs for some of our scans. I'm currently looking into
> differences between "good" and "bad" sessions. There are a few other issues
> with these files, e.g. the time found in the file names is the same for all
> PULS.log files within a session, the first ~2000 values are the same for
> all PULS.log files within a session.
> >
> > It would be great to know if other uses are experiencing these issues,
> or if this is specific to our site.
> >
> > Cheers,
> >
> > Andrew
> >
> > On Thu, Oct 6, 2016 at 11:37 AM, Burgess, Gregory <gburg...@wustl.edu>
> wrote:
> > I haven’t had a chance to look at those new files, so I’d be interested
> to hear more about your experience.
> >
> > If you’re not familiar with it, you should check out
> https://github.com/CMRR-C2P/MB/blob/master/readCMRRPhysio.m .
> >
> > One thing to note, at least with the legacy files, the time stamp in the
> DICOM corresponds to the onset of the “dummy scans”: scans used for the
> SBRef plus dropped scans for T1 equilibration. In HCP data, those dummy
> scans corresponded to 13 TRs (MB8 -> 8 TRs for SBRef, plus 5 TRs for
> dropped scans). It would be interesting to see if ACQ_START_TICS
> corresponds to some number of TRs after the time stamp in the image DICOM
> header.
> >
> > In the legacy files, there were timestamps in each modality that
> corresponded to the ms clock time of the PMU. If you’re getting different
> clock times for different modalities, they might correspond to these.
> (Although I thought the point of the ICE logging was to eliminate reliance
> on the PMU times.)
> >
> > --Greg
> >
> >
> > Greg Burgess, Ph.D.
> > Staff Scientist, Human Connectome Project
> > Washington University School of Medicine
> > Department of Psychiatry
> > Phone: 314-362-7864
> > Email: gburg...@wustl.edu
> >
> > > On Oct 6, 2016, at 10:07 AM, Andrew Bock <bock.and...@gmail.com>
> wrote:
> > >
> > > Hi all,
> > >
> > > Has anyone had issues with the "new" format of the physio files, which
> end in PULS.log? For some of our scans, I have found that the
> 'ACQ_START_TICS' time stamps do not align with any of the time stamps found
> in our dicom headers.
> > >
> > > Andrew
> > >
> > > --
> > > Andrew Bock, PhD
> > > Postdoctoral Researcher
> > > Department of Neurology
> > > University of Pennsylvania
> > > Philadelphia, PA 19104
> > > bock.and...@gmail.com
> > >
> > > ___
> > > HCP-Users mailing list
> > > HCP-Users@humanconnectome.org
> > > http://lists.humanconnectome.org/mailman/listinfo/hcp-users
> > >
> >
> >
> >
> > The materials in this message are private and may contain Protected
> Healthcare Information or other information of a sensitive nature. If you
> are not the intended recipient, be advised that any unauthorized use,
> disclosure, copying or the taking of any action in reliance on the contents
> of this information is strictly prohibited. If you have received this email
> in error, please immediately no
