Back to the main page.
Bug 1246 - Biosemi2ft has undefined state for the split-trigger config option if not specified.
| Status | CLOSED FIXED |
| Reported | 2012-01-06 08:57:00 +0100 |
| Modified | 2012-06-20 15:03:21 +0200 |
| Product: | FieldTrip |
| Component: | realtime |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 normal |
| Assigned to: | Boris Reuderink |
| URL: | |
| Tags: | |
| Depends on: | 1234 |
| Blocks: | |
| See also: |
Boris Reuderink - 2012-01-06 08:57:18 +0100
Biosemi2ft has undefined state for the split-trigger config option if not specified. See email exchange below. --- Dear Boris, I'm pleased to report that progress has been made. First let me say that your assessment was spot on. I looked at SignalConfiguration.c and saw the problem you were talking about, and I thought that that seemed like a reasonable culprit for the problem. I reasoned that if this was in fact the source of the issue, then it should be the case that if I included the splittrigger configuration option, the problem might be overcome. This is exactly what happened. Once I uncommented the splittrigger line in the config file, the triggers were detected by ft_realtime_synchronous (however, I immediately ran into the problem that the function 'offset2time' that is called on line 162 of ft_realtime_synchronous is not accessible from that function --likely because it is in the fieldtrip\private folder, so I imagine if I move ft_realtime_synchronous from the fieldtrip\realtime\tutorial folder up to the main fieldtrip folder I should be fine). This problem and subsequent bugs should be no problem for me to sort out now that I'm at least getting the triggers in). I am just going to leave the splittrigger configuration option in there since it makes no difference to me, but it might be a good idea to patch up SignalConfiguration.c moving forward so that it handles this more smoothly. Many thanks again for taking the time to look at this for me. I know well how much time and effort goes into debugging code like this (especially remotely). Kind wishes, Adam On 05-Jan-2012 05:48, Boris Reuderink wrote: Dear Adam (CC: Robert Oostenveld), It took a look at your problem, and made the following observations so far: # FT's recorder.exe Odd that recording.exe did not generate any data... maybe this is a separate issue, maybe it is not. I take it that the command you used to record the stream to disk are in ft_realtime_debug_command.png, with left the recorder, and on the right the command to read the data from the amplifier, and write it simultaneously to a .gdf and a buffer? I took a look at the source for recorder.exe, and it does not seem to contain output that would help us to identify the problem --- based on the screenshot I cannot judge if it recorded data at all. # Biosemi2ft When I look at the output of biosemi2ft, the format of the trigger display lines indicate that it assumes *a split trigger format*. This is odd, since the config file does not specify a split trigger format. I hunted through the code, and in realtime/buffer/cpp/SignalConfiguration the value is read from a file if it exists, *but apparently it is not initialized*. This could mean that it will get initialized to a random state. Before I continue, could you confirm that this is a more or less correct assessment? Best, Boris
Boris Reuderink - 2012-01-17 12:13:23 +0100
Restimated time for fix.
Boris Reuderink - 2012-02-24 12:25:45 +0100
I committed a fix, see http://code.google.com/p/fieldtrip/source/detail?r=5316# . Note that the binaries were not updated yet, as I will recompile all the binaries in one pass (see #1234).
Boris Reuderink - 2012-03-28 10:53:14 +0200
I have recompiled the biosemi2ft executable (see bug 1234). I mark this issue as FIXED:RESOLVED.