Back to the main page.
Bug 1359 - detecting the wrong acquisition rate
| Status | CLOSED FIXED |
| Reported | 2012-03-06 17:16:00 +0100 |
| Modified | 2012-08-23 14:02:01 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | Macintosh |
| Operating System: | Mac OS |
| Importance: | P3 minor |
| Assigned to: | Jörn M. Horschig |
| URL: | |
| Tags: | |
| Depends on: | 149013111348 |
| Blocks: | |
| See also: |
Anahita Mehta - 2012-03-06 17:16:13 +0100
My EEG data has been acquired using a 32 bit system. However, if I try to specify the rate using : cfg.dataformat = 'ns_cnt32'; cfg.headerformat = 'ns_cnt32'; cfg.eventformat = 'ns_cnt32'; the values are not in the correct range (there are no negative values). If i remove the lines of code stated above, then it processes the data using a 16 bit acquisition rate and i end up with every alternate column of the processed data being a zero. Not sure if this is a bug or something I am doing wrong (sorry if it is the latter).
Robert Oostenveld - 2012-03-06 21:56:12 +0100
This all seems to be related to bug 1311 and 1348. I suggest to revisit 1311 and make a thorough test script with sufficient data.
Robert Oostenveld - 2012-06-05 16:38:27 +0200
it might also relate to bug #1490 which I took over from Roemer and for which promised to make a test script with multiple neuroscan datasets. The test script could also include this dataset. Anahita, would you mind sharing one of your problematic cnt files with us? Ideally it would be as small as possible for practical reasons.
Anahita Mehta - 2012-06-05 20:41:37 +0200
Hi, Here is a sample EEG recording file. http://dl.dropbox.com/u/15215625/sub1E3a.cnt Hope it helps. (In reply to comment #2)
Robert Oostenveld - 2012-06-05 23:17:10 +0200
I have made changes in the code to solve bug 1490. Following those changes I also made a very simple test script for this bug, see http://code.google.com/p/fieldtrip/source/detail?r=5914 and http://code.google.com/p/fieldtrip/source/browse/trunk/test/test_bug1359.m Based on that test script and visual inspection it seems that the data contains some meaningful channels. There are also a lot of channels that are all zero, but with some channels being non-zero and containing physiological signals and electrode drifts, it is difficult to imagine that the file was incorrectly read. Could you please confirm that the data is now read correctly, by downloading the latest fieldtrip version tomorrow (that is fieldtrip-20120606.zip on the ftp server, or revision 5913 or later from svn)? I suggest that you compare the data as read in fieldtrip (using the eeglab loadcnt reading function) with another implementation, or perhaps with the neuroscan software.
Jörn M. Horschig - 2012-06-13 15:49:15 +0200
Hi Anahita, I just checked what Robert's been saying, and can confirm that with the newest FieldTrip version the data has positive and negative values. However, most channels are just zeros, whereas the others look quite normal. Can you please tell us what the data should look like? e.g. give the range of the values that they should have? Without knowing what the data should look like, we cannot check whether the data is read in correctly :/ Best would be of course, if you check whether the data is read in correctly yourself and then report back. Thanks in advance for your cooperation! Best, Jörn
Anahita Mehta - 2012-06-14 07:10:43 +0200
Hi, Sorry for the delay but I am currently out of the country. I should have mentioned earlier that this data was a single electrode recording..so the only channels active would be Fz and the 4 eye electrodes. AFz and A1 are ground and reference electrodes respectively. If you have got positive and negative values in these channels, then the code should be working correctly. The rest of the channels are supposed to have zeroes only. Sorry for not mentioning this earlier! Thanks for sorting this problem out. Best, Anahita.
Jörn M. Horschig - 2012-06-14 10:34:15 +0200
There are indeed 5 non-zero channels, so I assume that this got fixed with bug 1490. Thanks for reporting this and helping out! Should you observe any other problems with neursoscan data, feel free to just file another bug.