Category Archives: Mobile

Remote sensors and mobile access: a simple exercise (part 2)

Following from a previous post, in this part I will highlight the coding section of the exercise aiming to a very simple goal: enable mobile access to a remote sensor reading.

With reference to the architectural schema, I will focus on the left-hand side:

Architectural schema to address the exercise’s goal: “enable mobile access to a remote sensor reading”.

In this case I opted to make use of the Spring framework, to follow a structured approach while being able to deploy everything inside a plain Tomcat server; I will reserve my JavaEE 6 for a different exercise, this time I really wanted to play around with Spring.

So overall the dependencies from a Java perspective are:

  • XBee API
  • RXTX – this is for serial communication over USB, enabled by the FTDI chip / breakout board on which the XBee coordinator is mounted on (detailed in the previous post)
  • Spring
  • CXF RS – this is for making use of REST webservices
  • JUnit, logging, etc.

In turn the POM, as I like to Maven stuff, looks like this:

Screen Shot 2012-12-02 at 15.05.36

Then I developed the REST webservice which will buffer all the readings from the XBee; when the webservice is consumed, the call will de-spool all the buffered readings from the buffer and place it on the webservice response.

I’m going to describe this webservice in two steps. First, is the webservice class declaration along with the constructor code, extract:

public class XBeeService implements PacketListener {

	private XBee xbee;
	private Queue queue = new ConcurrentLinkedQueue();

	public XBeeService() throws XBeeException {
		xbee = new XBee();
		try {"/dev/tty.usbserial-A4004CwJ", 9600);
		} catch (Exception e) {
			// TODO no xbee

	public void processResponse(XBeeResponse arg0) {
  • It is a Spring’s Service, line 18.
  • It is also a CXF REST webservice available on the “xbee” URL path, line 19; more on this later.
  • It implements the PacketListener interface, meaning I can setup this class to be a subscriber and notified every time it’s incoming a packet from the Coordinator XBee, line 20.
  • Every time a packet is incoming will be placed on an internal buffer, line 35.
  • The buffer is actually a Queue of XBeeResponse packets, and implemented with a proper java.util.concurrent class in order to support concurrency (as from one side the XBeeResponse will need to be buffered every time they are incoming from the XBee Coordinator, meanwhile the webservice call will need to consume the same XBeeResponse packets from the buffer), line 23.
  • The constructor on line 25 make sure all the stuff are properly initialized at Spring container start. Because as mentioned earlier, this is a Spring Service class.

So now that the webservice class has all the code in order to be properly initialized and listen for XBeeResponse and place them on the buffer, it’s time to implement the code for the webservice call, extract:

	public String getReading() {
		if (!xbee.isConnected()) {
			return "<p>No xbee connected.</p>";
		StringBuffer sb = new StringBuffer();
		XBeeResponse response;
		while ((response = queue.poll()) != null) {
			try {
				ZNetRxIoSampleResponse ioSample = (ZNetRxIoSampleResponse) response;
				sb.append("<p>Sample from " + ioSample.getRemoteAddress64());
				if (ioSample.containsAnalog()) {
					sb.append(" - 10-bit temp reading (pin 19) is " + ioSample.getAnalog1()+"</p>");
			} catch (ClassCastException e) {
				// TODO not an IO Sample
		return sb.toString();

So this method will be invoked every time I submit a HTTP GET request at the “xbee/” URL:

  • It will check for the Xbee to be properly initialized, otherwise a simple dummy message is returned, line 43.
  • Otherwise, for every XBeeResponse packet de-spooled/consumed from the internal buffer, line 48, a simple string of the reading in English language is returned.
  • You can notice every line of message, being the former or latter case, is decorated by the HTML p tags.

So it’s now the turn of the web.xml descriptor, which role is to kick-start the Spring container and the CXF stuff, extract:

  <display-name>Archetype Created Web Application</display-name>
        <display-name>CXF Servlet</display-name>

Then it’s the turn of the Spring beans.xml file for the actual Spring components, extract:

    <import resource="classpath:META-INF/cxf/cxf.xml"/>

    <context:component-scan base-package="net.tarilabs.test"/>
    <jaxrs:server id="restContainer" address="/">
            <ref bean="ciaoService"/>
            <ref bean="xbeeService"/>

Which will scan the package “net.tarilabs.test” (line 12) where I got the @Service annotated class for the webservice, which will be a proper Spring bean in the container, which I later bind to the jaxrs:server (line 17).

Now that the server backend is fully implemented, it’s now turn for some HTML.

I incorporate my favorites: Twitter Bootstrap templates, and jQuery. Then in the html page I just place the following div container:

      <div class="well logarea" id="thelogarea">

Meaning it will be rendered as a Twitter Bootstrap well, containing a default p paragraph line, but it’s also a CSS logarea which I defined as:

.logarea {
  min-height: 300px;
  max-height: 300px;

in order to have some pre-defined height dimensions.

Now, it’s time for some jQuery magic: from the user’s browser, will poll the REST webservice to obtain new content to place inside the mentioned div:

function doUpdate() {
	  $.ajax({type: "GET", url : "./ws/xbee",
	          success: function (data) {
	             if (data.length > 0)
	                var divx = document.getElementById("thelogarea");
	                divx.scrollTop = divx.scrollHeight;
	             setTimeout("doUpdate()", 2000);
	setTimeout("doUpdate()", 2000);

Specifically, consume the REST webservice via ajax call and on success, append the response of the webservice call inside the div (this is the reason why the webservice replies with html p line statements) and then programmatically move the div scrollbar all the way down to the bottom of it – simulating the trail command in Linux.

Time to deploy it on Tomcat and experience all the components working nicely all together:
Overview of the implementation modules and component which perform the goal: mobile access to a remote sensor reading.

Why do I blog this

This is the conclusion of this exercise; I reached my goal, enable mobile access to a remote sensor reading, by making use of some simple electronics and XBee modules, while for the coding part I leveraged the xbee-api with Spring and CXF REST webservices, along HTML5 and jQuery to access the data via mobile access.


Remote sensors and mobile access: a simple exercise

In these new series of articles, I want to share my experimentation with remote sensors and mobile access; nowadays there is a lot revolving around mobile and mobility, in addition to the “Internet of Things” widely announced – I don’t know if the Internet of Things will ultimately happen in the way predicted, but I wanted to have my go at it.

This exercise aims to a very simple goal: enable mobile access to a remote sensor reading.

In the followings, I will introduce the experiment I crafted for this exercise and document each module.


From the goal/delivery which I explained above, “enable mobile access to a remote sensor reading“, the first thing, is that I drafted a schema:

Architectural schema to address the exercise’s goal: “enable mobile access to a remote sensor reading”.

In this schema I already marked down some constrains for implementation, that is the use of the XBee modules: normally I try not to bind myself to implementation constrains while drafting the architecture; this is more dictated by the fact that I had these modules sitting in a box from past projects, so I wanted to put them to new use. The same applies for having a sensor to actually measure some sort of distance.

Here is a picture of all the modules and components working nicely all together:

Overview of the implementation modules and component which perform the goal: mobile access to a remote sensor reading.
Overview of the implementation modules and component which perform the goal: enable mobile access to a remote sensor reading.

In the picture above:

  • background, upper-right: the distance sensor connected to the XBee router module mounted on a prototyping breadboard
  • background, upper-left: the XBee coordinator module which receives the reading, connected to the MacBook which acts as the server implementation to access the reading’s data from the Intranet
  • foreground: an iPad accessing the web application hosted on the server which provides the reading’s data live, similarly to the Linux tail command

Remote sensor reading

In this section I will detail the lower part of the architectural schema and how the XBee modules enable for the remote sensor reading.

Implementation for the remote sensor reading: XBee modules and the distance sensor

In the picture above, from right to left:

  • The distance sensor, mounted on the fixed-mounting brackets
  • The XBee router module, mounted on the prototyping breadboard: this is connected to the distance sensor
  • The XBee coordinator module, this is connected to the server

The distance sensor is in fact a transducer which provides an analog signal related to the distance seen, in this case, up to the Post-it note block also mounted on the fixed-mounting brackets. The XBee router -the one mounted on the prototyping breadboard- performs the Analog-to-Digital (ADC) conversion of this analog signal into a reading transmitted via the ZigBee protocol, to the XBee coordinator module.

One interesting part in this section is actually the electrical schema on the distance sensor side:

Electrical schema on the distance sensor side

The schema is quite simple but in the details:

  • The distance sensor is a Sharp 2D120
  • The Sharp 2D120 requires power supply and complementary electrical circuit as documented in its own datasheet, in this case I bought it from Phidgets as P/N 1101 because I found a nice boundle with the Sharp 2D120 which is Phidgets P/N 3520.
  • The AIN signal out of the Phidgets 1101 will vary 0-5V, while the ADC on the XBee is expecting a 0-3V: in this case I brutally cut the AIN signal in half with R1 and R2 which are 220ohm. This brutality is justified by my priority in having some contingency out of the Phidgets 1101.
  • The block marked IC1 in the schema is actually a “break-out” module called XBee Adapter board from Parallax P/N 32403 which is used to conveniently mount the XBee on the standard hole sizes of the prototyping breadboard.
    • schema IC1-pin 12 corresponds to Parallax 32403 pin VSS which is ground, which in turn corresponds to XBee Pin 10 GND for ground as well
    • schema IC1-pin 13 corresponds to Parallax 32403 pin VDD which is +5V, which in turn will provide +3V to the Xbee module
    • schema IC1-pin 23 corresponds to Parallax 32403 pin IO1, which in turn corresponds to Xbee Pin 19 D1, which is Analog input 1 or Digitial input 1 – in this case it’s setup as Analog input 1

Next is to setup the XBee by configuring and flashing the correct firmware on them.

Starting from the XBee router module, the one in charge to perform the ADC of the distance analog signal and transmit it.

XBee router configuration

The XBee router must be setup in such way to connect to its coordinator, so you will notice the Destination address has been set to the address of the coordinator, ending with 403AE77A. I also setup in this case the Personal Area Network as 4747, from the X-CTU software appears not a valid address but accordingly to other reference is perfectly allowed.

XBee router configuration – ADC settings

Next is to setup pin D1 of this XBee router module as ADC. Once also this settings has been saved, time to flash the firmware and configuration on it with the appropriate function in the X-CTU software.

Then it’s turn for the XBee coordinator module; in this case it’s very simple, as it’s just to setup it as a coordinator:

XBee coordinator configuration

Then also time to save and flash this firmware as well.

The XBee coordinator is mounted on the XBee USB Adapter board from Parallax P/N 32400, which is very helpful to connect it via USB as a Virtual Com Port (VCP) thanks to the mounted FTDI chipset. This will auto-magically wire it a serial port /dev/tty.usbserial-xxxx on the Mac, although accessing it from Java – which is my preferred programming language of choice – is not the easiest thing.

This overall setup of the two XBee modules can be proved quickly by using a Processing sketch – as I was saying in an earlier post, it’s a very handy prototyping environment – as documented on the xbee-api Google code site, just to be sure it’s working already.

To be continued

This is the conclusion for the remote sensor access part, in follow-up post(s) I will explain the implementation details applied on the server, specifically the Java web application, xbee-api and Spring used, HTML5 and jQuery to access these readings and data via mobile access.

Mobile in the enterprise changes everything

An interesting article I originally read at the beginning of this year, and lately found again a printout – still so very true, I think mobile in the enterprise is still yet to start…

Mobile in the enterprise changes everything: In the medium-term a mobile strategy means thinking completely differently about the user experience.

In the world of mobile, IT leaders and business stakeholders must consider how new capability such as geolocation, sensors, near field communications, cameras, voice, and touch can be integrated into functionality. It also means that core issues such as security, device form-factor, and limited screen real-estate must be addressed.