# Part 2: Sending numeric data using App Inventor Bluetooth communications

Part 1 of this tutorial introduced Bluetooth communications and implemented a simple method of sending text data back and forth between two Android devices over the Bluetooth wireless link. If you are not familiar with using App Inventor’s Bluetooth component, start with Part 1.

In Part 2, a data packet concept is introduced to guide the communications between devices, and is used to send a combination of text and numeric data. This section introduces the concept of binary numbers so that you can understand why we would handle text and numbers in different ways.

This tutorial modifies the user interface of both the client and server programs introduced in Part 1. Then, blocks code is added to send text and numeric data. Numeric data is sent as binary data using special methods of the Bluetooth components.

Related:

Related:

## Brief Introduction to Binary Numbers

Numeric data is sent in binary format rather than decimal text format (e.g. a number like 237 is in decimal format). With Bluetooth, we need to decide if our numbers are 1-byte, 2-byte or 4-byte numbers – and to understand that, we need to understand a little bit about binary numbers. (This will not hurt – I promise! Or at least it will not hurt very much!)

When we write programs with numbers, we type in numbers like “42”, “9”, and “128”.  But computers do not (normally) store numbers in text form, but instead, convert them into a binary representation. This section gives an introduction to binary numbers and how they are stored, and why this is a factor in Bluetooth communications.

You do not need to know these details to use Bluetooth communications for sending text and numbers – but it is helpful to understand why App Inventor can send several different types of numbers! If you prefer to skip this section, you may do so.

When we write numbers, such as 128, we are writing them in “base 10 notation”. That is because each digit holds a value from 0 to 9 (or ten values). The number 128 is 3 digits stored as:

1 * 100 + 2 * 10 + 8

From the right and the moving to the left, there is a “ones digit”, then a “tens digit”, and then a “hundreds digit”.  Another way to look this is to say we write out numbers similar to:

hundreds     tens      ones

Another way to write the value of the digit positions is:

102     101     10

Let us look at binary notation. In binary, each digit can hold only the values 0 or 1 – we only have 2 values per digit, not ten! Indeed, we say a binary number is stored in base 2 (get it? just 2 values in base 2 whereas base 10 has 10 values per digit). A binary number might look like:

1001

representing a value of 0 or 1 at each digit position. But what does that mean in terms of a number value? It means instead of having position values like 100s, 10s and 1s, we have position values of:

16     8     4     2     1

which corresponds to

24     23     22     21     20

In binary notation, each digit has only the value 0 or 1 (not the 0 to 9 of base 10).  To keep this simple, consider the number 9 (in good old base 10). Writing this in binary, we get the digits:

1001

Remember – each digit position holds only a value of 0 or 1, which is then multiplied by the digit’s place. Just as we multiplied the “1” in 128 by one hundred and the “2” by ten, binary numbers have their own multipliers for each digit’s place. For the above number, the multipliers are:

8     4     2     1

Or

1 * 8 + 0 * 4 + 0 * 2 + 1 * 1

Because we have two values per digit position (0 or 1), we say this is “Base 2” (versus base 10 which had 10 possible values per digit position).

Numbers that we write in text are converted into the binary form for processing on computers [1]. A group of 8 binary digits – also known as 8 bits – is called a byte. The value 1000 0010 represents 8 bits stored in one byte of data.

Depending on the range of values stored, numbers are typically stored as 1-, 2- or 4-byte binary values. A 2-byte number has 16 bits and a 4-byte number as 32 bits.

• 1 byte: for values in the range of 0 to 255, or -128 to +127
• 2 bytes: for values in the range of 0 to 65535 or -32768 to +32767
• 4 bytes: for values in the range of 0 to 4294967295 or -2147483648 to +2147483647

For negative numbers, one of the bits is reserved for the sign of the value which leaves one less bit for the value, as shown above.

Key Point for Bluetooth in App Inventor

App Inventor’s Bluetooth component supports the sending and receiving of binary values. But to use the feature, you need to know the range of values the app will send – and then specify whether the app should use 1-byte, 2-bytes or 4-bytes for the numeric value per the above table.

Floating point or “real” numbers?

The numbers in the preceding example are called “integers” – they do not store a decimal point. How would you represent a value like 3.14159 or 127.35?

Such values are called “real” or “floating point” numbers (because the decimal point can appear at any location). There are several ways computers can store floating point numbers but a description of those details is beyond what we need to understand Bluetooth communications.

Binary Numbers Footnote

[1] There is another type of numeric storage called binary coded decimal or BCD. It is sometimes used in business and accounting applications. BCD numbers store each digit in binary by converting the values 0 to 10 to a 4-bit binary number. A number like “128” would be stored using 3 BCD digits, where each digit is stored in binary, like this:

1        2        8

0001 0010 1000

You do not need to know about BCD to use Bluetooth – this is just to illustrate that there are other ways that numbers may be stored in computing systems.

## Designer View: Bluetooth Server and Client Apps

The purpose of this app is to demonstrate the sending of binary numbers (versus just text values). The Server app is modified to send binary numbers and the Client app is modified to receive those numbers.  (Optionally, the Client app could also be modified to send binary numbers and the Server could be modified to receive binary numbers. Both sides can process binary numbers.)

The user interface of the Server Demo app shown in Part 1 is modified as shown below, to send either text or to send numeric data. For the full implementation details, download the source code, at the end of this blog post.

The Client Demo app is slightly modified to present two lines for the incoming data: (1) a display of the incoming command, and (2) the data received (either text or numeric values go here). The purpose of the command value will be explained in the next section.

## The Blocks Code

In Part 1 of this series, our sample Bluetooth program sent and received only text messages.

In Part 2, our sample program can send both text and numbers. The sender needs to notify the receiver that the data being sent is either a text value or a number. Specifically, the sender needs to indicate whether the data is text, a 1-byte number, a 2-byte number or a 4-byte number.

The type of the data being sent is included in the data stream as the first byte of data. We call this the command byte (as in “you are commanded to receive one of the following”).

The command byte has one of the following values to indicate the type of data being sent:

Command Bytes
1=text string
2 = 2 byte number
3 = 4 byte number
4 = 1 byte number

The command byte is sent before the data as shown by the blocks in the Send Text button event handler:
Think of the data transmission as a data packet that contains both a command byte and a package of data.

The Send Numeric data button is similar – but a bit more complex!  While we could put all numeric values into a 4-byte value, why send extra bytes if we do not need to?

The event handler looks at the value of the number, determines in which the range the value lies, and then uses the 1-byte, 2-byte- or 4-byte Bluetooth sending methods, as required for the number:

In the Client app, the bulk of the code changes are in the Timer event handler. At each timer “tick”, the app checks to see if data is available over Bluetooth. If data is available, the first byte of the incoming data is read using ReceiveSigned1ByteNumber.  This is the command byte. Depending on the value of the command – 1, 2, 3 or 4 – the appropriate Bluetooth method is used to read the next bytes of data as either a number or as a text value.

The methods ReceivedSigned1ByteNumber, ReceiveSigned2ByteNumber, and ReceivedSigned4ByteNumber correspond to the 1-byte, 2-byte- and 4-byte binary numeric data types.

Key Features Shown

• Introduction to binary data formats
• The concept of 1-, 2,  and 4-byte numeric values
• The concept of integer and floating point numbers
• Use of the App Inventor Bluetooth features for sending and receiving numeric data
• The concept of the command byte to specify the type of data sent

Downloads

• BTClient2.aia App Inventor source file (App Inventor source code files have the filename extension .aia)
• BTServer2.aia App Inventor source file
• Download the source code to your computer. Then, in App Inventor, go to the Projects menu and select “Import project (.aia) from my computer…”
• Remember – you need two separate Android devices in order to run and test the Bluetooth sample programs!

## E-Books and Printed Books

If you find these tutorials helpful (I hope you do!) please take a look at my books on App Inventor. To learn more about the books and where to get them (they are inexpensive) please see my App Inventor Books page.

• App Inventor 2 Introduction (Volume 1 e-book)
Step-by-step guide to easy Android programming
• App Inventor 2 Advanced Concepts (Volume 2 e-book)
Step-by-step guide to Advanced features including TinyDB
• App Inventor 2 Databases and Files (Volume 3 e-book)
Step-by-step TinyDB, TinyWebDB, Fusion Tables and Files
• App Inventor 2 Graphics, Animation and Charts (Volume 4 e-book and printed book)
Step-by-step guide to graphics, animation and charts

Thank you for visiting! — Ed

Please Share on Social Media

Please click on the buttons below this post to share with your friends on Facebook or other social media.

If you are not already following this blog, click on the following links to like on Facebook, add to your Google+ circles or follow on Twitter or in your RSS news reader. Thank you for visiting!

## 25 thoughts on “Part 2: Sending numeric data using App Inventor Bluetooth communications”

1. bala says:

can you say how to send the float value to the paired bluetooth device?
while i try to send the value it shows as “could not decode as integer”

Like

1. Edward M says:

I am pretty sure that Bluetooth in App Inventor sends only integer values, not floating point values. But there are two possible solutions you could try.

One is to just send the value as text. This, however, requires a conversion on each end – from a floating point number to text, and then from text to floating point. App Inventor makes this easy, if App Inventor is used on both ends – just assign a floating point value to a text variable and the conversion should happen automatically.

The other way is to convert a floating value to a 4-byte long value. For example, let’s say we wanted to send a value such as 3.14.

Send this as a large integer 314. Start with 3.14, multiply by 100 to give 314. Send the value 314, and then divide by 100 on the other end. This is known as “fixed point” representation.

This method, obviously, does not work very extremely large floating point numbers, nor does it work for all potential decimal places unless extra code is added. Example: 3.14 versus 31.4 need to be handled differently.

Like

2. Carlos says:

Hey! I wonder if anyone can help me with my problem. I am trying to finish this project as my thesis but after a month trying different ways to solve it, I really don’t know what else to do now.

I am building my app with App inventor 2 and with my arduino. I have a gas sensor which via bluetooth sends the numbers to the app and whenever the value of the gas increases the phone has to give a notification and to speak some text.

My problem is that I am trying different ways of receiving the value and I can not find the correct way to receive the numbers and then with a math block is needed to compare if that value is higher or lower than another value.

So I will explain what I have and let’s see if it helps you to understand what I am doing wrong:
Inside the timer it checks first if the bluetooth is connected, if so, set variable Sensor to Call Bluetooth BytesAvailableToReceive. And if button On is not enabled, set value text to get global Sensor.
And right after that it comes the comparison, if get global Sensor is higher or equal than 700 then set Color Alarm red, call notification and call VoiceAlert.

And here I just receive a number 1 on my label value. I have also tried different ways of receiving the value but none of them has worked yet, so if you could please help me to solve this I would really appreciate it.

Thank you in advance for your help.

Carlos.

Like

1. Edward M says:

Have you tried sending data only from the Arduino to the Android device, independent of your application code? By splitting out and testing the BT communications link by itself, this might help to isolate whatever is causing this problem.

Ed

Like

3. Alan says:

Hello there !
Is it possible for a sensor to control an android apps using bluetooth ?

Like

1. Edward M says:

I think you mean, an external sensor? Yes, if the sensor can speak classic Bluetooth, then App Inventor code could talk with that sensor device.

One way to do that is to use an external microcontroller and a serial Bluetooth adapter connected to the controller. Use the microcontroller to monitor the sensor readings and then send those to the Android device over the Bluetooth link.

Be aware that App Inventor does not appear to support Bluetooth Low Energy (LE) devices. Bluetooth LE is becoming a popular choice for sensor networks. If you can stick with the older Bluetooth “classic”, you can use App Inventor.

Ed

Like

4. Maria says:

Hi! Can I put the send button for texts and numbers together?

Like

1. Edward M says:

Sure, I do not see why not.

Like

5. Yohan says:

Hi Edward,

Thank you so much for your blog. It is very helpful. I’m just wondering, is there a way to send simple data through bluetooth by converting to either numeric or text data, and then the recipient device would convert it back to some useful way. I’m really interested in sending stuff other than just “texting”. Suppose that the app lets someone choose a fixed number of choices and the type of choices. Could the recipient get that info and translate it to a fixed number of choices automatically?

Like

1. Edward M says:

Yes, the actual transmission of the numeric values is in numeric or binary format when using the features to send 1, 2 or 4 byte numbers (see http://appinventor.pevest.com/?p=569).

This separate tutorial on using App Inventor Bluetooth to communicate with an Arduino microcontroller does something similar to what you are seeking: http://appinventor.pevest.com/?p=718

That code sends a “command” and a “parameter” byte between the Android device and the Arduino board. That same code structure could be set up for App Inventor (and I may put that on my to do list as it would be very useful for Android to Android BT communications).

Ed

Like

6. ed says:

Just a question. I send data from an Andoid to an arduino and that doesnt give any problems. However, I als want to send a single byte from the Arduino to my Android.I do that by sending a command from my Android to the Arduino, that then reacts by sending that single byte.
i then use the readonebyte command to read that byte. However, it also reads previous Serial.print text that have been send by the Arduino. I use a command to flush the serial buffer but that doesnt seem to help.
So my question is, how do i transfer 1 specific byte from Arduino to Android? The send is with Serial.write, but how do i isolate that specific byte upon receipt?

Like

1. It sounds like a byte or bytes are being left in the input buffer. That could happen if, for example, the code checks
if get bytesAvailable> 0 then
Received1ByteNumber

BUT, suppose for whatever reason, there is an extra character in the incoming receive buffer. If that happens, then we have only the first of whatever bytes are there. I don’t know why there would be extra character(s) there, but once its is read, it should be cleared out.

To clear the input buffer, you could do something like
while get bytesAvailable > 0
getbyte = Received1ByteNumber

If there were 4 bytes in the input buffer, this should read them all out of the incoming input so that none are remaining. This is just an idea to try as I do not know why, specifically, you might have more than 1 byte in the input buffer – or even if that is the case.

Ed

Like

7. kevin says:

Could you tell me bluetooth device how to send and receive 6-bytes (hex) data?
I try to send but it show as “could not decode as integer”

Like

1. Hi Kevin,

MIT App Inventor only supports the transmission, over Bluetooth, of 1, 2 or 4-byte binary values.

I recommend splitting your 6-byte binary value into a 2-byte value and a 4-byte value.

I do not know what format your 6-byte value is, to begin with. If it is something that is already available as individual bytes, then you could just send the six bytes, one-byte at at time.

If the 6-byte value is a number, then you may want to split it up. App Inventor is not great for this because App Inventor uses floating point numbers, not integer. Many programming languages have an easy way to shift the bits in a number to the left or right – we could take the 6-byte value and shift it 32 bits to the right, leaving us with just the 16 bits in the left most two bytes of the 6-byte value. (That is a bit of a head full of text – drawing it as 6 bytes and then shifting that 4 bytes to the right will illustrate the idea.)

This leaves us with another way to try and split it up, by using division.

Let’s say we have a 16-bit numeric value (in the range of 0 to 65,535, unsigned). To separate this in to two bytes, we can divide this number by 256 (2^8 or the largest number we can represent with 8 bits).

Let’s say we have 40,000. Divide this by 256 to give a value of 156.25. This tells us we have 156 (in base 10, but really it would be in binary) in the left byte and 64 in the right byte (64 is 0.25 times 256). By doing this, we’ve split the 2-byte value into separate individual one byte values.

We can do this with a six byte value too. Let’s say we have a big number that is larger than 2^32 (about 2 billion) and want to separate out the two left most bytes. We’d take the starting value, let’s call it X, and divide by 2^32:

rounded off of X / (2^32) is going to be the left most two bytes.
the remainder of X / (2^32) needs to be remultiplied by 2^32, giving us the numeric value of the right most 4 bytes.

Their are potential problems with this approach. Floating point numeric values may end up rounding off bits that are important, and we’d lose some of the binary data. And also, we need to make sure that when we round() we are using something like the floor() function to just chop off the parts to the right of the decimal point (not round, which rounds up or down).

Those are some ideas to work with. Good luck

UPDATE: Another idea that may work far better in App Inventor. In the Math blocks section using the “convert number base 10 to hex block”. This would convert, potentially, a large numeric value into a text string of hex digits. Then you can text string block functions to extract each byte from the text and send it across the BT link as byte sized hex values.

Ed

Like

1. kevin says:

Hi Edward,
Thanks you very much!

Like

8. Hi Edward. Probbably you can help to solve my problem.
I’m trying to send a set o decimals devided by “;” from Arduino to AppInventor. like 123;2345;200;500 some time AppInventor get full pack, but some time occasionaly split for few packs like “123;234” and “5;200;500” or maybe “123;” “2345;200;50” and “0” or any other way… It’s never missing any chars but some times split the pack — How to fix the problem?

Like

1. I suspect it is a timing issue in how App Inventor transmits the data. Only part of the data has been received or read when the text string is returned to your app. I suspected this could happen when I wrote the code but had not exhaustively testing all possibilities.

What you might do (or I might do at some point) is add a layer of code to this routine so that we add an “end of data” character. For example, let’s set our end of data character to “~”.

We’d transmit our data as “123;2345;200;500~”.

Then, when receiving the incoming data, we would continue to read characters until receiving the “~” character. If this comes in separate pieces, such as “123;2345;” and “200;500~”, we would continue to read incoming data and copy everything we’ve read into a single text string, until we receive the “~” character.

We would then combine the two pieces into one piece.

One way to do this would be to create a new procedure. I will give an example in pseudo code, something like this:

ReadBTData(String DataRead)
FullTextString =””
Repeat
ReadBT (String IncomingData, EndOfData)
FullTextString = FullTextString + IncomingData
Until EndOfData is true

—-
ReadBT would be the existing read data from Bluetooth code, but have it check to see if a “~” (or other end of data character you select) has been received.
If the end of data character was received, then it sets the EndOfData value to True so that we know we’ve read everything.

Basically, this is a procedure that just keeps reading incoming data until we know for sure that we’ve reached the end of the full data sent to us.

Ed

Like

9. seghier says:

hello
i have question ; if i write number like : 1975 and i want separate “19” and “75”
how i can do that with appinventor?

Like

1. There are two ways to split a number like that.

If you take the number 1975 and divide it by 100, you get 19.75.

If you use the Math function “floor”, the “floor” of 19.75 is 19 (it rounds the number down to the integer value) (but see this link http://www.exploringbinary.com/numbers-in-app-inventor-are-stored-as-floating-point/ for examples of where floating point numbers and floor might not give you what you want, although its because of decimal/binary conversion issues)

You can get the fraction part (.75) by subtracting the original (19.75) minus the floor (19.75) giving you .75. Multiple that result by 100 and you’ve got 75.

Now you have both the 19 and the 75.

Another way is to treat the number 1975 as a text value and use the segment text function to extract the first two characters and then the second two characters.

App Inventor automatically converts numbers into text format so you could use segment “1975”, 1, 2 to get the first 2 characters, and segment “1975”,3,2 to get the last 2 characters. While the result is in text, AI will also convert those back to numbers if used in an equation.

Ed

Like

This site uses Akismet to reduce spam. Learn how your comment data is processed.