Deciphering the functions. #256
Comments
|
Object Explorer : DataAcqThread Comments: |
|
I would agree, this is what I found as well while running EPOC+ |
|
Object Explorer : CognitiveDetectionG2_Clamshell Comment: |
|
I think that code is what is used to draw the graphs. It repeats in the loop x number of times equal to i think 500ms as it looks like it prints half a second to the display. |
|
its a little more slow going than i thought, still looking for that function that explains it all. double checking them though. I decided I might take another approach, and went back to looking Figured it might be easier to pin point it there, and then go back to the new one. Though I am noticing some key differences, kind of like some of the functions were renamed, |
|
Signal Quality |
|
Some sort of main thread. Could be useful in seeing what order the functions |
|
Signal Quality for Insight. Not entirely sure how useful this will be. Probably more to this function. |
This function is interesting, because i noticed it Floor's one of the values (brings it to integer) obviously this would be some sort of binary math... this function looked promising because... |
|
Also found the function for when the USB dongle is removed, but that's not entirely helpful here. Emotiv Dongle Plus function, not helpful either, think that's just more HID functions. Data Acquisition, really thought there would be something to that one, and it does have some |
|
v8 in that function could be the counter. |
|
|
sub_1307C40 <--- this function is important |
|
sub_14C76A0 <-- this one too |
|
|
There definitely appears to be some juiciness in this function: sub_149D5A0 would like to see that. |
|
Is there anywhere I can see a few lines of raw output from the pure eeg program (even if they are screenshots)? There are references in some of the other threads to it's output and the values, I was just hoping I could see some as I play with the output of the various read functions from the Control Panel. And I apologize ahead of time if I have missed a post where this has already been addressed!!! |
|
Terrific news bill... it looks like i've discovered the function for Epoc Plus, that handles evaluating data quality. |
|
|
I found this little nugget nested below some "data ACQ thread" in a double precision float. its obviously some math dealing with Epoc Plus microvoltage, because its multiplaying by 0.03125 (i.e .031) which is a little confusing now that i think about it, because they have been saying that the microvoltage |
|
there is even more math i believe that you will find useful... in the "data Acq thread" |
|
what would be really helpful.... is if Minifiredragon could put a breakpoint in there... and look for the values being returned. |
|
Data Acquisition Thread: |
|
again, this is part of the data acquisition thread. i renamed the function "reverse_bits" because that Sub is linked to a function and then after that, you'll notice there is a negotiation between 64-bit Floating doubles. and then a little bit below, a function to "floor" |
|
another nearby function . . . |
|
we can also know, that these functions provided, are not sub functions, or some part of other pieces of code, because each one makes reference to "Epoc" or "Epoc Plus". |
|
_mm_unpckl_pd means to unpack and interleave double. also, i think you've probably noticed by now, theres lines like: I'm pretty sure they are related to profiles, not entirely how that works, but pretty SETP |
|
Also, SignalQualitySW... apparently it stands for "Signal Quality Square Wave" |
|
pretty sure that long function is the one we're primarily after, it makes another which i believe is a double representation of 0.03125 theres a few other functions that reference it, and they seem to do a right shift 31 places, and then I think at this point though, we're going to need someone who actually has the Epoc+ to It might be difficult to read the memory as well in IDA, because we're using a double float, and I had a |
|
Unless it's concatenating the packets? |
|
thought it might be useful to go back to how daeken first started out.
|
|
In the get_level code we'd been working on, i did see a specific byte that, i have been calling the byte_Counter, because it loops 0-28 so that makes some sense now. then I also found the 0-127 counter he was speaking of, but i don't remember seeing it hit 233. its obvious that all the code is correct for the regular Epoc mode, but the better I understand how the I thought by going back to the old version of control panel, that it would be easier... and some parts of I'm still trying to figure out how they get their byte_names, sometimes I get the feeling like i'm staring but i'm also wondering if maybe they aren't using the strings of numbers like we have them set up, something i'm curious about though.... is when I was looking at some of daekens old code, that he was he also said that... some of the sensors have less noise or something, so that it was relatively easy to either way... we're on the right track with our get_level |
|
Found this in a Double 0.5128205128205129 Undoubtedly its the double precision version of the 0.51 microvolts. |
The order of data in each packet is as follows: 1 interpolation, 1 packet counter, 1 battery level, 16 inputs but sometimes 2 unused (last one might be square wave data), 2 gyro, 1 unused, 3 for anti-debugging clock check. |
|
Thanks kanzure, Back to the Epoc+ They actually explain the formatting of all of the data being stored in the files, and are pretty specific. |
|
So I'm looking at the data packets for Epoc+ that minifiredragon provided a while back, I think to test that theory, would be to have him try it again, but this time, wearing the headset. |
|
Bill, check this out... and then I looked for patterns in the data that minifire gave us, from our decrypted version. Counter Interpolate (7 sensors in 2 bytes each) (2 unknown bytes) (7 sensors in 2 bytes each) 32 delimiter then every couple packets, there is extra data, which i think is obviously gyro data and the last now.... if you hilight all of the data pieces that have 125 in them, you can see a pattern. 125 125 125 128 125 125 125 115 125 125 126 134 127 149 they are all centralized around that range group... and i think when we first began, we were looking for -8900 +8900 values.... and trying to make because its actually being added/subtracted from 4200 i also found code supporting this theory.... by searching for 4200 i found some code, that also adds so i think the first number (before 125), is actually what is used to get the floating point number. and judging by the gyro data, i should find that it is also being added to 2000 |
|
it also coincides that every couple packets that there is gyro data, because there is an option to increase the rate at which the gyro data is provided, to preserve battery life. |
|
|
sub_10fc680 the function above.
|
|
i think the hardware is basically just doing the baseline math... which coincides with the sensor_quality |
|
i'm not sure if that function i gave is the heart of the data handling for epoc+ |
|
Just received the Insight and the Epoc+ and am currently charging them. I inspected the quality of the headsets, and found a few things to note. The Insight polymer, as expected, feels like a stiff kind of rubber. I think it may have also came with The plastic, does seem a bit durable, think it might be the pureness of the polycarbonate that has been The Insight is made in China + Vietnam I got a universal USB dongle for the Insight, but it appears it may have been unnecessary, I inspected the Epoc+ and I thought again I seen hairline fractures in the arms, but from what I can The Epoc+ is made in the phillipines, the same as the original Epoc, and the USB dongles. Included with the Insight was a large EmotivInsight t-shirt, and a button that said i<3emotiv. lol Insight out of box, requires 2 hours charging. Insight also comes with an alan wrench to remove reference sensors. |
|
Sorry to have seemed to disappear. Got caught up in reading a book for these headsets called Analyzing Neural Time Series Data. Something that will be needed to process the raw data that is saved from these files. That and I had upgraded my web server and just realized a few of my email addresses weren't collecting email. When I fixed it man did I get alot of emokit messages. :) |
|
yeah I got every charged up and ready to go. The Insight has an odd charging cable, its like a audio jack that plugs into USB... When you plugin the Insight cable (to charge), Pure.EEG detects a headset device, and the USB Also, with the universal dongles, bill has it already setup to detect the product_name 'EEG Signals' From the date provided, these were created in March 2016 My insight model # is: (where i X-ed out my unique identifier) |
|
So I attached the Epoc+ physically to the USB of the PC, (which is required to establish 2-way The interface it makes is to: |
|
I believe I have decoded the settings for the mode change for Epoc+ First, it appears that the Epoc+ will only change settings if the USB data cable is plugged in, If it is just plugged in and turned off, no settings will be changed. The USB dongles are detected as a 'Composite Device' The dongles display 2 device interfaces, and the headset only 1 However the headset says it has 2 endpoints, where the dongle only has 1 I will have to read up a bit more on the USB protocol and pywinusb to go further. Here is the data formatting for changing modes: Below each 5 bytes, i display the affected character in binary, I already have created a script to try to push these changes into the Epoc+ |
|
To get the data values, I found this neat program called "USBlyzer" that lets you packet sniff Now.... I just have to get pywinusb to communicate it to the right interface... |
|
So I tried a few different things for the Epoc+ I found the only useful data to be model 6 from this listing: Here is a sample: So basically, the same data that minifiredragon collected with his. and then the second counter is for the MEMS. I tried wearing 1 sensor on a couple different contacts, verified a positive signal, and Checked to see if anything special happens at 255 counter but it just loops back to 0. While wearing the headset with just a couple contacts, I did notice that it seemed like it Also a little displeased with the Epoc+ sensor contacts, one of the blank contacts kept falling off. Upon further consideration, I don't think my idea about values being subtracted from 4200 was so no new news, but we're on track. |
|
Well, i've made some interesting discoveries for the Epoc+. I managed to setup my CyKit version to stream the data values, I figured it would be easier First, I displayed the 127 in a line graph, and they were all flat-lined. Then I just plotted a line graph of the data value after 127, and it looked pretty close to how So then I went to see if I could figure out which sensor was which... and by tapping on them, Then I went back to displaying all of the 127's again.... and I noticed that with 1 sensor attached, Once I discovered that, I was quickly able to discern which sensor was which, by attaching only one The order is: Which, is the same order of sensors that we already have in Emotiv for the Epoc, so nothing I first mapped it by tapping the sensors So now we know that... the following 127 for each data value, corresponds to that particular sensor. If the 2nd byte is 16, then thats for the data... if the 2nd byte is 32, thats for the MEMS, I would attach some screenshots of the line graph, but I was streaming too many packet duplicates |
|
note, that the 127's only changed when that sensor was attached to the head, which would lend to the impedance idea. |
|
This is just from the data line after the 127. What do you think Bill? |
|
|
|
It appears the Insight #268 we knew the key already, but now we know that solving one will likely solve for the other as well. I didn't have a lot of time to go through the values... but I can tell you, that the order of the values half the sensors seemed like they were giving good results, and half the sensors seemed like they Also, I noted that in Epoc-Mode, Xavier does not report the battery correctly... which is what minifire |
|
Bill, perhaps you will find this interesting (or you've already seen it) has some examples in Python that could prove useful... at very least, shows some of |
|
I noticed in my graphics of the EPOC+ signals, that it wasn't quite measuring the data peaks, likely why some peaks or lows seem exaggerated in Xavier and not in my version. Also... in my version that uses gevent, I noticed that it was triggering the init twice, The odd thing is, I was getting a faster/consistent speed with the Epoc+ which sends data faster I think I remember you said your version doesn't even use greenlets anymore, so I should |
|
what might interest some of you.... https://www.emotiv.com/emotivpro/ it appears emotiv has produced a new program, this one is specifically for recording. plus... they're charging you even more per month.... but this time... you have and if i'm reading this correctly.... it looks like they've done away with the $49/month its a shame, all of the price gouging will have the opposite effect of making this device |
|
https://discordapp.com/invite/gTYNWc7 You can either download the discord chat messenger, Basically we have the input and the output.... and just need to sort out how I also compiled a list of floating point numbers that correspond to each Decimal value (ie.4200) The floating point numbers actually repeat and are not unique at all.... i think if someone with also, it seems like if you multiply or add some of them together, they match up, but with a slight would appreciate it if you could take a look... |
So it occurs to me that trying to locate the get_level and decryption functions, based on where
the rjindael code is... is pretty much a lost cause, because the rjindael is just mixed in with a bunch
of other encryption functions, and they could be doing all sorts of other processes in between
actually utilizing the data acquired.
So I think I'm getting a little closer, by first looking at "Imports" or Symbols, which are basically
the function names.
What I want to focus on at this point, is "sure thing" code and recognizable code segments,
because there is a ton of code, and we don't want to waste our time on false positives and
confusing ourselves.
I think I'll break the code up into sections, to make it easier to edit later.
If you want to comment on an item, reference its function name. (for clarity)
The text was updated successfully, but these errors were encountered: