Assembling the Data Logger

Until now development has been on a table with components loosely connected together. However, the data logger is a tool to be used both inside and out and so requires suitable packaging. This in itself has proved quite a challenge to achieve a professional finish as there are many requirements that must be considered.

At this stage in the development the focus is on packaging the XBee module to give it adequate protection whilst allowing flexibility to connect to it's interfaces and include power from batteries. Central to the design is the enclosure to house the module. It could be thought that finding an enclosure that accommodated this would be easy. Unfortunately, although there are a wealth of enclosures available, a suitable product has been surprisingly difficult to find!

Eventually an enclosure that hopefully will be suitable has been found at Maplin although RS Components, Farnell  etc were extensively searched. Most importantly it only costs a few pounds. Very few of the enclosures include a convenient method of holding components inside so this is to be achieved by self adhesive PCB mounts.

The XBee itself utilises a small 'motherboard' called an XBee Explorer to provide regulated power and a means of attaching external connections. Thankfully the Explorer is also designed to accept pcb header connectors so these are going to be added in order to connect the Explorer to another very small development board. This will be used to make the external connections which will be brought out of the enclosure as a small loom of wires terminated by crimped on pins protected by heat shrink sleeving. Overall this should provide a flexible method of onward connection and allow the enclosure to be made weather tight.

The battery power supply has and continues to be a problem to accommodate. At the moment a switched battery holder is proposed that will attach to the XBee enclosure with velcro. Of course an integral battery supply will be best in due course but nothing particularly suitable has been found so far.

The next step is finding the time for assembly.

Command processing now added to data logger

The software is now able to receive data from any number of XBee nodes and log it to file. However, it was realised that the software would require to be able to program the nodes as well. For example, to adjust the sleep, wake and sampling intervals. This has also now been achieved.

Configuration of the software is accomplished through a configuration file rather than a user interface. The reason being that it will enable the simplest of equipment requirements to run it. The objective being to use a RaspberryPi and without a keyboard and display. Just a USB memory stick to configure and write data to.

So that said here's a sample of what the configuration file looks like.

# loginterval units are seconds
loginterval=30
node1=0013a200409029a5
0013a200409029a5.command1=NI
0013a200409029a5.interface1
0013a200409029a5.interface1.index=0
0013a200409029a5.interface1.conversion=TMP36
0013a200409029a5.interface1.nickname=kitchen

As can be seen the log interval is configurable. The software works by listening for incoming data which is then saved but not written to file. That's because it will be coming in all the time so it's the function of the logging process to rationalise this and bring it all together in one record written each loginterval seconds.

The next entries define the nodes from which data will be accepted for logging. The value 0013a200409029a5 is the 64 bit node address. The succession of commands following the node1=0013a200409029a5 entry define the interfaces in use and such things as the conversion routine to apply. For example, interface1 is an analogue interface with a TMP36 temperature sensor attached and so it reports in millivolts. Therefore, the conversion converts to Celsius before logging.

So now I've got a data logger and can once more start thinking about measuring where my energy is being used! Well, not quite! I've now got the problem of packaging the nodes so they can be left around the house. Always another challenge!

Adding XBee command processing to the logging software

The software so far is pretty much usable. That is, it receives data from XBee nodes and logs it to a file. However, at the moment, my test node sends data every second which is too frequent and I need an easy way of controlling this behaviour.

One way would be to physically plug it into an XBee Explorer and configure it directly. However, this is a bit of a clumsy time consuming thing to do and also risks damaging these little devices. Sending commands via wireless would be much better so that's what I'm now working on. Of course, when I've done that I've then got not just a logging system but a control system as well!

The work is nearly finished and the commands seem to be accepted by the local XBee software for transmission. What I must do now is include a means of confirming that the commands have been acknowledged by the remote node.

New version of data logging software now available.

Code06 now available with radical enhancements

There are always improvements to be made but the latest version of the logging software is now available. Code06 is a radical development on the previous version and can be found here.

Objective to provide a low cost logger supporting multiple nodes

The objective is to be able to log data from a network of XBee's and analyse the data using the Google Docs suite of software. In particular the spreadsheet application which has a very powerful graphing capability. In addition the objective is to develop a low cost instrument with minimal equipment requirements.

Summary of latest functionality

Here's a summary of the new functionality etc.

• It's now a pure Java application.
• The development environment is Eclipse.
• An unlimited number of XBee nodes can be supported.
• Configuration is via a text file.
• Logging nodes are registered in the configuration file.
• Logging interfaces are registered in the configuration file.
• Data from nodes not in the configuration file is discarded.
• Received data can be recorded as raw values e.g. ADC output value, or converted e.g. temperature.
• User friendly names can be used to identify the nodes and interfaces.
• Data is recorded in a comma delimited text file.
• The data recording process is a separate process to the capture process.
• Data is stored as it is received. 
• Log records are written at programmed intervals. e.g. 1 min, 1 hour, 1 day
• A new log file is created per day.
• Debugging is provided by log4j
• Debugging is configured via a configuration file
• Debugging provides low level data packet inspection
• Debugging provides monitoring of the application operation
• Debug output is written to a logging file or console.  

At the moment my development  facilities include only two XBee's which is not really a network! Therefore I'm waiting for another to arrive in the next few days and then I will be able to test the multi node operation.

A few thoughts about Eclipse

I feel compelled to write a few words about my move to Eclipse which I'm now using to develop my Java data logger. Prior to this I had been using Processing but found I missed the features and facilities I knew existed.

In awe at Eclipse

It's been a couple of months of very steep learning but what a program Eclipse is! Certainly no regrets. Obviously learning the syntax and semantics of a new object orientated programming language is going to be a challenge but Eclipse does it's best to help. Rather like having a team of very talented programmers constantly at your shoulder. It's also a little humbling. To produce programs like that must require such a talent and experience.

The good and not so good Java reference sources

In contrast, these attributes can often hinder when creating legible documentation for mortals and this I have found in the official Oracle tutorials. A good source of information when you've attained a certain level of proficiency but difficult when starting out. If it wasn't for Tutorials Point I would have been really struggling!

Next version of Data Logger nearly ready

It was the end of January when I posted last so it's taken 2 months to produce this latest version. That said it does represent a significant effort both to get familiar with Java and Eclipse not to mention the XBee's.

Harnessing the power of XBee's worth it

There were times when I wondered why I'd introduced so many changes at once but it now feels worth it to be able to harness the power of these little wireless devices. There's no doubt that this technology will be more and more common place in our everyday life. For example a service engineer recently told me of a support call that would have been perfect for a simple monitoring system. The type that the XBee's would be ideally suited to provide.

A real life application

The user was reporting that the boiler was not working on a recently installed system. On investigation it was a simple case of the fuel hopper being empty i.e. out of fuel! However, XBee type technology could have  provided an easy solution. Instead of this being an expensive waste of support resources through a pointless service visit or time consuming telephone support calls, a single XBee node (and gateway) could easily have provided all the required information to a simple smartphone application. But back to this project which was more specifically focussed at data logging.

Support for multiple nodes and interfaces

First of all the application that is now very nearly ready is significantly different from the last version. To begin with it has the capability to support multiple nodes with multiple sensor interfaces and sensor types. Also, the data received from the nodes is collated and recorded in a format suitable for analysis and graphing.

Simplicity is the design objective

Overall, the system should be very simple and require minimal use of a display/keyboard for configuration and operation. Eventually it is hoped to migrate the application away from a laptop and onto a Raspberry Pi and make it very portable. For that reason the configuration is performed from a text file which will be read from a USB memory stick. A logging facility has also been included which allows low level debugging.

Planning

I'm not sure how far I'll be taking this project but it's smooth development requires a degree of planning. Hence the delay in publishing the next version of code. This approach saves an awful lot of wasted time writing, rewriting and debugging code. It's tempting to do the latter but  planning first is more satisfying and efficient.