Emokit Weird Rendering

[mbeccaro]

I see a weird render stuff when I launch render.py script. When I not move my head I'll get something like: Instead when I move my head:

That seems it is movement that make it change and not thoughts.

Also gyro gives me weird data.

I'm posting my what I get about key and ID of my device. [code] Serial: SN201302040228GM Device: hidraw1 (Active) 0x4d 0x00 0x47 0x54 0x38 0x10 0x32 0x42 0x4d 0x00 0x47 0x48 0x38 0x00 0x32 0x50 [/code]

Thanks.

[metasoarous]

Weird. Just got my headset and am seeing similar things with render.py. Basically flatlined unless I josstle the headset around while it's on my head. Have you managed to figure out what's causing this?

[mbeccaro]

Unfortunatly not. Do you?

[wmvanvliet]

I get the same result. This is caused by render.py not being particularly clever about the scale of the signal. Shaking the set will produce noise with a very high amplitude, high enough to use the entire range of the ADC and show up in the plot. A normal EEG signal usually has a much smaller amplitude, not enough to show up in the plot. I recommend adding a control to the code that 'zooms in' on the data.

[olorin]

Another potential factor is sensor contact quality - what kind of quality numbers are you getting when you're doing this?

I haven't used render.py, but when rendering with nerven[0] head movement doesn't cause significant changes in the signal (it causes some, as it should, because surface electrical activity is changing, but nowhere near the magnitude of those in your screenshot).

[0] https://github.com/fractalcat/nerven

[warrenarea]

I had one dev headset (from 2011) that worked fine with render.py i had to get a new headset (purchased 2013) and it seems to be doing this now. the versions appear to be the same, i looked under the hood and one circuit board has the same version. the color differences are supposed to indicate the quality of the signal.

black=0 red=1 orange=2 yellow=3 green=4

and any other signal quality provided will display white. it gets the signal quality from a function called get_level that cycles through the numbers 112 down to 99 and shifts the bits to arrive at the number.

For me, it was producing 9 through 14, I altered some of the quality_bits, and some of the sensors worked, but could not find an ideal match.

I used emotiv control panel to verify all of the sensors had the best signal quality. I did have to uninstall an older version of emotiv control panel because it wasn't showing any activity. I chalked it up to a malfunction, but its got me wondering now if emotiv hasn't changed something. Testbench didn't appear to work either.

quality_bits = [99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112] Cycles through these Right to Left.

def get_level(self, data, bits):                  # data = ASCII from device.
    level = 0                                     # sets level to 0
    for i in range(13, -1, -1):                   # loop backwards from 13 to 0
        level <<= 1                               # shifts level 1 bit Left
        b, o = (bits[i] / 8) + 1, bits[i] % 8     # sets two variables at once.
                                                  # b takes quality_bit and divides by 8 + 1
                                                  # 'o' takes quality_bit and modulus 8
        level |= (ord(data[b]) >> o) & 1          # level OR (ascii of data Shift Right 'o' times) AND 1
    return level

It uses this function as well for the data handling, so if you decide to print results be sure to indicate which is the data and which is the quality. My EEG isn't showing as much activity as it used to, and im not yet willing to account this for brain damage. I am wondering if the sensor_bits for the data, has changed as well.

[olorin]

This project does badly need a cleanup and audit. I will hopefully get time to do so at some point, but I'm not sure when that will be.

[warrenarea]

i noticed that with the newer models of SN keys, the last 2 bytes are the letters GM. SN201302040228GM where the first 8 bytes are definitely the purchase dates. unsure about the next byte, and the byte after which used to start with 8? has changed too.

i went to see if the rijndael code had changed, and loaded emotivcontrolpanel.exe into ida, however being a bit rusty it was difficult to sift through, i did find something that looks typical of a rijndael key, but its hard to say if it is or not. Heres what i found 4D004754381036424D00474838003650 the numbers here do seem to match the post above. anyways not sure if its even any use, and still not certain if the 'GM' is part of the key, or a new protocol.

[ghost]

Update to the latest version.