Sensors2OSC

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.
Download and Installation
For Android 4.0 and up:
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:
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.
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.
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.
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.
Data received is /bt/D9-XX-XX-XX-XX-91/0x2a5b 0x031001000049713e001e36
btshows this is a Bluetooth sensorD9-XX-XX-XX-XX-91is the MAC address of the sensor, so that multiple sensors with the same characteristics can be read0x2a5bis 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
03specifies the flags (00000011in 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 71is the wheel revolutions data. The first four bytes
10 01 00 00represent cumulative wheel revolutions, reversed00 00 01 10(272in decimal)The last two bytes
49 71represents last wheel event time in 1/1024 seconds, reversed71 49(29001in decimal, equal to 28.3s).
- Bytes 1-6
- Bytes 7-10
3e 00 1e 36is the crank revolution data. The first two bytes
3e 00respresents cumulative crank revolutions, reversed00 3e(62in decimal).The last two bytes
1e 36respresents last crank event time in 1/1024 seconds, reversed36 1e(13754in decimal, equal to 13.4s).
- Bytes 7-10
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.
