Re: [MindIO-devel] remote connection

[Ian V. <vi...@ig...>]

>>
>>>I've been thinking about how we can implement remote connections, such as
>>>for remote supervision.
>>>
>>>One option I see is that the ModEEG object will have the ability to create a
>>>server socket that is listened to by a ModEEG object on the supervisor's
>>>computer.  It could just pass the raw bytes over the connection to be
>>>decoded on the supervisor's computer.
>>
>>
>>Nelo was talking of socket connections to. I know nothing of them, so 
>>can't comment in an informed way. There is no provision in the original 
>>design for realtime monitoring of the training session, but that is not 
>>to say that it would not be useful. However I need to get away from 
>>locking the supervisor and trainee into a 1:1 realtime relationship since 
>>this is what makes the current application of NFB expensive. I want to 
>>focus on Trainee self analysis, and use the supervisor in a revisory 
>>role. Real time superevision would provide an additional option and is 
>>interesting and no doubt achievable..
>>
>>Why would the data need to come in via the ModEEG object. Could it not be 
>>a separate channelobject customised for this purpose. Like SocketObject 
>>or something. I previously envisaged that data would transfer by file, at 
>>the completion of a session, but thats not very technically 
>>sophisticated, and we can probably do better than that.
>
>It would be easy to create an object that writes signal data to a file, 
>and it may be a good option for what you have in mind, not to mention 
>making a permanent record of a session.

I had assumed that this was a given, that data would be streamed to a file 
for session records. I don't think there is any standard format for EEG 
data, so we can evolve our own.

>I thought it would make sense to implement the remote connection from one 
>ModEEG object to another, before the data is decoded, because the ModEEG 
>packet format already encapsulates 6 channels, plus a packet counter, in a 
>compact format.

Yes, this does make perfect sense. We should stick to the predefined ModEEG 
data format/protocol if possible since it was designed for that purpose.

>If the connection was too slow, or if only one or two channels was needed, 
>it may make more sense to write a Terminal object that encodes a signal 
>channel of data, with a packet counter, and sends it along a remote 
>connection.  Another Terminal object on the remote computer would receive 
>the data and could be considered a "source" object.

hmm..I guess a packet counter is essential here to maintain the integrity 
of the timing. Also the Terminal objects at each end of the connection 
could be presetable to a channel count, like 1, 2, 4, 6 etc. so long as 
both ends know what is going on, then anything is possible.


>>>In that case, the connectivity would
>>>be internal to the ModEEG object and outside the scope of our API design.
>
>>Can you explain this. It seems to me to be a contradictory statement. Do 
>>you mean that the socket connection would not go via the API, but via its 
>>own connection implementation.
>
>I'm just discussing the options for remote connectivity, to see if it 
>requires any changes to our design.  My above statement just means that, 
>as far as I see it, no changes are needed, because there could be objects 
>that fit into the current design that implement remote connections.

I just presume that the connection would be handled by a specialist 
terminal object and is conceptually similar to the ones that would handle 
data streaming to file. Effectively the 'connection' is to an external 
device, just as with audio, file, etc. Basically these Terminal objects are 
identifiable by the fact that they have Rx's and no Tx's. 'End of the line' 
Terminals, rather than 'pass through' Terminals. Something like that.

When I was doing NFB with my supervisor, she was altering settings on the 
fly, and this would imply a two way connection. I hadn't planned on this, 
but come to think about, if you have psuedo  real-time supervision, then 
being able to change Terminal objects properties mid segment is fairly 
essential.

>>>Another option is that there can be a Terminal object that passes a signal
>>>through but also sends the data over a server socket.  One would need to be
>>>placed in line of every channel the supervisor wanted to listen to.
>>>There
>>>would be some kind of listener object on the supervisor's computer.
>>
>>
>>Two channels of data could be combined as a 512 bps signal, could it not? 
>>That way we only need a single channel.
>
>No.  ModEEG produces 256 samples each second, but each sample is 10 
>bits.  So, 2 channels would require a minimum of 5120 bps, and that 
>doesn't take into account a packet counter.  The P3 packet format, as an 
>example, requires 40 bits for 2 channels, though I don't see the need for 
>an auxilliary channel, which would cut out 8 bits.  That means two 
>channels would require at least 8192 bps, but that's still well within 
>even dial-up internet connection speed, which is usually around 
>44,000-50,000 bps.

I really had this screwed up, my thinking must have been elsewhere when I 
wrote that. (??:-) btw, in rural areas, like where i live such fast dialup 
speeds are not acheivable due to the prescence of electric fences. My 
dialup is restricted to 32k bps since it provides faster throughput than 
using the higher speed protocols. It might connect Ok at something higher, 
but the error rate can go way up.

 From a practical NFB pov, it would be absolutely fine to limit 
transmission to two channels of EEG, but then again I see a case for 
additional channel for HRV that runs concurrently with the EEG since that 
provides the supervisor with very good feedback on the state of relaxation 
of the Trainee. Since the bandwidth is a available for 6 channels, lets 
stick with that.

>>>Neither of these options requires any change to our design.  I'm sure there
>>>are other options.  Any ideas?
>>
>>
>>Seems to me that this supervisory channel needs its own protocol.
>
>I agree, but I think our current API should be independent of any 
>particular application.  That way the objects can be used in various 
>applications.  We can consider the actual application we produce to be the 
>"default" application of MindIO.

Yes, this is also my thinking, that MindIO will be minimalist in terms of 
clinical NFB function but will contain objects that can be used elsewhere. 
It could be a single 'segment' application, much like BE currently is.


>>>If the supervisor needed the ability to modify the  layout at run-time, that
>>>could be built into the application and would also not require any change to
>>>our general object relationship design.
>>
>>Since we need the Trainee to be able to train when the supervisor is off 
>>line, 24/7 there is a case for there being a supervisor server of some 
>>kind where the Trainee can log into to download session designs etc 
>>perhaps. Maybe this server could act as a go between for all 
>>Trainee/Supervisor transfers. One factor that I haven't even mentioned is 
>>that the Trainee needs to be able to assess the effect of each segment 
>>and transfer that info to the supervisor. This would ideally be in the 
>>form of a brief questionaire, and a html server could work well in this 
>>role. Its getting complicated though. Part of Trainee training is the 
>>doing of this self assessment, and is an integral part of the self 
>>training concept. The results of the assessment are used in customising 
>>the following sessions.
>
>I think you're talking about a server-side web application.  You could say 
>that's my specialty, as that's the majority of programming that I've done 
>recently.  That's how I make a living (one of my three jobs, anyway).

Take for instance the situation where the supervisor had two or more 
trainees training concurrently, or where the supervisor was of lnie or 
doing something else, like sleeping. A server side web app could manange 
the training process, including the collection and storage of session EEG 
data for retrieval by the supervisor as and when required. It could also 
manage the transmission of session and layout designs as required. I 
actually really like this conception.

Jeremy..read through this scenario and take a stab at the question at the 
end. Assume for this example, that we are using a server side app rather 
than a socket connection. The Terminal object transmits EEG data to the 
server side app, via http, the server processes this data, stores it in its 
data base, and if required echos it to the supervisor. What would the time 
delay be reasonably expected to be. I realise that there are variables in 
here such as the number of concurrent trainees, the server cpu speed, the 
server loading, the nature of the app, or whatever. Can you give a ball 
park. Could it typically be within say 3 seconds. Why I ask is that there 
is no absolute need for strict real time monitoring in this situation, and 
a few seconds delay is acceptable.

I just thought of a new connectivity issue and that is that the supervisor 
should somehow know exactly what the Trainee is 'actually' seeing and 
hearing so some mechanism needs to be in place to correlate the two 
systems. Trainees can change Terminal properties at run time and the reward 
response of the system will reflect that, so somehow these changes need to 
get through to the supervisor. Reward ratios are an important factor and 
Trainees might get them wrong initially, so the supervisor needs to be able 
to monitor that. Seems we almost need some kind of ongoing change log or 
something. This is very important and have not previously thought of it. 
More thinking needed here.

Time for xmas dinner..yumm

Ian







>-------------------------------------------------------
>This SF.net email is sponsored by: IBM Linux Tutorials.
>Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
>Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
>Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
>_______________________________________________
>MindIO-devel mailing list
>Min...@li...
>https://lists.sourceforge.net/lists/listinfo/mindio-devel