Doesn't regular Epoc models just return integers?

I doubt it.

oh yeah, weren't we supposed to get you an epoc csv?

Yeah we need to know what they should really be.

A dump of both running at the same time would be optimal, if possible.

with no electrodes attached or anything.

bill... in Xavier, theres an extra window for "Sequence number" and it shows this graph, that creates a line that increments up... and then drops off sharply... basically like the "counter"

i'm curious.... you said there were 2 counters... so i wonder what MiniFire's looks like, when its in Epoc mode.... whether theres maybe 2 or more lines?

pretty sure its a graph for the counter though. thought you might find that interesting.

i dont think i'll be able to do the CSV for you, unless i'm missing something... its asking me for a license key, or to be signed in.

i probably could sign in using my emotv id, but i'm not sure that'd be such a hot idea.

The render is not right, the data is structured differently in Epoc .

so did we even come up with something workable with Epoc ?

i was kind of confused with all we had going on.

The data is decrypted but is 16 bit values instead, so the levels are not accurate at all.

I've been playing with the data to see if I can get it to match the pure eeg output.

okay i see now. can you give me a quick sample of the data you are trying to decode.

epocplusdata.txt

There a packet length inserted every packet and some text I added, it kind of looks like two bytes per sensor.

So I've been trying to convert the bytes to floats or doubles using struct pack and unpack.

I was getting some stuff that looked like this:

'4080.00389105'
'4080.99610901'
'4335.0000152'
'4335.003891'
'4335.99609375'

but it didn't hold up entirely.

You cannot save recording with pure.eeg without a subscription. Tomorrow I can put my headset in epoc mode and do some recordings.

MiniFire, also, take a look at the last tab, "Data Packets"
and see if under Epoc if it is displaying multiple lines (for the counter).... or just 1.

The packets is just 1 saw tooth line that goes up at 45 degrees and drops. If packets are lost there will be a deformation in the line.

I look at that graph alot when I am using the headset when I see a weird output in the eeg display.

Does this help with the sensor data?

Resolution: 14 bits 1 LSB = 0.51μV ( 16 bit ADC, 2 bits instrumental noise floor discarded), or 16 bits*

and also: 2 resolution: 14 bit or 16 bit per channel (0.51 µV @ 14 bit / 0.31 uV @ 16 bit)

its actually .13uV

if you check their website, on the comparison chart it shows .13uV
and on the specifications, it says .31uV

the web designer for Emotiv keeps getting it wrong, lol

and i know its .13uv because gmac clarified that once.

EPOC high resolution mode is the same full scale reading as 14 bit mode, so the LSB resolution is 4x smaller due to the extra 2 bits. 0.51 to about 0.13 u,V for the LSB., NOT 0.31
The 256Hz mode also applies to all channels at the same time, that’s what is commonly understood by ‘256 samples per second per channel’.

i don't quite understand what he meant by the resolution being 4x smaller... maybe he meant, that it has more floating point precision, due to the extra 2 bits.

There is a hint in there actually, reading it again.

1 LSB http://stackoverflow.com/questions/19161872/meaning-of-lsb-unit-and-unit-lsb

It makes perfect sense, actually.

so if we multiply out values for the old headset we get 2 places of precision.

4x more than that is 8 more places, 10 places total, which is the precision we see in the the pure eeg data.

Minifire, i think bill was looking for Epoc 14-bit CSV, when you get a chance.

bill, did you add the 1,2,3,4,5,6,7 into the epocplusdata.txt ?

yeah, I was counting the pairs of repeating bytes.

@BillErqiHuang
Data is not going to be accurate with you headset yet. Unless you have access to pure eeg and can switch to epoc mode.

Also, that example is to load an existing file.

Now I have to buy pure eeg software which can switch my headset moed to epoc?
Then I will access the data, it is your mean, right?

or you could just wait we'll have this figured out soon, hopefully.

Thank you so much for your response!!
I want to get the data on free way permanently, so if the headset switch to epoc mode and I get the data through your code directly, I will buy pure eeg right now.

I'm not sure how it works @minifiredragon is the only person I've heard of actually being able to switch modes.

@minifiredragon
Hello, dragon!
Can you tell me how to switch the headset mode from epoc to epoc?
I didn't find the dialog to modify it

You need the pure.eeg software. In it there is a tools section. You will find it in therr.

https://en.wikipedia.org/wiki/Unitary_method we should have been dividing not multiplying.

When dividing these values we get the really long precision.

Also I can say for certain that the value we divide by is not 0.13
When dividing by 0.13 the precision repeats.

The pure eeg data does not behave the same way.

Adding two values both divided by 0.13 gives the same result, kind of interesting how common it is to get whole numbers doing that though.

Alright I think I got it for real.

The answer is stupid simple.

The left byte is the precision.

The right byte is the whole.

You divide the left byte by 3.1

You divide the right byte by 0.031

Add the values together and you get numbers that slowly increment/decrement.

Right along the lines of the pure eeg data and the precision values don't repeat.

Epoc render:

Looking pretty good. I turn on the set, shook it a little and let it sit. Then I wetted half the electrodes and out it down again. reading looks the same wet or not wet

When I 1st turned it on the lines were all in a row. After it was moved this is how it rested and the white square never moved.

Here it is on windows

Yeah gyro's in epoc mode are not done yet, while I was in the shower I thinking about it how to get the correct values from the normal epoc mode.

Since the sensor bits looks so similar I've come to the conclusion that they really stored two bytes in 14 bits with a leading or trailing null padding bit.

Now to reconstruct the bytes and test my theory.

I also have some thoughts on how to make the render look more like theirs.

For the render, it looks like you do not display all the data. And to make it look like theirs, they have a uV scale that can be adjusted to show more of less of the wave form. It starts out at 200 which makes the idle sensor data look almost flat.

The post I did with the the pure.eeg display, that window from render was really slow, nothing compared to the linux speed.

Bill, what I usually do is, i have a function called Set_Baseline, then at the start of capturing data, or
when triggered manually or by intervals... it records a few data packets, averages them together.

Then just subtract that average from every new packet. That's how I arrive with this:

Yeah, resetting the baseline would not be a bad idea every now and then.

Thoughts for later, maybe the bit mask is wrong for the 14 bit epoc mode?

I've set up IDA with a plugin called Hex Rays.

its pretty cool, because it lets you take the functions, and it converts them to a slightly more legible
C code.

I thought I might have something sooner, but I can tell its going to take me a bit more time to come
up with something a little more definitive. I can at least now see functions that they're using and how
many parameters are being given, the setting of variables, and some math functions.

Its going to take a bit more studying though... I was tempted to paste some of the code here and
see if it might be useful to Bill.

However, there is a lot of moving parts involved, and I want to be positive I'm posting relevant
information.... else it might just lead to unnecessary confusion.

Plus I might look into some other plugins that maybe can assist in converting the functions.

Perhaps tomorrow I'll be able to make a more focused effort.

Think I'm definitely on the right track though, and should lend a big hand in definitely saying, this is
how its done.

@warrenarea Yeah that's probably the best plan.

You can post everything if you like, might help narrow down your search.

I know what you mean @warren. It is a messy jump all over shift left move right multiplily by 108.

Hi, Bill! I got a problem in the example_render_encrypted_data.py
When I run this, it will turn out the ValueError: Reached end of data or corrupted data. Whether some settings I haven't done or EPOC didn't support this encrypted_data?
I can execute the render.py successfully.

@BillErqiHuang That is expected, it is done reading the file.

Quote from Bill """
Also I can say for certain that the value we divide by is not 0.13
When dividing by 0.13 the precision repeats.

The pure eeg data does not behave the same way.
"""

bill you said that the padding repeats when dividing by .13
have you tried .03125 ?
Also.. like i said in my other post, its possible that the headset is actually using .31 microvolts
or maybe the headset actually is .13 microvolts, and the program is converting it wrong as well.

either way, it seems there might be some confusion with the people at Emotiv, on what exactly the
microvoltage actually is...

https://github.com/CymatiCorp/CyKITv2