Category Archives: Pervasive

Expert Systems and JavaEE on ARM: a simple benchmark

This post is to report my findings while experimenting and – a simple, overall – benchmark of a JavaEE use case on ARM platforms. I currently have on my desk a Raspberry Pi (model B) and an Odroid-U2 now: given my interest on Expert Systems, I thought this could be a great way to test them out!

Photo 14-08-13 10 53 28Premise: I’m not a guru on Expert Systems, in fact I consider myself just a happy power user, so it is not my intention to delve into the debate on how an Expert System should be benchmark-ed, this is not in the scope of this post. Likewise, is not in the scope of this post to report a fully comprehensive benchmark comparison of running Java/JavaEE on these platforms.

In fact, much simplier:

GOAL: Given the use case of a JavaEE application which provides a reasoning service, benchmark the overall performance on the different platforms.

The Use Case

For the reasoning service, I use my all time favorite, JBoss Drools. On their GitHub repository, they provide several examples and benchmarks, based on published papers related to the Rete algorithm. Again, while I’m aware of the big discussion if actually these benchmarks are still relevant nowadays, given the progress on the Expert System algorithms, that debate is not impacting on this use case, because here the benchmark is used for a relative comparison.

I have a very simple webservice:

public class WaltzWs {
	WaltzKb waltzKb;

	public String waltz(@WebParam(name="WaltzDTO")WaltzDTO dto) {

		StatefulKnowledgeSession session = waltzKb.getKbase().newStatefulKnowledgeSession();

		for (Line l : dto.getLine()) {
		long start = System.currentTimeMillis();
		session.setGlobal( "time", start );

		long time = System.currentTimeMillis() - start;
		System.err.println( time );

		return "time: "+time;

which exposes the reasoning functionality by webservice call. When the webservice is consumed, a new Knowledge session is created, the content of the SOAP message is insert-ed into the Working memory, and then all the rules are evaluated. This webservice relates to the second half of the Waltz benchmark as linked above on the Drools GitHub repo.

For the actual Knowledge base, this is created by a Singleton EJB:

public class WaltzKb {
	private static final transient Logger logger = LoggerFactory.getLogger(WaltzKb.class);
	private KnowledgeBase kbase;

	public void init() {
		KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
        kbuilder.add( ResourceFactory.newClassPathResource("waltz.drl", WaltzKb.class), ResourceType.DRL );
        if (kbuilder.hasErrors()) {
        	for (KnowledgeBuilderError error : kbuilder.getErrors()) {
        		logger.error("DRL Error "+error);
        Collection<KnowledgePackage> pkgs = kbuilder.getKnowledgePackages();
        kbase = KnowledgeBaseFactory.newKnowledgeBase();
        kbase.addKnowledgePackages( pkgs );

	public KnowledgeBase getKbase() {
		return kbase;

Taking the Webservice + Singleton EJB approach, I can have several webservice calls happening at the same time, each with its own Knowledge session, while actually the Knowledge base is efficiently shared among them.

All the code, and the benchmark project file with results, available on GitHub.

The Benchmark

In order to load test this JavaEE application, i.e.: the webservice, I use SoapUI:

Screen Shot 2013-08-14 at 11.48.27

I created two webservice request template, each reflecting the “12” and “50” data file of the original JBoss Drools “waltz” benchmark. Then, before actually running the load test, I consume the webservice a couple of times, just to “warm up” the JavaEE container – in this case, JBoss AS.

I have performed load test session of 60s, with 1 thread first – i.e.: all webservice calls are sequential, await for the first webservice call to return before starting new one. Then followed by other load test session of 60s, this time with 2, 3 and 4 thread – i.e.: concurrent webservice calls, similarly to a stress test of the system being used by multiple “users”.

There are some limitations applying here, that’s why I put all the premises above to warn that this cannot be considered a comprehensive benchmark, more of a simple one to get the overall benchmark figures:

  • Raspberry Pi is single core, so this platform is put on disadvantage when the load test session is performed with 2+ threads.
  • for the performance baseline I’m using a MacBook Air (mid-2011, 1,8 GHz Intel Core i7) having for JVM the JDK 6, while on both the ARMs platforms I’ve got JDK 8ea, build 1.8.0-ea-b99. So yeah, JVM and architecture of the baseline for the figures is quite a different beast, but again, this is just to get an overall performance indicator.
  • while on both the MacBook Air and the Odroid I can leave both the flags: -server -Xmx512m, while starting the JavaEE container JBoss AS, this is not possible on the Raspberry Pi, where I have to change them into -client -Xmx400m given constraints of the memory and the ServerVM is currenlty implemented only since ARM7, and the Raspberry Pi is an ARM6. Please bear in mind on the ARM is a Early Access version of the JVM.
  • for the performance baseline test is performed on localhost, so the overhead of the LAN is not included in the figures.

The Results

I have to say I’m quite impressed with the results. Although it is an overall performance indicator, it provides great insights there is plenty of potential in using JavaEE on an ARM embedded platform – and I’m specifically referring to the Odroid. The Raspberry Pi suffers a lot in this case, possibly an unfair comparison due to the computational resource intensive use case of this scenario.

Below are the results of the load test; columns are type of test (waltz12, waltz50) and number of threads used for the load session, rows is platform (localhost is the baseline MacBook Air), figures are expressed in average ms of response of the webservice, within the load test session.

Screen Shot 2013-08-14 at 12.25.51

Below are the same results, this time figures are expressed in percentage with reference to localhost (MacBook Air) as the baseline.

Screen Shot 2013-08-14 at 15.02.39

My perspective on these results, considering the Raspberry Pi and the Odroid: Odroid is also an ARM embedded platform as the RPi, but with 4x the cores, 4x the RAM and priced $89 Vs $35 (meaning 2.5x) which is still very cheap. I think the most make it the fact that it is a multi-core. With this specs, we’re improving the performance of the above use case scenario with reference to the Intel i7 baseline, from ~130x slower on the Raspberry Pi, to ~4x slower on the Odroid. I mean, IMHO, this is A LOT.

Why do I blog this

I do believe this is a good experiment to show the potential of JavaEE on ARM embedded platform; I’m really curious to perform again these test once the JDK is fully released! Given the small size of these platforms and their small power requirements, I think is a great way to have Pervasive and Mobile Expert Systems!

(Bladerunner mode ON:) I do also believe we might see in the future a platform shift in the data centers, as we know them nowadays: from the current platforms, to smaller and less power-eager platforms, like these two ARM platforms I’ve presented in this post. Potentially this also make a case from shifting from air cooling, to liquid cooling, by submerging this tiny size computer in mineral oil?


Hacking with a Pervasive Expert System (AI) my electronic toothbrush


Just made some progress on my Mobile & Pervasive Expert System tool, finally enabling some Pervasive dimensions but, most importantly, drafting a first round over the AI-side of the system.

The current goal for this step is: enable the system to be pervasively aware when I’m using my electronic toothbrush, infer how much time I’ve used, and then finally post the result to Facebook.

The current implementation, which I’m going to briefly describe in this post, is based on the following technologies and Java libraries:

Description of the process

I will starting describing from the physical world. I’ve put an IR-sensor in front of the toothbrush stand, as shown in the picture above.

Then I connected this sensor, using some simple electronics, to the XBee module in order to perform the ADC and therefore to have the sensor’s measurement available in digital form.


This XBee mesh provides a wireless way to communicate the reading from the toothbrush stand, located in the bathroom, to the actual room where my pc/server is located having the software application running.

This concludes for the physical/hardware part, in fact the biggest part is actually in the software world!

Fortunately there is for the XBee modules a Java library called “xbee-api” available on Google Code, so in my case I just wanted to write for myself an Apache Camel component, to serve as a wrapper for the sensor readings. The code I’ve written for this, is available on GitHub, although the wrapper implementation is only partial at present – implementing only the “receive” direction of the packets from the XBee mesh to the USB, meaning from XBee to the Camel Endpoint, in turn to the Camel Consumer, and in turn you’ll have the packets on the Camel routes.

The great thing about this approach, is that you can later latch the Camel routing in a very simple way, thanks to this wrapper:


			.log("route log ${body.getAnalog1()}")
			.log("I don't know what to do with this packet from the XBee mesh: ${body}")

In this case I’ve used the Camel SEDA to have the two routes asynchronous to each other.

Then it comes the Expert System, AI part. I’ve always been a big fan and used extensively JBoss/RedHat Drools.

The main idea is to be able to write a simple rule, something as the following mock-up:

Screen Shot 2013-06-01 at 15.39.10

In the example picture, the rule should be self-explanatory, as it’s responsible to infer when a fact, representing current and previous status of the “Home Toothbrush” object, has changed from UNDOCKED to DOCKED, where this transition did last for more than 30 seconds.

However, in order to get there, I first still needed to transform the sensor readings in terms of the status object.

So first, I needed to have all XBee analog readings represented as an Event:

declare ZNetRxIoSampleResponse

This way, I see each sensor reading as an Event proper in the CEP (Complex Event Processing) working memory of the Rule Engine.

This, in turns, enable me to write a rule to detect the current status as DOCKED of the toothbrush object:

 * Detect Docked
 * The analog sensor reading for docked is about 1023.
 * The rule shall detect the Home Toothbrush as docked when the average is above 950 including at least 3 analog sensor reading.
rule "Detect Docked"
    accumulate ( ZNetRxIoSampleResponse( containsAnalog == true, $analog1 : analog1 ) over window:length( 3 );
    			 $avg : average( $analog1 ),
    			 $count : count( $analog1 );  
    			 $avg > 950 , $count == 3
    $cp : CurStatusPrevStatus( id == "Home Toothbrush" , curStatus != "DOCKED")

In this case I want the toothbrush object set to DOCKED when the average of the last 3 sensor readings is above 950 (this is the converted ADC value from the XBee).

Notice the accumulate function in this case constraints not only on the average, but also on the count: this is important otherwise the sliding-window defined by window:length(3) would also intercept the initial warm-up of the system, when only just one or two sensor reading Event are available in the working memory. I want the status be detected over at least 3 continuous readings.

The rest of the work is really all about Unit testing, testing, and more testing; and then, writing some little more JavaEE code, deploying it on the JBoss AS Container…

…and it works! :)

And you can find the source code, evolving, on GitHub of course.

Why do I blog this

I think there is a lot nowadays revolving around “Internet of Things” that’s just the tip of the iceberg, and to me that’s really all about technologies becoming more and more pervasive in our daily life. Personally, I’m very interested how Expert System can benefit in this scenario, and I find amazing the little hacks you can start to do even at home!!

Welcome to my RPi: simple JavaEE exercise with webservice and JMS

So my Raspberry Pi has arrived and I was eager to try out some Java programming on it; actually, I wanted to have a first simple exercise to stress test it with a JavaEE container, which I choose JBoss AS 7. Of course the overall performances are nothing comparable to usual servers where you would normally deploy a JavaEE application, however being for small/home projects it doesn’t seems too bad either in order to get started!

Photo 16-12-12 20 24 38

The goal for this exercise is simple: develop a webservice to be exposed in a JavaEE application, which “spool” the content of the webservice call onto a JMS Queue.


  • Rasberry Pi (model B)
  • Java 7 SE for Embedded
  • JBoss AS 7 as the JavaEE container
  • Apache Camel
  • SoapUI to test the webservice
  • Hermes JMS as a consolle to access the JMS Queue

First things first, in order to install the Java SE 7 RE, I overall followed the instructions found here, and also a maybe plain but still interesting video on YouTube of what seems to be a Java User Group session – check out the related James Gosling video as well, it’s not RPi related but a very interesting talk nevertheless from THAT James Gosling!

Anyway, once the JRE is installed on the RPi:
JRE on the RPi

… it’s time to install JBoss AS 7:
Screen Shot 2012-12-16 at 10.49.27

In this case, what I did is a custom standalone.xml configuration file to have all the basics, plus JMS which HornetQ is the implementation for JBoss AS.

Time to code!

With the JBoss Developer Studio IDE (basically Eclipse IDE + JBoss Tools), Maven for a simple webapp, and switch Java Compiler to 1.6:


and some simple dependencies:



The former block is to have Apache Camel to simplify as much as possible, while keeping loosely coupled, the integration between the webservice and the JMS, while the latter block is for the JavaEE libraries provided by the JBoss AS container.

Then, time to code the webservice:

public class SpoolOnQueue {

	CamelBootstrap cb;

	public String sayHello(String name) {
	    cb.getProducerTemplate().sendBody("direct:spoolOnJms", name);
	    return "Your message has been spooled on JMS";

Which is actually rather simple: it defines a webservice class thanks to the @WebService and related @WebMethod annotation, for a sayHello() method of our interest, in charge of spooling the content of the message onto the JMS queue via the Camel’s sendBody() to a specific route.

There is a CamelBoostrap cb dependency injection, which is the JavaEE component in charge of managing the Camel context and routing, defined as:

public class CamelBootstrap {
	private CamelContext camelContext;
	private ProducerTemplate producerTemplate;

	public CamelContext getCamelContext() {
		return camelContext;

	public ProducerTemplate getProducerTemplate() {
		return producerTemplate;

	protected void init() throws Exception {
		camelContext = new DefaultCamelContext();
		camelContext.addRoutes(new RouteBuilder() {
			public void configure() throws Exception {
				// in the JMS connection we can use # for the ConnectionFactory because by not using Spring the default for Camel is the JNDIRegistry
				// just remind by default it's implied it's a Queue as per Camel JMS doc
				.log("spoolOnJms: ${body}")
		producerTemplate = camelContext.createProducerTemplate();

The CamelBoostrap therefore is a simple Startup, Singleton JavaEE Bean, in charge of initializing the CamelContext, the Camel’s ProducerTemplate, and the one and only camel route of our interest here:

  • starting at direct:spoolOnJms
  • logging the body content
  • and spooling the body content onto the jms:sample JMS Queue

Time to amend the web.xml configuration file to the 3.0 Servlet specs (meaning as well EJB 3 in this case) and linking the aforementioned SpoolOnQueue webservice class:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="" xmlns="" xmlns:web="" xsi:schemaLocation="" version="3.0">
  <display-name>Archetype Created Web Application</display-name>

Last thing before packaging up and deploy, is to define the JMS Queue, which in the camel route is defined as “sample”; to do so, there are several ways from JBoss consolle, to JBoss CLI, configuration files, etc. and in this case I opted for a deployable configuration file – in the WEB-INF/ directory it’s enough to place a HornetQ configuration file which must be ending with -jms.xml, et voilĂ !:

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-deployment:1.0">
         <jms-queue name="sample">
            <entry name="jms/queue/sample"/>
            <entry name="java:jboss/exported/jms/queue/sample"/>

Note to self: in this case the -jms.xml HornetQ configuration file is to be placed in the WEB-INF/ directory because the application is packaged as a WAR, otherwise it should have been placed in the usual META-INF/ directory.

Time to deploy:
Screen Shot 2012-12-16 at 20.35.48

You may want to note the deployment takes longer if compared with today’s server or machine where you normally test and deploy these artifacts, however it’s not so bad for home project just reminds me the performance of my old Pentium II with JBoss 3 (or 5? can’t remember) with the difference that nowadays JavaEE 6 and JBoss AS 7 simplify and improve things by great extent.

Then, I use SoapUI to consume the SpoolOnQueue webservice with a call for a simple “Ciao here is some content to place on JMS. Matteo.” message:
Screen Shot 2012-12-16 at 20.37.47

In the JBoss log there is a line now for the Camel route started and spooling the body content on the JMS Queue.

Then, time to connect HermesJMS to this remote HornetQ / JBoss AS, as I hope to have contributed here:

When I start I can see the AS7 I can see in the log the RemoteConnectionFactory JNDI, but this cannot be seen in the console:9990 because of some bugs. However still:
12:47:16,653 INFO [] (pool-4-thread-2) JBAS011601: Bound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory. With reference to the aforementioned -jms.xml HornetQ configuration file, from a REMOTE perspective: the RemoteConnectionFactory is on java:jboss/exported/jms/RemoteConnectionFactory, the Queue is on java:jboss/exported/jms/queue/sample

Therefore to configure HermesJMS

Step 1: Create a classpath group for HornetQ in HermesJMS
Only one JAR is needed, is the jboss-client.jar inside the directory bin\client of the JBoss AS 7 / JBoss EAP 6 directory

Step 2: Configure a HornetQ session in HermesJMS:
Class: hermes.JNDIContextFactory
Loader: HornetQ – the one defined in step #1

Step 3: In the Destionations of the HornetQ session which you are defining as part of step#2, Add a new Desitionation
Name: jms/queue/sample
Domain: QUEUE

Now in HermesJMS in the left tree structure you have your Sessions > Your Session > Queue which you can double-click to connect to. You want to notice that for the binding you set the RemoteConnectionFactory without the java:jboss/exported prefix, and the same goes for the Queue defined, where from java:jboss/exported/jms/queue/sample I stripped away the java:jboss/exported prefix. Also notice that you can define the username/password either via the (securityPrincipal,securityCredentials) properties as above, or either use the “Connection” settings fields (User, Password) at the bottom of the Session Preference page of step#2.

So because the webservice has been consumed, which in turn started the Camel route, to spool on the JMS Queue:
Screen Shot 2012-12-16 at 20.38.12

The message now appears on the “sample” JMS Queue which is now inspected thanks to the HermesJMS consolle application.

Why do I blog this

I wanted to have a first “stress” test exercise with my new Raspberry Pi, not only to develop with some Java on it, but using a recent JavaEE container: the performances are not the best, still requires time to deploy or to compile .jsp pages (more in following posts) however I do believe for small/home projects the Rapsberry Pi is a very interesting, cheap both in terms of money and power consumptions, and cool platform where to deploy simple JavaEE applications!
ps: code available on github.

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&quot;, 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 &quot;&lt;p&gt;No xbee connected.&lt;/p&gt;&quot;;
		StringBuffer sb = new StringBuffer();
		XBeeResponse response;
		while ((response = queue.poll()) != null) {
			try {
				ZNetRxIoSampleResponse ioSample = (ZNetRxIoSampleResponse) response;
				sb.append(&quot;&lt;p&gt;Sample from &quot; + ioSample.getRemoteAddress64());
				if (ioSample.containsAnalog()) {
					sb.append(&quot; - 10-bit temp reading (pin 19) is &quot; + ioSample.getAnalog1()+&quot;&lt;/p&gt;&quot;);
			} 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:

  &lt;display-name&gt;Archetype Created Web Application&lt;/display-name&gt;
        &lt;display-name&gt;CXF Servlet&lt;/display-name&gt;

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

    &lt;import resource=&quot;classpath:META-INF/cxf/cxf.xml&quot;/&gt;

    &lt;context:component-scan base-package=&quot;net.tarilabs.test&quot;/&gt;
    &lt;jaxrs:server id=&quot;restContainer&quot; address=&quot;/&quot;&gt;
            &lt;ref bean=&quot;ciaoService&quot;/&gt;
            &lt;ref bean=&quot;xbeeService&quot;/&gt;

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:

      &lt;div class=&quot;well logarea&quot; id=&quot;thelogarea&quot;&gt;

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: &quot;GET&quot;, url : &quot;./ws/xbee&quot;,
	          success: function (data) {
	             if (data.length &gt; 0)
	                var divx = document.getElementById(&quot;thelogarea&quot;);
	                divx.scrollTop = divx.scrollHeight;
	             setTimeout(&quot;doUpdate()&quot;, 2000);
	setTimeout(&quot;doUpdate()&quot;, 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.

SAP on my MacBook Air

So I just wanted to run a quick experiment.

SAP on my MacBook Air

I got a new MacBook Air as a replacement of my previous machine. Installed Java JRE smoothly and, just immediately after, the SAPGUI for the Java Environment. After sorting out the syntax for the connection string (i.e.: in the most simple scenarios it’s something like /H/hostname/S/3200 ) then connection to SAP works like a charm.

Why do I blog this

Usually most users and consultants working with SAP are lead to believe it’s a very strict and well framed ERP environment. This is true from several perspectives, however with a simple research on the SDN and Googling around, there are also several interesting related products and technologies. Potentially this could prove that “the best run businesses run SAP” leveraging connections from several platforms.

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.