-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reading Data from QuSpin Gen 2 OPMs #8671
Comments
this is no acq system to allow to save your data for such device?
… |
@LauriParkkonen and @rzetter added a QuSpin OPM example back in #5525 where the data was in FIF format. Any thoughts on QuSpin formats / acquisition / saving? Was writing to FIF a home-grown solution? |
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
<#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
<#8671 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJ7C3ECRHPJOEWARBJI2RLSVNBTTANCNFSM4VAKBOUQ>.
|
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 :) ) |
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? |
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:
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. |
@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? |
@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. |
Thanks @rzetter
|
I think we have this now but feel free to reopen if I'm mistaken (thanks @georgeoneill !) |
Hi All, Just echoing what Robert mentioned. I just posted some QuSpin Neuro-1 sample data with a document that describes the formatting here. This may help with the use case of data saved using the QuSpin Neuro-1 software (labview based). We're finishing up some TCP/IP data stream details, but once those are finalized, I'll provide a document explaining the data stream format. Reach out any time with questions, cheers! |
Okay I'll reopen this since from a quick look this looks like a new file format. So we either need to improve our existing reader or write a new one. Not sure which is the best option. Would depend on how similar the formats are probably and someone will need to dig into the details a bit to know. |
I'm not directly based in the UCL OPM lab anymore (now a 3rd party user). But we have a Neuro-1 here so can get some more information on the state of the file format. My hunch is QuSpin use the .lvm from LabView and then we decorate it with our BIDS-like metadata offline. But let me get back to you on that. |
Happy to be involved in writing the reader for this @larsoner @dbobela406 - I'll be using Neuro-1 in combination with MNE very soon! I'll follow the discussion on the Fieldtrip post as well. OK to open a new issue as this isn't for Gen-2 OPMs...? |
Yes feel free! I'll close this then |
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...
The text was updated successfully, but these errors were encountered: