Fun with arduino and android
« Monday, April 15, 2013 »

android arduino bluetooth

I started working with arduino and android for about a year. Progress is slow but I've got pretty good news recently. I have a bluetooth chip that unfortunately only does SPP profile, but it's good enough. I'm trying to create a smart home protocole using bluetooth. There are a couple of reasons why I'd rather see bluetooth being used for domotic than z-wave, xbee and zigbee. I'm not much aware of all wireless protocoles out there but that's a short list that I wouldn't probably use. Bluetooth fits most of what I need.

  • Energy efficient
  • Wireless (good distance is possible)
  • Good speed
  • Easy to use
  • Available almost anywhere… Not hard to find a bluetooth device.
  • SDP is a proved protocole for device and profile definition
  • Encryption and security
  • Bluetooth devices are separated in classes (range, power, speed, energy consumption)

As far as I can say, Z-Wave is being used for a couple of good reasons. It is energy efficient. It as good wake up time. Faster than a bluetooth chip and it can cover good distances too. But since z-wave is a closed technology and availability to mobile devices is non existent, it's a deal breaker for me. I believe that anyone should be able to build or design some hardware. Bluetooth is a technology that enables developers without much restrictions. If speed is a problem, there could always be a possibility to implement part of the mesh network over wifi technologies. The wakeup time for bluetooth is slower than z-wave, but I read that a new spec is in the work and this problem should be fixed in the future.

For the time being, I have to create my own “sdp” over serial because I just can't use it. As I understand, sdp is done at pairing time. When a device is paired, it shows to the initiator which profiles it can run. When a device is paired, it shouldn't have to require these informations anymore. In my case, at pairing time, only spp is available and I'll have to create a mini sdp for profile recognition over spp.

The main idea was to create an interface:

interface IDevice
  name: String
  id: const String
  firmware_version: const Integer
  device_type: const String

It's quite simple, the id should be unique but the name should differ. To make things simpler, an application should have a list of device_type instead of profiles. There is a big downside to this choice. For that reason, it wouldn't be easy to create hybrid devices. Having profiles would make it easy to create a mouse keyboard and a camera/screen. But for simplicity and testing purpose. I'm not going to add profiles yet.

The other idea is to have a standard way to push and pull data from the device. And I'm possibly going to implement BSON or plain JSON. BSON would be a good fit if it's not a big library to add. This way, it could be possible to handle RPC over bluetooth to devices.

For example, we could implement a BSONRpc (based on JSONRPC). Building a mouse would be as simple as doing that from the device.

device.broadcast('getRelativePosition', {x: device.x, y: device.y});

>> {method: 'getRelativePosition', {x: 1.23, y: 2.34}, id: null}

And from the computer we could do things like that to configure the device.

device.send('setting': {'speedX': 2, 'speedY': 1});

Binary data could also be handled in some ways and the Apackaging time shouldn't be terrible. While it could be an issue. Using bson, could make building of devices and protocoles much more easier. Instead of sending structures or binary data, we could just send data that has to be parsed back again in the device. It will certainly be slower than just loading a binary struct. But I'm pretty certain that it will be much more pleasant to write could that human can read.

comments powered by Disqus

Copyright © 2015 Loïc Faure-Lacroix