Receiving Large Values (>256) over Bluetooth - MSB and LSB

Hello Forum,

I am reading an external 10-bit accelerometer with an Arduino Pro Mini, calculating the resultant magnitude in my C code, and then transmitting the result over Bluetooth to an Android smartphone using MIT App Inventor.

Since I am working with a 10-bit result (0-1023) I am having issues with reception on the MIT App Inventor side of the project at hand. You can see where this is going.

At first, I could not figure out what was happening. So I created a variable in the Arduino IDE and incremented that variable by 1 up to 260. I sent each incremented value from the Pro Mini to App Inventor and I saw the "hiccup" as the number passed 256...just what I suspected.

So I do see what I am getting and have a pretty good idea about how to fix the issue.

Thank you Evan Patton for the elegant solution to one part of my problem (BLE - Convert two bytes in one signed 16bit integer).

The other part of my problem is that I transmit the bytes from the Arduino to MIT App Inventor very rapidly. So on the App Inventor side, HOW TO I RECEIVE THE MBS AND LSB SEPARATELY? Can I set up an array in App Inventor so that the first byte received is let's say rxByte[0] and the second byte received is rxByte[1]? Should I do this in a list? I just do not understand how to receive the msb and lsb separately.

Once I parse those bytes into msb and lsb, I can use Evan's procedure to convert back to a larger number (>256).

I might also just divide the raw number for magnitude of acceleration by 4 prior to transmitting to MIT App inventor so that the max value transmitted never exceeds 256. This would keep the G's from the accelerometer between 0-3G's. This would be a simple solution to the problem with less resolution...but might still suffice....not my preferred solution.


It sounds like you would need

  • RegisterForShorts – Registers to receive updates when one or more 16-bit integer values from a connected BluetoothLE device are changed. Service Unique ID and Characteristic Unique ID are required. The signed parameter indicates whether the shorts should be interpreted as signed values or not when being converted into App Inventor numbers. Whenever a change is received, the ShortsReceived event will be run. Parameters :
    • serviceUuid ( text ) — The unique identifier of the service passed in the read or register call.
    • characteristicUuid ( text ) — The unique identifier of the characteristic in the read or register call.
    • signed ( boolean ) Interpret the shorts as signed (true) or unsigned (false).

call BluetoothLE1 RegisterForShortsserviceUuidcharacteristicUuidsigned


  • ShortsReceived – The ShortsReceived event is run when one or more short integer values are received from a connected Bluetooth device. Depending on the sign parameter of the last call to ReadShorts or RegisterForShorts for the given serviceUuid and characteristicUuid , the shortValues list will contain numbers ranging from -32768 to 32767 ( signed = true ) or 0 to 65535 ( signed = false ). Parameters :
    • serviceUuid ( text ) — The unique identifier of the service passed in the read or register call.
    • characteristicUuid ( text ) — The unique identifier of the characteristic in the read or register call.
    • shortValues ( list ) — A list of values read from the device. The range of each value will depend on the sign flag previously specified in the call to read or register.

when BluetoothLE1 ShortsReceived serviceUuid characteristicUuid shortValues do

Also, if your transmitting device allows it. you might first expand your MTU:

  • RequestMTU – Requests a new minimum transmission unit (MUT) for the BluetoothLE connection. This feature is only supported when both devices support Bluetooth 4.2 or higher. If the MTU is changed successfully, the MTUChanged event will be run. The default MTU is 20.This block is intended for advanced apps that need to change the size of the messages sent between the BLE devices. Most developers will not need to adjust this value. Parameters :
    • bytes ( number ) — The desired MTU size.

call BluetoothLE1 RequestMTUbytes


  • MTUChanged – The MTUChanged event is run when the two BluetoothLE devices have successfully changed their maximum transmission unit (MTU) to a different value. This event will only run in response to a call to the method block RequestMTU. Parameters :
    • bytes ( number ) — The new size, in bytes, of the new MTU.

when BluetoothLE1 MTUChanged bytes do

All text is from
blocks (1)

1 Like

Thanks ABG for your reply. I have been researching your suggestions. I realize that MIT App Inventor takes the many layers of complexity out of Bluetooth and makes it relatively easy. That being said, I have been looking for examples of RegisterForShorts and the other items that you suggested. I am not looking to copy code. I am looking to understand the code so that I can customize where needed. I cannot figure out how to obtain UUID and how to configure/structure the RegisterForShorts. Way too complicated at the current time. Is there a tutorial showing a "mixed" data stream (e.g. 2 byte ints, 1 byte ints, etc.) and how to set up Bluetooth per your suggestion?

I think that the best path for the moment is to take the 10-bit value (0-1023) that I am transmitting from the Arduino Pro Mini and divide by 4 in my Arduino IDE code (0-255) prior to transmitting to MIT App Inventor over Bluetooth. While this will take out a great deal of resolution, it will greatly reduce the complexity of my project. I can always add the complexity into my MIT App Inventor project later.

Thank You,

This board has a number of BLE tutorials by KIO4, like