Open nh2 opened 9 years ago
I also wonder where the variance in the C version comes from. Is the clock in the EEG not accurate or is it my system (USB, OS etc.) that is jittering?
The device itself is probably accurate, see this Emotiv forum post.
If the jitter is from USB and cannot be fixed, then we should probably re-time properly the values before sending them to e.g. Openvibe (space them out so that they appear at proper 128 Hz).
If it's in the OS though, then doing this will not help because the jitter might as well re-appear in the socket communication between Hemokit and OpenVibe (0.7 ms is a LOT though, that is like Ethernet latency, we should be able to do better inside a computer...).
If the jitter is USB, why would hemokit's be greater than that of emokit? They're both using hidapi under the hood.
I'd be curious to see the distribution of the jitter, if the data's still readily available. I agree that instrumenting readEmotivRaw
might shed some light on this; 0.3ms doesn't sound like excessive jitter when the TCP stack is involved as well.
It seems like putting a threadDelay 4000
before HID.read
can significantly reduce the jitter to 5.6 %.
@fractalcat The measurement data I took is here: http://nh2.me/hemokit-timings-and-jitter.ods
(Will re-upload it as I add more data.)
I've taken some rough measurements of how long
emokit_read_data_timeout
andhemokit-dump
's main loop take per iteration.For this I modified:
Results (times in microseconds):
So the distance between time measurements varies quite a bit more in Hemokit.
This wasn't measured properly though on the Hemokit side; for it to be a fair comparison, I should measure how long
readEmotivRaw
takes, not the time of ahemokit-dump
loop.