PICNET

1.  The PICNET Nodes

A PICNET node consists of a Microchip PIC18F74 and a small number of associated components necessary to make it run (A crystal and a couple of capacitors and resistors), a level shifter chip to produce RS-232 signals, and whatever electronics is needed to interface with sensors, relays etc.

2.  The PICNET Network

2.1  Hardware

PICNET employs standard RS-232 serial communication at a baud rate of 2400.  The PICs simulate UART functionality entirely in software - a technique commonly known as bit-bashing - which is why the speed is kept so low.

The "network" is in the form of a loop, the server PC transmits to the first node, and then each node transmits to the next until the last one transmits to the server PC.

2.2  The Token Ring

The network works in the style of a token ring.  Basically the server PC sends a message and each node passes it on until it eventually returns back to the server PC.

When the PC wants to communicate with a specific node it sends out a message and each node examines the message's address.  If the address matches then the node acts on the message and transmits a response.  If the address doesn't match the node passes on the message unmodified.  There is also a broadcast address where any node can act on the data received but does not modify the message.

When the server has no messages to send it sends a special "empty slot" message round the loop.  Any node which wants to send a message to the server waits until it receives an empty slot and then transmits its message.  Nodes which have nothing to send pass on the empty slot unmodified.

There is no method in this design for nodes to send messages to other nodes, all communication is to and from the central server PC.

2.3  Message Format

All messages consist of four octets:
Octet 0 contains the address - 0 for broadcast, 1 to 7d for individual node addresses, 7e for an empty slot.  The top bit is set by the addressed node to indicate it has received the message.
Octets 1 and 2 contain the information of the message.
Octet 3 contains a checksum.

2.4 Message Information

This varies for each node and message type but usually part of octet 1 contains the message name and
the remainder of octet 1 and all of octet 2 are available for data.

2.5 Example Message Protocol

For a simple input output node there are only a very few messages:

1. The PC sends a Set Outputs message with the outputs value in octet 2.  The node's response has the top bit of octet 0 set and has the values of its inputs in octet 2.
2. The node takes an empty slot to advise the PC that one or more of its inputs have changed,  putting the input value in octet 2.
3. The node takes an empty slot to tell the PC it has just started up, and needs to be told what its output values are.  (Octet 2 in this message contains the build level of the node software.)

In practice, the majority of nodes use just the above messages, but some have other data.

3.  Design Decisions

3.1  Network Topology

As described above, I chose a ring arrangement for my network, but this is not the only possibility.  After I had implemented my system I was made aware of another domestic control system in which the remote nodes were connected on a sort of omnibus RS232 system where the control PC's transmit went to every node's receiver, and all the nodes' transmits were or'ed together.  There are pros and cons for either system:

The omnibus has to be able to cope with collisions where two nodes try to transmit at once.  If I recall correctly this was done by only allowing nodes to transmit when they were requested to do so by a message from the server.

The loop system suffers the problem that if one node fails or is powered off the whole network is down.  I avoided the power problem by adding a relay to each node which bypasses it when the power is off, but this still leaves the possibility of crashed software in the node stopping the whole network.  Use of the watchdog facility provided in the PIC chip should prevent this, but in practice I found the node software was so simple that there were no subtle bugs to cause problems - the software either failed in the first few seconds of testing or it ran for ever.

3.2 Local Control

This is where the PICNET node makes its own decisions without passing everything back to the central computer.  So, for example, when the motion sensor sees someone entering the room, the node could turn the light on.  The central node would still have to tell the local node when it got dark, and settings like how long to leave the light on.  On the face of it this is a much better configuration, providing much shorter response times with much less communication between nodes.  Even better, it opens the possibility of a generic node which is configured entirely by instructions from the central controller.

However, this design strategy has one major flaw - It requires related inputs and outputs to be wired to the same node, and this is not always convenient.  For example, in my house the motion sensor on the stairs is wired to a node in the hall, but the landing light is controlled by a node in loft.

Thus I made the decision that the nodes would in general simply act as dumb input/output ports with all processing being performed in the main software.

3.3 Isolation Working

Notwithstanding the decision about local control, there is still the situation where the node has lost contact with the central system to consider.  This can arise due to the network being broken, or the server has crashed or been shut down.

During isolation working, as it is known, it may be possible for the node to do something useful, so I have coded some logic into the individual nodes; in the majority of cases this simply turns the lights, boiler etc. off.