Stream raw data from Muse2016 to MAC


I’m experience with working with Muse2014, to stream raw data from the device to MAC laptop, so that a simple server I’ve created could pick up the data as OSC (or it’ll be picked up by MuseLab).

I’ve just purchased Muse2016, and also the 3rd party app to stream data with (
However I’m still unable to pick up the data. I’m streaming the data to my computer’s IP + port.
My server does not see the data as OSC on that port.
I’m also unable to use muse-io, since it expects the device to be paired to the computer (which is impossible in the new Muse2016 Bluetooth version).

Is there some documentation on how to use Muse2016? Have anyone managed to steam raw data with it to their computer?


Hi shiran,

I just learned how to set up a similar stream earlier today, only with a PC and Android phone. Sorry if this is obvious but I wanted to say make sure your phone and computer are on the same wifi network. Also, within whatever software you’re using to pick up the stream (e.g. MuseLab) make sure you are using UDP and not TCP. Beyond that, make sure a firewall or VPN is not interfering in some way, and also try changing the port or making sure that the port you specify is not being used by another application.


Hi @zephyr4563
Thank for replying! I just managed to work it out. The issue was that I configured the data to the public IP.
It worked when I configured it to send data to the internal IP (


I started to look into the data I’m streaming.
Is there a way to stream the data through muse-io?
I’m asking cause I’m looking to enable the –osc_timestamp functionality to get the timestamp along with the raw data.

Is there another way to get it directly with Muse Monitor?


Muse Monitor does includes the timestamp in the OSC stream data.

Note that the timestamp is stored in the OSC Bundle, not the OSC Message.
OSC Messages just contain the data, the bundle is a collection of message with a timestamp.


Thanks! I was not aware of that. Now I’ve read the spec :
Something still not seems right - the value of the timetag is always the same: 2147483647 (MAX_INTEGER)
f you break it down to two 32 bit ints, the first one equals 0 and the second one MAX_INT.

I’m using Java 's OSCP5 to parse the data, but even when I’m debugging the source code, it looks like the issue is with the Original data.
For example, I’m getting a Bundle’s byte[] as input.
When parsing the first 8 bytes:
new String(Bytes.copy(theBytes, 0, 8)) == "#bundle
As expected, but when parsing the next set of 8 bytes:
(new Long(Bytes.toLong(Bytes.copy(theBytes, 8, 8)))) == 2147483647

Is there some flag I’ll need to turn on to get the timestamp?


You’re right. It looks like there’s is a bug in the VVOSC library I’m using in Muse Monitor, exclusive to iOS 10!
Testing on iOS 9 it works fine.

I’ll try and release a fix for this ASAP, but bear in mind that the bug is with a third party library, so it might take me a while to find.

For reference it looks like oscP5 copies the bundle time to the individual message, so you can get the date time with something like this:

long timeTag = theOscMessage.timetag();
long epocTimeMS = (timeTag + 8959209420479266816L)/4294967L;
String timeStamp = convertTime(epocTimeMS);

public String convertTime(long time){
    Date date = new Date(time);
    SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS Z");
    return format.format(date);


Cool. Just FYI, I was not using iOS10, but iOS9


Muse Monitor iOS v2.0.6 is now available with the OSC timestamp milliseconds fix.


FYI, after much testing I have found out that the timeTag produced by oscP5 is incorrect. The millisecond bytes are a fractional component of the maximum value (4294967296) as per this bug fix:

But oscP5 calculates it as: final long secsFractional = ((theTime % 1000) << 32) / 1000; which is incorrect.

I have tried coding a work around without altering the oscP5 source, but processing encounters floating point number rounding errors due to the very large numbers involved and so accuracy is lost.


Thanks, works like a charm!
setTime is never called when parsing the incoming data. Are you using oscP5 to also send the data? Is that why that is an issue?
I’m not sure what 8959209420479266816L and 4294967L stands for, but I take it that now the timestamp is accurate, but since you have to bypass the bug the resolution is lower? How much more accurate the data is without this bug?


long epocTimeMS = (timeTag + 8959209420479266816L)/4294967L;
… is a terrible hack to get a semi accurate time stamp from oscP5!

oscP5 is fundamentally flawed in its time stamp implementation. If you want accurate time stamps, you can’t this code, or oscP5 at all.

To send the data, I am using the VVOSC library for iOS Muse Monitor, and JavaOSC for the Android version.

I don’t code for Mac’s, but if you want some windows app code to look at, I’ve written a small test app in Visual Studio 2015 in C#.Net using the SharpOSC library.