Search found 13 matches
- Mon Nov 07, 2011 5:03 pm
- Forum: Discussion about OpenViBE
- Topic: Arduino serial port
- Replies: 5
- Views: 16074
Re: Arduino serial port
Hello, I worked with an arduino board for its digital outputs, maybe I can help you. I am not sure to understand what you want to do : do you want to acquire data from the arduino board in an openvibe-driver ? If yes, did you already program the arduino board so that it acquires data and send them t...
- Fri Sep 02, 2011 9:51 am
- Forum: Discussion about OpenViBE
- Topic: realtime and delay
- Replies: 16
- Views: 19885
Re: realtime and delay
Hello Jozef,
I think it will not be a problem for the measure, as I already deactivate the drift correction (to treat all data as fast as possible when they are received) and I use just one machine.
Regards,
Amélie
I think it will not be a problem for the measure, as I already deactivate the drift correction (to treat all data as fast as possible when they are received) and I use just one machine.
Regards,
Amélie
- Thu Sep 01, 2011 1:48 pm
- Forum: Discussion about OpenViBE
- Topic: realtime and delay
- Replies: 16
- Views: 19885
Re: realtime and delay
It is an important aspect of my delay problem, but as I am using simple scenario with few boxes, the delay seems to be introduced mainly by the "acquisition" part (the order of magnitude is 2 to 12 ms for scenario/effector activation, 30 to 60 ms for acquisition server->client). I would like to test...
- Mon Aug 29, 2011 9:46 am
- Forum: Discussion about OpenViBE
- Topic: realtime and delay
- Replies: 16
- Views: 19885
Re: realtime and delay
Hello, thank you both for this instructive discussion ! I will try to reduce the delay at different levels, and see if it is enough for my use, even with acquisition server's buffering. Drift correction is Ok, I noticed immediately that it makes delay vary much more :) I can certainly spare time in ...
- Mon Aug 08, 2011 6:24 am
- Forum: Discussion about OpenViBE
- Topic: realtime and delay
- Replies: 16
- Views: 19885
Re: realtime and delay
Hello, I tried with lower block-size, but unfortunately one of my acquisition devices doesn't allow a real-time processing under 32 samples per block. I noticed that the delay is lower and less variable when deactivating all network connections, anti-virus etc. If you don't need to run the acquisiti...
- Wed Aug 03, 2011 8:16 am
- Forum: Discussion about OpenViBE
- Topic: realtime and delay
- Replies: 16
- Views: 19885
realtime and delay
Hello all, I want to measure the treatment time of a BCI loop using OpenViBE and different acquisition systems and drivers, to evaluate the delay between the user's decision and the result (display or effector activation). If necessary, I want to identify which steps take a long or variable time. To...
- Wed Jul 06, 2011 10:51 am
- Forum: Driver development
- Topic: type of sampling frequency
- Replies: 1
- Views: 9506
type of sampling frequency
Hello all, a new question about a choice in Openvibe acquisition server : why is the sampling frequency an integer ? Why not a float32 for example ? Some acquisition devices can propose non-integer sampling frequencies, so a drift is introduced (but the drift correction manages this well). Best rega...
- Fri May 27, 2011 9:32 am
- Forum: Driver development
- Topic: question about signal data type
- Replies: 4
- Views: 12283
Re: question about signal data type
I found it was a strange choice, now I understand.
Thank You Yann !
Thank You Yann !
- Fri May 27, 2011 7:04 am
- Forum: Driver development
- Topic: question about signal data type
- Replies: 4
- Views: 12283
Re: question about signal data type
Hello Jozef
I agree with you, it's great that the designer allows double precision. But my acquisition device also provides double precision data, and this precision is lost in the driver, which requires simple precision data. This is what I do not understand.
Best regards,
Amélie
I agree with you, it's great that the designer allows double precision. But my acquisition device also provides double precision data, and this precision is lost in the driver, which requires simple precision data. This is what I do not understand.
Best regards,
Amélie
- Thu May 26, 2011 8:08 am
- Forum: Driver development
- Topic: question about signal data type
- Replies: 4
- Views: 12283
question about signal data type
Hello, I am developping a driver and I just encountered something curious : in the Designer, the type of signal samples is float64, so I though no precision would be lost if the driver acquires double precision data. But in the driver, the buffer that has to be filled with these samples and sent to ...
- Thu Dec 02, 2010 8:21 am
- Forum: Box and application development
- Topic: signal informations
- Replies: 4
- Views: 5151
Re: signal informations
It is the format of the files generated by the Biomea acquisition system that we use.
Indeed, the only software I know to read this format is provided by Cambridge Electronic Design (Spike2). But I don't know much more about it
Amélie
Indeed, the only software I know to read this format is provided by Cambridge Electronic Design (Spike2). But I don't know much more about it
Amélie
- Wed Dec 01, 2010 11:21 am
- Forum: Box and application development
- Topic: signal informations
- Replies: 4
- Views: 5151
Re: signal informations
Hi Laurent,
it was simple and my box works now perfectly.
I did not think these informations would be available at initialization (I wondered when the signal-stream header was receive exactly).
Thank you very much !
Amélie
it was simple and my box works now perfectly.
I did not think these informations would be available at initialization (I wondered when the signal-stream header was receive exactly).
Thank you very much !
Amélie
- Fri Nov 26, 2010 3:29 pm
- Forum: Box and application development
- Topic: signal informations
- Replies: 4
- Views: 5151
signal informations
Hello all, I am writing a box whose task is to write a signal from the acquisition client (eventually with some known modifications) and other information channels (text marks) in an smr file. Is it possible to get informations on the signal (channels number, sampling rate ...) when initializing the...