Unreliable connectivity to MUSE


#1

I’m on a mac running os x 10.9.2. I have paired with the muse but I only receive a little bit of data before something fails and muse-io attempts to reconnect. Has anyone seen this behavior? Any clues how to debug / fix this problem would be appreciated.

I’m running muse-io 3.0.0 (Build-479 Apr 9 2014 16:07:49)

 ./muse-io --preset 14 --verbose --device-search 'Muse' --osc osc.udp://localhost:5000

I get output that looks like:

Battery:  [============        ]+  62%  voltage: 3.85mV
[ ID_REQUEST_FAIL ]
[ HALT_DATA ]
[ HALT_DATA_WAIT ]
bits/second: 0    receiving at: 220.00Hz         dropped samples: 0
Battery:  [============        ]+  62%  voltage: 3.85mV
[ ID_REQUEST_FAIL ]
[ HALT_DATA ]
[ HALT_DATA_WAIT ]
bits/second: 0    receiving at: 220.00Hz         dropped samples: 0
Battery:  [============        ]+  62%  voltage: 3.85mV
[ ID_REQUEST_FAIL ]  wait for close
com thread stopped
Pause 1s before retrying...
Reconnect attempt: 1.

Device match pattern:wait for close
com thread stoppeded device "Muse": n/afailed to open rfcomm channel, read thread not started
Pause 1s before retrying...
Reconnect attempt: 2.

It sometimes will reconnect but only momentarily and then repeats the same error messages.

Here is the muse hardware information.

================== Muse Status ==================
  Muse Hardware:         7.0.0
  Muse Firmware:         7.0.9
  Muse Firmware type:    Consumer
  Muse Bootloader:       7.0.9
  Build No:              20
  BT Mac Address:        00066664173F
  BT Firmware:           Ver 5.45 IAP 10
  Serial:
  Preset:                14
  Filters Enabled:       true
    - Notch Frequency:   60Hz
  Accelerometer Enabled: true
  EEG Sample Frequency:  1760Hz
  EEG Output Frequency:  220Hz
  EEG Samples Bitwidth:  0
  EEG Channel Count:     4
  EEG Channel Layout:    A1 FP1 FP2 A2
  Downsampling:          8
  Output Mode:           SEROUT_COMPRESS
=================================================

#2

I found the problem. I had another muse-io running in minimized terminal window.


#3

Hey! Yea, that’s definitely something that is to be improved - muse-io needs to fail nicely if there is another muse-io process active on the system. There’s some complexity around getting that to work nicely in a cross platform manner, and the problem of getting blocked by zombie processes (stuck waiting on bluetooth drivers and hardware more often then not), but we’re working on it.


#4

Yes, I have noticed that bluetooth connectivity is very intermittent, and often needs frequent resets before it finally connects.