Back to the main page.
Bug 3185 - incompatibility of ft_realtime_headlocalizer and new CTF hardware electronics
| Status | CLOSED FIXED |
| Reported | 2016-10-17 17:53:00 +0200 |
| Modified | 2018-06-19 09:57:15 +0200 |
| Product: | FieldTrip |
| Component: | realtime |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P5 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Johanna - 2016-10-17 17:53:41 +0200
Hi all (but in particular Robert), I've collected MEG at Nottingham not too long ago (spring 2016) and the ft_realtime_headlocalizer there was working fine in communication with their CTF hardware. However, over the summer they had a hardware upgrade, and apparently only 2 sites in the world have this new version (Nottingham and Beijing). Unfortunately, it does not seem to communicate with the ft_realtime_headlocalizer anymore. I don't know the details of what aspect doesn't work... it is now Sebastian who is trying to use it. Please contact Sebastian Michelmann (SXM1085@student.bham.ac.uk) and/or George O'Neill (George.Oneill@nottingham.ac.uk) for details. (I'm just filing this on their behalf). They should be added to the cc of this bug. Is this something you can assist Sebastian/George with fixing? Presumably more CTF sites will eventually get this hardware upgrade. Cheers and thank you, Johanna
Robert Oostenveld - 2016-10-17 21:50:05 +0200
I just added George to the bug report (@George, please reset your password). There was a poster at Biomag from a CTF engineer outlining the new realtime interface. I forgot his name, but we should try to get that person in the loop to give us more details. Regarding new electronics: I am not sure whether the new electronics is per see the cause, or "merely" the upgrade to a new acquisition computer (with upgraded software). At Cardiff they also have the new computer, but with the old electronics. At Donders we'll also get that mixed setup. I had expected that the updated version of the Acq software still would allow the same shared memory (IPC shmem) interface. It would be the same inefficient interface, but I don't see why they would have removed it as it would not interfere with a newer interface. Could you (i.e. someone at Nottingham) check the acquisition computer with the Linux IPCS command? See http://stackoverflow.com/questions/18786466/command-to-check-status-of-message-queue-and-shared-memory-in-linux. There should be a bunch of IPC shared memory segments. If you post them here, I can compare them to the ones we have on our old Nijmegen acquisition computer.
George O'Neill - 2016-10-18 13:24:58 +0200
Running the command ipcs -m returns: ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 1441792 meg 600 393216 2 dest 0x00000000 1474561 meg 600 393216 2 dest 0x00000000 1507330 meg 600 393216 2 dest 0x00000000 1540099 meg 600 393216 2 dest 0x00000000 1572868 meg 600 393216 2 dest 0x00000000 1605637 meg 600 393216 2 dest 0x00000000 1638406 meg 600 393216 2 dest 0x00000000 1671175 meg 600 393216 2 dest 0x00000000 1703944 meg 600 393216 2 dest 0x00000000 1736713 meg 600 393216 2 dest 0x00000000 1769482 meg 600 393216 2 dest 0x00000000 1802251 meg 600 393216 2 dest 0x00000000 1835020 meg 600 393216 2 dest 0x00000000 1867789 meg 600 393216 2 dest 0x00000000 1900558 meg 600 393216 2 dest 0x00000000 1966095 meg 600 393216 2 dest 0x00000000 1998864 meg 600 393216 2 dest 0x00000000 2031633 meg 600 393216 2 dest 0x00000000 2064402 meg 600 393216 2 dest 0x00000000 2097171 meg 600 393216 2 dest Just as an additional sanity check, I queried /proc/sys/kernel/shmmax and it returned 68719476736.
Robert Oostenveld - 2016-10-18 13:49:12 +0200
(In reply to George O'Neill from comment #2) On our acquisition computer I get this ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 15826944 root 777 94208 1 0x39457f73 29458441 meg 666 67600000 1 0x00000000 16646154 root 644 106496 2 dest 0x00000000 29491213 root 777 4096 1 0x00000000 29523982 root 777 4096 1 See also https://github.com/fieldtrip/fieldtrip/blob/master/realtime/src/acquisition/ctf/AcqBuffer.h which has #define ACQ_MSGQ_SIZE 600 #define ACQ_MSGQ_SHMKEY 0x39457f73 So the 2nd segment is where the realtime data gets passed. That also makes sense on the basis of the size, it should hold 600 packets of 28160 samples each. Well, it does not match completely, but it is close: 28160*4*600=67584000 You don't have this. Did you (or could you) try both sequences of starting acq2ftx and Acq? I.e. first start one, then the other, and vice versa. If that does not solve it, we should bet CTF involved (and/or look at the CTF code, which I don't have).
George O'Neill - 2016-10-18 15:11:38 +0200
Apologies, I forgot to run acq2ftx when checking the shared memory. Indeed the addressed memory appears when running the binary. ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status ... 0x00000000 2129939 meg 600 393216 2 dest 0x39457f73 2162708 meg 666 67600000 2 Note: nattch changes from 1 to 2 once acquisition starts on memory address 0x39457f73. If Acq is launched before acq2ftx (with options -:1972:RE:1:*) then ac2ftx hangs on 'Waiting (on 0)' irrespective if the data is being recorded to disk. If we launch acq2ftx before Acq, it detects the file being created and reads the res4 file as shown below Setup | ID=0 | /ctfmeg/M041-acq2/data/meg/CTF_DATA/20161018/Noise_Noise_20161018_01.ds CTF RES4 file /ctfmeg/M041-acq2/data/meg/CTF_DATA/20161018/Noise_Noise_20161018_01.ds/Noise_Noise_20161018_01.res4 contains 3167523 bytes. Number of channels: 302 Sampling frequency: 600.000000 Hz Ch 1: SCLK01 Gain: 1 Ch 2: BG1 Gain: 7.96683e-15 Ch 3: BG2 Gain: -7.43626e-15 Ch 4: BG3 Gain: 8.28958e-15 Ch 5: BP1 Gain: -7.13271e-15 etc. After that system repeatedly prints 'Waiting (on 1)' irrespective of head localisation being started or if data is being recording to disk or merely being previewed. However this is not all... The strangest part is that if acq2ftx enters this 'Waiting (on 1)' period then the MEG seems to detect ~uT amplitude field changes across all channels and Acq will crash at the end of recording, and reviewing the data in DataEditior shows a 'broken' fieldmap. (I can send some example data over if you are interested in what effect it has!). One has to restart the acquisition machine to return to normal operation. Below is a somewhat intimidating crash log associated with it. *** glibc detected *** Acq: double free or corruption (out): 0xd5879008 *** ======= Backtrace: ========= /lib/libc.so.6[0x3ebc81] /lib/libc.so.6[0x3ee5a1] /usr/lib/libstdc++.so.6(_ZdlPv+0x22)[0xf74b1df2] /usr/lib/libstdc++.so.6(_ZdaPv+0x1e)[0xf74b1e4e] Acq[0x82bbe84] Acq[0x83d83c2] Acq[0x82de8df] Acq[0x82e23c4] Acq[0x82c1abd] Acq[0x8200630] Acq[0x81ddb7e] Acq[0x81e3909] Acq[0x81e438f] /usr/lib/libXt.so.6(XtCallCallbackList+0x121)[0xb32631] /usr/lib/libXm.so.4[0x7dbc68] /usr/lib/libXt.so.6(XtCallCallbackList+0xb6)[0xb325c6] /usr/lib/libXm.so.4[0x7e5e78] /usr/lib/libXm.so.4[0x7e747e] /usr/lib/libXm.so.4(_XmDispatchGadgetInput+0x1af)[0x7b62ff] /usr/lib/libXm.so.4(_XmGadgetActivate+0x3f)[0x870f5f] /usr/lib/libXt.so.6[0xb6a37b] /usr/lib/libXt.so.6(_XtTranslateEvent+0x394)[0xb6ab94] /usr/lib/libXt.so.6(XtDispatchEventToWidget+0x46a)[0xb40e1a] /usr/lib/libXt.so.6[0xb41653] /usr/lib/libXt.so.6(XtDispatchEvent+0xb1)[0xb405c1] Acq[0x8694712] Acq[0x8694690] Acq[0x8145348] /lib/libc.so.6(__libc_start_main+0xe6)[0x391d36] Acq[0x8057da1] ======= Memory map: ======== 00359000-00377000 r-xp 00000000 fd:00 3149806 /lib/ld-2.12.so 00377000-00378000 r-xp 0001d000 fd:00 3149806 /lib/ld-2.12.so 00378000-00379000 rwxp 0001e000 fd:00 3149806 /lib/ld-2.12.so 0037b000-0050b000 r-xp 00000000 fd:00 3149663 /lib/libc-2.12.so 0050b000-0050c000 ---p 00190000 fd:00 3149663 /lib/libc-2.12.so 0050c000-0050e000 r-xp 00190000 fd:00 3149663 /lib/libc-2.12.so 0050e000-0050f000 rwxp 00192000 fd:00 3149663 /lib/libc-2.12.so 0050f000-00512000 rwxp 00000000 00:00 0 00514000-0051c000 r-xp 00000000 fd:00 943414 /usr/lib/libXrender.so.1.3.0 0051c000-0051d000 rwxp 00007000 fd:00 943414 /usr/lib/libXrender.so.1.3.0 0051f000-00655000 r-xp 00000000 fd:00 944423 /usr/lib/libX11.so.6.3.0 00655000-00659000 rwxp 00135000 fd:00 944423 /usr/lib/libX11.so.6.3.0 0065b000-00681000 r-xp 00000000 fd:00 3149733 /lib/libexpat.so.1.5.2 00681000-00683000 rwxp 00025000 fd:00 3149733 /lib/libexpat.so.1.5.2 00685000-006b8000 r-xp 00000000 fd:00 944379 /usr/lib/libfontconfig.so.1.4.4 006b8000-006ba000 rwxp 00032000 fd:00 944379 /usr/lib/libfontconfig.so.1.4.4 006bc000-006dc000 r-xp 00000000 fd:00 944377 /usr/lib/libxcb.so.1.1.0 006dc000-006dd000 rwxp 0001f000 fd:00 944377 /usr/lib/libxcb.so.1.1.0 006df000-00706000 r-xp 00000000 fd:00 944371 /usr/lib/libpng12.so.0.49.0 00706000-00707000 rwxp 00026000 fd:00 944371 /usr/lib/libpng12.so.0.49.0 00709000-0070c000 r-xp 00000000 fd:00 3149678 /lib/libdl-2.12.so 0070c000-0070d000 r-xp 00002000 fd:00 3149678 /lib/libdl-2.12.so 0070d000-0070e000 rwxp 00003000 fd:00 3149678 /lib/libdl-2.12.so 00710000-00724000 r-xp 00000000 fd:00 944490 /usr/lib/libXft.so.2.3.1 00724000-00725000 rwxp 00013000 fd:00 944490 /usr/lib/libXft.so.2.3.1 00727000-009ba000 r-xp 00000000 fd:00 944375 /usr/lib/libXm.so.4.0.3 009ba000-009d2000 rwxp 00293000 fd:00 944375 /usr/lib/libXm.so.4.0.3 009d2000-009d3000 rwxp 00000000 00:00 0 009d5000-00a6a000 r-xp 00000000 fd:00 944431 /usr/lib/libfreetype.so.6.3.22 00a6a000-00a6e000 rwxp 00094000 fd:00 944431 /usr/lib/libfreetype.so.6.3.22 00a70000-00a74000 r-xp 00000000 fd:00 3149712 /lib/libuuid.so.1.3.0 00a74000-00a75000 rwxp 00003000 fd:00 3149712 /lib/libuuid.so.1.3.0 00a77000-00a7e000 r-xp 00000000 fd:00 944465 /usr/lib/libXp.so.6.2.0 00a7e000-00a7f000 rwxp 00006000 fd:00 944465 /usr/lib/libXp.so.6.2.0 00a81000-00a98000 r-xp 00000000 fd:00 943368 /usr/lib/libICE.so.6.3.0 00a98000-00a9a000 rwxp 00016000 fd:00 943368 /usr/lib/libICE.so.6.3.0 00a9a000-00a9b000 rwxp 00000000 00:00 0 00a9d000-00aaf000 r-xp 00000000 fd:00 3149676 /lib/libz.so.1.2.3 00aaf000-00ab0000 r-xp 00011000 fd:00 3149676 /lib/libz.so.1.2.3 00ab0000-00ab1000 rwxp 00012000 fd:00 3149676 /lib/libz.so.1.2.3 00ab3000-00ab5000 r-xp 00000000 fd:00 943337 /usr/lib/libXau.so.6.0.0 00ab5000-00ab6000 rwxp 00001000 fd:00 943337 /usr/lib/libXau.so.6.0.0 00ab8000-00afe000 r-xp 00000000 fd:00 944492 /usr/lib/libjpeg.so.62.0.0 00afe000-00aff000 rwxp 00046000 fd:00 944492 /usr/lib/libjpeg.so.62.0.0 00aff000-00b0f000 rwxp 00000000 00:00 0 00b11000-00b22000 r-xp 00000000 fd:00 943383 /usr/lib/libXext.so.6.4.0 00b22000-00b23000 rwxp 00010000 fd:00 943383 /usr/lib/libXext.so.6.4.0 00b25000-00b7e000 r-xp 00000000 fd:00 944461 /usr/lib/libXt.so.6.0.0 00b7e000-00b82000 rwxp 00058000 fd:00 944461 /usr/lib/libXt.so.6.0.0 00b84000-00bac000 r-xp 00000000 fd:00 3149670 /lib/libm-2.12.so 00bac000-00bad000 r-xp 00027000 fd:00 3149670 /lib/libm-2.12.so 00bad000-00bae000 rwxp 00028000 fd:00 3149670 /lib/libm-2.12.so 00bb0000-00bc7000 r-xp 00000000 fd:00 944463 /usr/lib/libXmu.so.6.2.0 00bc7000-00bc8000 rwxp 00017000 fd:00 944463 /usr/lib/libXmu.so.6.2.0 00bca000-00bd1000 r-xp 00000000 fd:00 943385 /usr/lib/libSM.so.6.0.1 00bd1000-00bd2000 rwxp 00006000 fd:00 943385 /usr/lib/libSM.so.6.0.1 08048000-0878c000 r-xp 00000000 fd:00 2495702 /opt/ctf/bin.release/Acq 0878c000-088eb000 rwxp 00743000 fd:00 2495702 /opt/ctf/bin.release/Acq 088eb000-08a1d000 rwxp 00000000 00:00 0 0a417000-235a6000 rwxp 00000000 00:00 0 [heap] 77f00000-77f21000 rwxp 00000000 00:00 0 77f21000-78000000 ---p 00000000 00:00 0 78000000-78021000 rwxp 00000000 00:00 0 78021000-78100000 ---p 00000000 00:00 0 78100000-78121000 rwxp 00000000 00:00 0 78121000-78200000 ---p 00000000 00:00 0 78200000-78221000 rwxp 00000000 00:00 0 78221000-78300000 ---p 00000000 00:00 0 78300000-78321000 rwxp 00000000 00:00 0 78321000-78400000 ---p 00000000 00:00 0 78400000-78421000 rwxp 00000000 00:00 0 78421000-78500000 ---p 00000000 00:00 0 78500000-78521000 rwxp 00000000 00:00 0 78521000-78600000 ---p 00000000 00:00 0 78600000-78621000 rwxp 00000000 00:00 0 78621000-78700000 ---p 00000000 00:00 0 78700000-78721000 rwxp 00000000 00:00 0 78721000-78800000 ---p 00000000 00:00 0 78800000-78821000 rwxp 00000000 00:00 0 78821000-78900000 ---p 00000000 00:00 0 78900000-78921000 rwxp 00000000 00:00 0 78921000-78a00000 ---p 00000000 00:00 0 78a00000-78a21000 rwxp 00000000 00:00 0 78a21000-78b00000 ---p 00000000 00:00 0 78b00000-78b21000 rwxp 00000000 00:00 0 78b21000-78c00000 ---p 00000000 00:00 0 78c00000-78c21000 rwxp 00000000 00:00 0 78c21000-78d00000 ---p 00000000 00:00 0 78d00000-78d21000 rwxp 00000000 00:00 0 78d21000-78e00000 ---p 00000000 00:00 0 78e00000-78e21000 rwxp 00000000 00:00 0 78e21000-78f00000 ---p 00000000 00:00 0 78f00000-78f21000 rwxp 00000000 00:00 0 78f21000-79000000 ---p 00000000 00:00 0 79000000-79021000 rwxp 00000000 00:00 0 79021000-79100000 ---p 00000000 00:00 0 79100000-79121000 rwxp 00000000 00:00 0 79121000-79200000 ---p 00000000 00:00 0 79200000-79221000 rwxp 00000000 00:00 0 79221000-79300000 ---p 00000000 00:00 0 79300000-793f9000 rwxp 00000000 00:00 0 793f9000-79400000 ---p 00000000 00:00 0 79400000-79421000 rwxp 00000000 00:00 0 79421000-79500000 ---p 00000000 00:00 0 79500000-79521000 rwxp 00000000 00:00 0 79521000-79600000 ---p 00000000 00:00 0 79600000-79621000 rwxp 00000000 00:00 0 79621000-79700000 ---p 00000000 00:00 0 79700000-79721000 rwxp 00000000 00:00 0 79721000-79800000 ---p 00000000 00:00 0 79800000-79821000 rwxp 00000000 00:00 0 79821000-79900000 ---p 00000000 00:00 0 79900000-79921000 rwxp 00000000 00:00 0 79921000-79a00000 ---p 00000000 00:00 0 79a00000-79a21000 rwxp 00000000 00:00 0 79a21000-79b00000 ---p 00000000 00:00 0 79b00000-79b21000 rwxp 00000000 00:00 0 79b21000-79c00000 ---p 00000000 00:00 0 79c00000-79c21000 rwxp 00000000 00:00 0 79c21000-79d00000 ---p 00000000 00:00 0 79d00000-79d21000 rwxp 00000000 00:00 0 79d21000-79e00000 ---p 00000000 00:00 0 79e00000-79e21000 rwxp 00000000 00:00 0 79e21000-79f00000 ---p 00000000 00:00 0 79f00000-79f21000 rwxp 00000000 00:00 0 79f21000-7a000000 ---p 00000000 00:00 0 7a000000-7a021000 rwxp 00000000 00:00 0 7a021000-7a100000 ---p 00000000 00:00 0 7a100000-7a121000 rwxp 00000000 00:00 0 7a121000-7a200000 ---p 00000000 00:00 0 7a200000-7a221000 rwxp 00000000 00:00 0 7a221000-7a300000 ---p 00000000 00:00 0 7a300000-7a321000 rwxp 00000000 00:00 0 7a321000-7a400000 ---p 00000000 00:00 0 7a400000-7a421000 rwxp 00000000 00:00 0 7a421000-7a500000 ---p 00000000 00:00 0 7a500000-7a521000 rwxp 00000000 00:00 0 7a521000-7a600000 ---p 00000000 00:00 0 c6600000-c666b000 rwxp 00000000 00:00 0 c666b000-c6678000 ---p 00000000 00:00 0 c6678000-c6700000 ---p 00000000 00:00 0 c6800000-c68f8000 rwxp 00000000 00:00 0
Robert Oostenveld - 2016-10-18 17:19:02 +0200
(In reply to George O'Neill from comment #4) nattch changing from 1 to 2 is a good sign, it is the number of processes attached to the memory. The shared memory needs to be created prior to Acq using it, i.e. Acq does not create it, but will use it when present. Also: if not already present at start of Acq, it will _not_ start using it later. Hence acq2ftx will wait forever. Furthermore, it reading the res4 file means that the name of the res4 file is still being picked up correctly from the shared memory. So it seems that the interface still exists, but that it is broken on the CTF side. It might be (and would not surprise me) that the organization of the shared memory has changed, or is messed up in the new code. E.g. byte alignment of C structures represented in RAM may have changed due to switching from 32 to 64 bits OS. Do you have new (pdf) documentation to go with the updated software? Do you have access to CTF source code (under a NDA or so)? You may want to explore the "ctf_shm" format in ft_read_header and ft_read_data, which use the fileio/private/read_ctf_shm.mexglx file and read_shm_data.m, read_shm_event.m, read_shm_header.m. The source code for that mex file is in fieldtrip/src and it reads the packets directly from shared memory. I used it for debugging and as an initial implementation to the realtime CTF interface but realized that a stand-alone executable would be easier. By peeking in the shared memory (with the mex file) you may get a better feel for what is going wrong. But possibly more efficient is to ask a software engineer at CTF to get involved... do you have a lead at CTF for this? If not, I can ask at their support desk.
George O'Neill - 2016-10-21 15:28:15 +0200
We've not received any documentation with the new release of software, or have access to the source code yet. Having asked for new documentation recently we were told it will be "coming soon". I shall have a bit of a further dig and will report back in due course. Intrestingly, I've also found in the old Acq manual the appendix describing the realtime interface libraries ctf provided. I shall use those as another start point.
George O'Neill - 2016-11-18 12:14:19 +0100
I have some updates on the situation. CTF have pointed out that the size of the buffer has changed with the 3000 series electronics. See below. --- The feature has not extensively been tested with the new release, but the only change should be in an include file: In code /ctf/ctfacqrt/include/ACQ_MessagePacket.h The size of the data array has been increased from 28160 to 40000 i.e. change // int32_t data[ 28160 ]; // For MEG2005. 110 packet * 1024 bytes / 4 bytes/long to int32_t data[ 40000 ]; and then rebuild the real time application --- I haven't successfully managed to recompile ACQBuffer and acq2ftx yet (on the hunt for the appropriate dependencies) but it appears the solution is trivial. I will let you know if we managed to make it work reliably on our system soon.
George O'Neill - 2016-11-18 18:29:21 +0100
Update on compiling. I managed to create a binary, which runs and was detecting packets of data (which is further than we got before). However using bufferViewer it wasn't showing any data coming through at all. Could this be to do with that fact I compiled on a 64 bit system possibly? I haven't got access to all the 32 bit libraries required to cross compile to double check at the moment unfortunately.
Robert Oostenveld - 2017-05-03 14:28:44 +0200
(In reply to George O'Neill from comment #8) Hi George, It has been quiet for some while on this. We have a new CTF acquisition computer and face the same (similar) problems with access to the real time data. I have just CCed Erik from our technical group on this bug. Did you make any progress? best Robert
George O'Neill - 2017-05-09 11:16:42 +0200
(In reply to Robert Oostenveld from comment #9) Hi Robert, Unfortunately I didn't make any progress on this front. I think this arose from trying recompile the buffer on one type of RH linux and then deploying it onto the new MEG acquisition machine ran into library issues. I know simply installing packages onto the acquisition machine may solve these issues, however I don't have access to the Red Hat DVD and we cannot use yum over the internet on that machine. Also as we were to some extent the test lab for the new acquisition hardware I was hesitant to do anything to that computer whilst other bugs were still being diagnosed and fixed. As it stands the suggestions in comment 7 may work, but I have not been able to confirm or deny that this works. Sorry!
Robert Oostenveld - 2018-01-17 09:57:07 +0100
Our technical group spent some time working on this and have suggested a solution. To implement this, I started with cleaning up the existing code base (which revealed too much the hands of the various people that have worked on this in the past). I have make those initial changes available on https://github.com/fieldtrip/fieldtrip/pull/638 and will update them with the actual fix. After testing on our CTF system, this will be merged to the release version. commit 58148d777d4e2e597d71e6ef8a6512ac2b72ba65 Author: Robert Oostenveld Date: Wed Jan 17 09:48:08 2018 +0100 made the file name of the source code and executables more consistent, updated the Makefile, removed the old binaries, updated the README. commit de596f7679667262d7616647f4f5c941bedf4f06 Author: Robert Oostenveld Date: Wed Jan 17 09:22:26 2018 +0100 removed binaries from source code directory
Robert Oostenveld - 2018-01-17 10:37:48 +0100
The following documentation was provided by Mike from our technical group. Sorry that it is all in Dutch. -------- Om samen te vatten welke werkzaamheden ik verricht heb om CTF_ACQ2FT(x) aan de praat te krijgen: Ik heb met “clone” de volledige Fieldtrip repository gedownload van Github, hier stonden de “originele” source files in voor meg2ft. Deze heb ik geplaats in: /root/Downloads/fieldtrip op de nieuwe ODIN (DCCN-MEG001) als de gebruiker root. Tijdens het kijken in de repository kwam ik de make file tegen in de source folder, deze probeerde ik te runnen, maar liep tegen het probleem aan dat buffer.h niet gevonden kon worden. Na wat dingen gecheckt te hebben kwam ik er achter dat deze library nog niet gecompileerd was. Deze library heb ik met succes weten te compileren door de make te runnen in de folder: /root/Downloads/fieldtrip/realtime/src/buffer/src Hierna vanzelfsprekend geprobeerd om de source files opnieuw te compileren, omdat nu de buffer library aanwezig was, dit was helaas nog niet succesvol door een variabele die verkeerd werd gedeclared. Deze bug heeft Robert zelf ook gevonden en al gefixt, dus dit ga ik verder niet toelichten in deze mail, gezien dit een non-issue is geworden. Na het fixen van de code kon ik de source files met succes opnieuw compileren. Nadat ik dus vast had gesteld dat de source files succesvol gecompileerd kunnen worden ben ik gaan kijken naar de inhoudelijke code, om te zien of ik ergens referenties kon vinden naar de grootte van de originele buffersize (28160). Deze vond ik in meerdere bestanden terug: - acq2ft.c - Acq2ftx.c - Acqbuffer.h - Acqbuffer.c In al deze bestanden heb ik 28160 veranderd naar 40000 zonder verdere aanpassingen te doen aan de code. Na deze mutatie heb ik de source files nogmaals gecompileerd met succes, er waren dus volgens de compiler geen illegale veranderingen gedaan aan de code. Toen ik daarna de binary acq2ft probeerde te draaien in deze folder: /root/Downloads/fieldtrip/realtime/bin/glnxa64 Kreeg ik de foutmelding: “shmget: Invalid argument” Na het lezen van de WIKI van fieldtrip op: http://www.fieldtriptoolbox.org/development/realtime/ctf#known_problems_with_ctf_real-time_acquisition kwam ik er achter dat ’t te maken had met het harde limiet die wordt gesteld vanuit Linux bij het maken van shared memory. Samen met Edward heb ik dit opgelost door op de nieuwe ODIN (DCCN-MEG001) het limiet aan te passen zoals beschreven in de WIKI (opgehoogd naar: 1099511627776) Toen ik na een reboot de binary probeerde te draaien ging dit met succes, en zag je de tekst: Waiting for (0) voorbij komen. Een aantal dagen later heb ik samen met Uriel gekeken of de data uit de shared memory buffer ook werd ingelezen door de acq2ft binary terwijl de nieuwe ODIN aan het MEG rack hing, dit leek inderdaad het geval te zijn, de data die we zagen in het venster kwam overeen met de data die we zien op de oude Odin. Hiermee heb ik eigenlijk de conclusie getrokken (komt mede door het feit dat ik tegen de grens van mijn ervaring/kennis aan liep in deze) dat het programma functioneert zoals het zou moeten. -------------
Robert Oostenveld - 2018-01-17 10:45:17 +0100
(In reply to Robert Oostenveld from comment #11) 130-229-11-149-dhcp> git commit -a [bug3185-ctf-realtime 9e001e1] updated the buffer size from 28160 to 40000, see http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=3185#c12 1 file changed, 7 insertions(+)
George O'Neill - 2018-01-30 17:48:58 +0100
Excellent news, I should be able to work with those instructions to get it up and running again. Will update with news in due course. Thanks for getting round to looking into this in the end!
Robert Oostenveld - 2018-01-31 17:05:51 +0100
(In reply to George O'Neill from comment #14) I have just tested the ctf2ft_v1, v2 and v3 executables on the old acquisition machine. They compile fine, as does the buffer source code. Furthermore, running all three also works fine. I will now proceed testing the compilation on the new acquisition machine.
Robert Oostenveld - 2018-01-31 17:11:41 +0100
(In reply to Robert Oostenveld from comment #15) The code changes have been merged with the master branch, i.e. the release version. See https://github.com/fieldtrip/fieldtrip/pull/638