Skip
to content

Arduino++

Arduino, CNC, software and other ramblings

Menu

Search

About

Tools
and Utilities

Geek
Humour

Contributing

Search for:

Search

Reliable Bluetooth LE Comms Between Arduino and MIT App
Inventor (AI2)

On May
23, 2017July
5, 2017 By marco_cIn AI2, algorithm, App Inventor, Arduino, software

In
a previous post, I looked at
creating reliable communications using Classic Bluetooth. While that approach
works well, and is a reliable way to connect devices, there may be circumstances
when a Bluetooth Low Energy (BLE) connection is preferable.

As it turns out, Bluetooth and BLE are about as similar as apples and
oranges. The change in transmission protocol technology is more than a trivial
change in the code and its structure.

In this article I explore the difference between BT and BLE and how the
previous BT AI2 app needs to be adapted.

This article does not repeat information contained in its predecessor, so it
is advisable to read that first for a complete picture.

Bluetooth and Bluetooth Low Energy

It is important to understand that BLE is not at all backwards compatible
with older versions of Bluetooth. For the purposes of this article, I will
highlight the differences that are important in this application.

Bluetooth Low Energy (aka BLE, Bluetooth 4.0, Bluetooth Smart) is the most
recent Bluetooth technology standard. Its main use is for applications that
transfer small data packets at relatively low speed using low power
consumption.

With BT Classic, a device must be paired in order to establish
communications. With BLE there are a number of differences to the connection
process:

the target device must be advertising that it is connectable when
a connection is required.

a connection can be made without pairing. Pairing is an optional security
mode only.

a connection does not have to be made in order to get data from a remote
device.

The BLE specification allows a device to take one of two roles, depending on
the device’s capabilities. The two types are central or
peripheral, and client or
server.

Central vs Peripheral. The role of the central device is
similar the ‘master’ in BT Classic. The central device is responsible for
searching for and establishing a connection with one or more peripheral
devices.
The role of the peripheral device is similar to ‘slave’ in BT
Classic. The peripheral device advertises whether it is connectable, and the
services it might provide, so that the central device can decide if it should
connect to the peripheral device.

Client vs Server. The client and server roles relate
to data ownership and transmission relationship in a BLE network. Typically,
the central device will take the client role – requesting and sending data
from and to one or more server devices. Peripheral devices typically take on
the role of server, keeping a database of attributes a connected client can
write to, read or subscribe to receive changes.

This specificity of roles means that the BLE interface is not as transparent
to the application as a BT Classic one might be, as each device’s available data
must be accessed in a specific way.

Generic
Attribute Profiles (GATT Profiles) define the hierarchical structure of the
server’s database. A profile is made up of a list of Services,
each of which may contain one or more Characteristics. This web site has a list of the officially adopted GATT
profiles, although manufacturers may create their own.

A service is used to group a category of characteristics and all
characteristics must belong to a service. A characteristic represents one
client accessible data attribute. Each characteristic stores a single value
and has associated permissions such as read, write, and notify.

Services and characteristics are all assigned and referenced using a
Universally Unique IDentifier (UUID).

In
this application, the commonly available HM-10 BLE module is used at the Arduino
end of the link. The standard module firmware exposes a BLE peripheral with
a proprietary connectivity service (UUID: 0000ffe0-0000-1000-8000-00805f9b34fb)
that enables bidirectional communication between the module and any central
device connected to it. The service defines a single characteristic (UUID:
0000ffe1-0000-1000-8000-00805f9b34fb) that stores 20 bytes of unformatted
data. When the central device wants to send data to the module, it writes
the characteristic with the desired content. When the module wants to send data,
it sends a notification to the central device.

We now have enough information to modify the original BT Android App for BLE
applications.

AI2 Support for BLE

The Connectivity modules in AI2 include a BT Classic Server and Client
object. The BLE object is an extension to the standard modules that must be
loaded into the AI2 interface. The BluetoothLE extension and instructions for
installation are found here.

Click to
enlarge

There is a bug in the permissions of the BLE object that requires the BT
Client to also be loaded in each Application, even if it is not used. This bug
and the solution are described here.

The BLE module works differently from the BT module – most of the BLE
functionality is implemented as event callbacks – requiring structural as well
as syntax changes to the previously implemented BT code.

The Android AI2 BLE interface code (shown at right) is split into a number of
functional blocks triggered from application events.

Screen Initialization

The initialization process is similar to the previous code, with the important
addition of the UUID’s as global variables. As mentioned, the BT client needs to
be loaded, so we may as well continue using this to detect if the BT hardware is
not started.

Discovering and Connecting to a BLE Device

The first significant difference in code is in how the devices are selected.
As the BT devices are not paired to the BT server, they will be discovered over
a period of time once Scanning is started.

This discovery process means that devices will become progressively
available, changing how the user interface is implemented. The
ListPicker object does not seem to handle changes once it is displayed,
so it is replaced by a ListView object. As each new device is
discovered, the ListView is cleared and refreshed from the
DeviceFound callback event.

There may also not be any devices to discover, so ‘Cancel’ functionality must
be added to allow the user to abort the discovery process.

Once a selection is made, the App stops device Scanning, separates
the IP address and connection name from the ListView selection, and
starts connecting to the device using the IP address.

When a connection is confirmed through the Connected event, the
App requests to be notified when there are any changes to the string data
associated with the Service/Characteristic, setting up future data change events
to be captured.

Sending Request Messages

Sending message to the Arduino application is essentially similar to the previous code.

However, the Timeout timer is set for the full timeout rather than
increments. The previous BT module was invoked in a ‘polling’ mode, using the
timer event to check for available characters. The BLE module data receive is
handled via callback events. The timer is therefore is used to detect the full
timeout time.

Handling Response Messages

The message receive portion of the BLE app is also different from the previous code.

The timeout is handled directly by a timer (as explained above).

The receive Finite State Machine does not run off the timer but is now part
of the StringValueChange event. The code is essentially equivalent to
the BT code in the polling timer event with requisite changes for the changed
data source.

Share this:

Click to share on Twitter (Opens in new
window)

Click to share on Facebook (Opens in new
window)

Like this:

Like Loading...

Related

AI2algorithmBLEBluetooth LEBluetooth Low EnergyFSMsoftware

Post navigation

Previous

Reliable Bluetooth Comms Between Arduino and MIT App
Inventor (AI2)

Next

PID Control Experiment – Making the
Testing Rig

21 thoughts on “Reliable Bluetooth LE Comms
Between Arduino and MIT App Inventor (AI2)”

oldgeebee

Hi, many thanks for such an informative tutorial. However, when I try to
download the extension using your link, I get a zip file with various jar
files but no aix file. Trying to add the extension from my project fails
because it doesn’t recognise any of the files in the zip file and needs the
aix file. Any thoughts on where I’m going wrong?

LikeLike

November 1, 2018 at
01:42 Reply

marco_c

There are 2 files at the download shown as BluetoothLE.aix and
BluetoothLE-Source.zip. I assume you are taking the source file (which would
be java files) and not the aix file.

LikeLike

November 1, 2018 at
16:17 Reply

oldgeebee

Hi Marco, many thanks for the reply. When I click on the .aix download
I get the zip file – the source file link doesn’t work (not underlined and
nothing happens when I click on it). Sounds like the link on the MIT site
is pointing to the wrong download. Is there a way to generate the aix file
from the source code?

LikeLike

November 1, 2018 at
19:21

marco_c

Not sure what to say. The file I get when the aix file is downloaded is
called edu.mit.appinventor.ble.aix. This does seem to be a zip file
(browsable with 7-Zip), but it is simply a package that you install with
AI2 for it to know about BLE. The instructions are on the web site the
where the package is sourced.

LikeLike

November 2, 2018 at
09:17

oldgeebee

Hi Marco,
thanks for taking the time to reply. Just to close the
loop, I posted the issue on the AI2 forum and got pointed to another link
for the aix file on the BLE documentation page which downloaded and
installed OK. I also contacted the MIT AI2 team via their problem report
to let them know (IMHO) that they have a broken link of the Extensions
download page.
Now back to studying your BLE tutorial and getting it to
work in my App!

LikeLike

November 3, 2018 at
18:42

CL

Hi, May I know if it is possible to connect, send and transmit data from
MIT app to Arduino using Bluno Nano (BT4.0(BLE))? Thank you in advance!

LikeLike

October 16, 2018 at
04:55 Reply

marco_c

I have not used this hardware but I would think this should be
possible.

LikeLike

October 16, 2018 at
07:52 Reply

Eduardo Mendez

Hi Marco!
Do you have any project that I can use to modify from “App
Inventor” (only blocks to connect via Bluetooth LE) to connect my own
application and control my Arduino Uno through my bluetooth module HC-08? I do
not know much about programming in “App Inventor”

LikeLike

January 31, 2018 at
05:31 Reply

marco_c

I have not used the HC-08, so I cannot give you much advice as I have no
knowledge of this hardware. If you have never programmed in AI2 then you
should try the tutorials they have on the AI2 site to get the basics, and
then try something harder (like BLE comms) after that.
I have code for a
clock project that uses the Arduino and BT (not BLE) that can be used as a
starting point for learning BT and BLE if you want to access it at https://arduinoplusplus.wordpress.com/2017/09/27/neopixel-led-analog-clock-part-1-hardware-and-specifications/

LikeLike

January 31, 2018 at
06:38 Reply

iotlearner

hello!

i am trying to follow the example from this video on esp32 (https://www.youtube.com/watch?v=osneajf7Xkg&lc
arduino: https://github.com/SensorsIot/Bluetooth-BLE-on-Arduino-IDE/blob/master/Polar_H7_Sensor/Polar_H7_Sensor.ino
this emulates a ble hr monitor)
on the appinventor side i am following this
example http://appinventor.mit.edu/explore/blogs/karen/2016/08/heart.html

i want to experiment with sending and receiving data between the two…but
looks like the appinventor can’t read the notify values?

any help?

LikeLike

December 25, 2017 at
06:24 Reply

marco_c

I would just get the app inventor example working first as-is before
making any changes to the code. Once you have a working base then make small
modifications from there and test as you go along. This way you know the
last thing you changed caused the problem.

LikeLike

December 25, 2017 at
09:10 Reply

iotlearner

Thanks for responding. looks like the hr monitor used an old version of
ble extension. I used some other example and it is working now. Difficulty
is how to separate different characteristics from the received bytes,
otherwise it is a long string.

LikeLike

December 25, 2017 at
21:08

Leon Young

Hi Marco,
Thanks for post this! I’m trying to get BLE on App Inventor to
communicate reliably with my device. Do you have an .aia file of the app
inventor blocks available somewhere?

Leon

LikeLike

December 6, 2017 at
11:26 Reply

marco_c

The final code was for a project where I was getting paid to do the work,
so I can’t put that online as a complete .aia file. You have the most
important parts in the blog post.

LikeLike

December 6, 2017 at
13:32 Reply

Paco Camacho

Hi Marco, Thanks for this interesting and didactic tutorial.

LikeLike

July 7, 2017 at 03:27
Reply

Jaldomir Da Silva Filho

Thank you again Marco. Now, only one more thing: the link for large and
complete blocks picture is broken, or don’t exists, so the procedures you have
created isn’t available. Could you recheck the link? Thanks again, and
congratulations for this simple but outstanding tutorial.

LikeLike

July 5, 2017 at 18:35
Reply

marco_c

Fixed.

LikeLike

July 5, 2017 at 19:52
Reply

jaldomir

When I found this article by title search, I assume “Reliable Bluetooth LE
Comms Between Arduino and MIT App Inventor (AI2)” is about the two code parts,
MIT App Inventor AND Arduino sketch.
So, where is the Arduino sketch?

LikeLike

July 1, 2017 at 14:58
Reply

marco_c

Good question. The article is meant to show how to implement the AI2 end
of the protocol defined in the previous article at https://arduinoplusplus.wordpress.com/2017/05/10/reliable-bluetooth-data-transfer-between-arduino-and-mit-app-inventor-ai2/#more-6619.
The Arduino end is really up to the reader to implement, as this would
generally be the easier end for an Arduino programmer.
An example of one
in my own code can be found in the Parola_Bluetooth_Control example of the
Parola library at https://github.com/MajicDesigns/MD_Parola.

Hope this helps.

LikeLike

July 1, 2017 at 17:08
Reply

Jaldomir da Silva Filho

Hi Marco.Thanks a lot. Was just an case to tell that the serial
communication from arduino throught BLE is inserted in the UUID.

LikeLike

July 3, 2017 at
06:08

marco_c

No UUIDs required at the Arduino end. The firmware in the interface
module makes it work very similarly to the non-BLE modules for simple
serial communications, which really simplifies the Arduino code for that
application.

LikeLiked by 1 person

July 3, 2017 at
09:57

Leave a Reply Cancel reply

Enter your
comment here...

Fill in your details below or click an icon to log in:

Email
(required) (Address never
made public)

Name
(required)

Website

You are
commenting using your WordPress.com account.
( Log Out /
Change )

You are
commenting using your Google account.
( Log Out /
Change )

You are
commenting using your Twitter account.
( Log Out /
Change )

You are
commenting using your Facebook account.
( Log Out /
Change )

Cancel

Connecting to %s

Notify me of new
comments via email.

Notify
me of new posts via email.

Follow
Arduino++ on WordPress.com

Search for:

Search

Recent Ramblings

A
simple Command Line Interface (CLI) December
7, 2019

Easy
Neopixel bitmaps using Excel November 16, 2019

Making
noise with a SN76489 Digital Sound Generator – Part 3
November 3, 2019

Making
noise with a SN76489 Digital Sound Generator – Part 2
October 19, 2019

Making
noise with a SN76489 Digital Sound Generator – Part 1
October 5,
2019

Tags

advice
algorithm
animation
Arduino
Bluetooth
BT CNC
electronics
ESPEasy
Finite
State Machine FSM
hardware
Home
Automation IoT
IR IR
remote LED
LED
Matrix library
MAX7219
MD_Parola
Parola
ParolaAZ
PCB ShapeOko
software
Sonoff
Wifi
Wifi
relay woodwork

MyLinks

My Arduino libraries

Parola Arduino Forum

Parola Software libraries

Archived Ramblings

December
2019 (1)

November
2019 (2)

October
2019 (2)

September
2019 (1)

August
2019 (2)

July
2019 (2)

June
2019 (2)

May
2019 (1)

April
2019 (2)

March
2019 (1)

February
2019 (1)

December
2018 (2)

November
2018 (1)

October
2018 (1)

September
2018 (1)

August
2018 (2)

July
2018 (2)

June
2018 (2)

May
2018 (2)

April
2018 (2)

March
2018 (2)

February
2018 (2)

January
2018 (2)

December
2017 (1)

October
2017 (2)

September
2017 (2)

August
2017 (1)

July
2017 (2)

June
2017 (2)

May
2017 (3)

April
2017 (2)

March
2017 (2)

February
2017 (2)

January
2017 (2)

December
2016 (2)

November
2016 (2)

September
2016 (1)

August
2016 (3)

July
2016 (2)

June
2016 (2)

May
2016 (2)

April
2016 (3)

March
2016 (2)

February
2016 (2)

January
2016 (1)

December
2015 (2)

November
2015 (3)

September
2015 (5)

August
2015 (2)

July
2015 (5)

June
2015 (3)

Categories

AI2
(2)

algorithm
(30)

App
Inventor (2)

Arduino
(84)

ATTiny
(1)

CNC
(5)

electronics
(31)

ESPEasy
(4)

hardware
(53)

Home
Automation (6)

Domoticz
(3)

LCD
display (3)

Parola
(13)

PCB
(8)

Raspberry
Pi (1)

ShapeOko
(7)

software
(71)

Uncategorized
(1)

woodworking
(5)

Follow
Arduino++ on WordPress.com

Powered by WordPress.com.

Add your thoughts here... (optional)
Post
to

Cancel

Privacy & Cookies: This site uses cookies. By continuing to use this
website, you agree to their use.
To find out more, including how to control
cookies, see here: Cookie
Policy

%d bloggers like this: