4 ms·
One thing that always annoyed me was the time stamps So much this. Now your example can still be countered somewhat by taking notes and writing down which scan
by stinos 6y ago
One thing that always annoyed me was the time stamps
So much this. Now your example can still be countered somewhat by taking notes and writing down which scan was taken when. This is usually common practice in research.
But it can get worse when trying to integrate integrating MRI scanner software with external systems which do get a correct timestamp (or at least, different one) and which are used for research experiments like presenting stimuli and recording behaviour all together with getting MRI data.
Scanner software usually doesn't provide any means of starting it except for clicking in the UI so that means the people doing such experiment have to start 2 or more pieces of software manually (and hope they don't forget one). Now if one session lasts 10 minutes and it's not uncommon to do test sessions (with no scan) or test scans (with no corresponding experiment) or make a mistake (start scan with wrong parameters, abort, start again) and a complete test takes a couple of hours, imagine the fun of linking all of that session data together correctly based on just timestamps. I don't even know how much time has been lost or many mistakes were made (and possibly published) because of that. But it won't be 0, it's just too easy to mess up.
Of course some of this is out of the manufacturers contro
Only partly. Some of these systems are always connected to the internet anway so then at least try to make sure NTP works.
- PascLeRasc 6y agoDo you know what software is usually used to get fMRI timestamps? My last position was in an fMRI lab, and we had this in-house piece of Windows 98 software that did real-time recording down to <10ms, but it was a huge codebase to maintain and pretty much impossible for me to migrate it to Windows 10. The output file was pretty hard to decode too. I've always wondered what else is out there.
- stinos 6y agoNot 100% sure what you mean with 'fMRI timestamps' but since you say 'recording' I assume it's the TTL/optical trigger produced at the start of each volume? And since you mention windows 98 and < 10mSec the in-house software is maybe using the parallal port? From former experience with such software: that's usually a mess, especially on later versions of Windows where direct access to such port was being ruled out. Anyway the principle is you use an A/D converter to digitize the signal then save it (either the complete signal or just timestamps of rising edge, the latter can also be done directly on some A/D cards). In the system I'm currently working on I'm using National Instruments PCI-X cards their C SDK to get the data but that's just because I need I/O channels for other things as well and because it has to include online processing of data. Otherwise you could just save the data at a nice and slow rate using Labview or Matlab or ... (pretty sure there are open source solutions as well). And there are many alternatives to National instruments as well of course. All woth resolution down to a couple of nanoseconds if needed. But note that it's still not trivial to get an accurate 'time of day' timestamp from it (should that be needed): at the recording site there's no way of knowing exactly when the data acquisition starts. And there can be clock drift.
- PascLeRasc 6y agoYes, that's it. Sorry it's been a while, and yes it was using the parallel port. I wish I had thought to try modern PCIe cards and different software like Matlab, that would probably have been much easier.
- deleted 6y ago[deleted]