Mne-python: Reading Data from QuSpin Gen 2 OPMs

[neurofractal]

Hi all. Planning on writing some code for importing data acquired using QuSpin OPMs: https://quspin.com/products-qzfm/ . A question before I start:

There is currently no data saving standard for this device. Our lab has opted to save the data in a simple .bin format and add BIDS descriptor json/tsv files. OK to implement for this specific use-case? I don't see too many issues given the limited number of teams using OPMs right now...

[agramfort]

this is no acq system to allow to save your data for such device?

>

[larsoner]

@LauriParkkonen and @rzetter added a QuSpin OPM example back in https://github.com/mne-tools/mne-python/pull/5525 where the data was in FIF format. Any thoughts on QuSpin formats / acquisition / saving? Was writing to FIF a home-grown solution?

[LauriParkkonen]

The plain QuSpin software cannot save the data properly - it gets
excerpts of the data via USB and is for monitoring/viewing only. Thus,
one has to hook up a proper data acquisition system to the QuSpin sensor
electronics. We used a customized version of the MEGIN/Elekta/Neuromag
SQUID MEG system DACQ and the associated software, which directly
produces FIFF files.

Eric Larson kirjoitti 18.12.2020 klo 14.14:
>

@LauriParkkonen https://github.com/LauriParkkonen and @rzetter
https://github.com/rzetter added a QuSpin OPM example back in #5525
https://github.com/mne-tools/mne-python/pull/5525 where the data was
in FIF format. Any thoughts on QuSpin formats / acquisition / saving?
Was writing to FIF a home-grown solution?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/issues/8671#issuecomment-748053807,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ7C3ECRHPJOEWARBJI2RLSVNBTTANCNFSM4VAKBOUQ.

[larsoner]

Maybe a good use case for MNE-SCAN?

@neurofractal is changing your acquisition method to something more standard / flexible another option, or are the plain binaries preferred at your site(s)? (And good to see you on GitHub again :) )

[neurofractal]

Hey @larsoner - good to be contributing to MNE again! Our lab is going to stick with binaries for the moment. I can implement and then other groups can customise with their solutions?

[larsoner]

Do you get the binaries in some semi-standard fashion from the system? I'm worried about including something too lab-specific in MNE -- for example if you have an in-house (and not used / planned to be used anywhere else) data-saving scheme then it might make sense to keep an in-house data-reading scheme, as well, at least to start. @bloyl do you have some insights from your work with the Artemis123 system?

How close is your data from being usable directly with RawArray + create_info? I'm guessing the difficulty is mostly with the sensor positions, but maybe we can come up with a solution for that. For example if this is all you need:

info = mne.create_info(25, 1000., 'mag')
for ch in info ['chs]':
    ch['coil_type'] = ...
data = np.fromfile(..., dtype=np.float64).reshape(...)
raw = mne.io.RawArray(data, info)

then the "in-house" wrapper isn't too bad. This doesn't implement things like on-demand reads that you would get from having a proper BaseRaw instance, but those could be added fairly easily I think.

[neurofractal]

@larsoner OK - sounds like a plan. I have already made something very similar, but the main issues were with sensor positions, orientations and some weird scaling.

Where would such a wrapper sit within MNE?

[rzetter]

@neurofractal Just in case if you're using the USB serial stream for your binary files, be advised that it's only at 200 Hz. Further, the serial stream data are not time-stamped, meaning that any latencies in the data transfer (e.g. when using multiple sensors and a USB hub, or if the measurement PC is under heavy load) may affect the data. Finally, IIRC the data has low resolution (bit depth). If you're already using the analog output (e.g. with the NI dacq system that Quspin sells https://quspin.com/products-qzfm/ni-9205-data-acquisition-unit/), the approach discussed sounds great!

Sensor positions is an issue, and to my understanding (I might be wrong) BIDS isn't quite suitable for (wearable) MEG data in which the sensor positions (relative to each other) are variable across subjects using the same MEG system. Something like the EEG-BIDS *_electrodes.tsv file would perhaps be required?

PS. MNE-Python includes coil_type-entries for Quspin sensors (see the end of the file) with different accuracies. These entries represent the actual sensitive volume, i.e. the ~cylindrical volume that the laser passes through.

[neurofractal]

Thanks @rzetter

1. Yep using the NI dacq
2. Exactly. We make a ..._positions.tsv file for each recording with position(xyz) and orientation (xyz) as extra columns
3. Perfect - that will be very useful 👍