Sensors2OSC

/images/osc/osc_header.png

This is an Android app for sending sensor data via Open Sound Control (OSC).

Open Sound Control (OSC) is a protocol for networking sound synthesizers, computers, and other multimedia devices for purposes such as musical performance or Show control. Bringing the benefits of modern networking technology to the world of electronic musical instruments, OSC's advantages include interoperability, accuracy, flexibility, and enhanced organization and documentation.

Wikipedia

Download and Installation

For Android 4.0 and up:

get_from_fdroid

For Android versions from 2.3 up to 3.2.6, Sensors2OSC 0.3.0 can be downloaded as APK for installation. Sorry for being a debug build, but this build cannot be reproduced with modern tools.

Basics

Depending on your Android version and your device, a number of sensors are available for apps to read. This app enables you to selectively send this data as float over OSC to any receiver.

Use the settings dialog to set the host, that should receive the data, as well as the UDP port, that the receiver is listening to. The rate of sensor readings is settable too.

The switches on the main screen are used to toggle sending of data.

The main switch toggles sending the data as a whole. Only when this switch is set to "on" will the app send data over the network.

Different sensors have different number of ranges and different number of values. Each sensor type has a corresponding OSC address, that is shown to the right of the sensor name.

If a sensor has only float values, then the values will be sent as: /<osc_prefix> ,<n times f> <values separated by space>

Example for one dimensional data: /proximity ,f 9.

Example for three dimensional data: /acceleration ,fff 0.001 -0.001 9.790.

The numerical values all correspond to real physical values, for details about these and possible ranges, see the Android developer documentation.

Tapping on multitouch while sending data is enabled opens an area for sending touch data. Each finger touching the phone will send a three dimensional data corresponding to the number of the finger, plus Cartesian coordinates, normalized to a range of 0 to 1, starting from bottom left. Lifting the finger will result in a message of -1 on both axes. Indexing starts at 0. The receiver address is /touch

Bluetooth data is sent as a byte array. Available sensors can implement multiple profiles, and if sending is selected, the raw byte array of the sensor readings is sent as an OSC blob with the format /bt/[MAC address of sensor]/[profile id] ,b [byte array].

Profile ids and interpretation of the data can be found at the official Bluetooth website:

Usage Examples

You can download examples in different programming languages from the code repository.

An example of a working Pd patch that displays typical sensors for most devices and multi-touch:

/images/osc/osc-patch_full.thumbnail.png

The phone is lying flat on the desk, so only the gravity is showing as the acceleration value. Shaking the phone violently will show much higher absolute values. NB: negative values are possible as well.

/images/osc/osc-patch_sensors.thumbnail.png

Three fingers are still touching the phone. Values range from 0 to 1. Finger 1 has been lifted from the phone, so it reports both X and Y as -1. There were never more than 4 fingers on the multi-touch page, so touch5 and higher show constant 0. NB: finger 1 has been lifted, but the other touches are not renumbered.

/images/osc/osc-patch_touch.thumbnail.png

Location data is sent as a 5 dimensional array: latitude, longitude, altitude, bearing and accuracy. You can guess my location from the data here. Additionally, a bluetooth sensor is connected to the phone and data is read as well.

/images/osc/osc-patch_bt_location.thumbnail.png

As byte arrays are not really a data type in Pd, the byte array is shown as the number of elements followed by numerical values of each byte. Here we have a byte array with a length of 11 from a cycling data sensor. See below on how to interpret the data.

Interpretation of Bluetooth Data

For Bluetooth data the format is dependant on the sensor type, but most sensor specifications start with a byte to show the measurements present in the data, and then one or more measurements of possibly different lengths.

This example uses a sensor for cycling data. Bytes are written as hexadecimal data.

/images/osc/bt-data.thumbnail.png

Data received is /bt/D9-XX-XX-XX-XX-91/0x2a5b 0x031001000049713e001e36

  • bt shows this is a Bluetooth sensor

  • D9-XX-XX-XX-XX-91 is the MAC address of the sensor, so that multiple sensors with the same characteristics can be read

  • 0x2a5b is the profile id. According to the "assigned numbers" PDF this is "CSC Measurement".

CSC measurement is defined in section 3.70 of the "GATT specification supplement". For integer data, the bytes first have to be reversed to get the value.

  • Byte 0 03 specifies the flags (00000011 in binary). Bit 0 and 1 are set, so both wheel revolution and crank revolution data are present in the rest of the byte array.

  • Bytes 1-6 10 01 00 00 49 71 is the wheel revolutions data.
    • The first four bytes 10 01 00 00 represent cumulative wheel revolutions, reversed 00 00 01 10 (272 in decimal)

    • The last two bytes 49 71 represents last wheel event time in 1/1024 seconds, reversed 71 49 (29001 in decimal, equal to 28.3s).

  • Bytes 7-10 3e 00 1e 36 is the crank revolution data.
    • The first two bytes 3e 00 respresents cumulative crank revolutions, reversed 00 3e (62 in decimal).

    • The last two bytes 1e 36 respresents last crank event time in 1/1024 seconds, reversed 36 1e (13754 in decimal, equal to 13.4s).

Talk at Linux Audio Conference 2025

At the Linux Audio Conference 2025 in Lyon I gave a presentation about Sensors2OSC, and talked about availability usability of different sensors on Android devices and gave a demonstration.

Get Involved

Development is done over at Codeberg.

If you want to report a bug, please first have a look at the issue tracker. If you already have a Codeberg account, please report your bug there.

You can also send bug reports or feature requests to osc-bugs@sensors2.org. Please try to be as specific about your problem as possible.

If you want to help with translating: Translation is currently coordinated via weblate.

translate