The article also provides an update on what’s been happening with Hooroo since it’s launch and how Continuous Deployment and the cloud not only helped fast track delivery, but also enable data to be collected in real time to discover what features work and don’t work.

Read our case study - Hooroo: A Qantas Start-up

Read the ZDNet article - Qantas Group checks into the cloud for hotel bookings success

ChargeIQ is the world’s first ZigBee-certified electric vehicle charger with the ability to communicate with Smart Meters, allowing drivers to take advantage of flexible pricing to reduce the cost of their electric vehicle charging.

Having spent over three years developing ChargeIQ, the Australian technology company is now looking to team-up with “heavy hitters” in the market to take its innovation to the rest of the world.

As part of the newly created role, Mr Handberg, who has an automotive industry background and a deep understanding of the global electric vehicle market, will help DiUS Computing commercialise the revolutionary technology and facilitate investment from partners in the energy and electric vehicle industries or new entrants into these markets.

A recent report from the US forecasted the market for electric vehicle infrastructure will rise significantly around the globe over the next decade, with an expected increase in the market from $140 million in 2012 to $1.2 billion in 2020.

DiUS Computing is leading the world with ChargeIQ.  In December 2012 ChargeIQ was used for the Victorian Department of Transport demonstration project – Electric Vehicle Charge Management using Victoria’s Smart Grid. The project was the first use of the Victoria’s Smart Meters for electricity demand management, and one of the earliest field demonstrations worldwide.

Mr Handberg said ChargeIQ is ready to be tailored to the needs of a commercial partner such as an electricity utility, electric vehicle manufacturer/seller or electric vehicle charging system supplier.

“We’re already in discussions with a number of potential partners who can see the market-leading ‘Smart Energy’ innovation embodied in ChargeIQ.  For these partners ChargeIQ can be a key enabler for their business or an extension of their Smart Energy portfolio,” Mr Handberg said.

DiUS Computing co-founder and director Clency Coutet said Mr Handberg’s expertise in the field will assist DiUS Computing in achieving their goals for ChargeIQ.

“Mr Handberg brings with him an impressive track record in the EV market as well as a background in engineering, which will significantly contribute to DiUS Computing’s strategic goals to take ChargeIQ forward,” Mr Coutet said.

-ENDS-

Media Contact:
Sonja Viduka at SoVi Communications on behalf of DiUS Computing on 0425 718 662 or Email info@sovi.com.au

About DiUS Computing:
DiUS Computing is an Australian-owned technology company, comprised of over 100 talented professionals across Melbourne and Sydney with a passion for emerging technology and its intelligent business application.

DiUS Computing’s involvement with Victoria’s Advanced Metering Infrastructure (AMI) program began in 2006. Since then, DiUS Computing has helped a number of Australian utilities with technology strategy, planning, architecture, design, build, testing and procurement related activities for their AMI solutions.

With DiUS’s enduring company focus on fostering and stimulating innovation, we’re thrilled to support Agile Australia 2013’s focus on how business can use an Agile approach to stay ahead of the curve.

Agile Australia 2013 features an inspiring range of keynotes from international thought leaders on the idea of accelerating, or fast-tracking, innovation through Agile delivery methods:

• Bjarte Bogsnes , Author, Beyond Budgeting
• Ryan Martens – Co-Founder and Chief Technology Officer, Rally Software
• Mary Poppendieck – Author, Lean Software Development: An Agile Toolkit
• Dave Snowden – Chief Scientific Officer, Cognitive Edge.

There’s also an impressive line-up of local talent focused on showcasing strategies and new ideas, as well as mastering fundamental building blocks, to help establish an environment where innovation thrives. DiUS will be presenting two talks:

Make a real difference: Community innovations for social good
Pete Cohen, DiUS Business Analyst and Random Hacks of Kindness (RHoK) star, is teaming up with Julian Smith, Senior Policy Officer at the Department of Sustainability and Environment to talk about how technology communities are using technology to develop innovative and sustainable solutions to development problems. This session presents a case study of a recent RHoK hackathon that developed a solution that enables emergency crews to keep track of one another’s locations and share real-time information about a fire on their smart devices.

A disruption story: how an Australian startup helped a utility giant lead the electricity market into a new world of smart energy
Mark Anderson, DiUS Smart Energy Lead and co-founder and Chief Technology Officer of Percepscion, is going to talk about how an Australian utility giant was able to disrupt and lead the heavily regulated energy market into smart energy with a world-first Energy Monitor fridge magnet that displays customer power consumption in real-time. The session explores the challenges of innovating to create product differentiation and deliver added value to customers.

For more information on the conference agenda and speakers, please visit the Agile Australia website.

In the last episode, I described my first attempt at getting the ZigBee modules communicating with messages, using a JSON format. It worked, but this approach was not very efficient for a couple of reasons:

• It increased the bandwidth required to send each image segment by a factor of two.
• It required a Base64 encoding and decoding step for each image segment.

Another shortcoming of this approach is that it used the XBee’s transparent serial or ‘AT’ mode, in which the connection to both ends look like a serial cable between the remote node and the Coordinator. This was not going to suit my ultimate objective of having multiple remote nodes, all sending images to a central repository through the Coordinator, because I would need to reconfigure the Coordinator each time I wanted to receive data from a different remote node. Transparent AT mode is great for one-to-one node communications, but that’s not my real goal here.

The XBees have another mode, called API mode, in which a client can send and receive low-level data packets and individually address each one. I will use this mode to resolve the shortcomings of my JSON-based approach.

There are a number of client libraries that handle the marshaling and unmarshaling of the underlying ZigBee data packets. There’s an Arduino library called xbee-arduino which I could see is well-supported and mature.

For the server-side, in the last episode I used a Ruby script running on my Mac Pro. This was easy to get going and worked well for early development. For the future, though, I want the Coordinator to use a server running on a Raspberry Pi. This is of course because Raspberry Pis are cool, and a Pi can be running 24×7 much more cheaply and easily under a pile of papers on my desk than running my Mac Pro all the time.

With the pieces in place for API mode, I needed a new protocol, this time based on binary messages. I don’t have much space to play with; for a Series 2 XBee with ZB Pro firmware like the modules I’m using, the maximum payload size for each packet is 84 bytes. Using encryption reduces the size further. So far I’ve been using 32-byte segments for the images, mainly so the very small serial buffers on the camera and Arduino don’t get overwhelmed; I’ll stick with that size to make sure the segments can fit into a packet even if I want to use ZigBee encryption later.

At this stage I want to send two types of messages from remote nodes, for images and information, but there may be more in the future. So I’ll use the first byte of the payload to indicate the message type. Just for fun, I will choose arbitrary values: 0xf3 in the first byte of the payload to indicate a packet contains an information message, and 0xf4 for image messages.

DiUS Computing is proud to announce its sponsorship of Web Directions Code 2013. The two-day conference will be held in Melbourne on the 2nd and 3rd May 2013.

Web Directions Code 2013 is focused on the art and science of programming for the web with HTML, CSS and JavaScript. The impressive line-up features CoffeeScript and Backbone inventor Jeremy Ashkenas, everyone’s favourite “big CSS” guru Nicole Sullivan, Etsy’s Garann Means, “Mr Maths” Steven Whittens, Twitter’s Angus Croll, as well as many other local and international experts in JavaScript, CSS and HTML5.

For more information on the conference agenda and speakers, please visit the Web Directions Code 2013 website.

Now that I had the radios talking to each other, I wanted to try out the camera. I chose the Weatherproof TTL Serial JPEG Camera from Adafruit.com, based on the VC0706 security camera digital processor from Vimicro. The core part of the camera is a 1/4-inch CMOS sensor. A microcontroller can talk to the camera through a serial port; sending a command over the serial port to take a photo and retrieve it will return a JPEG image up to 640 x 480 pixels. The serial port baud rate can go up to 115200 baud. You can send it commands to change focus, and also to take a snapshot when it detects movement.

Another nice thing about this camera is the weatherproof enclosure, and the array of infrared LEDs and a built-in light sensor; if the light sensor detects there is not enough visible light, it switches on the infrared LEDs to illuminate the scene, making it possible to take night shots. At USD$55, I reckon it’s good value.

The camera module uses 3.3V logic on its pins; the Arduino uses 5V, so I needed to have a voltage divider on the input to the camera so that voltage levels don’t blow it away.

This is the circuit:

The TX and RX pins refer to the transmit and receive pins, relative to their module. Pins 2 and 3 on the Arduino will be used for serial receiving and transmitting respectively. RX and TX on the camera are for receiving to and transmitting from the camera.

For now, I wired this up on a small breadboard.

Adafruit have done a lot of work to make this camera as easy to use as possible. They have published an Arduino library and examples for talking to VC0706-based serial JPEG cameras with a higher-level API. It’s quite simple to get the camera to take a snapshot and read it out from the serial port. Then I only needed to send it to the serial port on the XBee module to get the image to the Coordinator and the receiving node.

Since I was now sending a couple of different types of messages, binary images and text debug and information messages, I needed to design a simple message protocol. I decided to use JSON format.

A debug and information message looks like this:

To decode these message types, I changed the Ruby server to handle each type. If it receives an ‘inf’ message type, it just prints out the message contents. If it receives an ‘img’ message type, it decodes the Base64 string into an array of bytes. When it has received all the image in the byte array, it writes the image to a file and waits to receive the next one.

On the Arduino side, I needed to set up the serial port as before, and to initiate the camera. As indicated in the diagram above, the camera module is connected to digital ports 2 and 3 on the Arduino. Basing the code on the Adafruit snapshot example, it looked like this:

The best part is how well the infrared LEDs automatically illuminated the same scene when I turned off the lights.

I’m hoping this will work really well out in the field. More on that later.

With the XBees running at 115200 baud, it seemed to take an average of 20 seconds to send a 45K-byte image. Keen observers, or even casual ones, will note that by choosing a JSON format for the messages, I have effectively doubled the number of bytes required to send an image to the server. I will fix that problem in the next installment.

DiUS Computing is excited to announce its sponsorship of the Amazon Web Services (AWS) Summit 2013: Navigating the Cloud in Sydney on April 24, 2013 at the Hilton Hotel.

AWS Summits are free, one-day events hosted in 12 major cities around the world. These events are designed to provide developers and technical leaders with an introduction to the AWS Cloud and guidance on architecture and engineering best practices. Whether you are new to the cloud or an experienced user, you will learn something new at the AWS Summit.

The Sydney AWS Summit features a keynote address from Adam Selipsky, VP of Amazon Web Services, customer presentations and technical content specifically designed for new and experienced users.

Customer case study: Hooroo – How the cloud and a Lean mindset helped Qantas launch a new business

A joint presentation by Warner Godfrey, DiUS Computing, and Bruce Fair, Hooroo, at the AWS Summit in Sydney will cover how DiUS used the cloud to help Qantas successfully enter the burgeoning online travel market with the speed, scale and agility typically associated with a start-up.

Twelve months on and now a global player, we examine the challenges, successes, what we’d do differently and the changing measures of success.

Also covered is how Qantas responded to the commercial challenges of using the cloud such as security, privacy and data sovereignty, and the key development practices such as Continuous Deployment that facilitated three major production releases in 15 months, for Qantas, Jetstar and the launch of a new brand, Hooroo.

In this video of the Tech Report interview Joe explains how ChargeIQ works and how it enables consumers to take advantage of flexible pricing to reduce the cost of their electric vehicle charging.

He discusses how DiUS has been working for the past few years with the Victorian Government on ChargeIQ and that the technology has been in the field for over two years as part of the Department of Transport’s Electrical Vehicle Trial.

The company plans to team-up with “heavy hitters” in the market to take CharqeIQ to the rest of the world and to as many parts of the electric vehicle market as it can.

Video length: 3 minutes 50 seconds

Vist the ChargeIQ website for more information.

With the parts gathered, the next step was to get the XBee modules communicating with each other. Just to be clear on the terminology I’m using: ZigBee is a communications protocol for low-power wireless mesh networking. The XBee modules I’m using are radio modules from Digi that use the ZigBee protocol. There are other XBee modules that use different communication protocols, but for this project it’s ZigBee I’m interested in.

To begin, each XBee module needs to be configured according to its role in the network. A ZigBee network needs one Coordinator, which is a node that forms the network, hands out addresses to other nodes, and routes information between nodes. A Router node can join a network, send or receive information, and route information from other nodes. An End Device node can also join a network, but it sleeps most of the time, and only wakes up to send or receive information. It doesn’t route information from other nodes. The diagram below shows an example network with the three node types.

For this project, the Coordinator will be the node at the house, and the node to which all the remote nodes send images. The Coordinator can be anywhere on the network, but since it plays a vital role on the network, I thought it would make sense to give it the most reliable power source.

One of the nice features of a mesh network is that it can create new data paths if a Router node becomes unavailable, or if the signal strength of one of the available paths changes. For example, the End Device on the right-hand side of the diagram has two paths to choose from; if one of the Router nodes becomes unavailable, the other Router node can be used to send data to the Coordinator.

To get the XBee modules talking, I set up the simplest network possible, with a Coordinator and a Router, as shown in the diagram below.

The Coordinator will be the XBee module on the XBee Explorer USB dongle. The Router will be the XBee module on the Arduino shield.

To tell each module its role in the network, and update its firmware, we need to use a utility from Digi, called X-CTU. X-CTU only runs on Windows, unfortunately, so Mac users will need to use Fusion or VirtualBox to spin up a Windows VM. I used VirtualBox for this.

We can also use X-CTU to tell a module which PAN (Personal Area Network) it belongs to, and configure its destination address, along with stacks of other parameters. We can also use the module’s terminal mode to do that, with AT modem-like commands.

The modules have defined serial number addresses, as each ZigBee radio is uniquely identified. On my modules, the addresses are:

Coordinator address

High: 13A200

Low: 409959F7

Router address

High: 13A200

Low: 409959D6

I decided to use a PAN identifier of 2001.

For the purpose of this initial setup, I told the Router that it’s destination address is the Coordinator, and vice versa. In the screen shot above, you can see that I’m setting up the Coordinator and setting its destination address to that of the Router.

I programmed the Arduino to repeatedly send a simple-but-friendly message.

int index = 0;

void setup() {

  Serial.begin(9600);

}

void loop() {

  String message = "Hello " + String(index++);

  Serial.println(message);

  delay(5000);

}

A potential trap for newbies is that, by default, the XBee shield uses the Arduino’s hardware serial port, which is also used for programming the Arduino with new sketches (the program running on the Arduino). Initially I thought I would need to take off the XBee shield each time I needed to update the Ardiuno’s software, which was going to get annoying after a while. Then I discovered the DLINE / UART switch on the XBee shield. In the DLINE position, the hardware serial port is used for uploading sketches; in the UART position, the hardware serial port is used for talking to the XBee.

On the Mac connected to the Coordinator node, I wrote a simple Ruby script to receive and display the messages from the Arduino.

require 'serialport'

sp = SerialPort.new "/dev/cu.usbserial-A901JYV9", 9600, 8, 1, SerialPort::NONE

loop { puts sp.gets }

With this setup, I was able to move the Arduino to the other end of the house, and the message was received by the Coordinator without any hiccups. Admittedly the 30m distance wasn’t much of a challenge for the radio, but it did need to go through several walls, a TV, a bookshelf, and a fish tank.

All good so far; onward to sending images! In the next installment, I’m going to get the Arduino capturing images from the camera.

I did build an Arduino-based prototype that worked. I chose Wi-Fi for the radio, which was certainly fast enough, but consumed too much power to be powered by a small solar panel, couldn’t easily be configured as a mesh network, and was really expensive. I shelved the project for a while, and filled my spare hours building iPhone apps instead.

A few weeks ago I finished reading Makers by Chris Anderson and Building Wireless Sensor Networks by Robert Faludi (both excellent reads, by the way), and I was inspired to have another try at my solar-powered, mesh-networked camera node. This time I’m trying ZigBee radios (XBee Pro 50mW modules), which have a decent bit rate, consume very little power, can easily be configured to form a mesh network, and are certainly cheap. This choice also presents a nice opportunity to get my hands dirty with ZigBee, which plays a key part in the products DiUS has built for the Smart Meter utility space.

I thought it would be interesting to document my journey, and that will be in the form of a series of posts here on the DiUS web site.

I kicked things off by ordering some parts from Sparkfun.com. It’s a very useful and well-stocked site for building gadgets. Here’s what I needed to get started:

• 1 – $29.95 – DEV-11021 – Arduino Uno – R3
• 2 – $81.90 – WRL-10421 – XBee Pro 63mW Wire Antenna – Series 2B (ZigBee Mesh)  ($40.95 ea.)
• 1 – $24.95 – WRL-08687 – XBee Explorer USB
• 1 – $3.95 – CAB-11301 – SparkFun USB Mini-B Cable – 6 Foot
• 1 – $1.50 – PRT-10007 – Arduino Stackable Header Kit
• 1 – $24.95 – WRL-10854 – XBee Shield

I already had an Arduino Duemilanove on hand, which was the latest thing in 2010. Now the latest version is the Uno R3, so I ordered one of those. It’s interesting to see them side-by-side; the updated design of the Uno is a lot cleaner.

The Arduino Uno R3 (right) PCB is a lot cleaner-looking than the circa-2010 Duemilanove (left). One of the nice things about the Uno is it uses a ATMega16U2 for USB, which means my Mac’s OS X recognises it without extra drivers.

The Arduino IDE is now at version 1.0, and after a quick glance the software development environment is more mature and the libraries are richer.

There are heaps of different XBee modules from Digi to choose from, but I settled on the XBee Pro 50mW Series 2B with a wire antenna (the 63mW version is switched to the 50mW version for non-US markets). I wanted ZigBee for the ability to set up a mesh network, so that the radio network will have resilience in the case of node failure, and so that each node doesn’t need to be within range of the “home” node. It’s supposed to have a range of 1.5 kms line-of-sight, which should be enough to hop between nodes. The maximum data rate of 250 kbps is faster than previous version of the XBee modules, and I figure it should be enough to send small images if I’m not fussed how quickly they all come in.

The XBee Pro 63mW module with wire antenna – Series 2B (ZigBee Mesh)

The XBee Explorer is really just a USB dongle that takes an XBee module and lets you talk to it over a USB port.

The XBee Explorer

The XBee Shield is for connecting an XBee module to an Arduino board. It takes the analog (PWM) and digital pins through, and the power line as well. It doesn’t come with stackable headers on the board; they need to be ordered separately and soldered in.

The XBee Shield with stackable headers soldered in. The trick for newbies is to get the headers sitting straight, which I almost managed to do.

The first part of the project will be to configure the XBee modules and just get them talking to each other. That’s what the next post will cover.