search

ChrisVeigl / BrainBay

Open Source Biofeedback Software
http://brainbay.lo-res.org
Other
166 stars 52 forks source link

Connection interruptions #39

Closed encoded-evolution closed 1 year ago

encoded-evolution commented 2 years ago

Hi @ChrisVeigl

While playing a session, there are interruptions that have the following symptom:

Is this due to a design complexity issue? Are certain widgets more to blame? Or is it a BLED connectivity issue?

Often when trying to restart the session (but not always) I get a session 3 error.

Sometimes I get a session 18 error. Many times when I get session 18 I have to exit the app, pull the BLED, then reinsert. This does not always work.

What do these errors mean, how should I begin to troubleshoot them?

Muse 2 with BLED dongle

encoded-evolution commented 1 year ago

@ChrisVeigl - after asking around on the Brainflow slack, I was given instructions to check connectivity directly using a brainflow test script (also instructed that BLED connectivity is second best to direct connection.)

As mentioned before, I cannot connect directly from BrainBay to my Muse 2. But if this can be remediated, it is clearly the preferred method, per the BrainFlow devs.

But, when using the test script provided by Andrey, I was able to connect when I used a timeout of 1000 or 2000. This may be the same cause as the reason I cannot connect in BrainBay. Is there any way to modify this? I tried entering the same parameter config in "config string" area of the device setup panel, but that does not work.
image

It seems possible that being able to properly apply the BrainFlow configuration parameters may be helpful for all of their supported devices, not just the Muse 2. Would this require an additional field be added to use parameters? Or is there a parameter file that I can modify?

ChrisVeigl commented 1 year ago

hi, actually i have no idea if/why the timeout parameter works/does not work.... i cannot test this with your HW - so it's difficult to debug. I just send the config string to BF as is... Could you maybe investigate how the BF script applies the timeout parameter ? or if this just performs a waiting loop when/after BLE connection is established ?

encoded-evolution commented 1 year ago

Hi @ChrisVeigl my knowledge of C++ is poor at best. But, looking through your code, in file ob_brainflow.cpp I see this: image

I think that if the Device Settings dialog had an additional field for timeout, and then you collected the contents of that field in a similar fashion to the others and added it to the configuration (ie: ipport, macaddress, etc) it might do the trick.

Sorry my coding skills are not sharp, or I would have tried it myself. :(

ChrisVeigl commented 1 year ago

hi, thank you for the hint - yes we could try that and use the dedicated set_timeout function for the BrainFlowInputParams class: https://brainflow.readthedocs.io/en/stable/UserAPI.html#_CPPv4N9brainflow9brainflow20BrainFlowInputParamsE

should be easy to add... but unsure if it is gonna work beause according to the docs the timeout parameter is not supported by the MUSE boards: https://brainflow.readthedocs.io/en/stable/SupportedBoards.html#muse

encoded-evolution commented 1 year ago

The timeout appears to be purely Brainflow, it's used to establish the connection. Seeing it in action, as BF cycles through the visible bluetooth devices, it waits the length of the timeout for a response when trying to connect to an identified board. Time out only appears to function when establishing connections.

Without this timeout, it seems that the non-BLED versions of the muse boards cannot connect. I even saw this behavior with a python script Andrey had me experiment with. And if it makes the non-BLED useful in BrainBay, this is good: the plain "muse 2" and "muse S" device types are supposedly more stable than the BLED versions, per Andrey's recommendation. Hopefully this would manage the disconnection issues with BLED.

It looks like it's worth a try.

Sent via the Samsung Galaxy S8 Active, an AT&T 5G Evolution capable smartphone Get Outlook for Androidhttps://aka.ms/ghei36

From: Chris Veigl @.> Sent: Saturday, October 29, 2022 5:46:34 PM To: ChrisVeigl/BrainBay @.> Cc: encoded-evolution @.>; Author @.> Subject: Re: [ChrisVeigl/BrainBay] Connection interruptions (Issue #39)

hi, thank you for the hint - yes we could try that and use the dedicated set_timeout function for the BrainFlowInputParams class: https://brainflow.readthedocs.io/en/stable/UserAPI.html#_CPPv4N9brainflow9brainflow20BrainFlowInputParamsE

should be easy to add... but unsure if it is gonna work beause according to the docs the timeout parameter is not supported by the MUSE boards: https://brainflow.readthedocs.io/en/stable/SupportedBoards.html#muse

— Reply to this email directly, view it on GitHubhttps://github.com/ChrisVeigl/BrainBay/issues/39#issuecomment-1295992432, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAL2YLXAMGVCTYIGADTKBVTWFWLLVANCNFSM6AAAAAAQXXOZ34. You are receiving this because you authored the thread.Message ID: @.***>

ChrisVeigl commented 1 year ago

I added the timeout parameter, please try the .exe in this branch: https://github.com/ChrisVeigl/BrainBay/tree/museTimeout

encoded-evolution commented 1 year ago

Hi @ChrisVeigl thanks for the quick change! I think there is something else going on that is still "short circuiting" the BF board for this. See below some logs from the experiments:

The original brainBay.exe (Aug 2022), this is a situation that we expect it to fail, given that the error was occuring. Interestingly, there is a timeout of 6 even though the json config definitely shows a 0. At any rate, see how it appears to fail at loading the dll, which generates a "General Error" 17 from Brainflow. 

[2022-10-30 12:35:46.108] [board_logger] [info] incoming json: {"file":"","ip_address":"192.168.4.1","ip_port":4567,"ip_protocol":0,"mac_address":"","master_board":-100,"other_info":"","preset":0,"serial_number":"","serial_port":"COM4","timeout":0}
[2022-10-30 12:35:46.109] [board_logger] [trace] Board object created 38
[2022-10-30 12:35:46.109] [board_logger] [info] Use timeout for discovery: 6
[2022-10-30 12:35:46.110] [board_logger] [debug] use dyn lib: C:\Users\folde\AppData\Local\BrainBay\simpleble-c32.dll
[2022-10-30 12:35:46.110] [board_logger] [error] failed to load lib
[2022-10-30 12:35:46.112] [board_logger] [error] Failed to init dll_loader
[2022-10-30 12:35:46.113] [board_logger] [error] failed to prepare session17

This example is from your new brainBay.exe (Oct 30 2022), I tried it using your new timeout field in the modified dialog. It seems to successfully use the new timeout for discovery, but we have the identical issue loading the library. :

[2022-10-30 12:37:10.414] [board_logger] [info] incoming json: {"file":"","ip_address":"192.168.4.1","ip_port":4567,"ip_protocol":0,"mac_address":"","master_board":-100,"other_info":"","preset":0,"serial_number":"","serial_port":"COM4","timeout":2000}
[2022-10-30 12:37:10.416] [board_logger] [trace] Board object created 38
[2022-10-30 12:37:10.416] [board_logger] [info] Use timeout for discovery: 2000
[2022-10-30 12:37:10.416] [board_logger] [debug] use dyn lib: C:\Users\folde\AppData\Local\BrainBay\simpleble-c32.dll
[2022-10-30 12:37:10.416] [board_logger] [error] failed to load lib
[2022-10-30 12:37:10.416] [board_logger] [error] Failed to init dll_loader
[2022-10-30 12:37:10.417] [board_logger] [error] failed to prepare session17

Also note that this error appears IMMEDIATELY, the app never gets to the actual "discovery" phase where it attempts to find and connect with the device. I suspect this loading issue needs to be resolved. I cannot find that dll in the listed folder, and it appears that this dll is for BLE when the configuration selected is not for BLE? I am unsure but it appears it is calling a non-existent and possibly erroneous library.

As a point of comparison, here is the new brainBay.exe able to load the board for Muse 2 BLED. No library loading issue, not even the same debug message, not sure which library it finds and loads. 

[2022-10-30 12:38:08.966] [board_logger] [info] incoming json: {"file":"","ip_address":"192.168.4.1","ip_port":4567,"ip_protocol":0,"mac_address":"","master_board":-100,"other_info":"","preset":0,"serial_number":"","serial_port":"COM3","timeout":2000}
[2022-10-30 12:38:08.966] [board_logger] [trace] Board object created 22
[2022-10-30 12:38:08.968] [board_logger] [debug] Library is loaded
ChrisVeigl commented 1 year ago

I suppose loading failed because of the wrong board type (id 38) was selected. the question is why it also does not work now with the correct board type (22) and timeout (2000) ... maybe somebody in the BF-forum can help ...

encoded-evolution commented 1 year ago

To me, it appears the right board is selected, at least according to the logging information. When I select "Muse 2" as in my second trial above, the right board is reflected in the logs: # 38 image

Maybe the version of BF is dated? What version of BF is BrainBay using? Is it the latest version?

Or maybe I misunderstood your question...?

ChrisVeigl commented 1 year ago

I am referring to your log files. There the board ID 22 (Muse2BLED) does not show a connection error - so I supposed you have that board ... i do not know why it doesn't work although we tried the timeout option.

encoded-evolution commented 1 year ago

Ah, board 22 does work. it is just that when using board 22, the connection continually drops unexpectedly and unpredictably.

This is why Andrey recommended to use the regular board 38 - it should be more stable than the BLE boards. But, we have hit these issues trying to run board 38, such as the timeout, and the call to the dll that fails.

ChrisVeigl commented 1 year ago

hi, is there any new information about this problem? - should I merge the timeout patch and close this issue - or try some other idea?

ChrisVeigl commented 1 year ago

https://github.com/ChrisVeigl/BrainBay/releases/tag/v2.8 includes the timeout parameter