CursorTask --> Serial Com Port

[jjbaker]

In a previous post, I needed to get P300 to output to serial. There was a option in P300 to output to UDP, and then I redirected that to a serial port.

Now I need CursorTask to output to serial as well but I noticed that there is no UDP option, at least not that I can find, to do this. Any help would be greatly appreciated.

John

[gschalk]

John,

This is very simple. Any BCI2000 configuration supports the AppConnector protocol, which sends all current control signals and states to a UDP port. This will of course work with the CursorTask. Just check out the protocol using the search function on doc.bci2000.org.

Gerv

[jjbaker]

Thanks, that helped. I have the information outputting from BCI2000 via UDP packets, and then getting converted to serial.

Now I'm running into the problem that I need the UDP output to be realtime compared to the CursorTask performance but it would seem that it runs considerably slower. One second of CursorTask behavior takes about a minute to output via UDP.

Is there any way to accelerate this?

[gschalk]

John,

The AppConnector protocol sends out data in real time and will not produce increasing lags over time. I can see two reasons for what you are experiencing:

1) For some reason, your external program is slow and thus gets increasingly behind
2) You actually expect one AppConnector message for each sample, and not each sample block. You can expect SamplingRate/SampleBlockSize messages per second, and not SamplingRate messages per second. Please see the Wiki for an explanation of how BCI2000 is clocked.

Gerv

[jjbaker]

Here is the program I wrote, I'm going to make a stripped down program for testing throughput rate of the UDP output, the only other thing I could think of is that my laptop has a bottleneck somewhere. If you have any suggestions to make this program more efficient/elegant, I would be interested even from a learning standpoint as I'm a mechanical engineer by trade. (My comment formatting was eaten by the forum, sorry.)

Code: Select all

// This segment of code will search a UDP packet for a '(' and then determine 
// if its reading the X or Y mouse movement vector by the 0 or 1 that follows. 
// It writes an 'x' or 'y' to the signal transmit buffer which will be used by 
// the MCU to differentiate between X and Y signals. It then writes characters 
// 12 though 17 to the buffer which are the mouse signals. E.G. x-0.123y1.2345 
// and then outputs the signal via serial. The MCU is only interested in the
// first three decimal places. When the number is positive, it will not have
// a negative sign and thus have a fourth decimal place, this is discarded
// by the MCU but permits a static string length for this program.

	while(1){
		if(getline(udpIn,line)){					// UDP Packet Input
			transPos=0;								// reset trans position
			buffOut=0;								// reset out buffer length
			sig="#######";							// reset signal string
			readLen=line.length();					// length of UDP info
			for(readPos=0;(readPos<=readLen)&&(!transPos);readPos++){
				if((line[readPos]=='(')){			// Found mouse vector
					if(line[readPos+1]=='0')		// Found X signal
						sig[0]='x';					// Write x to trans buffer
					if(line[readPos+1]=='1')		// Found Y signal
						sig[0]='y';					// Write y to trans buffer
					transPos++;						// Increment trans buffer
					for(readPos=min;readPos<=limit;readPos++){ // Read signal
						sig[transPos]=line[readPos];// Write to trans buffer	
						transPos++;					// Increment trans buffer
					}					
					buffOut=sig.length();			// Determine serial buffer
					sendData(sig.c_str(),buffOut);			// Serial Output				
					//cout << "BCI2K Out: " << sig << endl;	// Display Progress
				}
			}
		}	
	}

[gschalk]

Hi,

In general, your program seems fine. How do you know that it gets behind? What happens if you remove the sending to the serial port? Is it still behind then?

Gerv

[jjbaker]

It turns out that I fixed the program before sending it to you. I removed some lines that read serial input from my MCU that I use for error checking. The serialSend is a very quick function, but since the readData is waiting for the MCU and there is some hardware flow control going on, it was slowing things down considerably.

Thanks for the help in tracking this down,

John