protocols icon Protocols | Data Streaming Protocol

NOTE: This documentation is accurate for the Muse 2014 headband. Updated documentation for the Muse 2016 headband is coming soon.


Muse communicates over Bluetooth 2.1+EDR and adds its own structured data on top of it. This is called the Muse Communication Protocol or MCP. For the purposes of this documentation, we use the term “client” to refer to the device communicating with Muse. You can think of communication between a client and a Muse as a serial connection.


There are two main modes of operation:

  1. Configuring Muse
    1. An ASCII-encoded text protocol where Muse accepts a range of serial commands and responds with output. For details see Serial Commands.
  2. Data streaming from Muse to the client
    1. Sensor readings are sent from Muse as soon as they are available. The format, layout, and frequency will depend on the chosen setup in the configuration mode. For details see the Data Streaming Protocol.

The general flow of connecting to Muse from a client is:

  1. Stop the data stream(in case it happens to be streaming already)
  2. Do a version handshake
  3. Load a preset
  4. Send other configuration messages(such as changing the EMI filtering based on region of the world)
  5. Request Muse status
  6. From this status a data stream parser should be configured
  7. Start data streaming
  8. Stream data and parse it
  9. Stop the data stream when it is no longer needed

Protocol Version

Current protocol version is 2, and this documentation only covers version 2. Protocol version 2 is supported on all firmware 6.6.2 and up(all shipped hardware has firmware 7.0.11 or higher).

To allow for incompatible changes in the communication protocol between Muse and client, the protocol is versioned. The protocol version is negotiated with the version handshake on establishing the communication. See the ‘v’ command for details in Serial Commands.

To allow for maximum freedom in improving the protocol only the ‘h’ and the ‘v’ command are guaranteed to be stable. This allows a communication partner to always stop the communication and attempt to negotiate a protocol version. Between protocol versions, anything can be changed including the serial commands(including their outputs) and the data streaming protocol. An up-to-date firmware will always support the latest protocol version and most likely at least one older protocol version, to allow for backwards compatibility and migration time.

In general the protocol is very stable there are no plans for any big changes. If a change is needed, we will usually incorporate multiple unrelated changes to reduce the number of different protocol versions and have a longer lifespan of a protocol version.