hemokit data has higher time stdev than emokit

[nh2]

I've taken some rough measurements of how long emokit_read_data_timeout and hemokit-dump's main loop take per iteration.

For this I modified:

int emokit_read_data_timeout(struct emokit_device* s, unsigned timeout)
{
    static uint64_t t_before = 0;
    struct timeval tv;
    gettimeofday(&tv, NULL);
    uint64_t t = ((uint64_t) tv.tv_sec)*1000000 + (uint64_t) tv.tv_usec;
    fprintf(stderr, "%lu\n", t - t_before);
    t_before = t;
    return hid_read_timeout(s->_dev, s->raw_frame, 32, timeout);
}

Results (times in microseconds):

	emokit (gettimeofday)	hemokit (getCurrentTime)
mean	7818.57	7662.45
std	410.32	725.25
std/mean	~5.2 %	9.5 %

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 a hemokit-dump loop.

[nh2]

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?

[nh2]

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...).

[olorin]

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.

[nh2]

It seems like putting a threadDelay 4000 before HID.read can significantly reduce the jitter to 5.6 %.

[nh2]

@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.)