I really need the SDK for Muse 2… I think If Intraxon release temporary library like v6.0.4 with patches for Muse 2 then I can use some basic sensor functions at least (even the sample Android app won’t work because of the current SDK). Anyways I hope it will be available soon🙏
I’m try to use Muse Direct but, even if I use different pcs, I always receive the same message: “Connessione non riuscita” (Connection failed).
If it’s not possible to have an official application that allows me access to raw data on brainwaves, then please, release the sdk!!!
I am a psychotherapist and I bought Muse 2 for clinical and research purposes. At present, however, I can make a very limited use of it.
I’m waiting a sdk for the muse 2 too. Any news ?
Hi guys, the Interaxon dev team is working on features and bug fixes with Muse 2, and support for Muse 2 in the SDK is not a priority right now. If you’re planning a Muse development project, please plan to work with Muse 2016 for now, as a timeline for Muse 2 support can’t be provided at this time.
Thats sad to hear. Can we at least get documentation on the BLE characteristics? That would provide me with enough to connect with my own software so I’m not waiting on you all to prioritize your community of eager developers.
Snown, appreciate your enthusiasm. You can access all of the data from Muse 2014, 2016, Lowdown Focus, or Muse 2 using MuseDirect, and you can access all of the Muse 2 data stream (or that of other Muse versions) for individual and research use with MuseLSL, which is free and open source - you don’t need the SDK to access those data for personal and research use.
Wonderful. I have looked into Muse Lsl already and I’ve used it as a reference when writing my own software for connecting to the Muse. @Graeme My aspriations are a bit more vast though and I require the data for the new hardware functions such as the Heart Beat sensor. Is it not possible to get the BLE characteristics? If not, can you explain why?
I’d recommend looking in the NeuroTechX Slack channel for help with MuseLSL data structures. There’s not really a heartbeat sensor per se in the raw data - rather it’s raw PPG signal, and you can get that from MuseDirect for iOS, which has a free trial option. MuseDirect for iOS also allows broadcast of the OSC data stream, including PPG data, to other IP addresses.
Thanks Graeme. Are you also aware of the new requirement (see below) from Google about the move to 64-bit. The current MUSE Unity SDK has 32-bit libraries in it. This will need to also support 64-bit. Are you planning on adding this in the future? Here’s the statement from Google:
The 64-bit requirement: what it means for developers
Starting August 1, 2019:
- All new apps and app updates that include native code are required to provide 64-bit versions in addition to 32-bit versions when publishing to Google Play.
- Extension: Google Play will continue to accept 32-bit only updates to existing games that use Unity 5.6 or older until August 2021.
Starting August 1, 2021:
- Google Play will stop serving apps without 64-bit versions on 64-bit capable devices, meaning they will no longer be available in the Play Store on those devices.
- This will include games built with Unity 5.6 or older.
I just bought the Muse 2 2018. I had to buy the Muse Monitor app to visualise data on my Android Phone (Xperia xz1). It runs well, even when doing groceries and driving in the car.
I’m going to perform experiments with my clients and need to stream the data to my macbook pro mid 2012.
How can I stream my data from my android Muse Monitor app to my Macbook Pro 2012?
64-bit libraries are already built in.
i think, whit the muse monitor app, and using the streaming funcionality
Any plans for Muse 2 SDK? We are looking to buy a couple for an arts festival. The lack of SDK real deal breaker to be honest.
Yet another unsuspecting academic who unfortunately didn’t do enough research (ha!) before buying to end up slightly disappointed (caveat emptor, I suppose). But since my needs are relatively simple right now (access to streaming raw data via network, a la OSC), I think what is available out there could fit my needs right now. I’d like to confirm that I could go for one of the following options:
@Enigma644: Your app, Muse Monitor (either iOS or Android) fully works with the Muse 2. One time purchase (would have to choose the platform).
Muse Direct (either iOS, Android, or Windows), will at least be able to obtain raw data. But it requires a monthly subscription fee. The flip side is it’s a universal login I’m guessing, which means I could in theory work with any platform?
Thanks in advance for any replies, and patiently awaiting for the eventual release of the SDK, as I’m sure many others are as well
@johnty Re: Muse Monitor, you are 100% correct. Note that currently the Muse 2 PPG sensor data is not available, but everything else is! The Muse Monitor FAQ Page has the OSC and CSV specs for available data. As soon as the SDK is updated by IX, I’ll add in PPG data.
@Enigma644, after trying out the subscription based version for a week, I’ve decided to purchase your app. Only had a brief run with it but so far have to say it’s very slick and well done!
You’re not by any chance working on desktop (either W10 or OSX) version? Not a huge deal since I can always use a phone as an intermediary for now…
@johnty Sorry no desktop version coming. Bluetooth on Windows and OSX is pretty terrible. I went through five different Bluetooth adaptors before I could find one that worked with the 2016 Muse and I still haven’t found one that works well with the 2018 Muse-2.
Interesting! I have some experience with BLE MIDI (built some microcontroller-based interfaces on the nRF51822 and ESP32), and did notice that OSX for example enforces a pretty long connection interval (11.25ms), despite the fact the MIDI spec should allow for as low as 7.5ms for better latency characteristics. Do you think something similar happening for the Muse - for whatever reason, the BLE radio/stack combination on these desktop platforms is not able to operate at high enough rates?
Even with 7.5ms (the minimum possible value for BLE, IIRC), it means that given a sample rate of 256 Hz would imply multiple samples would have to be packed together for each connection interval. Not ideal for “real” realtime data, but at the same time the raw sampled EEG data is likely not that interesting and the processed wave signals which need to go through quite a bit of frequency domain processing don’t really need such high sampling rates anyway… I suppose you could have a frame skip of 1 sample for each FFT, but the processing requirements would be immense and most likely not necessary for the signals of interest.
This is making me curious about how the headset transmits BLE data: does it throw everything out all the time when active, or is it dependent on the driver app asking for certain signals? Briefly looking at the BLE profile (via PunchThrough’s tool on iOS), I see a single writable characteristic and a lot of notify ones. So my guess is that you write certain commands to it which then selectively activates other characteristics as needed… but of course I don’t need to try muck around here since we already have a great tool (Muse Monitor) that does all this… so this is more of an academic exercise
Sorry, getting a bit off topic
If you’re interested in the BLE protocol check out Alexandre barachant’s work.
Regarding Win/OSX, I think it’s a hardware issue. I’m guessing Bluetooth just isn’t something that is used much in that environment, so the support isn’t there… where as on mobile it’s essential, so it’s more developed.
That said, I’ve found a few mobile devices which can’t handle the Muse bandwidth and chuck out NaN data errors. Namely the LG G6, Samsung Galaxy Tab A and Hauwei P10/P20.