Back to the main page.
Bug 2569 - windaq data cannot be read on a matlab2013a machine
| Status | CLOSED FIXED |
| Reported | 2014-05-09 12:55:00 +0200 |
| Modified | 2014-06-18 12:30:46 +0200 |
| Product: | FieldTrip |
| Component: | fileio |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P5 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Robert Oostenveld - 2014-05-09 12:55:12 +0200
during the meg toolkit tineke had problems reading windaq data. It was fixed on her computer with changing this dat = bitshift(dat, -2) into something like this dat = double(bitshift(int32(dat), -2))
Robert Oostenveld - 2014-05-09 12:55:48 +0200
I suspect this to be the consequence of the matlab version
Robert Oostenveld - 2014-05-11 08:42:01 +0200
The on-the-fly fix would be simple to apply to the svn version, however, I have some questions: in fileio/private/read_wdq_data.m I see at line 84 that for low bits it reads one segment at a time and inserts it in dat, whereas for ~lowbits it replaces dat with the segment. Is that inconsistency on purpose? Looking at the history of the code https://code.google.com/p/fieldtrip/source/list?path=/trunk/fileio/private/read_wdq_data.m&start=7123 it seems to me that the chunking that was introduced in r3163 should apply both to triggers and data. @Jan-Mathijs, do you agree? Do you have some test data?
Jan-Mathijs Schoffelen - 2014-05-11 19:52:19 +0200
Hmmm, this looks like a typo to me. I suspect that this indeed is wrong. The documentation and hopefully some test code may be on my Desktop PC. I cannot locate it on my Mac. I recall that I did most of the implementation in Windows, because I needed Windows-only software to compare the output.
Robert Oostenveld - 2014-05-13 12:15:59 +0200
I have added Tineke and caspar to the CC list of this bug. @Tineke, could you share one of the windaq files with us for testing purposes? E.g. the one that you had on screen last Friday? See http://fieldtrip.fcdonders.nl/faq/how_should_i_send_example_data_to_the_developers We suspect (as you can read on bugzilla) that there is potentially a 2nd issue with the present importer, i.e. one that I did not notice on Friday.
Robert Oostenveld - 2014-05-13 13:49:53 +0200
Tineke just sent me a file. Here are the details according to her: Opbouw van de file: 8 kanalen: sample frequency 12500 per kanaal (was de max instelling en de frequencyinhoud van de audiostimuli was 6.5 kHz) -1 kanaal als controle (dood dier aangekoppeld) -4 kanalen local fieldpotentials: brainstem, thalamus, cerebellum, cortex. -1 kanaal met stimulus markers (11 Hz) -1 kanaal met de frequentieinhoud van de stimuli (6.5 kHz piepjes, 20 ms, met envelop) -1 kanaal met wat de microfoon registreerde. Ik stuur ook de header die ik maakte om het in BrainVision in te openen.
Robert Oostenveld - 2014-05-13 14:17:18 +0200
(In reply to Robert Oostenveld from comment #5) I copied it to the directory /home/common/matlab/fieldtrip/data/test/bug2569. Trying to read it, the bit "mask" in line 35 in read_wdq_header is giving me problems. I can work around it for the moment...
Jan-Mathijs Schoffelen - 2014-05-13 14:41:22 +0200
I have the official Windaq software+documentation on my desktop PC I believe, so we could use this to verify.
Robert Oostenveld - 2014-05-13 15:03:37 +0200
mac011> svn commit private/read_wdq_*m Sending private/read_wdq_data.m Sending private/read_wdq_header.m Transmitting file data .. Committed revision 9514. this change deals with the matlab change in bitget, includes some cleanups to the code to make the flow more clear, and has a change in header bitmasking for nchan. For the specific test dataset I now have, the mask with "32" (see code) would not do it. The flow in the data regarding the chunks was actually not causing any problems, it was only difficult to see how the logic was. Oh, one relevant change is on line 76 in read_wdq_data, where I changed offset = begsample(k) * hdr.nchan * 2; into offset = (begsample(k)-1) * hdr.nchan * 2; This is added to hdr.nbyteshdr and I guess it should be 0 if you want to read the first sample of the first channel. The 1-sample offset change applies both to data and triggers, so with a completely fresh analysis nobody would notice. It can only be observed if you take an old event structure from disk (or trl) and preprocess the data again. But since it is only a 1-sample shift, I don't think it is a problem. @Jan-mathijs: Could you check? To me it now all seems fine.
Robert Oostenveld - 2014-05-15 08:49:34 +0200
mac011> svn commit test/test_bug2569.m Adding test/test_bug2569.m Transmitting file data . Committed revision 9535.