cboulay
commented
5 years ago From @chkothe on May 16, 2016 21:58
Hi David, cool stuff! So if you have the premium SDK you can use the app to get raw EEG?
Re timestamps, I would definitely not use the device clock and push that into LSL as an LSL timestamps (you'd have to keep that clock synced carefully, which is pretty hard to do right). Without looking at the code, can you detect when you got a chunk from the driver? Because then you could assume that the last sample in that chunk was recorded "now" (and prev samples successively older based on sampling rate as usual), and you could just call push_chunk without any time-stamp arguments at all.
Christian On May 16, 2016 2:51 PM, "David Medine" notifications@github.com wrote:
I just pushed a new branch called 'emotiv_app'. This is based on some work that cboulay had sent me earlier. Everything works but there are a couple of details to address. Most of these are just cosmetic and I will get around to them before doing a PR on this. There are 2 main concerns, however.
The first is that emotiv seems to be increasingly disinclined to play nice with the research community. Among other things, this means that in order to harvest raw EEG data from their headsets, you need to purchase the 'Premium' edition of their SDK. Basically we can redistribute the binary that holds the functions that read the EEG from the headset.
The other issue is that it seems to be impossible to grab one from of data off the headset at a time. Frames buffer up and every so often, you get a bunch all in a chunk. Worse yet is that the number of frames per buffer differs from frame to frame. The function that pulls data off the headset doesn't appear to be blocking, so there is no straightforward way to clock off the device.
One datum in each frame is the emotiv timestamp. What I've done is to find an initial offset (with local_clock()) and then when I get a bunch of frames, I simply add their timestamps to this and push the frames through an lsl outlet frame by frame with the offset+timestamp as the timestamp data. This is all fine and well, but there is certainly going to be some drift between the emotiv clock and the CPU clock. One thing to do would be simply to update the offset value every so often. If anyone has any suggestions as to the 'right' way to do this, please chime in.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/sccn/labstreaminglayer/issues/118
which says: IEE_EmoEngineEventCreate entry point, C:........\Emotiv\Emotiv.exe dll not found!
(Meanwhile, i don't start Openvibe or anything)
From @dmedine on May 16, 2016 21:51
I just pushed a new branch called 'emotiv_app'. This is based on some work that cboulay had sent me earlier. Everything works but there are a couple of details to address. Most of these are just cosmetic and I will get around to them before doing a PR on this. There are 2 main concerns, however.
The first is that emotiv seems to be increasingly disinclined to play nice with the research community. Among other things, this means that in order to harvest raw EEG data from their headsets, you need to purchase the 'Premium' edition of their SDK. Basically we can redistribute the binary that holds the functions that read the EEG from the headset.
The other issue is that it seems to be impossible to grab one from of data off the headset at a time. Frames buffer up and every so often, you get a bunch all in a chunk. Worse yet is that the number of frames per buffer differs from chunk to chunk. The function that pulls data off the headset doesn't appear to be blocking, so there is no straightforward way to clock off the device. I also tried writing a callback style function to block until the next frame of data was ready. This did not appear to work very well. I think that the engine in the headset is not equiped to work this way.
One datum in each frame is the emotiv timestamp. What I've done is to find an initial offset (with local_clock()) and then when I get a bunch of frames, I simply add their timestamps to this and push the frames through an lsl outlet frame by frame with the offset+timestamp as the timestamp data. This is all fine and well, but there is certainly going to be some drift between the emotiv clock and the CPU clock. One thing to do would be simply to update the offset value every so often. If anyone has any suggestions as to the 'right' way to do this, please chime in.
_Copied from original issue: sccn/lslarchived#118