Networking PICAXE Microcontrollers

The above is a complete dogs breakfast and represents a number of networks that have been used by myself and others. The point of this article is to describe each network and why each one is not perfect, and to help create some protocols for communicating between networks. Given that this network can interface with the internet via several methods, there is no reason why this network could not be communicating with a similar network of ‘real world’ devices on the other side of the world.

This is perhaps the simplest network to interface to a picaxe though it has problems that mean the bus below with hang protection is a better choice. The bus is held low with a 10k resistor and each device puts data onto the bus with a 914 diode. Devices can put data onto the bus or listen to the bus and respond to messages. Because the PICAXE has the problem that listening to data via SERIN hangs the chip, devices can be ‘transmitters’ or ‘receivers’ but not both. A transmitter might be a device like a light sensor that is near a front door and detects the light coming on and transmits to the rest of the network to turn on some garden lights. A receiver would be the device that listens to the signal and turns on a mains powered relay. This all works fine, but after about 10 units have been added to the bus, data clashes start occurring and sometimes data doesn’t get through. Adding bi-directional comms (eg ‘did you get my message?’) does not work because of the SERIN problem – any device that starts listening for a reply hangs till it gets the reply, and a reply might never come back due to a data clash. The single wire bus is great for comms where it doesn’t matter if the data doesn’t get through – eg a tank measuring a level and sending the data every minute – if one packet doesn’t get through the next one will. It is not suited for comms where a data packet simply has to get through. The single wire bus is well suited to interfacing a number of modular picaxe units on a control board.

A picaxe that is about to send some data puts the bus high for a defined time (eg ½ a second then low for 10ms and then sends a Serout using N1200 or N2400 baud. Every picaxe is monitoring the bus at least 4 times a second and only if it goes high, it goes into SERIN. This means that most of the time picaxes are not stuck doing SERIN and that a single picaxe can be both a ‘sensor’ and a ‘doer’ and react to sudden changes in the environment without being stuck in SERIN. The bus is pulled low with a 1k resistor in one place. Devices communicate via a 914 diode in parallel with a 10k resistor. The diode allows the picaxe to put data onto the bus, and the 10k resistor allows the picaxe to read data on the bus. Let dirs = %00000000 sets all pins back to inputs after a Serout. This bus only requires one pin for connection, so leaves 4 other pins free on an 08M.

This is a protocol I have been working on to send data about 1Km over rough terrain. Overhead wires keep being struck by lightening. Undergrounding is not practical as the signals go up and down rocky cliffs. The mesh consists of multiple units powered by solar panels. Each unit has an RF transmitter and receiver and listens for data packets. If a packet is received and is for that unit, then the unit acts on the data. If the packet is for someone else, the unit waits a random time and then retransmits. Each packet has a unique header and each unit only sends a packet on once so packets don’t bounce around the network indefinitely. A wireless mesh has the advantage of being robust as the data takes multiple paths and will still work if some nodes are not functioning. The disadvantage is that the units have little spare power so only small amounts of data can be transferred eg one packet every few minutes.

I use this bus to control sprinklers and to send data down a fence line. Slow speed means about 1 byte every two seconds, and the data can be sent via relays controlling currents of several hundred milliamps. The advantage of this is that the data can go long distances (much further than 1200/2400 baud RS232) and can cope with things like a wire strung on wet wood poles with some resistance to ground.

The token ring is a physical ring of picaxe nodes where data packets called tokens are passed around in a circle. Bytes can be added or read from the packet. A token ring partially solves the SERIN hang problem and also avoid the data clashes that can occur on a single wire bus. It probably is the best network for a group of picaxes within tens of metres of each other, but would not be the network to extend out into the garden where comms become more unreliable as it is only as strong as the weakest link. It does use two pins on a picaxe vs one bi-directional pin for interfacing to a single wire bus.

This communication method would have applications for picaxes very close to each other – eg a group of mobile robots. Infrared is easy to interface between picaxe chips.

The internet is relatively expensive to interface to (in terms of picaxe costs) but would be the comms method of choice between two PCs any distance apart as WiFi/wired connections are so much faster than RS232 type speeds. The disadvantage of the internet is the ongoing costs of connection to broadband, and the power computers use (thousands of times more than picaxes). There are some very useful lessons to learn from the TCP/IP protocol which is the hidden backbone of the internet.

Picaxes on networks can do the same thing, with an id byte 0-255 on a local network such as a single wire bus, and then a second byte which identifies which bus to use. On the internet, once a data packet leaves a local network there are routers with lookup tables that route the message. We can use the same system on a local network with routers moving messages onto the correct bus which decreases congestion as not every packet goes to every single picaxe on the system. Single wire bus systems tend to get congested with more than 10 ‘chatty’ units but adding extra busses is easier than adding more units onto a congested bus. As with the internet IP addresses, someone needs to assign the numbers and for a home network, one needs to keep a record of the numbers somewhere. In practical terms, this is something that perhaps should be in a notebook as well as on a computer. So the picaxe sitting in the fridge detecting the light going on and off has an ID that is unique.

So far, nothing above is that novel, but the clever part is the routing of messages. Routers could be programmed with a lookup table for every network, but this would be impractical as the network grows as every picaxe would need to be reprogrammed. It makes more sense to build a network that can grow incrementally without every having to go back to working circuits. Hence in practice, a router sitting at the end of single wire bus #1 needs to check data packets and if they are for this local bus they can be ignored. If they are for another bus, they are sent on to another router. The message propagates round the network but only amongst the routers. It hence does not clog up other local busses unless it is meant for a device on that bus.

As networks grow there may be multiple data paths and hence messages could end up going round in circles forever. As with the wireless mesh protocol, every message packet has a unique random ID number and routers remember the last few numbers and only pass on new messages.

The TCP part of TCP/IP is the error checking part. With complexity comes unreliability. For single wire bus systems, data clashes start occurring. For token rings, the token can get dropped. Chips can reset due to power spikes, or get stuck on a SERIN. Routers could get two signals at exactly the same time. One practical error checking system is to have a checksum on a data packet. I have found a simple system is to make packets about 8 bytes long, and have a checksum word which is the sum of those 8 bytes. The second system is for a picaxe to send a message to another picaxe and to request an acknowledge. If no acknowledge comes back within a few seconds, then the message is resent.

Lots of packet protocols are possible and sooner or later one has to standardise on something. I went for 12 bytes DataABCDEFGHIJKL where A and B are random numbers making up the unique header, C is the originating device bus number, D is the originating device number, E and F are the destination bus/device, GHIJ are 4 data bytes and K and L are the checksum. ‘Data’ is the string SERIN waits for. UUUUUU can be added to radio packets to stabilise the Rx (01010101).

This consists of two 08 picaxes. Picaxe 1 listens to bus 1 and if there is data for any other bus/picaxe besides bus 1, then it puts the data on bus 2. Picaxe 2 listens to bus 2 and sends data to bus 1. Each works asynchronously.

A hub is a single unit that talks to lots of picaxes in a ‘star’ configuration, as per the modern CAT5 ethernet. Picaxes can’t listen to more than one SERIN at the same time so the next best solution is to use the "single wire bus with serin hand protection" protocol. All data packets are preceded by a high, and a picaxe can poll its inputs looking for highs, and then set the relevant pin to Serin ready for the data. There is a small chance data might arrive at two pins at once, but if picaxes are sending out packets asking for a reply and don’t get one, then they can resend that message. An 08M has three inputs it can use as inputs/outputs so an 08M can act as a router passing traffic between 3 separate bus lines. Any of those bus lines can also interface with another 2 bus lines with another 08M. Given a bus can support 10 or so devices, this means the network is scaleable.

One problem found during testing is that if a picaxe detects a high line and then goes into Serin and the data never arrives, it will hang. A router should not hang, so the answer is to use pin0 to send out regular pulses, say 10 per second. A second picaxe controls the power to the router picaxe and monitors these pulses and if they stop arriving for a few seconds, it resets the power to the router.

One picaxe needs to be the master on the token ring with an interface to other networks. Outputs from the ring are easy using SEROUT. Inputs to the ring involve two masters talking to each other. One master is on the ring and the other is waiting for inputs from the outside. These communicate via simple high/low signals and make sure they don’t inject packets onto the network at the same time.

Messages from the bus to the wireless mesh are an 08 listening to the bus and then sending data to a Tx radio unit. Messages from the mesh go via another 08 onto the bus (or to another router).

The creation of multiple interfacing networks can solve many problems in home automation and robotics. Multiple sensors can be interfaced with multiple controllers using networks suited for a particular purpose. Networks can be made scaleable, reliable and modular and it is possible to add to networks and nodes without dismantling systems that already are working.