2013 – Personally a great year!

Out with the old, in with the new. I’ll be sad to see 2013 go as for me personally it was a great year. I did a bunch of cool stuff, met loads of cool and interesting people and generally I’ve been living the freelancer dream!

Some of the things I have done or achieved this year, that I can remember, in no particular order:

  • Cleared all my loans and credit card debts and kept them clear, except mortgage.
  • Attended my first weekend music festival – Download2013 you were awesome!
  • Flying over the Download main arena on a zip-wire shouting Mother*****rs to the people below.
  • Had a great family holiday touring through France.
  • Dolphin watching in the Bay of Biscay while heading down to Bilboa.
  • A few weekends away in London with wifey and no kids – Quality time!
  • Visited UK MakerFaire in Newcastle.
  • Visited Elephant and Castle Mini MakerFaire.
  • Saw a couple of good cover band gigs.
  • Iron Maiden at the O2 were excellent second time seeing them this year!
  • Saw Avenged Sevenfold and Five Finger Death Punch at the LG Arena, Birmingham.
  • Saw Meatloaf – Like a Bat out of Hell!
  • Had a day of off-road motorcycling for the first time, must do it again.
  • Attended Over The Air 2013 at Bletchley Park, won IoT prize for the hack challenge.
  • Attended Thinkmonk IoT conference.
  • My parents celebrated 50 years of marriage.
  • Celebrated 19 years of marriage to my lovely wife.
  • My eldest turned 18 and still hasn’t bought me a pint yet!
  • My mother-in-law turned 80.
  • Built my first 3D printer – its the future!
  • Started to learn to use OpenSCAD to create 3D models for printing.
  • Made significant progress on my CNC cutter, but still not finished, one for 2014!
  • Celebrated the first anniversary of my company!
  • Attended the first SusHack hackday to kick off the Oxford Flood network – continuing this in 2014.
  • Did a brewery tour at the Wadworth brewery.
  • Drank a lot of beer, some good, lots great.
  • Drank a lot of wine but not much spirit this year.
  • Got a taste for Margaritas!
  • Successfully grew sweetcorn for the first time – those plants are tall.
  • Took over 40 days leave during the year, some to work on other projects. The joy of being a freelancer!
  • Contributed to the excellent Node-RED.
  • Learnt to use EagleCAD to design schematics and PCB layouts.
  • Had a lot of my PCBs professionally manufactured.
  • Bought a Quadcopter, now need to learn to fly it without crashing.
  • Had my first sit in an ambulance while being checked over after coming off bicycle.
  • Built lots of cool things including what could be most annoying IoT device – Bellduino!
  • …and anything else I’ve forgotten!

Many thanks to all the great people I’ve met along the way on my journey that was called 2013, you know who you are!

I’ll be raising a glass of something, beer, wine, cocktail or spirit to say “Here’s to 2014!”

Bellduino – The Internet connected handbell

I’ve recently been looking at alternative notification after seeing things like Bubblino created by Adrian McEwen, co-author of Designing the Internet of Things and the Cheerlights project from ioBridge labs. I had a gift ‘Ring for Beer’ bell that has been hanging around my desk for a couple of years now and decided to use this as the notification device. The first job was to decide how to ring it, the obvious solution would be a servo motor connected to an Arduino Ethernet or equivalent. The prototype uses a basic ATMega328 board and a shield containing a Wiznet Wiz820io module as this is what I had available to me at the time.

I have also successfully used an old Nanode board (Arduino compatible ATmega328 with ENC28J60 Ethernet controller) to drive Bellduino. This was achieved using the Arduino_UIP library with a few minor modifications to the original sketch. So far this seems to be working quite well as a lower cost solution.

The following describes how I built Bellduino, but first, lets see it inaction:

Building the Frame

OpenBeam parts used for the frame:

  • 4 x 150mm extrusion
  • 2 x 90mm extrusion
  • 1 x 45mm extrusion
  • 4 x Corner joining plates
  • 5 x T joining plates
  • 4 x Feet
  • 1 x NEMA17 Stepper motor mount and 608 Bearing mount
  • 1 x Servo motor mount
  • 1 x Big bag of M3 nuts and screws
2013-12-28 11.27.48
The frame is made up as a rectangle with the bottom and top as shown below. Remember to insert enough M3 nuts into the extrusion for the various inner brackets and mounts if the ends of the extrusion are blocked by other pieces. The parts that need extra nuts adding are:

  • Bottom – 3 nuts for T-piece, same side as corner pieces
  • Top – 3 nuts in front slot for servo mounting plate, 3 on rear for T-Piece
  • Right – 3 nuts in rear slot for T-piece to mount Arduino
  • Left – 3 nuts in front slot for NEMA17 mounting plate
  • Right and Left – 2 nuts in outer slot for frame feet
2013-12-28 11.42.46
The support feet are attached using T-joining pieces. The plastic OpenBeam feet are fitted underneath to provide protection to the surface that Bellduino stands on. 2013-12-28 18.45.57
The Arduino or equivalent electronics are mounted using two T-joining pieces taking care to ensure the screws are not shorting any tracks, if in doubt, use fibre washers between the screw head and board. 2013-12-28 18.47.45

Bell Clamp

Using my 3D printer I printed out a clamp and actuator arm that I designed using OpenSCAD. This clamps to the bell, providing a hole at the back that was threaded after printing to take a M8 bolt. The clamp also provides an arm that can then be attached via a rod to the servo motor in order to ring the bell. 2013-12-28 18.33.30
The pivot for the bell is made up from a M8 bolt, 2 nuts and an old 608 skateboard bearing robbed from one of my kids skateboards (Must remember to put it back and source a replacement bearing!). This just sits in the bearing mount and as there isn’t a lot of weight on it a single bearing does the job adequately. 2013-12-28 18.35.28
Close up of the bell pivot. 2013-12-28 18.36.01
The actuating rod connecting the bell to the servo motor is made up from a 140mm strip of 8mm wide aluminium with a hole drilled in each end. Washers and double nuts locked together provide a smooth motion when the servo operates. 2013-12-28 19.16.10
I found that the bell wouldn’t ring properly due to the spring supporting the hammer being too strong. To fix this, a lump of blu-tak (or similar) was added to provide additional weight to the hammer. This solved the problem and it now rings on command. 2013-12-28 18.34.24
The finished Bellduino 2013-12-28 18.31.05


The software runs on an Arduino Ethernet or equivalent and is basically an Arduino sketch that subscribes to a specific MQTT topic on my local server listening for any requests. It uses the Arduino MQTT client library created by Nick O’Leary, one of the co-creators of Node-RED.

As Bellduino subscribes to a MQTT topic, its just a matter of publishing to this topic in order to get it to ring. The easiest way to do this is to use Node-RED to produce the required MQTT publish request based on whatever input you want to use. The example I have at present is a twitter node that responds to the word ringmybell. A rate limiting delay node is included so that the bell is not continuously ringing.


  • Publish bell clamp design files
  • Publish sketch for Bellduino – still a work in progress
  • Example Node-RED flows

Using Node-RED with Twilio **UPDATED**

For a while now I’ve been using the most excellent Node-RED to provide a way of integrating my various sensors and devices around the house. One thing that was lacking is a general mobile control or status update facility. This could be achieved using browsers on smartphones or custom made Android or iOS apps. These have the problem that they take up resources, are platform specific and may not always work if there is no data signal available. Using SMS to receive notification and perform simple control and status request operations would therefore seem to be the ideal solution. There are a number of providers that provide an API to send SMS but this is all they do. Having a service that enabled both sending and receiving SMS plus the ability, if needed to use voice calls would be ideal. Such a service is provided by Twilio. You can sign up for free and try a limited version of the service. Once you upgrade and start paying for the service you can choose your own number instead of the number allocated originally. You can also have multiple numbers, there is no Twilio banner at the start of your SMS and no Twilio announcement at the start of each call.


Twilio already provide extensive documentation and a number of libraries to use their service. They conveniently provide a helper library for Node.js so this was a perfect starting point for the Twilio node. The node I created is a basic output only node as this is what uses the helper library. The input side can be implmented using existing Node-RED nodes.

The Node-RED Twilio output node

The Twilio output node is configured with a twiliokey.js file located in the directory (or folder) above node-red. This includes your Account-SID, Auth-Token and the telephone number that you will be sending SMS from.

2013-11-08 10.41.20

To send a SMS to a number, the topic parameter of the msg object must be set to the number, e.g. +4416358000xx and the payload parameter is the actual message that is to be sent.

In a simple test, you would use an inject node to create the msg topic and payload, this would feed directly into the Twilio node to send the SMS. How this is used would be up to your own imagination and requirements.

Receiving SMS

To receive and process SMS from Twilio is a little more involved, however there isn’t a node for this and it can be easily implemented using the available Node-RED nodes. Input is handled using a http input node. This URL must be available to the Twilio servers so you may have to set up a dynamic dns service such as to point to your IP address. In addition to this, you’ll also need to setup port forwarding to your internal Node-RED server. This URL mus then be configured in the Twilio Messaging Request URL field. The purpose of this URL is that it returns a TwiML XML file to tell Twilio what to send as a response.

On the site, select the NUMBERS tab and select the number you want to use. In the Messaging section shown below, enter the URL that Twilio will send the SMS request to in order for Node-RED to handle it.


The Twilio callback URL is formed of your external dynamic DNS name followed by a port number you use for port forwarding and the url that your Node-RED HTTP input node will be listening on. In this case, it is /twiliosms. It is strongly advisable that your port forwarding does not use the default Node-RED port of 1880 but instead uses a port number known to yourself that your router then maps the incoming connection to the Node-RED port. The callback url should then be of the format http://:/twiliosms.

The basic function to create the response message could be:

var messageObj = { "Message": "You sent: " + msg.req.query.Body } ;
msg.payload = messageObj;
return msg;

The JSON msg object must be converted to XML format using the json2xml node and specify a root element of Response. The final node is the http response node that then sends the reply to Twilio. Once Twilio receive the XML they will read the message and send the reply to the originator of the SMS. This could be as simple as a status update or an acknowledgement that the command had been processed.

The received message can be processed to look for key words and commands to perform actions such as returning the status of a switch or sensor or just acknowledging that a light was switched on as requested.

Example usage:
2013-11-08 17.16.56

The usage described here only relates to sending and receiving SMS, however it is possible with little more effort to use voice calls instead. I’ve done a simple test where the number is called and a voice reads a custom message. Other examples include having your computer call you up and tell you that a window has been opened on your property. The possibilities for communication with mobile devices in this way is only limited by your imagination.

Over The Air Hackday challenge

I recently attended the Over The Air mobile development conference at the historic Bletchley Park, Home of the Codebreakers. This was a superb event including talks and hackday challenges covering a variety of categories. The challenge lasted just over 24 hours and in this time teams and individuals had to come up with something that was fun, useful, clever or just plain stupid! I had decided to enter the Internet of Things category and here is a description of what I came up with during that time. The photos included here were taken at the time of the event and subsequently used in my 90 second presentation for the audience favourite.

The venue: Bletchley Park
2013-09-27 13.51.49

The hack idea

By the evening of the first day I still didn’t have nay idea as to what I was going to do, other than using Node-Red as a way of interconnecting a number of devices. I had taken a large box of Arduino, mbed boards, cables, components, sensors, pcbs, tools and devices. I was looking to do something with wireless sensors that I had taken with me but what, I wasn’t sure. I eventually came up with the idea to use the TFT LCD display I had built previously. This would become a display for the temperature and also the number of tweets detected with the hashtag #ota13. As an added feature I added some very bright addressable RGB pixel strips as everybody likes flashing lights!

Implementing the hack

The Hardware

The temperature sensor node is a pcb and Ciseco SRF module running the LLAP thermistor firmware. For demo purposes it was set to send the temperature reading every 60s. Full details of the sensor node are in a previous post.

2013-09-28 13.31.45

The display is based on a Ciseco RFu-328 which is basically a tiny Arduino with a SRF radio module in a surface mount form factor. The display is a cheap 128×160 SPI display. Its all put together on a PCB that I’d previously designed and had manufactured by Ragworm. A recent post describes the display. As an additional feature I decided to add a pair of Adafruit NeoPixel strips to provide an indication of the number of tweets seen. The connections for these had already been designed into the PCB, but up until this point, no sockets had been soldered on. The sketch used is available for download.

2013-09-28 13.31.36

To be able to receive temperature readings from the sensor and to send updates to the display I used a USB SRF Stick plugged into my laptop.

2013-09-28 13.32.02

The Software

The obvious choice for integrating the various bits of hardware and other systems is the new Node-Red, Node.JS application. The screen capture of the nodes may look like there are a lot of nodes in there but this includes many debug and inject nodes used for debugging and testing the application. I’d pre-installed Node-Red onto my Windows7 laptop and installed all the required libraries, making sure it actually ran too. So during the hack day, it was only a matter of dragging the appropriate nodes into place, linking them up and writing the functions to do all the clever bits.


The two main input nodes receive the LLAP input from the temperature sensor and search for new tweets with the hashtag #ota13. The input from the temperature sensor is formatted into a single message then directed to three (there is a fourth shown but this was not used in the hack) nodes that reformatted the data to a Xively datastream, sent it via the api to my mobile phone and the third was to re-broadcast the temperature reading to the wireless display module. The second input node reads a twitter stream and filters on the hashtag #ota13. A count is incremented and the new value is sent to the wireless display. The code for the main nodes is shown at the end of this post.

The twitter input node was configured with my usual twitter name and I’d put ota13 into both the tags and topic boxes. I’m not sure this made much different as it didn’t seem to catch every tweet with the hashtag.

2013-09-28 13.33.11

The Xively output was setup to send the request to a newly created feed and datastream using the MQTT API. This is easy to setup using a MQTT output node, entering the hostname and using a topic of api_key/v2/feeds/feed_number/datastreams/0.csv. Where api_key is the API key for the feed with write permissions and feed_number is the number of the feed.


Node-Red functions

These can be pasted into the function nodes to perform the given action. For some reason the code tags are not preserving the format.

Parse LLAP – input from temperature sensor

// name: Parse LLAP message
// outputs: 1
// anything stored in context is kept available for next time we get called
context.buff = context.buff || "";
context.count = context.count || 0;

// wait for an a and reset the buffer and counter
if (msg.payload == "a") { context.count = 0; context.buff = ""; } // this does mean the a must NOT appear elsewhere in the message

// add payload to the buffer and increase the count
context.buff = context.buff + msg.payload;
context.count += 1;
// when we reach 11 then output the whole message, assumes length is the a plus 11 - may need to tweak...
if (context.count == 12) {
msg.topic = context.buff.slice(1,3); // return the first two chars as the topic
msg.payload = context.buff.slice(3); // return rest of the buffer as the payload
return msg;
return null;

Format Xively – Output to Xively for logging

var msgType = msg.payload.substr(0,4);
if( msgType == "TMPA") {
// Create message
var value = msg.payload.substr( 4, 5);
// Strip any - chars
value = value.replace(/-/g,"");
var msgPayload = value;
var newMsg = { payload: msgPayload };

return newMsg;
return null;

Format Temperature for Pushbullet

var msgType = msg.payload.substr(0,4);
if( msgType == "TMPA" || msgType == "LVAL" || msgType == "BATT" ) {
// Create message
var value = msg.payload.substr( 4, 5);
// Strip any - chars
value = value.replace(/-/g,"");
var msgPayload = "Temperature is " + value + "C";
var newMsg = { payload: msgPayload };

if(msgType == "TMPA" && msg.topic == "T4" ) = value;
else if( msgType == "TMPA" && msg.topic == "T2" ) = value;

return newMsg;
return null;

Format LLAP to send to wireless display

var msgType = msg.payload.substr(0,4);
if( msgType == "TMPA" ) {
// Create message
var msgPayload = "aNPTMPR" + msg.payload.substr( 4, 5) + "-----";
var newMsg = { payload: msgPayload.slice( 0, 12 ) };

return newMsg;
return null;

Extract Hashtag to count tweets and send count to wireless display

var entities = msg.tweet.entities;
var hashtags = entities.hashtags;
var newMsg;
try {
var numTags = hashtags.length;
if( numTags > 0 ) {
var tagName = hashtags[0].text.toUpperCase();
else if( tagName == "OTA13" || tagname == "OTA2013" || tagName == "TESTOTA13" ) {;
var count =["tweetCount"] || 1;

var llap = "aNPTWOA" + count + "-----";
// Extract first 12 chars
newMsg = { payload: llap.slice(0,12) };
count += 1;["tweetCount"] = count;
return newMsg;

return null;

} else {
newMsg = { payload: "No tags" };
return null;
} catch(e) {
newMsg = { payload: e };
return null;

That’s it, the hack was entered into the Internet of Things category and won first prize, winning a Fez Spider starter kit worth about £200.
Look out for some .NET Gadgeteer posts!

My slides from the Over the Air presentation are available at SlideShare.

Using Node-Red with OpenRemote for basic home automation

I’ve recently been using a new tool that describes itself as “A visual tool for wiring the Internet of Things“. More details are available at their website The idea is that ‘things’ can be brought together in a visual manner without any programming, although a little coding in JavaScript is needed in places. I’ve also been looking at OpenRemote to provide a tablet based front-end for home automation and monitoring. For this project I selected the D-I-Y approach using the open source version available from MQTT is also being used as a message passing mechanism. The broker I use is the most excellent Mosquitto. This post described a basic setup for using Node-Red and OpenRemote to produce a simple tablet based control and monitor application. Full details of Node-Red, OpenRemote and Mosquitto are available on their websites and should be referred to for installation and configuration of these packages.

The components

I have a number of components that need to be linked together, these are on the hardware side:

  • 2 Channel wireless relay board, based on Ciseco SRF module
  • Linux server to run the stuff on
  • Ciseco XRF with FTDI interface connected to Linux server
  • Nexus 7 tablet

And on the software side:

  • Node-Red
  • OpenRemote controller and Android app
  • Mosquitto MQTT broker


Wireless communications is being done by the Ciseco SRF modules using the LLAP protocol described in detail here.

The relay boar id controlled by sending the command aRLRELAYAON- to turn on relay A on board with an ID of RL. The relay board will respond to indicate the state of the relay.

Within the server, the messaging broker will have topics that the various parts of the Node-Red application can subscribe and publish to. For example, to send new LLAP message, I would publish to a topic llap/send. Received messages from sensor nodes would publish to their own topics, for example llap/T4/TMPA or llap/T4/BATT which would be for the sensor node T4 where the temperature and battery voltage are published to.

One final part of the communications is to provide a basic HTTP interface to control the relays and provide feedback to the OpenRemote application.

Building the Node-Red application

Interfaces to wireless devices

The first part is to receive LLAP messages from the module plugged into the Linux server, this uses the Serial input node then builds up the complete 12 character message. The LLAP message is then split up by the second function before it is finally published to a MQTT topic. A number of debug nodes are included for debugging purposes and can be turned on and off at runtime to display messages being passed between the nodes. A number of values are also stored in the Node-Red global context variables for retrieval later.


Code for the LLAP Parse function:

// name: Parse LLAP message
// outputs: 1
// anything stored in context is kept available for next time we get called
context.buff = context.buff || "";
context.count = context.count || 0;

// wait for an a and reset the buffer and counter
if (msg.payload == "a") { context.count = 0; context.buff = ""; } // this does mean the a must NOT appear elsewhere in the message

// add payload to the buffer and increase the count
context.buff = context.buff + msg.payload;
context.count += 1;
// when we reach 11 then output the whole message, assumes length is the a plus 11 - may need to tweak...
if (context.count == 12) {
msg.topic = context.buff.slice(1,3); // return the first two chars as the topic
msg.payload = context.buff.slice(3); // return rest of the buffer as the payload
return msg;
return null;

Code for LLAP to MQTT function:

// Topic is part set, now see if TMPA, LVAL or BATT msg

var msgType = msg.payload.substr(0,4);
if( msgType == "TMPA" || msgType == "LVAL" || msgType == "BATT" ) {
var newTopic = "llap/" + msg.topic + "/" + msgType;
var value = msg.payload.substr( 4, 5);
// Strip any - chars
value = value.replace(/-/g,"");
var newMsg = { topic: newTopic, payload: value };

if(msgType == "TMPA" && msg.topic == "T4" ) = value;
else if( msgType == "TMPA" && msg.topic == "T2" ) = value;

return newMsg;
return null;

The second part is to subscribe to the topic llap/send and pass the message out through the Serial out node and onto the wireless devices that would be listening for it.


The code for the LLAP format function:

var newMsg = { payload: "a" + msg.payload };
return newMsg;

I have additional nodes that take received LLAP messages, parse them and store the values in the global context for later retrieval.

Interface to Openremote

Next I provided a way to read the previously stored values in the Node-Red global context, this takes a URL of the form http://ip_address:1880/sensor?name=varname where varname is the name of one of the variables. The value is returned without any other formatting or markup. The values I’ve setup this way include temperature measurements, electricity usage and relay states.


The code for the Get Reading function:

var name =;
var reading =[name];
var newMsg = { payload: reading };

// Send http response
msg.res.send(200, reading );

return newMsg

In order to control the relay board I’ve setup another node to receive http requests of the form http://ip_address:1880/relaycontrol?relay=a&action=on. This will post a message to the MQTT Topic llap/send that will in turn be picked up by the nodes previously described and turn on the relay. Other options are to select either relay a or b and to turn them on, off or tog (toggle).


Code for the Relay To MQTT function:

var deviceId = "RL";
var cmd = "RELAY";
var id = msg.req.query.relay.toUpperCase();
var origAction = msg.req.query.action;
var action = msg.req.query.action.toUpperCase();
if(action == "ON") action="ON-";
var llap = deviceId + cmd + id + action;
var newMsg = { payload: llap };

// Send http response
msg.res.send(200, origAction );

return newMsg;

Building the OpenRemote Application

The OpenRemote Android or iPad application connects to the local controller to retrieve the details needed to draw the panels on the screen that perform the control actions defined using the OpenRemote designer. To start with, OpenRemote needs a number of components defining. These are the building blocks that provide the functionality for a particular device. In the example presented here, I have associted them with a device called Node-Red which is my linux server with Node-Red running on it. The components are:

  • Commands – Perform communication with a device using a variety of different protocols and methods and polling intervals
  • Sensors – Define asensor that uses a command to read a value, range of values or custom data
  • Switches – Select the commands to turn the device on, off and determine its state
  • Slider – Select a command to send a range of values depending on slider position

In the example below, I’m setting the http command to access the relay control node that was previously defined using Node-Red.If this was a slider command then parameters could be passed in the URL using parameter notation ${param}.


Once the commands, sensors and switches have been defined, you can start on the panel layout by adding labels, buttons and images to create your panel. Multiple panels can be created and accessed via a series of tabs or sliding from left to right. An background image can be used to create different effects and styles.


When using switches, you need to select both an ON image and an OFF image to show the switch or button state. The community version of the designer doesn’t come with any images so you need to provide your own. I used a couple of images found on the net but for my final design I’m looking to employ a graphic designer to work on new images and the user interface. But for now its not pretty but is functional. The switches are defined as shown in the image below, they need the name, sensor selected from the drop down of available sensors and the images to use for the on/off states.


Adding labels that have a sensor associated with them will draw the received value where the label is positioned. You need to remember to set a polling interval in the command setup otherwise your readings wont be updated.

This is only a small selection of what OpenRemote can do. I’ve not even explored the many protocols and devices it can control or the macros and rules that can help automate tasks. I’ll leave this for another time.

Testing the application

When the panels have been designed and you are happy with it then you need to sync the design with your controller. This can be done in an online or offline mode. Online is the most convenient method as you just need to select the controller url of the form http://server_ip:8080/controller then enter your OpenRemote designer username and password and click the Sync with Online Designer button.

The Android app is available in Google Play, however this is an old version, following the links on download page will get you the latest version. If you use your tablet and have the option to install software from non-marketplace sites then you should be able to download and install directly.
If all is well then you should see your panel appear on the tablet. The buttons should be selectable as shown in the demo video below.
If the switches fail to operate correctly then it could be down to the sensor part not working correctly as it appears the state of the switch needs to be correct for it to change the image and command used.

Quick Demo video

Listen for the Exterminate as its triggered by the relay board when the second round button is pressed.

Have fun if you decide to try this yourself.

Programming Ciseco SRF LLAP Firmware

I’ve been using a number of Ciseco SRF Radio modules recently, including designing my own PCBs to produce temperature sensors and button sensors. The firmware used is for the XRF range of devices, but as they use the same chip, the firmware will mostly work. There are one or two exceptions, plus the fact the XRF firmware is not supported by Ciseco when programmed onto the SRF modules. Firmware is available from Github repository.

The SRF is hooked up to my SRF programming jig. This is basically a number of spring loaded pins that provide power and the serial rx/tx signals for the SRF module.
2013-09-10 20.32.49

A FTDI cable was used to connect to my programming jig. The Ciseco XCM software is available from, the Ciseco support site. The SRF are shipped with serial pass through firmware loaded, running at 9600 baud. Using the Download config option you can verify that the SRF is responding to commands.
2013-09-10 20.44.23

Once you are happy that the XCM software is communicating with the SRF, you can re-program the firmware. Select the Upload Firmware tab, select the image to use then press the 3 buttons in turn to Program, Verify and Commit the new firmware. Once the firmware has been committed, the SRF will restart. When the SRF starts, it will send a a–STARTED– message 5 times.

2013-09-10 20.47.24

Using the Download config option again should confirm the firmware has been uploaded.

Once the firmware has been uploaded, the SRF can be soldered onto your board.

TODO: On board re-programming.

Using Node-Red with Ciseco LLAP devices

I’ve been using the Ciseco wireless modules for a while now and after seeing Node-Red I wanted to use the Ciseco modules as both an input and output to the nodes. This post describes how to setup the Serial In and Serial Out nodes to use either the USB SRF Stick or the XRF and a FTDI breakout module.

The Serial In node node should be dragged to the workspace and by double clicking on it, you will get the edit dialog.


This one has already been configured, but selecting the Add new serial port… option and clicking the Pencil icon will allow you to define a new port


In this example I have used /dev/ttyUSB0, alternatives could be /dev/ACM0. Select the correct speed and clear the newline character. The node should be named something suitable, such as LLAP In. Do the same with the Serial Out node, this time there should already be a serial port defined. Select this and give the node a name, for example LLAP Out.


Once you have the serial nodes defined, you can start to build up the received LLAP messages. This i sdone with a function as each time the Serial In node receives a character it passes it on. The function identifies the start character, builds up the message and then passes it to the next nodes.

The output of the LLAP Parse function will store the LLAP node ID in the msg.topic property and the rest of the message in property msg.payload. For example, if the received string is aT4TMPA19.56 then msg.topic will contain T4 and msg.payload will contain TMPA19.56. The function looks like this:


Code, for cut and paste:

// name: Parse LLAP message
// outputs: 1
// anything stored in context is kept available for next time we get called
context.buff = context.buff || "";
context.count = context.count || 0;

// wait for an a and reset the buffer and counter
if (msg.payload == "a") { context.count = 0; context.buff = ""; } // this does mean the a must NOT appear elsewhere in the message

// add payload to the buffer and increase the count
context.buff = context.buff + msg.payload;
context.count += 1;
// when we reach 11 then output the whole message, assumes length is the a plus 11 - may need to tweak...
if (context.count == 12) {
msg.topic = context.buff.slice(1,3); // return the first two chars as the topic
msg.payload = context.buff.slice(3); // return rest of the buffer as the payload
return msg;
return null;

All the nodes can now be put together to send received messages to other services, or use other inputs to generate LLAP messages to send out.



Thanks to @Dave CJ for helping out with the LLAP parsing function while I get my head round Node.Js.

Simple Wireless Display using Ciseco RFu-328

The Idea

For a while I’ve been tinkering with the Ciseco RFu-328 Arduino compatible wireless module but hadn’t done much with one. I’d obtained a pair of 1.8″ SPI TFT displays via an eBay seller in China that I had previously used with Arduino and mbed modules. The displays are driven using the Adafruit ST7735 library. I built a quick prototype and was able to test the basic LCD software. I then decided to go for a proper PCB design based on my recent experience designing PCBs using EagleCAD.

The remote sensors I was using are all base don the Ciseco SRF radio modules using the LLAP protocol described at

The PCB was manufactured in the UK by


The features I wanted to include were:

  • Compact design
  • Battery powered
  • Over the air programming – No cables!
  • Mini Joystick for control – Eagle footprint available in Sparkfun library
  • Additional PWM or NeoPixel outputs for indicators
  • Software should display nodes and the values they send
  • Include timer to remove nodes that dont respond after a certain time
  • Display receive battery voltages, if nodes support it

Build and use pictures

2013-09-03 12.05.11

2013-09-03 17.28.58

A quick trial fit of the display and spacers Starting to populate the board
2013-09-03 17.11.12

2013-09-03 17.05.41
More components and headers added Working display

EagleCAD files

Files are available from SolderPad.


This is the early stages of this project, future plans include:

  • Use joystick to navigate menus for setup and control
  • Be able to send LLAP commands for control of relay boards
  • Use as a range tester for mapping signal strength around a building

More to follow….

Custom PCBs for Ciseco SRF Wireless modules

After my earlier experience of designing and having manufactured my own PCBs, I found I’d like to do more. This time using the Ciseco SRF surface mount wireless module. The company provide the EagleCAD schematic and PCB footprint for the module so it is a case of building the PCB around these. I did a quick presentation at the July Reading Geek Night covering the topic of producing PCB using EagleCAD, slides are available on SlideShare.

The SRF used, has been pre-programmed with the Ciseco LLAP Thermistor firmware for the XRF modules. As these share the same chips, this approach works with most of the XRF firmware, however, this approach is totally unsupported by Ciseco due to slight differences in the two modules.

Building a wireless temperature sensor

2013-07-21 20.21.21

2013-07-21 20.24.26
The components needed, PCB, SRF module, coincell holder, coincell, 10K resistor, 10K thermistor and wire for antenna. Center contact of battery requires a solder blob. Just enough to be proud of the PCB is enough.
2013-07-21 20.28.12

2013-07-21 20.31.04

The coincell holder solders onto the 2 pads, following the orientation of the silk screen. The 10K resistor and thermistor are soldered into the correct place as shown.
2013-07-21 20.32.08

2013-07-21 20.33.45

The SRF can be a bit tricky to solder the first joint, so a lump of blu-tak or similar holds the SRF in place while the first joint is made. I suggest the antenna pad. Once the SRF has been secured you can solder all the pads. I have only soldered the ones being used here, the antenna, power, analog input plus the two serial Tx/Rx pins.
2013-09-10 21.24.12 2013-09-10 21.33.09

Updated The updated boards arrived. They are slightly smaller and with a 4 way header for power and comms for programming. Updated New version built

First use

To setup the sender you’ll need another compatible device to see the messages and send messages. I use the Ciseco SRF Stick which is a USB based SRF module. I then use TeraTerm to display the messages being received. Setting Terminal option to display local echo will enable the commands to be seen as you type them.

When the SRF with the LLAP firmware is powered up, it sends a string of STARTED messages with a default node ID of . The idea here is that a LLAP enabled hub will assign a suitable address. For now, we’ll configure the sensor manually.


Set the Node ID using command a–CHDEVIDT4 where T4 is the new node ID:


The command is echoed back if received successfully.


Reboot the device to set the new Node ID, the device will restart and advertise itself as started:


SRF responds with:


The sensor now has the node ID T4 and this can be used in addressing the sensor now.

The sensor needs to be set into a cyclic sleep mode to wake up at a scheduled interval and send a reading, I chose 60S for testing but changed to 300S (5mins) to extend battery life:


SRF responds with:


The interval has been set and a temperature reading was returned.

Now put the sensor to sleep:


SRF responds with:


Now, every 60S, a reading will be sent and every 10 readings the battery voltage will also be sent.

Increasing range
The built in antenna has a reasonable range, but can be restricted by walls and floors. To increase the range you can add a wire antenna. This should be about 82mm long and soldered to the ANT pad on the PCB. The onboard antenna is removed by either unsoldering or cutting through the tiny inductor bridging the row of holes then snapping the board to break off the redundant part.

2013-07-21 20.50.25

Other boards
The multi purpose PCB I have designed can be used as:

  • Temperature sensor using thermistor
  • Light sensor using a light dependant resistor< li>
  • Single button remote control
  • Magnetic switch using hall-effect sensor
  • Remote tilt sensor using a tilt switch

More builds to follow

EagleCAD files

Files are available from SolderPad.

Using the Scrolling message display

Following on from a previous post describing the scrolling message display, I’m adding a few notes on how to use it with a service called If this then that (

The idea behind IFTTT is tthat when an event occurs on one application or site it can trigger another application or event. There are a number of channels including Google Calendar, date and time, weather, Facebook, Twitter, Foursquare, Dropbox, Google Drive, Skydrive, RSS amongst others and interestingly SMS.

It is the ability to send SMS when a certain event occurs that can create messages for the scrolling message display. For example I have created recipes for:

  • Send SMS when I checkin with Foursquare, showing my location and date/time
  • Send SMS when an event in my Google Calendar is to start
  • Send SMS with daily summary of weather, days high/low etc
  • Send SMS if tomorrow is to be cold or rainy
  • Send SMS when new mail recieved in GMail inbox

Other ideas could be to send a message when trains are delayed by using the RSS feed, to send a message when someone tags you in a photo on Facebook.

Its use is only limited by your imagination and and the technical tools you have for sending SMS messages.

UPDATE: At present the IFTTT SMS channel is not working with UK networks therefore I am unable to receive updates. No estimate for a fix has been provided by IFTTT.