Bug: 16 Channel not always working. Data values are completely different from Processing GUI

[PhEigl]

Hey guys!

I would like to conduct some SSVEP experiments using this module. I can hook everything up to my machine and the simulated data works the way it should. As soon as I switch to the real data there seems to be something wrong. I do an FFT to see the spectrum of the data but the peek at 50 Hz for the AC noise is missing entirely (which is there for simulated data). Also the values from the module are completely different to the logged data I get from the Processing GUI. The values from the module range from -100 to 100 µV while in the Processing GUI there are values in the range of several mV. I run impedance tests to see if there is a problem but all channels are "good". Am I missing something? Would be nice if you could point me to the right direction.

I'm using: OSX: 10.12.1 node: v6.9.1 npm: v4.0.3

[andrewjaykeller]

@PhEigl ok I reopened the issue for Impedance #28, I think there is still a bug with it, would love some help there. I can look back into it too, I've gained some more skill since last time I tried to patch it.

The values from the module range from -100 to 100 µV while in the Processing GUI there are values in the range of several mV.

This module outputs volts and the processing GUI outputs micro volts. Is this what you are referring to?

I do an FFT to see the spectrum of the data but the peek at 50 Hz for the AC noise is missing entirely (which is there for simulated data).

This makes sense, as that 50hz wave is injected in the simulator and be toggled off.

[PhEigl]

I convert the values to micro volts to have the same unit as the processing GUI. Yet in the the logged files of the GUI there are values around 27,000 micro volts or even higher while with this module I only have around 100 microvolts with the same setup and no interruption in between (except of course turning on/off processing and switching to my app). This wouldn't do any harm if the spectrum would be alright. The missing 50 Hz in my real data is somewhat suspicious as the AC noise should still be here without a notch filter present. I mean it is there in the processing GUI and it is by far the dominant frequency so I was surprised not finding it.

[andrewjaykeller]

@PhEigl this is very strange. I would expect to see the 50Hz line noise in the FFT you did on this data. Can you talk more about your system? 8 chan vs 16 chan?

I ask because maybe this is related to #89

[PhEigl]

I have a daisy module attached but I'm only using 7N and 8N of the original channels with SRB2 and BIAS. I use the autoFindOpenBCIBoard() function to connect the board. I'll do another test run later and provide more input. Thank you for your help

[andrewjaykeller]

I just tried duplicating with just an 8 channel and am not seeing this issue. From OpenBCI Output:

%OpenBCI Raw EEG Data
%
%Sample Rate = 250.0 Hz
%First Column = SampleIndex
%Other Columns = EEG data in microvolts followed by Accel Data (in G) interleaved with Aux Data
0, -24719.24, -29145.69, -35392.09, -18644.89, 20526.08, -6495.91, -37500.08, -32607.37, -0.03, 0.19, 0.45
1, -24407.81, -28835.87, -35083.12, -18338.22, 19640.95, -6664.60, -37192.09, -32301.27, 0.00, 0.00, 0.00
2, -24485.33, -28916.56, -35196.26, -18456.75, 19803.91, -6598.84, -37314.87, -32426.48, 0.00, 0.00, 0.00
3, -24839.92, -29269.09, -35552.95, -18811.65, 20736.34, -6357.98, -37672.12, -32782.54, 0.00, 0.00, 0.00
4, -24773.64, -29200.25, -35451.00, -18704.63, 20674.71, -6449.33, -37562.60, -32671.79, 0.00, 0.00, 0.00
5, -24452.18, -28880.26, -35123.80, -18377.80, 19769.42, -6644.39, -37233.45, -32344.43, 0.00, 0.00, 0.00
6, -24444.09, -28874.72, -35148.59, -18409.66, 19687.19, -6629.64, -37267.06, -32380.95, 0.00, 0.00, 0.00
7, -24800.53, -29229.04, -35514.82, -18776.36, 20618.95, -6389.63, -37636.34, -32749.64, -0.04, 0.38, 0.92
8, -24870.92, -29297.82, -35555.68, -18809.42, 20809.38, -6428.12, -37666.38, -32777.54, 0.00, 0.00, 0.00
9, -24553.26, -28980.47, -35221.48, -18472.24, 19946.14, -6665.36, -37325.63, -32437.10, 0.00, 0.00, 0.00
10, -24403.68, -28833.48, -35101.09, -18357.35, 19617.19, -6677.47, -37212.34, -32327.24, 0.00, 0.00, 0.00

Console log of node:

0,-25896.98,-29095.87,-31733.76,-20567.27,32275.43,-13306.69,-32053.45,-30165.56,
1,-25856.10,-29060.33,-31715.27,-20554.17,31991.96,-13475.35,-32041.20,-30157.67,
2,-25932.36,-29138.87,-31812.28,-20654.53,32739.47,-13321.62,-32148.42,-30263.26,
3,-25986.05,-29185.19,-31839.14,-20677.84,33116.55,-13145.33,-32170.06,-30281.34,
4,-25917.61,-29112.68,-31748.10,-20583.99,32427.04,-13269.81,-32070.93,-30181.72,
5,-25871.32,-29072.06,-31722.87,-20561.77,31962.91,-13452.06,-32048.65,-30163.66,
6,-25931.33,-29134.09,-31804.61,-20646.40,32598.19,-13380.69,-32139.89,-30254.81,
7,-25991.19,-29190.10,-31848.35,-20685.38,33147.21,-13154.45,-32177.26,-30288.67,
8,-25935.94,-29131.50,-31768.91,-20601.36,32580.37,-13241.71,-32087.96,-30198.79,
9,-25860.39,-29060.87,-31708.99,-20542.50,31954.81,-13422.22,-32027.66,-30141.82,

[andrewjaykeller]

@PhEigl please try removing the daisy to see if it resolves the issue. If it does, I'll go into HQ and grab a daisy to fix this. I've been meaning to grab one any way to start using it with my new mark IV and this module.

[PhEigl]

Sorry for letting you wait. I don't have access to the BCI all the time. So without Daisy module everything looks perfect. I ran debug and verbose with and without Daisy module and both times the following messages appear:

no daisy attached!..OpenBCI V3 16 channel..On Board ADS1299 Device ID: 0x3E..LIS3DH Device ID: 0x33..$$$ ready

So the board I'm using has firmware v1. Hope this helps and thank you a lot for your input.

[andrewjaykeller]

Weird, it looks like the board is not picking up on its daisy... you should force the module to 16 channels by either setting the info.numberOfChannels to 16 after the reset or setting boardType to daisy in the options you send to the constructor.

[andrewjaykeller]

I want to leave this issue open, I will clean up the titles and we will find either why this is happening from firmware or from module perspective. The module is parsing that startup string you posted so if the daisy is not reported there then no dice.

[PhEigl]

Hi again, so I've been using the device without the daisy module for a while now and it seemed to run properly. But after some experiments i was inspecting the bytebuffer a bit further and realized that channel 1 is always 0 for me no matter what i try.

<Buffer a0 05 00 00 00 89 a3 43 8e 50 98 8e a6 0b 8e f5 0c 2f d2 b7 97 8c 86 7f ff ff ff 80 ff 80 1f 30 c0>
<Buffer a0 06 00 00 00 89 a3 23 8e 53 cc 8e ad 85 8e ee cf 2f d3 46 97 8f 06 7f ff ff 00 00 00 00 00 00 c0>
<Buffer a0 07 00 00 00 89 a3 3c 8e 58 0c 8e aa e4 8e ef 1c 2f d4 ff 97 92 d0 7f ff ff 00 00 00 00 00 00 c0>
<Buffer a0 08 00 00 00 89 a3 06 8e 5c 26 8e a6 89 8e ee fe 2f d6 8c 97 96 55 7f ff ff 00 00 00 00 00 00 c0>
<Buffer a0 09 00 00 00 89 a2 79 8e 5f 24 8e a2 f4 8e f1 03 2f d7 6a 97 99 21 7f ff ff 00 00 00 00 00 00 c0>
<Buffer a0 0a 00 00 00 89 a2 62 8e 61 4e 8e a9 98 8e f1 c0 2f d7 40 97 9a f7 7f ff ff 00 00 00 00 00 00 c0>
<Buffer a0 0b 00 00 00 89 a2 2c 8e 64 ce 8e ac 01 8e ed b6 2f d8 78 97 9d f4 7f ff ff 00 00 00 00 00 00 c0>
<Buffer a0 0c 00 00 00 89 a2 05 8e 68 a1 8e a8 13 8e ed 9d 2f da 42 97 a1 9d 7f ff ff 00 00 00 00 00 00 c0>

See bytes 3-5 are all 00 all of the time. Setup is still the same. I set the boardtype to default and call the autoFindOpenBCIBoard() function.

%OpenBCI Raw EEG Data
%Sample Rate = 250.0 Hz
%First Column = SampleIndex
%Other Columns = EEG data in microvolts followed by Accel Data (in G) interleaved with Aux Data
0, -174147.31, -173766.72, -173656.53, -71095.66, -27409.54, 86722.58, -10959.91, -108394.36, -0.01, -0.01, 0.50
1, -174537.81, -173764.44, -173882.50, -71073.38, -27399.57, 86741.33, -10945.18, -108398.60, 0.00, 0.00, 0.00
2, -174668.08, -173734.83, -174063.02, -71080.94, -27404.73, 86746.88, -10945.85, -108418.05, 0.00, 0.00, 0.00
3, -174532.88, -173708.09, -174011.30, -71112.77, -27422.39, 86740.26, -10959.75, -108448.07, 0.00, 0.00, 0.00
4, -174400.47, -173689.41, -173934.61, -71149.73, -27446.47, 86728.14, -10978.53, -108481.84, 0.00, 0.00, 0.00
5, -174264.23, -173704.88, -173855.59, -71180.18, -27466.81, 86720.05, -10991.72, -108512.91, 0.00, 0.00, 0.00
6, -174123.17, -173716.14, -173770.19, -71203.55, -27481.76, 86717.75, -10999.45, -108539.64, 0.00, 0.00, 0.00
7, -173980.09, -173724.75, -173637.55, -71221.02, -27492.29, 86718.84, -11004.68, -108563.89, -0.02, -0.01, 1.01
8, -173831.95, -173731.19, -173593.08, -71216.81, -27496.76, 86726.69, -11002.65, -108580.99, 0.00, 0.00, 0.00

The values from processing look normal. Looking at your output I can see that there is actually no difference between Node and Processing. I tried doing the connection by hand with the proper portname string but same result. Any idea what this could be?

[PhEigl]

Just tried something else. I'm was calling the impedanceTestAllChannels() function after starting streaming. Apparently this results in the first channel being 0 all the time. Without the impedance test the data looks normal.

[andrewjaykeller]

@PhEigl Hey! Sorry got tied up with the Ganglion's brand new NodeJS Driver.

I did get a daisy board so will be looking to patch a final solution tonight. I'm sorry for the delay!

[andrewjaykeller]

If you set boardType in the constructor optionsobject to daisy The plan is to send the 16 channel command at connect, then we will force the board into 16 channel mode and ensure the daisy is attached. This will also be what sets the info. If the board is not able to run in 16 channel mode then we can catch and error.

[andrewjaykeller]

@PhEigl #134 will give you the functions you need to force the module to use 16 channels.

This needs more work, but this will give you what you need to use 16!

After you get the ready event, use the new function .getInfo() and verify board type is daisy. If it is not, call .setChannelToMax(16), wait for eot, parse that message for either no daisy to attach!8$$$ on failure or on success daisy attached16$$$ and call .setInfoForBoardType('daisy') to force the module to use daisy mode!

[andrewjaykeller]

@PhEigl #135 adds support for these functions in production. v1.4.4.

Will be working on a v1.5.0 to have this correcting done automatically.

[andrewjaykeller]

@PhEigl woof that turned into quite the little bugger... #136 should fix this once and for all.

Would you be able to verify this fixes your problem? It's working on my new daisy board...

[andrewjaykeller]

The root cause of this is fixed by v2.0.1. Please update your firmware!