The initial prototype as done using just the BGM111 development board and a small hand soldered breadboard containing a few push buttons.  The bulk of the work in this stage is getting the firmware of the BGM111 to communicate with the basic android app.  Once a few buttons were working properly we could expand the firmware to accommodate more buttons.  Many of the core design choices were made at this stage.  Some of the design choices are:

• Process clicks in hardware or software
  
  • I want the user to be able to interact with a button in multiple ways, just like a keyboard or touch screen.  This includes single clicks, long clicks, multiple clicks, simultaneous clicks, and holding down a button.  Processing all the types of click can either be done inside the Android app or inside the firmware of the MCU.  I chose to do all of this in the MCU.  The processor is more than equipped to handle it, and it take some load off the phone as well as limits the amount of data  need to transfer of BLE.  The MCU also has a more precise clock that is used to determine long clicks.  As of right now, only single clicks and long clicks are implemented.
  • The GPIOs are setup to interrupt on the rising and falling edge, so that we know when a button is pressed and when it is released.  When a button is pressed, the MCU starts a timer.  When that button is released, it checks the status of the timer.  If the elapsed time is more than one second, then a long click is processed.  If the time is less than one second, then a short click is processed.
• What data to send over Bluetooth
  
  • We need to send a packet of data from the MCU to the android app.  For the buttons, the packet is quite simple.  One byte for the button ID, and one byte for the type of click processed.  
• Outline of GATT profile
  
  • The GATT profile includes a service, and this service includes several characteristics, 2 bytes each.   Each characteristic corresponds to one button.  After a button is processed in the firmware, we will write a value to the characteristic corresponding to the pressed button, and then issue a BLE notification which alerts the android app that something has changed.  
• Bluetooth connection settings
  
  • The BLE connection settings do not need to be high speed.  We are just processing user interaction, which is fairly slow.  A user probably can’t push a button more than 10 times per second or so.  We can set the connection interval to 50ms for now to save power.  
• Android app flow
  
  • When initiated, the android app goes through the following actions to set up the BLE connection:
  • kDrive.java initiates Bluetooth scan in kDriveService.java
  • 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.  
  • The service then waits for the onCharacteristicChanged function to fire, which happens when the Bluetooth device sends a notification or indication.  The android app then processes the packet of data, unpacking the button ID and click type.  
  • The service now needs to send a message back to the kDrive class so that the current activity can act on it.  The service sends a bundle of data to the kDrive class.  
  • The kDrive class receives a message from the kDriveService, and initiates a callback function.  The callback function is overridden in the current activity, so that each activity can act upon the button however it pleases.