-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
High incidence of NaNs running in Electron #14
Comments
Issue appears to get worse with high CPU usage |
From my experiences, NaNs usually indicate a bad link - For instance, I had many of them in my ngAtl 2018 talk, where I also had a really hard time connecting with the headset - probably due to some kind of radio interference in the venue. Last year I experimented with different setups, and I found that Windows BLE Stack with the bluetooth adapter built into my laptop gave much worse results in comparison with an external BLE dongle with node-bluetooth-hci-socket (used by noble). |
Thanks Uri! That makes me feel a lot more comfortable, knowing that you've ran into the issue before. It's true, every time I've seen high NaNs is when using an internal bluetooth adapter rather than a dongle. I imagine this is not something we'll have the power to fix ourselves. So, until web bluetooth gets another major update I'll make sure to go the dongle route when running really important demos. Cheers |
@jdpigeon I'll just add that from my experience dealing with multiple stations (different laptops + muse) with over 100 hours usage per machine, bluetooth performs best using external dongle. even those cheap no-name brands always outperform the internal ones in terms of connection stability. crazy but true. perhaps the issues are related to the antenna, rather then the chipset. |
hi , |
My guess is that it has to do with interference... Bluetooth has limited bandwidth, and 45 real-time EEG data streams sound too much |
I was impressed it worked at all. so if you are correct the dongle wouldn't help right |
"most of today’s Bluetooth technology use what’s called spread-spectrum frequency hopping. That is, they rotate between 70 randomly chose frequencies within their range, changing 1,600 times a second. This makes it unlikely that two devices will share the same frequency. And when they do, they won’t for very long. Other Bluetooth technology also employs what is called AFH, a technology that identifies “bad” channels (i.e. those that are already in use) and instigates a switch." - https://www.goldtouch.com/stop-bluetooth-interference-messing-devices/ |
Once during a live-demo of the Muse in my talk, I had an issue where I couldn't connect to the device at all. I'm not sure what was interfering on-stage, but I tried a dozen of times before in the adjacent room and it worked perfectly. You can watch me miserably try to make my computer speak to the muse with very little luck: |
oh yeah i've been there many times, also with paid participants and in the hospital in an experiment, that is why we love how each muse-js connects, thanks, תודה! |
I want to also chime in and say that we've also ran into on-stage bluetooth connectivity issues at CTRL-labs. It happens to everyone 😅 |
Well all things considered our first try at running 45 muses in a class at once seems like a big success, actually biggest limiting factor was enough chairs for 90 students , not really a GitHub issue |
I've been noticing a high incidence of NaN values in some of the experimental data collected in the BrainWave app.
One of the most recent experiments collected on OSX has NaNs throughout the entire dataset.
NaNDataset.zip
I'll back when I get to the bottom of this. My suspicion is that this might be a web bluetooth specific issue
The text was updated successfully, but these errors were encountered: