Formatting for Openvibe

[warrenarea]

if I have the following data, how it will transfer?

EmotivState {counter = 34, battery = 70, gyroX = 115, gyroY = -39, sensors = fromList [8769,7945,8113,8658,8455,8767,8857,8351,7744,9585,8141,8019,8177,9101], qualities = fromList [24,24,0,0,8,24,16,0,0,8,16,8,16,24]}

You should use the --format spaced option, then the data will look like this:

$ ./hemokit-dump --format spaced
48 0 646 -1636 14260 5451 6184 15047 13613 6573 15294 9075 5637 9415 8906 4214 16064 4322 0 0 0 0 0 0 0 0 0 0 0 0 0 0
128 0 288 -1082 16339 731 9041 5104 3837 6126 1916 14906 9550 2759 10431 5920 6503 14713 0 0 0 0 0 0 0 0 0 0 0 0 0 0
42 0 -1340 -1270 3461 9534 11386 15808 9507 5725 3030 12763 6679 8898 3755 13544 2893 10611 0 0 0 0 0 0 0 0 0 0 0 0 0 0
...

I am working on a python script to convert the sensor values to a format openvibe can read.

i've looked over your code, and i see that these are 16-bit ints, big endian bytes. but i am
having trouble deciphering the values you have listed here.

i see here the format is:
'counter' 'battery' 'gyroX' 'gyroY' 'sensors'
'counter' 'battery' 'gyroX' 'gyroY' 'quality?'
'counter' 'battery' 'gyroX' 'gyroY' 'sensors'
etc.

Could you please step through how you would convert one of these values back to its original value?
for example:
'counter' 48 = 0000000110000000
? = 34

i've tried studying your code, but i am not very fluent with haskell.

thank you for your time.

[nh2]

Hey, Hemokit can already output its data so that Openvibe can read it: --format sensorbytes. This is a binary format, exactly how Openvibe likes it.

Check out this mini-tutorial I wrote, it describes how you connect the two.

The --format spaced output you are using currently is not a format that Openvibe can read. It is more useful when you want to communicate with other programs, e.g. Matlab.

Let me know whether this solves your question, and don't hesitate to ask more :)

[nh2]

(I also just updated the README to mention the wiki: https://github.com/nh2/hemokit#connecting-with-other-programs)

[warrenarea]

well yes, i realize hemokit can already communicate with openvibe by using --format sensorbytes

i was using the spaced example above for a reference.

https://github.com/CymatiCorp/CyKit
My project is located here, TCP server that can connect to openvibe, however i'm having
issues setting up the format.

do you just send a line of 14 sensors as bytes in a sequence, and should they be delimited?
because an array seems to put 0x00 in between them.

i see now that you have to pad the empty spaces with 0's, though i think i seen from a packet
capture of the oscillator it was padding with 0x20 which is 32 (ie a space key).

[warrenarea]

I think what i'm having trouble understanding is the length of the byte strings you are sending to openvibe. When I connected to hemokit via telnet and piped it to a file, and converted the hex data.
i found the individual packets delimited by 0d 0a (crlf)

20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 23 0d 0a

20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 1f 2e 21 6b 1e be 22 62 24 26 1e 9a 20 90 1f e9 1f 7d 20 37 20 e1 23 66 21 20 20 20 20 20 23 1f 2c 21 64 1e c0 22 60 24 2a 1e 9a 20 8d 1f e5 1f 7b 20 3b 20 df 23 od oa

20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 1f 23 21 5f 1e bc 22 6b 24 26 1e 97 20 93 1f e2 1f 78 20 40 20 da 23 6a 23

they are padded with x20 but the byte strings lengths seem to have varying length some
54 bytes, some 78 bytes, 108 bytes. etc.

the way i understood it, was that each sensor value should be converted to a
2 byte (16-bits) unsigned integer in big-endian format, and then padded to match something
like 32 bytes?

[nh2]

do you just send a line of 14 sensors as bytes in a sequence, and should they be delimited?
because an array seems to put 0x00 in between them.

When sending the data via TCP, e.g. with the --format sensorbytes --serve 127.0.0.1 option, I don't send any delimiters, I just put the data in and flush the socket.

When printing to stdout (--format sensorbytes without --serve), then I print a newline after the 14 sensor values, so one newline after each complete reading.

https://github.com/nh2/hemokit/blob/master/apps/Dump.hs#L131
https://github.com/nh2/hemokit/blob/master/apps/Dump.hs#L171
https://github.com/nh2/hemokit/blob/master/apps/Dump.hs#L196

an array seems to put 0x00 in between them

What do you mean by this?

the way i understood it, was that each sensor value should be converted to a
2 byte (16-bits) unsigned integer in big-endian format, and then padded to match something
like 32 bytes?

No, there is no padding involved, it should just be 14 16-bit-unsigned-big-endian integers after each other.

individual packets delimited by 0d 0a (crlf)

That's odd, shouldn't be a case with the TCP server.

Could you make a recording using sudo hemokit-dump --mode raw > yourfile.bin and send me yourfile.bin so that I can have a look at it?

[warrenarea]

http://blueskynet.org/edu/openvibe/hemokit.txt

TCP Writer output (from sinus generator)
http://blueskynet.org/edu/openvibe/sinusOut1.txt
http://blueskynet.org/edu/openvibe/sinusOut2.txt

[nh2]

Could you make a recording using sudo hemokit-dump --mode raw > yourfile.bin and send me yourfile.bin so that I can have a look at it?

Ah sorry, this will actually give the decrypted data which Hemokit cannot currently read in.

Could you send me the output of sudo cat /dev/hidraw1 > yourfile.encrypted.bin instead (assuming /dev/hidraw1 is your EPOC device file), and also the serial number of your EPOC?

http://blueskynet.org/edu/openvibe/sinusOut1.txt
http://blueskynet.org/edu/openvibe/sinusOut2.txt

These two give me HTTP 404 not found.

[warrenarea]

apologies
http://blueskynet.org/edu/openvibe/sinusOut.txt
http://blueskynet.org/edu/openvibe/sinusOut2.txt
EmotivDeviceInfo {hidapiDeviceInfo = DeviceInfo {path = "\?\hid#vid_21a1&pid
_0001&mi_01#9&33e8a85f&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}", vendorId
= 8609, productId = 1, serialNumber = Just "SN201404226268GM", releaseNumber = 3
, manufacturerString = Just "Emotiv Systems Inc.", productString = Just "0000000
0000", usagePage = 65535, usage = 2, interfaceNumber = 1}}
hemokit-dump.exe: Device open (by path) failed: hid_open returned NULL

[nh2]

Ah, are you on Windows? (Sorry, I have to go to bed for some hours, it's 4am here :))

[warrenarea]

yes, windows.
i alos might add my values are in the signed integer ranges as well.

Packets Received: 1932 Packets Processed: 1904
Y Reading: 3 Quality: 0
F3 Reading: 891 Quality: 0
F4 Reading: 219 Quality: 0
P7 Reading: -318 Quality: 0
FC6 Reading: 56 Quality: 0
F7 Reading: -214 Quality: 0
F8 Reading: 14 Quality: 0
T7 Reading: 364 Quality: 0
P8 Reading: -350 Quality: 0
FC5 Reading: 267 Quality: 0
AF4 Reading: -126 Quality: 0
Unknown Reading: 46 Quality: 0
T8 Reading: 146 Quality: 0
X Reading: 8 Quality: 0
O2 Reading: 1075 Quality: 0
O1 Reading: 614 Quality: 0
AF3 Reading: 779 Quality: 0
Battery: 62

[warrenarea]

this output from the latest version of emokit

[warrenarea]

raw hemokit-dump
http://blueskynet.org/edu/openvibe/yourfile.bin

[warrenarea]

taken just now

[warrenarea]

whats curious is that the values appear in the correct ranges in hemokit.
however.... hemokit doesnt display signal data if the Drift is Disabled.
Also, the signal display starts to increase in delay until it takes over a minute
to update. so the drift correction could possibly be slowing it down further.

[warrenarea]

i believe i've solved some of my issues if not all.
i'm not above thanking the lord on this one. lol

The reason why we see in the outputs i provided an 0D 0A (CRLF)
every 80 bytes, is i believe an (ibm/ms) telnet issue as it truncates
every 80 bytes. The padding I believe can be contributed to the same
issue, what we see as 0x20 is a space, which is telnet padding the
80 byte chunks.

I scripted something to read the connection manually, and the padding
was nowhere to be found.

also. what i was referring to earlier of the 0x00 being delimited in arrays.
this is how Python separates array indexes, and i was trying to drop the
entire array as raw data.

also, i was sending \r\n which is a typical CRLF for windows, where-as openvibe being
primarily programmed from a unix based machines, uses primarily the \n
formatting. I think this created an extra character that offset the data as well.