Tactile Remote Control of a Mobile Device

The android application is based on the tutorial by Dave Smith from NewCircle, except the bulk of the program is run in a service, instead of an activity.  

 
https://github.com/devunwired/accessory-samples/tree/master/BluetoothGatt/src/com/example

The app is separated into three main classes:

• kDriveButton.java
  
  •  This class defines possible types of buttons.  I was unsure at the time of development what kind of buttons I wanted on the hardware, so this class will make it easy to add different input elements with different characteristics.  It will also make it possible for future devices to be created with different types of input elements.  Possible types of input elements are:
  • Navigation buttons, similar to arrow keys on a keyboard
  • General buttons, can be used for general input, such as to launch an app, initiate a phone call, select a menu option, etc.
  • Rotary wheel, a spinnable element similar to a scrolling wheel on a mouse.
  • Rotary wheel clicker, spinnable element that can also click
  • Slider, capacitive touch slider
  • Joystick, directional joystick
  •  Each button has characteristics that describe how the button can operate.  The characteristics are:
  • --Clickable, double-clickable, long-clickable, scrollable, slideable

•  kDrive.java
  
  • This class provides methods to start/stop/bind/unbind the kdrive service, connect/disconnect BLE, initializes all of the buttons on the hardware (using the kDriveButton class), and defines the callbacks for when a button is pressed.  In order to make the kDrive system easy to use for app developers, the idea is to have almost all of the work done in these three classes.  An app developer who would like to incorporate kDrive actions in there app would need to write methods for the callbacks defined in kDrive.java.  These callbacks include “onKDriveSliderChanged”, “onKDriveButtonPushed”, etc, which are automatically called when the service detects an event.  These functions are implemented in an activity that wants to interact with the kDrive.

• kDriveService.java
  
  • The main functionality of the kDrive system occurs in a service so that it can run in the background and hopefully be accessible by any app.  This allows app developers to include kDrive functionality in their own apps.  The service is based on the example from NewCircle (see link above).

The service progress through the following cases:

• kDrive.java initiates Bluetooth scan
• onLeScan callback is called, searches broadcasted devices found for name “kDrive”.  Attemps to connect, if found
• If successful, attempt to discover GATT services
• If services discovered, enable GATT notifications
• Once notifications are enabled, the setup is complete.  
• o Once the BLE connection is setup, the service will wait for the BLE device to send notifications to the mobile device.  If a notification is detected, the callback “onCharacteristicChanged” will be run.  Inside this method, we will process the type of input that was detected (button pushed, slider scrolled, etc).  We will then pass this information back to kDrive.java, which will in turn launch the callback that the application developer has (hopefully) implemented. 

Firmware for the BGM111 is written using Silicon Labs’ proprietary scripting language BGScript.  The firmware includes the GATT profile, the settings for the GPIO pins, methods to broadcast and connect via BLE, processing interrupts on the pins connected to the buttons, and sending and receiving data over BLE to the client cell phone. 

The Silicon Labs development board has a few GPIO pins that I can used to get test basic connectivity and functionality.  It plugs into your computer using USB and allows the device to use the UART to send serial communications to your computer, which is essential for debugging.  There are a few LEDs and a few push buttons that we can use for further debugging.  For the first phase, I designated one of the LED’s to turn on when the device initializes, and another LED to turn on and off when the client cell phone connects and disconnects.  

The firmware will set up a GATT profile with a few different services.  We will have a “Device Information Service” to broadcast the name and revision of the device, and we will have a custom service which contains characteristics for each button on the device.  Each of these characteristics will have its own UUID, and will be set up so that it can provide indications/notifications to the client.

The firmware performs actions in reaction to events detected by the MCU.  A summary of the program flow is highlighted below:

• Upon Boot
  • Setup GPIO
  • Setup BLE parameters and advertise device name
  • Initialize global variables
  • Turn on LED1
• Upon BLE connection opened
  • Set BLE connection parameters, such as connection interval
  • Turn on LED2
• Upon BLE Connection Closed
  • Turn off LED2
  • Begin advertising device name
• Upon GPIO Interrupt (ie, button click)
  • Process  which button was clicked Send gatt characteristic notification to client

Update 10/23:  BGM111 firmware is now uploaded to Github

https://github.com/kylecthomas/kDrive/tree/master/BGM111_firmware

Summary of important files

• gatt.xml - gatt profile
• hardware.xml - GPIO initial setup
• kDrive.bgs - BGM111 firmware
• Pinout.xls - definition of GPIO pinout

We start with the basic components needed, and build from there.  At the very least, this device needs a Bluetooth chip, and a couple buttons.  To make development easier, I started looking at BLE modules that are a combination of microcontroller, BLE adapter, and antenna.  As a bonus, some of these modules have some FCC certifications already, allowing easier time to market.  Ultimately I chose to work with a Silicon Labs BGM111 BLE module.  It is an ARM Cortex M4 microprocessor with a BLE adapter and Antenna built into a small PCB module.  These modules don’t need expensive compilers to program, and have enough GIO to attach multiple buttons.  They are low power and have other features such as I2C which could be useful if the device gets a little more complex.  

The 2nd half of the system is an Android app that processes the BLE communications from the device.  The app doesn’t have to be too complex.  It will connect to the device, and process when a button is pressed.  It doesn’t have to communicate at high speeds, just fast enough to process user input.  The idea is that the device will act as a keyboard to take advantage of the android keyboard navigation procedures.  This allows you to navigate using arrow keys, and perform actions like selecting an application to run, and navigating through the app assuming the developer built in that functionality.  
To begin work on these two parts, I purchased the BLE Wireless Starter Kit from Silicon Labs.  This will be enough to get started on the firmware and Android App development.  As a bonus, the kit comes with a controller board with a few buttons, so this is all I need for my initial prototype!