Success with Android <--> Arduino over bluetooth

Community Exhibition / Gallery
1

Well! That took a bit of doing!

I have managed to get Android and Arduino talking to each other over bluetooth. Steep learning curve on the Android side of the fence, but got there eventually.

The goal is to dispense with having to wire up LCDs, potentiometers and miscellaneous hardware in order to control and get data back from an arduino project. To provide a user interface, in other words.

One approach is to set up a web server on the Arduino and generating HTML, but this type of thing is a whole slab of coding that you don't want to be doing on an Arduino.

Bluetooth seems IMO to be an appropriate tool for the job. Close range, not super fast, but cheap. Android devices are portable and can provide a UI that's as complicated as you like - graphs, knobs and dials, interfaces to email, dropbox, text files and so on.

There are several "Ardudroid" type apps available on the store, but I wasn't able to find an open source version. So I wrote one.

The current version is just the android app itself. The arduino project just echoes to serial and sends a heartbeat message every 5 seconds. No biggie.

the project release is here ArdDrive v0.1.

The APK has a self-signed certificate with no verification chain.

2

Git project now has both the arduino and android side of the project.

3

Developed a simple protocol to send packets across the link with a checksum. Using base64 encoding so that the packets can be printed to the serial monitor and look readable.

4

Now have two-way communication verified with checksums.

Issues:

Transmit from the arduino to the android is one character every 100ms. Any faster, or attempting to send more than one character, results in incredibly scrambled messages. Probably some sort of hardware/baud rate problem.

In the Android app, the UUID is not getting passed through from the Activity to the Service. Not sure why not. Perhaps a UUID object is not packagable?

In the android app, I do not have the layout wrking right: the fragment is positioned at 0,0 instead of being underneath the title bar.

Parsing of messages will not recover correctly. What you want is for an incoming '<' to always trigger a "oops" and immediately begin processing the next message. As it is, if the incoming bytes are '<foo#34<bar#1234>', then both messages will get dropped. Need to redo using 'lookahead' technology.

Still. Ready to write a fragment that controls some blinkenlights.

5

OK! Successfully driving some neopixels using a slider on the android tablet.

Demo with a color picker here.