aPROTOCOL an introduction

aProtocol is part of a family of solutions designed for highly intelligent sensor networks for energy saving, monitoring and electronic & manual device control. We have learnt from other protocols (just a big word for the definition of how they talk to each other) and tried to make this as simple as possible.

We have purposefully chosen to make the architecture open and simple, yet extremely powerful and even customisable beyond the core commands.

The aProtocol communications protocol is very simple to use. It’s limited character set is easily understood for programming and debugging. It’s extendibility beyond the core character set could potentially accommodate ten’s of thousands of sensors in a custom or industrial setting. In normal compatibility mode it's over 1200 sensors.

In aPROTOCOL compatibility mode the commands can be read by eye and sent or typed from programs such as Windows Hyper Terminal just as easily as from a PICAXE, PIC or other micro controller. It's easy to get the devices talking without any special software.

The majority of our examples are based around the PICAXE micro controller. This tiny one chip computer is a version of Microchip’s PIC but with a very easy to use BASIC programming language. It has been developed by Revolution Education http://www.rev-ed.co.uk and provides a great platform to start your projects on.

The PICAXE is inexpensive yet extremely powerful, and an ideal partner for us in terms of use and philosophy. Added to this it’s available worldwide from many different distributors if you decide to build your own devices rather than buy them.

An example command

Lets see how an aProtocol command is sent or received to a sensor equipped with one of the simplest devices, a Dallas temperature sensor.

All commands are made up of 12 bytes or text characters.

A sent command string may look like this “aC01T1------”.

What on earth does that mean I hear you shout, I’ll explain.

The first two bytes show we are sending an aProtocol command “aC”
The third and forth are the sensor we are sending to, in this case “01"
The fifth is the function “T” which is read temperature
The sixth “1" which is digital input channel 1 (the temp sensor is wired to)

The remaining “-----” bytes are just padding to complete the command to 12 bytes long, all commands and replies are always 12 bytes long.

The reply will look something like this “aR01T1+12.2--” which means it’s an aProtocol reply “aR” from sensor “01" doing a “T” temperature reading on channel “1" and the value is "+12.2" degrees.

All the commands are easy to follow and full documentation is available in the forum. The full command set isn't finished yet, we keep adding functionality and probably always will.

Why not join the forum and vent your ideas.