bci2000.org BBS

Hello,

I'm trying to send UDP messages over the AppConnector to BCI2000.
But I don't know which commands I can send.

On the wiki page I found: http://www.bci2000.org/wiki/index.php/U ... _Scripting
Can I send this commands over UDP to BCI2000? Or are they just for the .bat File?

Because if I send "START" or "Running 1\n" nothing happens....
How can I start a session?

Regards,
Nadine

Hi,

you cannot send scripting commands over the AppConnector interface. Also, you cannot start runs over the AppConnector because AppConnector messages are only processed while the system is running.

Otherwise, "Running 1\n" would be correct to set a state value.

In order to start a run from outside BCI2000, you may use Operator scripting as described on the wiki, or use the console version of the Operator module (which is called OperatorCl.exe) rather than the GUI version. With the console verision of the Operator module, you can actually control BCI2000 interactively via scripting commands. Using input/output redirection, you can use this to control BCI2000 from your own program (see http://msdn.microsoft.com/en-us/library ... s.85).aspx for information on redirecting input/output).

Regards,
Juergen

I have a question along these same lines, if I wish to run BCI2000 remotely, I can launch the Operator Module as follows:
Which opens up the port localhost:3999 to receive remote commands. At this point, the Operator module is in the "Idle" state and thus cannot receive connections from other modules. The only way I see to change this is by sending the command "startup", which then puts the operator in the Startup state. Is there a way to start the operator module directly in to the startup state or to script the module to immediately enter startup upon starting? I don't see an appropriate event to cause this to happen. The only difficulty that this causes is I can't script the entire startup sequence if I enable remote connection. Any hints?

Hmm... An additional note:

If I do start the operator as above, and log in via putty, I seem to have trouble starting the individual modules.

I have tried the following: As well as
Which results in a state transition from Idle to Startup, and when Launching SignalGenerator the putty terminal hangs and I am unable to open a new one.

Lastly I tried to put the command to launch the SignalGenerator module in a batch script which I called similarly and also causes the terminal to hang. Because I'm shooting in the dark a bit, and unsure what the problem may be, I also tried all of these steps with my Firewall disabled. I'm running Win7 x64 but using 32-bit binaries, and have the BCI2000 source that was current as of 4/3/2012, Operator Version 3.0.4


The only successful workaround I've found for the time being is as follows:
1) Locally run the operator: "start Operator.exe --Telnet"
2) Remotely (through PuTTY) run the following command to transition the operator from Idle to Startup states: "STARTUP"
3) Locally start the Source, Processing, and App Modules: "start SignalGenerator", "start SpectralSignalProcessing", "start CursorTask"
4) Remotely: "LOAD PARAMETERFILE ..\parms\examples\CursorTask_SignalGenerator.prm", "SETCONFIG", and "START"

This gets the app up and running locally, which is a good start (I can move on to AppConnectors from here), but requires that I access a command prompt on the machine running the operator module, which I would like to move away from. Any help is greatly appreciated!

Hi,

the telnet connection feature is rather new, and thus had some initial quirks around it. During the past two weeks, it has become more mature, so you should be able to use it the way you intend to.

Is there a way to start the operator module directly in to the startup state or to script the module to immediately enter startup upon starting?

Operator module startup behavior has been changed, such that it will now always execute "startup", no matter whether --Telnet is specified or not. To control this behavior, there is now a new option, --StartupIdle, which suppresses execution of "startup" when desired.

Lastly I tried to put the command to launch the SignalGenerator module in a batch script which I called similarly and also causes the terminal to hang.

There were a few issues with deadlock due to a coarse-grained locking strategy in the Operator module. These issues should be fixed by now. You should update to the latest SVN version (note that this will currently only compile under MSVC).

If you still have problems after updating to the latest version, I appreciate your feedback.

Regards,
Juergen

Juergen,

Thanks for the response. The changes that you have made in the most recent version have really helped with my development process. I seem to have stumbled across something else that I could use a bit of help with though.

If I run BCI2000 with the following batch file
and then run putty locally (ie. on the same machine that is running bci2000) to connect to the BCI2000 telnet server (connected to 127.0.0.1, port 3999, connection type = telnet), I can successfully send commands to the bci2000 server. However, if I try to connect using the actual IP address of the machine (in my case 192.168.1.4) the connection is refused. I can further verify this by trying to connect from another machine, for which the connection is also refused.

I do not have a lot of experience in Socket programming, but it looks like, for some reason, the BCI2000 telnet server is set up to only accept local sockets. I did a quick check in Java, launching a TCP server and was able to connect locally using the same parameters with putty on both the 127.* and 192.* addresses. I was also able to connect from the other machine using the 192.* address.

I have to run, but will try to play with this some more tomorrow as well. If you have any ideas I would love to hear them, and if I find anything myself I will make sure to post a follow-up.

Thanks!

I do not have a lot of experience in Socket programming, but it looks like, for some reason, the BCI2000 telnet server is set up to only accept local sockets.

This is intentional. The default telnet address is "localhost:3999", i.e. the server is bound to 127.0.0.1. To have it listening on a different address, use "--Telnet 192.168.1.4:3999". Listening on all addresses should also work, by writing "--Telnet *:3999".

Regards,
Juergen