Does this still work with newer models?

[gaby64]

I edited the library to print out some debug information:

There are 2 emokit HID devices Device Found type: 21a1 0001 path: /dev/hidraw3 serial_number: SN201302043788GM Manufacturer: Emotiv Systems Inc. Product: EPOC BCI

Device Found type: 21a1 0001 path: /dev/hidraw4 serial_number: SN201302043788GM Manufacturer: Emotiv Systems Inc. Product: EPOC BCI

Shouldn't one those be Brain Waves?

Im not getting any data from them

[soltanmm]

I'm just a (relatively satisfied) user here, so don't take everything I say to heart.

I received my headset two weeks ago and it does exactly what it says it does.

Following the example in the example 'contact' program, you should use the second one. Also, iirc, the double listing is already a known bug.

As for you not getting any data... I'unno, more details? Like, for all I know, you could be having the same permissions problem I had with hidraw, or it could be a programming error, or something else.

[gaby64]

Could you list your step by step process to getting it to work?

It cant be a programming error, im using the source from this git and printing out debug info to check if there is any data. I tried changing the device index and both block on hid_read forever(no data).

Thank You

[olorin]

What are you using to get the data? emokitd or something else? There are two lights on the USB dongle - what state are they in before you run emokitd (or whatever) and after you run it?

[soltanmm]

Alright, to clarify: the lights that fractalcat are referring to... One of them will blink when idle per second, and the other is constant. When actively reading data, the blinky light blinks really fast and is a little redder in color.

My process was making sure that I actually had read permissions. After stepping through the code with a debugger, I came to an open() statement and found that it was returning a permissions error. You don't actually need to do this particular step, though, because this can be checked just as easily in the file system.

When you have the USB dongle unplugged, check your /dev/ directory. Then plug it in. You should see two more /dev/hidraw* entries (you reported them as /dev/hidraw3 and 4). Try to read from them (ex. by running 'cat' on them). If you get a permission denied error, then you had the problem I had, and you need to either A: run emokit libs always as root, or B: write up a simple udev file and put it in /etc/udev/rules.d (I named mine /etc/udev/rules.d/99-hidraw-permissions.rules):

KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="plugdev"

Then add yourself to the plugdev group (note that plugdev can be any group you want - you may not have a plugdev group on your machine and may want to use dialout instead, or whatever) and you're good to do. Well, almost good to go. You may need to reboot, or use the command-line one-liner udevadm control --reload-rules.

On the other hand, if you already CAN successfully 'cat' on /dev/hidraw* (and please note that 'successfully' cat-ing will not print anything - it'll just be empty, but it WON'T be an error), then we can take it from there.

Oh, and also try running contact with sudo. If it works while the device is connected, you can rest assured that the library works (emokitd is silent on the matter of it working or not, so don't use it as a litmus test).

[gaby64]

thank you, it now works after adding the udev rule

im disappointed with the poll rate, is everyone getting ~128 frames/s?

do you think this limitation is built into the headset or usb? does the usb do the encryption or the headset?

[nh2]

do you think this limitation is built into the headset or usb?

That's the frequency of the headset.

(I've heard that internally it uses a higher sampling rate but preprocesses it to 128 Hz before sending it).

does the usb do the encryption or the headset?

If I remember correctly, the USB does the encryption and the wireless transport is proprietary but probably unencrypted.

[soltanmm]

Why would you want to go over 128 Hz? IIRC, anything above the Nyquist frequency for 128 Hz sampling is in Gamma wave territory and not well enough characterized for practical applications... and if you're researching Gamma waves chances are you don't want to be using this headset.

That said, if you must have the ability to return from the query so that you can do non-blocking work, you either want to chuck the sampling into another thread or add a function to the emokit C API that permits polling (I have added such a function in my fork of this repo; may come up with a pull request).

To put it succinctly: what's making you disappointed? We might be able to help!

[gaby64]

the brain does not operate on waves, that is an abstraction we have created. The more time resolution i can get the better i can figure out time dependent patterns of small fluctuations across brain regions. The brain is analog, not digital. Our conscious experience may appear to be continuous and in the now but that's all an illusion.

im no neuro-scientist so i may be wrong, but im pretty sure they have not explored all options and thought outside the box. profitability usually restricts areas of research.

I have put the hid device in nonblock mode when testing the speed.

[soltanmm]

Digital computers operate on samples. The brain being 'analog' becomes a moot point once you move the data into a computer - you'll be hitting that ceiling no matter what you do. The rest about waves and abstractions... I'm not here to argue; needless to say, I disagree with your sentiment across several disciplines.

What are you trying to do that has this making you disappointed? Everything with EEG is technically 'time dependent patterns of small fluctuations across brain regions'...

[gaby64]

understanding that the brain is analog is very important, our thoughts are not just "neurons firing", its a network of causality that spreads, having high time resolution view of this spreading will allow me to more accurately distinguish different patterns. A thought will be expressed in the brain as neural activity during an unknown time span, not an instantaneous event or lasting event. What i hope to bring forward is a new way of more accurately interpreting eeg data. But i need the absolute highest time resolution i can get. You must also not forget that there is more going on then just a simple thought that you may be conscious of, creating complimentary patterns only observable at high time resolution.

[olorin]

Sorry, but you're not making much sense. Let me know if there are any emokit-related technical issues; I'm closing this one.

[nh2]

That said, if you must have the ability to return from the query so that you can do non-blocking work, you either want to chuck the sampling into another thread or add a function to the emokit C API that permits polling (I have added such a function in my fork of this repo; may come up with a pull request).

Can you explain a bit what exactly you mean by polling? Does a read() from the device not mean "polling" for you?

[soltanmm]

No, a blocking read isn't 'polling' in my book, because a 'poll' should be able to succeed with the result, "Got nuthin'."

At least, whenever I've seen the word 'poll' as applied to event processing loops, they've all been non-blocking. I admit that I might be misusing my terminology, but I'm going to go with SDL and Allegro and whatever other libs out there (mostly graphics related) that when something says 'poll' with respect to an input event, it's non-blocking. If I'm wrong, I'll be more than happy to change my mannerisms. :-D