Emotiv Test Bench Manual Woodworkers
I've got some EPOC+'s around if I can help in some way with this, like maybe some testing, but I can only access them on certain days at work as they are being actively used for experiments. For the experiments we're using our legacy/grandfathered copy of the Emotiv Testbench which we get to keep using because we paid Emotiv a few grand a year or two ago. 😞Emotiv is not exactly a research friendly company for a variety of reasons. Open BCI is the obvious next choice-we just put in an order for a few development kits and a couple of headset parts kits, but we don't have the experience with them yet.
The other options depend a lot on your price point. Nothing is a cheap as Emotiv, but Open BCI is the next cheapest of which I am aware. I gave it an initial go:Ok dumb question time-how do I capture the dumped signals? I can run emotiv.py as main and get a dump to the screen from the EPOC+, but I don't know what to do to capture the signals (short of writing a new program in python which I cannot do just now).
Is there a simple way to capture the signal so I can load it in analysis software and check the values to see if they are reasonable?I can confirm that when I start and stop the headset data is acquired and starts and stops. Also the numbers flying by seem not unreasonable given my previous work with Emotiv's gear. But plots would help me confirm that.Thanks! I am unfortunately on Windows and at work stuck with limited permissions from my IT department so any installs are out of the question. I'm just looking for a quick way to capture the output from testing the Emokit fork for to see if it looks reasonable as proper EEG data. I believe the fork is working to pull data from the EPOC+, but want to look at the numbers to be sure.
I was also hoping to do this test without actually having to write a program to capture the data.If I can get to a computer where I can install the trial of Device Monitoring Studio, what will the device look like to it; what is the name? Will it be obvious? I don't usually work at this low of a level with hardware. I have here what appears to be a EPOC+ (at least, it says so on the device - I did not do the original order so I'm not 100% sure what the person who ordered it intended to get).Regarding the issues you noted - I think these are all intrinsic to the code and not specific to the EPOC+, except for the battery issue (which doesn't happen for me - battery level is fine).
There is nothing in the code that actually attempts to get the Z-reading.As far as I can tell in my testing so far - assuming that Emotiv has not actually yet implemented many of the + features of the supposed EPOC+, as others have noted - the only major thing that might be relevant from 's branch is the change in offset of the X/Y values (from 105/106 to 127). I didn't have the same issues with serial numbers and such that apparently did - my so-called EPOC+ was recognized as such just fine from the code in this branch.
This is not really an effective fix for your problems - nor an advertisement for our solution - but if you want to try it as a debugging step, you could try our re-written 'emofox' project that I mentioned a bit in the issue thread.It uses the same basic code as emokit (as of late September / early October, anyway. Looks like there has been some activity since then and I haven't looked yet to see how much has changed), but it is heavily stripped down to a bare-bones implementation. As such it is much less generally useful than emokit (we really wrote it just for ourselves) but it runs much faster on Windows, which was one of our main motivations.(It does do a graphical plot of the incoming EEG signal, which could slow things down if you're working on a not-so-fast system. But you could basically comment out all the graphical code and replace it with a simple text interface in just a few lines of code, if you were so inclined.). Thank you very much for your answers.
Manual Woodworkers Throws
Yes, I have the current master branch installed, although I tried to pull the latest version again just in case and the problem still remains. I have also changed the isresearch option to True in the initial values in emotiv.py and I don't see any difference.These are the versions of the libraries I have installed right now in Python 2.7:emokit 0.0.7 (?? Hope is the latest one)pywinusb 0.4.1future 0.16.0pycrypto 2.6.1gevent 1.1.2greenlet 0.4.10The Epoc + I'm using was acquired around June.I will try emofox just to see any difference.One last thing. Yes, I'm in a slow machine and, although the write param is False, after each time I run example.py a csv is written.
Even if it worked, should I expect the slow performance I commented before?Thanks! I just tried to test the data in emofox.
The program seems to work, but the data that it is acquiring doesn't seem to be reliable. When I use only two sensors (AF3, AF4) and acquire the signal correctly acording to the Control Panel, I'm not able to see any difference with the rest of sensors after plotting the signal (no eye blinks, no difference in values all of them range between 8000 and -8000). I have also tried changing the value of gisresearch to True but still having the same results. Well, glad to hear it sort of worked a little.
At the very least, maybe that helps you narrow down your issues with the main emokit package. Emofox still relies on pygame (for graphics) as well as pywinusb and pycrypto, but it eliminates the other dependencies. So I would be inclined to agree with others that gevent/greenlet might be the most likely culprits for your emokit woes.As for emofox itself. I'm not sure exactly what you're saying the problem is?
(I read your most recent comment, I'm just not quite sure I understand.)Anyway, it is quite possible that it would take some tweaking to get emofox working on other setups. As I say in the emofox notes, it is a very early product and really not designed for general use (at least, not yet). Our focus was first on getting things running fast and reliably in our lab, and that's as far as we've gotten. Although I would expect that if it failed on other people's setups, it would be most likely to fail in the initial setup stage (e.g. Recognizing that a headset was attached). That is the hardest part of the process.If you want help debugging emofox, feel free to attach some sample data or further info and I can try to figure out what the problem is. Although you may find it more productive in the long run to work on debugging the more generally useful emokit instead.
Still, if you want to use emofox, you are more than welcome. And I believe I have it set up on Bitbucket to handle pull requests, so if you make any useful edits to emofox in the debugging process that might be worth passing along to others, please feel free to share! Any news on this issue? I have a very similar problem with encryption not working properly (killing the battery code makes the program work but output pseudo-random data). Hi, I had collected some data by emotiv equipment, as the result, I got the 33 numbers per sample row as output.I have two problems,.the announcement ( it only has 256 bits, which is 32 bytes(the 15th always zero), but I got 33 bytes with the first one is always zero, why?.I thought maybe it's the fault of transfer from binary to decimal, so I ignore the first number(always zero ), and transfer the last 32 numbers(decimal) to binary and then transfer them back to decimal again follow the queue from the Emotiv EEG Protocol Documentation. But it still looks not right.( I am using deep learning to classify the different eeg signal in open and close eye, my code performs great when I use one public EEG database, but performs terrible when I use the data collected by emotiv, this is why I believe the data is still not right.).the announcement said the sampling rate is 128Hz, but I only got 40 Hz. Why?I am a student focus on the classification of EEG data, and these question means a lot to me.
Build A Computer Test Bench
Please help me. You can email me directly to. Thank you very much.