How to transfer data via LSL on a bare machine like Single Chip Microcomputer

[linzhang2015]

Dear all,

I'm wondering how did Muse transfer data using Bluetooth via LSL. And we can use LSL on windows, the bottom of network or driver has been implemented by windows, however, what if we want to use LSL without operation system? I think we need a working TCP/IP network to run LSL on top of (it's an overlay network), but how to realize this?

Any suggestions would be welcomed. Thanks.

[chkothe]

Hi Liam,

to use LSL in an embedded form factor you either need to use an embedded system that can run a Linux (there are many very small platforms like that out there, like Raspberry Pi, Intel Edison, and some others), or if you want to run it on bare-bones hardware without an OS you need to license a wifi implementation and either implement the LSL network protocol yourself (which is not too complicated and based on TCP and UDP) or you need to try to get liblsl to work without an OS (which can be challenging since it's multi-threaded and uses heap memory management and so on, which is often not available on these platforms). As far as small bluetooth devices like for instance the Muse go, what many vendors do is have a very lean system on the device that communicates via a Bluetooth point-to-point connection (often using the Bluetooth Serial Port Protocol) to a host device that runs an OS (like for instance a phone or a PC), and the software on the host is where LSL is implemented.

Christian

On Fri, Dec 18, 2015 at 8:59 AM, Liam. Zane [email protected] wrote:

Dear all,

I'm wondering how did Muse transfer data using Bluetooth via LSL. And we can use LSL on windows, the bottom of network or driver has been implemented by windows, however, what if we want to use LSL without operation system? I think we need a working TCP/IP network to run LSL on top of (it's an overlay network), but how to realize this?

Any suggestions would be welcomed. Thanks.

— Reply to this email directly or view it on GitHub https://github.com/sccn/labstreaminglayer/issues/75.

[eugene345]

Hi @chkothe , We are considering adding LSL to our product - EEG Dev Kit (https://www.foc.us/eeg). Would be good to know, if any low level documentation available about LSL (detailed description, principles of work, data formats, etc)? This could help to implement LSL in our devices.

Best regards, Eugene

[tstenner]

It's certainly possible, but probably needlessly complicated. Still, if you want to do it you'd need to

• send service advertisement packets so clients can find the device, see the multicast implementation in udp_server (see also stream_info_impl for the contents)
• listen on an udp socket for time and info requests (see udp_server::handle_receive_outcome)
• listen on a tcp socket where do an initial handshake with the client and then send the data (see tcp_server and sample.h)

There are two protocol versions, 100 and 110. 110 is quite simple (see sample::save_streambuf), protocol version 100 however depends on Boost.Serialization which has most likely zero support for your compiler / platform.

[mgrivich]

Euguene,

The documentation is at https://github.com/sccn/labstreaminglayer/wiki

If you'd just like to implement LSL on your devices, you are best off looking at the basic examples at https://github.com/labstreaminglayer/App-Examples/tree/master (if you are in C/C++, other examples exist in other languages) and the current example app at https://github.com/labstreaminglayer/App-BestPracticesGUI/tree/master

You posted in a very old thread that is probably off topic for what you want to do.

[mgrivich]

I edited my previous message with better links (to master rather than a branch).

[eugene345]

Thanks @tstenner and @mgrivich

Our device, EEG Dev kit, is an embedded system, based on Cortex M4F MCU, therefore has limited performance and memory. It can't run Linux, but has RTOS. Because of the above and lack of the libraries, which LSL uses, we can't use LSL as is. Our current implementation for streaming EEG data is MQTT. It works fine with our web UI, but we would like to make the device be compatible with existing software for EEG data viewing and processing, and LSL, seems, is right choice. So, we consider developing an LSL-compatible library (just bare minimum functionality) for our system.

[mgrivich]

In that case, to answer your original question, there is no low-level documentation. There is only the high level documentation that I linked. Or you could say that the code is the documentation, as Tristan was linking.

[tstenner]

Which compilers can you use? You won't get around reimplementing the networking code, but with newer compilers you could reuse a lot of the recent boost free code.

[eugene345]

I use ARM compiler 5, but, probably, could move to ARM compiler 6.

[tstenner]

Which C++ standard does the ARM compiler 6 support? Since it's clang, I'm hoping for at least C++11, but C++14 would be even better.

Also, is it possible to have threads and / or asynchronous networking operations?

[eugene345]

Yes, ARM Compiler 6 supports both C++11 and C++14. There is real time operational system, so threads are used. And network processor provides asynchronous network API. I worry about using C++ and the LSL code as is, because MCU has limited speed and memory (I think, less than 20-40 KB will be available to LSL). But, looks like LSL, hasn't been written for using in such small embedded systems. So, I'm considering writing of a very simple implementation of LSL in C: only necessary for our device functions, limited flexibility and parameters.

[cboulay]

@eugene345 I don't think a document outlining the packet structure and the communication protocol exists already. If in your pursuit you think it would be helpful to make a document, then please share it because I think it would be very helpful for the community and for the developers.

[tstenner]

I worry about using C++ and the LSL code as is, because MCU has limited speed and memory (I think, less than 20-40 KB will be available to LSL).

At the moment, I've brought down the binary size to about 700kB, which is still way too much for your use case. I'd still use C++ but without the potentially large extra features (exceptions, Boost, big parts of the STL). You can save a lot of space by precomputing the info packet (which is basically an XML string), leaving out the protocol version 100 and the endian conversion (assuming your device and all clients are little endian) and then streaming directly from the ADC to all connected clients. The one thing you can't do with 40KB is buffering the data for clients with connection issues to send it when they reconnect, so you either need to be absolutely sure the wireless connection is stable or risk data loss.