Errors loading new CTF data

[yuhanmc]

Hi brainstorm experts,

I am trying to load CTF data, and saw this message. I was able to load other CTF data, but not this one. Please let me know how to fix it.

Here is the screenshot of the error message. My brainstorm version is the most current one. Please let me know how to

[Raymundo.Cassani]

Check the discussion in this post:

Subject Outside of Helmet, Coregistration Error

I followed the tutorial that Marc mentioned, but I was unable to fix the problem. After using the defaults mentioned in the tutorial I received this error: ** Error: [process_adjust_coordinates] Import > Channel file > Adjust coordinate system ** Line 40: ctf_seek (line 40) ** Epoch #1 is not accessible in any of the meg4 files of this dataset. ** ** Call stack: ** >ctf_seek.m at 40 ** >in_fread_ctf.m at 92 ** >in_fread_ctf.m at 81 ** >in_fread.m at 84 ** >process_evt_head_motion.m>L…

Best,
Raymundo

[yuhanmc]

Hi Raymundo,

Thank you. I checked the previous post, and tried the solution and check if the file is empty (*.meg4 size). I still go the same error message. It was not about the size or if the setting is continuous/epoched (the data is continuous dataset).

Please let me know if you know other way to fix it.

Yuhan

[Raymundo.Cassani]

Could you share the problematic file?
Upload the file somewhere and post the download links here.

[yuhanmc]

Thank you for checking! Please see link below:

https://www.dropbox.com/sh/qxudknlejyrkhcv/AADYAeXdplnWLANAWj0tfTRma?dl=0

Yuhan

[Raymundo.Cassani]

Thank you for posting the data. After analyzing the files, it seems the issue was either at the recording session or when copying the data files.

The resource file (.res4), which contains the header indicates a 14-minute recording file (meg4), which should be a file of 1.3GB (850s * 1200Hz * 324channels *4bytes/sample), however, the available recording file weights only 595 MB, i.e., contains only ~6-minutes of data. Thus it cannot find the #1 epoch (entire recording)

[yuhanmc]

@Raymundo.Cassani

After analyzing the files, it seems the issue was either at the recording session or when copying the data files.

The resource file (.res4), which contains the header indicates a 14-minute recording file (meg4), which should be a file of 1.3GB (850s * 1200Hz * 324channels *4bytes/sample), however, the available recording file weights only 595 MB, i.e., contains only ~6-minutes of data. Thus it cannot find the #1 epoch (entire recording)

Thank you for checking! I am not sure what happened during data transferring, we will further investigate the size of original data in the acq before data transferring. Hopefully this is just a one-time case.