Standardize EEG Data Model for Streaming

[alexcastillo]

Hi everyone,

I've created this repo with the purpose of discussing a data model standard for streaming EEG.
Please review the README.md file and feel free to submit PRs.

cc @aj-ptw @marionleborgne @urish @teonbrooks @andrewheusser

Best,

Alex

[andrewjaykeller]

There is a lot of redundancy with this model. The only things that should be in a sample are dynamic variables i.e.:

{
  "buffer": [ // List of samples
    {
      "timestamp": Date, 
      "data": [ // List of channels
         float, 
         float, 
         float, 
         float
      ]
    }
  ]
}

Having to send these over the wire means we need to be lean as possible. I find the best results when i minimize the amount of redundant data between sample.

I think a header or start byte define what the metrics are:

{
  "metric": String // E.g. EEG, ACCL, etc (optional)
  "source": String // E.g. Muse, OpenBCI, etc (optional)
  "sampleRate": Number // E.g. 250. always in hz (optional)
  "mock": Boolean // E.g. false (optional),
  "topology": [ 'Pz', 'Oz', 'Cz', 'C1']
}

especially with hierarchal topics we can inject and split on these exact metrics.

[marionleborgne]

Hey guys. I'm in the mountains now. I will reply on Sunday with a more detailed answer but in short my recommendation for the data model would be to map it to the LSL model. 1. Send only one time the rich StreamInfo, serialized to JSON. This contains sampling rate, channel positions, channel data format etc. 2. Open a stream and the only data that is sent is Steam samples serialized to JSON. In LSL parlance it's : `{timestamp :..., data : [..., ...]}` For efficiency concerns when transmitting over the network we can bundle the samples in chunks and so the JSON transmitted is: ``` [ {timestamp :..., data : [..., ...]}, ..., {timestamp :..., data : [..., ...]} ] ``` Add the quotes to make it real json (I'm writing from my phone) but that's the gist of it. I can add more details when I'm back. I don't think we should send anything related to the stream info (like electrode positions, sampling rate etc) with the stream samples. It's just inefficient. The stream info should be query-able on demand.

…

On Fri, Jun 16, 2017, 10:02 PM AJ Keller ***@***.***> wrote: There is a lot of redundancy with this model. The only things that should be in a sample are dynamic variables i.e.: { "buffer": [ // List of samples { "timestamp": Date, "data": [ // List of channels { "id": String // E.g. FP1, FP2, F3, F4, C3, C4, etc (optional) "value": Number }, ... ] } ] } Having to send these over the wire means we need to be lean as possible. I find the best results when i minimize the amount of redundant data between sample. I think a header or start byte define what the metrics are: { "metric": String // E.g. EEG, ACCL, etc (optional) "source": String // E.g. Muse, OpenBCI, etc (optional) "sampleRate": Number // E.g. 250. always in hz (optional) "mock": Boolean // E.g. false (optional) } especially with hierarchal topics we can inject and split on these exact metrics. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACX3uy72L3IFgrIY7iCi5pBEs81_H0mBks5sE13HgaJpZM4N9H41> .

[marionleborgne]

Basically what AJ says. Except the streaminfo (what he calls the headers) should respect the LSL convention (really, it's the XDF format they're using)

[alexandrebarachant]

Out of curiosity, why not using LSL ? There is no js implementation but I might be easier to make one rather than creating a new standard from scratch.

[alexcastillo]

Thanks everyone for the feedback!

Sounds like we want to go leaner and use LSL.
I'm not familiar with LSL but definitely don't want to reinvent the wheel.

@alexandrebarachant can you point me to an LSL implementation in other languages? Maybe a Python implementation.

Maybe we can port it to JavaScript to make the communication between server/client more efficient.

Best,

Alex

[alexcastillo]

Have anyone used this one?

https://github.com/sccn/labstreaminglayer/tree/master/LSL

[alexandrebarachant]

That's the one. I'm using it extensively.

Now, the typical usecase is streaming on a local network, so that is why I'm asking the question.

[marionleborgne]

I've extended LSL to work outside of a lab network. It's in a private repo right now. I will try to release it next week.

…

On Sat, Jun 17, 2017, 11:16 AM alexandre barachant ***@***.***> wrote: That's the one. I'm using it extensively. Now, the topical usecase is streaming on a local network, so that is why I'm asking the question. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACX3u8GxU-9dakYi55EClqynikHfzZAVks5sFBfvgaJpZM4N9H41> .

[urish]

I went ahead and created a small node program to stream Muse 2016 data to LSL:

https://github.com/urish/muse-lsl

Basically, it leverages muse-js over noble (BLE bindings for Node.js) using bleat (emulates Web Bluetooth for muse-js), and then uses ffi to interface with liblsl.

So now I got the data streaming to LSL (I can see it in their Lab Recorder program).

Do you have any good pointers for LSL compatible software that I can use to visualize the EEG data, etc.?

[alexcastillo]

This is awesome, Uri!

Could we separate the lsl part into its own lib that can accept an EEG Observable?
That way we could use it for the Muse, OpenBCI, etc.

And of course, let me know how I can help.

[andrewjaykeller]

How do I stream to LSL from OpenBCI shield? Arduino C/C++ compatible.

[urish]

thank Alex!

Basically, the LSL wrapper sits in https://github.com/urish/muse-lsl/blob/master/lsl.js, so it can be quite easily separated. I don't have much experience with LSL though - I first heard about it today :)

[alexandrebarachant]

I also have a muse lsl repo : https://github.com/alexandrebarachant/muse-lsl It's in Python. There is a lsl viewer to plot live EEG signal. There is also something to record P300 data. More detail here : http://alexandre.barachant.org/blog/2017/02/05/P300-with-muse.html Le 18 juin 2017 00:53, "Uri Shaked" <notifications@github.com> a écrit :

…

thank Alex! Basically, the LSL wrapper sits in https://github.com/urish/muse- lsl/blob/master/lsl.js, so it can be quite easily separated. I don't have much experience with LSL though - I first heard about it today :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACC9thhbny9hXW2ieMZ5uw49GF8qVMqRks5sFFjmgaJpZM4N9H41> .

[urish]

Thank @alexandrebarachant , going to try to feed my muse-lsl into the viewer in yours!

What's the best way to communicate with you? Got some questions regarding how to analyze muse data, seems like you have some practical experience with this