32 G.Nautilus device stops sending data in the middle of recordings

[jabarragann]

Good night to all,

Recently, we decided to start collecting EEG data from our 32 channel G.nautilus headset with the LSL G.needAccess client. Our problem is that after 10 or 15 minutes of sending EEG data with the client and recording it with the LabRecorder App, the client seems to disconnect from our headset in the middle of the recording and once it happens, the client stops sends constant values. (This is my interpretation since I see constant values in the LSL Matlab viewer.) This issue is extremely frustrating and has already ruined a few EEG recordings.

Apart from the behavior that I am describing before there is not much more information than I can give. I don't see any additional warning or error in the console executing the client. It just stops working in the middle.

I was very happy using the client, but this bug might force me to look for other solutions to use the G.nautilus with LSL.

Has this ever happened to somebody before? Is there any debug messages that can be activated in the client to track the issue?

Thanks,

Juan A

[cboulay]

I'm pretty sure we've used it for more than 15 minutes at a time. I don't have access to the g.Nautilus at the moment but I'll try to get my hands on it this week.

A few questions until then:

• If you close the LSL app and restart it, without disconnecting the device, does it function correctly again (for a while anyway)?
• If no, same as above but restart the device too?
• Can you trigger the failure early by doing anything in particular? Try moving the headset far away from the receiver for a few moments. Try unpairing/pairing a different set of bluetooth devices (e.g. phone and headset).

I was very happy using the client, but this bug might force me to look for other solutions to use the G.nautilus with LSL.

Please let me know what the other solutions are. I would be happy to link to them in the README.

[jabarragann]

Hi @cboulay,

I believe that the problem was generated by the G.Tec Device Service (GDS). Yesterday, while doing the tests that you ask me to do we decided to kill and restart the service, and after, that we were not able to reproduce the problem. Today, we have another data collection so we will be able to closely monitor if the bug appears again.

Regarding the other solutions, I am working on some scripts to get the data of the G.Nautilius with G.tec python API (PyGDS), and the streaming them into LSL with python LSL library. A good option for those who have access to the API and does not want to compile the code. If it sounds interesting, I could send a pullup request with the code once I finish the scripts.

[cboulay]

to get the data of the G.Nautilius with G.tec python API (PyGDS), and the streaming them into LSL with python LSL library

Fundamentally this isn't any different than what the g.NEEDaccess application does, you're just adding a Python layer in between. Admittedly most people using LSL and g.Nautilus will likely also have Python installed, but some may not, and you may end up requiring certain versions of libraries etc., so this in fact adds a larger dependency. Also, depending on the source of the problem, it would encounter the same bugs.

If you are willing, then I think a very useful contribution would be to improve the current application with better error detection and reporting.

In terms of compiling, Christoph Guger gave me permission to host compiled versions of the program here. If you go to the release page you'll see that you can download binaries, no self-compilation necessary. (The user still needs the g.NEEDaccess SDK from g.tec installed on their machine for it to run).

[jabarragann]

Given my current C++ developing skills I might not be able to do any significant contribution to the g.NEEDaccess application, but I will be posting more updates if the issues that I described come again. As for the now the solution of restarting the GDS service seems to have solved the problem.

Thanks for your quick answers.

[cboulay]

I understand. C++ isn't my favourite language either. And I have made LSL apps using Python when I could have done something in C++ instead, just because Python was easier. But there are some drawbacks (as stated above), and especially so if you want to make an interactive GUI (threading becomes a problem).

But maybe a small task like this is a good stepping stone into basic C++ development. I got started in almost the same way.

Anyway, glad to hear that it's working and please let me know if you encounter the problem again. For the record, if it was streaming constant values instead of that just being an artifact of the visualizer in Matlab, then that's a big problem. It shouldn't send fake data under any circumstances. If you can verify that's what was happening then I'll try to put some protections in against that.