Hi all,
I am developing a simple P300 scenario with a VRPN client. However, the VRPN server does not receive the stimulation from rows and columns in a synchronized way. This leads to transient response in my VRPN client. Is there any means of circumventing this problem ?
Thanks a lot.
Duvi
Stimulations to VRPN Server synchronization
Re: Stimulations to VRPN Server synchronization
Hi duvi !
Indeed, VRPN is not very suitable for P300-oriented paradigm, as it can induce some unconstant lag in the process.
The best way to synchronize your application is by using parallel port on the EEG acquisition device, if any.
In this case the device sends the trigger events and everything receive it on time.
This is the only option I see so far... (Someone else, idea ?
)
Laurent
Indeed, VRPN is not very suitable for P300-oriented paradigm, as it can induce some unconstant lag in the process.
The best way to synchronize your application is by using parallel port on the EEG acquisition device, if any.
In this case the device sends the trigger events and everything receive it on time.
This is the only option I see so far... (Someone else, idea ?
)Laurent
Re: Stimulations to VRPN Server synchronization
Thank you for you response !
However, in my application I can not use the parallel port (not available).
My only possible way to communicate is through VRPN.
There is no box/trick to synchronize two stimulations from different sources ?
However, in my application I can not use the parallel port (not available).
My only possible way to communicate is through VRPN.
There is no box/trick to synchronize two stimulations from different sources ?
Re: Stimulations to VRPN Server synchronization
Hi,
I did not know of this problem. We used the VRPN analog box to send a signal to a client application to give a command to a robot arm (not for the P300 case however). I was planning to use the VRPN button box to communicate only the output stimulus of a classifier to a client application. Can I ask you how unconstant this delay is and how big?
What exactly is the reason of that unconstant delay?
If I understand correctly you want to communicate the P300 stimuli to another application? So, if you can not use the VRPN then I would suggest to use an ugly method like I did before: use interprocess communication via shared memory (part of the boost package that comes with OpenViBEs dependencies). I'm not sure if you can get it synchronized that way as I do not know the reason for the delay in the VRPN box and I also do not recommend it as I found it a clumsy solution.
Best regards,
Dieter Devlaminck
I did not know of this problem. We used the VRPN analog box to send a signal to a client application to give a command to a robot arm (not for the P300 case however). I was planning to use the VRPN button box to communicate only the output stimulus of a classifier to a client application. Can I ask you how unconstant this delay is and how big?
What exactly is the reason of that unconstant delay?
If I understand correctly you want to communicate the P300 stimuli to another application? So, if you can not use the VRPN then I would suggest to use an ugly method like I did before: use interprocess communication via shared memory (part of the boost package that comes with OpenViBEs dependencies). I'm not sure if you can get it synchronized that way as I do not know the reason for the delay in the VRPN box and I also do not recommend it as I found it a clumsy solution.
Best regards,
Dieter Devlaminck
Re: Stimulations to VRPN Server synchronization
Thanks all.
Actually, I succeeded in using P300 and Button VRPN thanks to a simple trick. the problem was that the pipelines from rows and columns were not synchronized resulting in a non-synchronized reception of button modification at the client. A simple way to solve this is to impose a modification of at least 2 buttons for a 2*2 P300. At the client side, no command is sent while two modifications are not received. In Openvibe, to force a modification of exactly two buttons, each button responds to one stimulation in on/off state (switch). This system works quite well.
Best regards,
Duvi
Actually, I succeeded in using P300 and Button VRPN thanks to a simple trick. the problem was that the pipelines from rows and columns were not synchronized resulting in a non-synchronized reception of button modification at the client. A simple way to solve this is to impose a modification of at least 2 buttons for a 2*2 P300. At the client side, no command is sent while two modifications are not received. In Openvibe, to force a modification of exactly two buttons, each button responds to one stimulation in on/off state (switch). This system works quite well.
Best regards,
Duvi
Re: Stimulations to VRPN Server synchronization
Great !
What are you working on (if you can talk about it of course) ?
We are very interested by having some feedback from our users, and what they really do with OpenViBE
Best Regards
Laurent
What are you working on (if you can talk about it of course) ?
We are very interested by having some feedback from our users, and what they really do with OpenViBE
Best Regards
Laurent
Re: Stimulations to VRPN Server synchronization
Hello everyone,
I think there has been some confusion and misunderstanding in this thread... On one hand, the problem duvi had was to send classified results to an external application so it can react accordingly. This is the same use-case as Dieter when he controlled his robotic arm using the OpenViBE speller. On the other hand, Laurent outlined some critical considerations when it comes to the external application doing the flashing sequence and sending tagging information to OpenViBE. In such case, parallel port (or whatever direction connection to the device) obviously provides better performances.
I hope this enlightens the issue
Best regards,
Yann
I think there has been some confusion and misunderstanding in this thread... On one hand, the problem duvi had was to send classified results to an external application so it can react accordingly. This is the same use-case as Dieter when he controlled his robotic arm using the OpenViBE speller. On the other hand, Laurent outlined some critical considerations when it comes to the external application doing the flashing sequence and sending tagging information to OpenViBE. In such case, parallel port (or whatever direction connection to the device) obviously provides better performances.
I hope this enlightens the issue
Best regards,
Yann
my blog
my tweets
my linkedinRe: Stimulations to VRPN Server synchronization
I want to elaborate on this a bit further, because I still do not fully understand it. So, the above problem is that the vrpn connection is not a good way to export the fast sequence stimulations of the P300 to an external program. This problem occurs when you want to use openvibe for recording and processing but want to present the stimulations into an external program/gui? This is off course a very interesting application, but the thing I still do not understand is the way duvi solved his problem, which I'm still curious about (something I maybe could use in the future too).yrenard wrote: On the other hand, Laurent outlined some critical considerations when it comes to the external application doing the flashing sequence and sending tagging information to OpenViBE. In such case, parallel port (or whatever direction connection to the device) obviously provides better performances.
Best regards,
Dieter Devlaminck
Re: Stimulations to VRPN Server synchronization
Dear Dieter,
the problem with p300 detection is that the signal epoching must be performed as precisely as possible regarding the moment the stimulus is perceived by the subject. When you use an external application to generate the stimulus (be it visual or anything else), you have to inform the OpenViBE platform that this event occurred. This information can be sent in several ways, such as e.g. through VRPN. The best OpenViBE can do in order to compute the actual date of the stimulus is to consider the time at which it received the event from VRPN. And since this is network communication, since VRPN may buffer data before sending them, since the OpenViBE scheduler choses when to activate a box, there are quite many places where the precision of the timing can be hurt. So for these reasons, there may be variations between the flash actually appearing on the screen and the date produced to epoch the signal accordingly. And this results in bad performance in the detection pipeline.
As you see here, I use "may" a lot. I am not certain how much this can be worked around because I never tried it myself. Fact is that people trying this kind of setup report some bad performances.
By the way, when it comes to motor imagery or more generally processing one-second moving window looking for power variations in frequency bands, this is not an issue. This is only an issue if you look at the signal shape over time.
Tell me if it enlightens things.
Yann
the problem with p300 detection is that the signal epoching must be performed as precisely as possible regarding the moment the stimulus is perceived by the subject. When you use an external application to generate the stimulus (be it visual or anything else), you have to inform the OpenViBE platform that this event occurred. This information can be sent in several ways, such as e.g. through VRPN. The best OpenViBE can do in order to compute the actual date of the stimulus is to consider the time at which it received the event from VRPN. And since this is network communication, since VRPN may buffer data before sending them, since the OpenViBE scheduler choses when to activate a box, there are quite many places where the precision of the timing can be hurt. So for these reasons, there may be variations between the flash actually appearing on the screen and the date produced to epoch the signal accordingly. And this results in bad performance in the detection pipeline.
As you see here, I use "may" a lot. I am not certain how much this can be worked around because I never tried it myself. Fact is that people trying this kind of setup report some bad performances.
By the way, when it comes to motor imagery or more generally processing one-second moving window looking for power variations in frequency bands, this is not an issue. This is only an issue if you look at the signal shape over time.
Tell me if it enlightens things.
Yann
Re: Stimulations to VRPN Server synchronization
I now understand the problem with the vrpn, I still do not understand the workaround duvi found.
If both processes run on the same computer and access the same clock should it not be possible to synchronize them? Also if you work the other way around: sending the sequence stimuli to the client application where it constantly checks a buffer (for example through shared memory) and then the client code should use those stimuli to show something in its own gui.
Indeed, for motor-imagery I do no really worry because in an asynchronous setup you do not even need the stimuli in contrast to the p300 paradigm.
Thanks for the explanation,
Dieter
If both processes run on the same computer and access the same clock should it not be possible to synchronize them? Also if you work the other way around: sending the sequence stimuli to the client application where it constantly checks a buffer (for example through shared memory) and then the client code should use those stimuli to show something in its own gui.
Indeed, for motor-imagery I do no really worry because in an asynchronous setup you do not even need the stimuli in contrast to the p300 paradigm.
Thanks for the explanation,
Dieter
Re: Stimulations to VRPN Server synchronization
Dear Dieter,
I let duvi explain his workaround
Yann
I let duvi explain his workaround
Yann
Re: Stimulations to VRPN Server synchronization
Dear all,
I am sorry but I didn't see the replies before..
Actually, we are controlling a device in "real time". The problem with VRPN (in the version 9.0 at least) is that when a modification appears at the input of the VRPN server, it sends the new data to the client. The problem with the P300 pipeline is the non synchronous computation time. When the row pipeline is finished, the classification is produced and the VRPN modifies the current state of the VRPN bouton ... without waiting for the column modification. So, by switching a fixed number of buttons at each time, the client knows when the information is synchronized -> when two buttons have changed in their values.
Hope it helps ... and sorry for the delay.
Best regards,
Duvi
I am sorry but I didn't see the replies before..
Actually, we are controlling a device in "real time". The problem with VRPN (in the version 9.0 at least) is that when a modification appears at the input of the VRPN server, it sends the new data to the client. The problem with the P300 pipeline is the non synchronous computation time. When the row pipeline is finished, the classification is produced and the VRPN modifies the current state of the VRPN bouton ... without waiting for the column modification. So, by switching a fixed number of buttons at each time, the client knows when the information is synchronized -> when two buttons have changed in their values.
Hope it helps ... and sorry for the delay.
Best regards,
Duvi