Hacking away with Android pt 4 – Researching options to attach sensors and devices to your Android

Posted on November 1, 2010

0


I have been doing some research on attaching sensors to the Android devices in the past days. I have not tested or build solutions yet with this information. That will be one of the next steps.

Purposes of this series

This series of articles is written with the following uses of Android Devices in mind:

  1. Using Android Tablets as an alternative for a Netbook – including the use of an external keyboard, external storage, and an external mouse
  2. Using Android devices as distributed computers – each fulfilling a specific task and each capable of communicating to the others and sharing and transferring files
  3. Using a chain of Android Devices as the “Smart Part” of Roomware installations – allowing Arduino devices and XBee-based devices to become connected to an Application Pool that can extend the local setup to a global installation.

This article focuses on 2. and specifically on 3.

Related posts

The (unofficial) Roomware Manifesto: stating the basis of Roomware and Roomeare related items

Android – more than phones: moving into alternative uses of the Android phone

Trends: the Roomware related landscape for the next 5 to 10 years, moving into emerging trends of the past years, including hardware as a commodity

Hacking away with Android: A series of articles to discover the possibilities of the Android hardware and software for productivity, hardware hacking and cluster-computing

Why sensors and devices?

Attaching sensors and devices to your Android Devices opens new options for you to work with:

  1. Switching lights and devices on and off
  2. Opening and closing doors in your house
  3. Remote-controlling robots and other toys
  4. Build installations and art-works that interact with people and react on sensor data

Limitations

  1. Serial port – Android devices do not come with a Serial Port (by default)
  2. USB drivers and controllers – not many drivers and controllers available for the Android platform, limiting your choices of connectible USB devices

Possibilities

  1. BlueTooth and WiFi – You can use both wireless protocols to connect to remote objects
  2. USB Host – you can connect (with Archos devices anyway) external USB devices to your Android Device.
  3. Running a server on your Android device - either Sockets (Roomware), HTTP or Telnet

Researched options and findings for Android

  1. Serial connections via a wire – is the most “simple” and direct – you would thought. As the Android OS does not provide default Serial input/output nor a default for Serial via USB, nor some USB host driver solution, you will have to create your own. Which leads to solutions like this: by Jernej Kranjec using the Audio Jack, a DIY modem and some custom software to make it work, or this by FlakeLabs using a similar solution. Unless you have one of the HTC phones, which use the Audio Jack as your Serial IO port and provides the option for this Serial IO hack using CyangenMod.
  2. Using the USB Host – on the Archos – Not many things are supported on the Android.
  3. Serial connections using BlueTooth - as we do not all own an HTC phone, I briefly reviewed BlueTooth and (re) found the Amarino project using BlueTooth to connect to an Arduino Board with BlueTooth. What I do not like about BlueTooth is the explicit extra action you need to perform to pair the objects. Another thing is the high energy consumption and the low return on “investment” you get (very fragile connections. Your body can already be enough to break the reliability of the data transfer)
  4. XBee – I have been enthousiastic about XBee in the past. The modules are small and once configured allow you to do neat wireless stuff with sensors. Main problems are:
    1. Your Android device does not support the XBee protocol (yet)
    2. You need a Serial connection to read the XBee host – see item 1 in this list
  5. Connections using WiFi - I started out with Arduino and WiFi, but soon moved on to search for stand alone WiFi devices. The hacks I have in mind are real time and do not require a “smart device” as man in the middle. And thus: enter WiFly by Roving networks. It offers you 10 digital Input/Output ports and 8 analog-in sensor ports (see specs on the RN-131). Enough for some real-time sensoring stuff. Communication to and from the WiFly is possible via TelNet, which should be available in the Java libraries of the Android phone.

Outcome

  1. Serial connections via wires - Android simply is not the platform (yet) to connect “unknown” devices to via wires or do Serial Magic – as required when using XBee or Arduino
  2. BlueTooth – In my past experience, it fails on many levels and due to these preconceptions I rather avoid it. Future experiments might prove me wrong.
  3. XBee – see above – not supported by Android and requires Serial Connections
  4. WiFi – It is simple, it is on all Android Devices (including the Archos) and open. Which also introduces some dangers.

Using WiFi and the WiFly

The WiFly R-131

This is the WiFly R-131. It is – for instance – used in hardware hacks in combination with Arduino. It measures 20 mm by 37 mm (a bit bigger than the average thumb). It contains all the hardware and software to operate as a WiFi server and:

  1. Send measurement data to your client – via Telnet or another protocol, using pull or push mechanisms.
  2. Receive commands from the client - via Telnet or another protocol
    1. To configure the digital I/O pins
    2. To set the digital pins to a specific value (on / off)
    3. To read the values on the Input-pins

Here you will find the manual of the WiFly GSX. Here on SparkFun you will find how the WiFly is used in an experiment, involving Arduino as well.

The WiFly GSX user manual – highlights

  1. Defining digital in/out - Chapter 10.5 and further. Describing the pins and setting the digital pins for being input or output
  2. Reading analog signals – Described in chapter 16
  3. Joining (secured) networks – both secured including the pass-phrase to connect to the WPA and unsecured, chapter 12
  4. Pushing sensor data to a Server – chapter 12.3 describes what settings are needed for the WiFly to automatically connect to- and push data to a specific IP-address. Unfortunately this chapter does not explicitly states what the default format or protocol is. I suspect it is Telnet.
  5. Automatically posting sensor data as HTML – to a web server via HTTP-GET. Chapter 13 and 13.5

Running a HTTP server on your Android device

If you choose to post sensor data via HTTP to your Android device (as it might function as a Hub for your in-house automation) you might be interested in:

  1. I-Jetty – very nerdy in setup and cryptic descriptions on how to deploy your own applications
  2. PAW Server by Fun2Code which seems to be more straight forward and offering a lower learning curve

Both offer the possibility to run Java Beans underneath, opening new possibilities to:

  1. Make decisions based on the Sensor Data
  2. Manage and distribute your sensor data to other devices and locations

To fix the IP-number of your Android device, either a manual setup in your Android network Settings or StaticWiFi might do the trick.

Stability

I have tested neither solutions yet, nor have I tested Android devices in a long running online situation. Archos seems to be unstable – i.e. losing connectivity and not restoring it. My two Android phones seems to be more reliable.

What we are working towards to

We are working towards a situation where various (Roomware) sensors and -devices are read and manipulated via a low-cost (below 200 euro) controller running on Android as one of the possible options to go. This solution might allow people to:

  1. Switch lights and devices on and off in houses and buildings
  2. Open and close doors in the house
  3. Remote-control robots and other toys
  4. Build installations and art-works that interact with people and react on sensor data

The dangers

One thing about using wires to connect to your hardware-controllers is that you create an potentially open door to whatever you control. Naturally you will use WPA2 or something similar and only interact with your devices within your WiFi network, but between your Android device and the WiFi device data will be transmitted without encryption. – Unless you take some extra steps.

The WiFly seems to offer:

  1. The option to configure it for WPA
  2. An “IP specific” protection which you can set. It apparently will only accept instructions from that address.
About these ads