Ok, as promised, I will post a few words about the acquisition server modifications we did for 0.6.0...
To give you a more detailed view of what lead us to those modifications, let's jump back in time around January, when
Dieter posted his
nice video about controlling a robotic arm with OpenViBE. Back then, he bought a new TMSi Refa32 device which did not work as expected with the Nexus32 drivers he used for his first device. At the same time,
Baptiste was working on a TMSi Refa32 dedicated driver and we hoped that would solve his problems. Unfortunately, it did not ; it seemed that the P300 peeks were received too late, suggesting some samples had been lost in the pipeline. We already had such issue with the Nexus32 driver which sometimes did not send enough samples, and sometimes sent too many samples. We then had to monitor the number of samples over time to be sure that the average number of received samples over time did not move too far of the actual sampling rate.
Based on those observations, we decided to monitor what was received from
all the acquisition drivers and compare it to the actual promised sampling rate... And we observed some problems on almost all the drivers. The gravity (e.g. number of lost samples) and the conditions in which those problem occurred was variable from a driver to another. But still, this had to be solved before the release. We identified three reasons why the number of samples did not match the promised sampling rate :
1. the driver flushes a big number of buffered samples at start time
2. GUI actions (e.g. move the acquisition server window) causes the driver to miss some samples
3. A small jitter is occurring over time because the hardware clock of the device is not perfectly synced with the hardware clock of the computer (e.g. the device believes it sends samples at 512Hz but the computer receives it at 512.1Hz. After 10 seconds, there is 1 more sample received and after 2 minutes, it is 12 more samples received, etc)
Case number 1 is not really an issue. Indeed, the designer usually connects to the acquisition server
after the buffer is flushed. Anyway, the driver should take care of this, flushing whatever buffer the used API has before starting to send those samples to the acquisition server.
Case number 2 is potentially a serious issue. The acquisition server being single threaded and the loop function being called only on idle, as soon as you click on the title bar of the acquisition server, there is no more updates from the driver. This can result in potential sample loss. This is not a typical use of the acquisition server, we usually don't manipulate its GUI while acquiring signal. But still, if someone moved the window for a reason, the whole data arriving in the designer would be misdated resulting in severe syncing issues. To correct this, we moved all the non-GUI related things in a separate standalone thread. Good to notice that such architecture was mentionned in the g.Tec API documentation.
Case number 3 can be an issue for long runs, and there is no ideal solution to solve it on the driver side. Inserting / removing some samples to keep the synchronization as it's been done in the Nexus32 driver should be acceptable as it only happens occasionally.
For the future of driver developments, it is important that each driver developer keeps in mind to send a number of samples as close as possible of the promised sampling rate (that means flush whatever buffer at
start time, does not lose samples from the device etc...). We included a few functions in the
driver context to monitor the jittering. In order to solve case number 3, we propose a function to correct the jittering (again, this jitter correction should be as small as possible, only related to hardware clocks not perfectly synced) and a function to get a hint from the acquisition server as the number of samples that should be corrected... Additionally, if a driver does not send the correct number of samples regarding the promised sampling rate, a console message will be displayed to request a bug report.
As a conclusion, the drivers currently included in OpenViBE should now send the correct number of samples over time. We hope that the proposed functions to { monitor / correct / get hint for correcting } the jitter will help in better device integration.
Do not hesitate to contact us on any issue you would find with those updates.
The driver development tutorial will be updated soon...
Best regards,
Yann
Login
Register
FAQ
Search
my blog
my tweets
my linkedin