Bidirectional Communication

It is necessary for trains, signals and other components (such as junctions) to be able to send as well as receive messages to operate in such a network. Without this, information is not well shared, and information-driven activity becomes difficult.

Model railways are deliberately simplistic, because they are meant as toys or collectables. Most, if not all, commercially available models are controlled in a unidirectional way; this basically means that the trains (and other components) can be controlled remotely, but do not have the ability to communicate back or exchange messages directly (peer-to-peer). There are two common approaches, both suffering from the same problem:

• Direct Voltage Control: The controller modifies the voltage on the rails and the train's motors are linked directly to them. Multiple trains can operate at different speeds, but this requires that the network be divided into isolated sections.
• Power Source Modulation: The controller is connected to an AC power supply and the frequency is modulated to send data to the trains. Data is usually sent many times to overcome loss. Power for the motors and on-train CPU is taken by passing the AC power supply through a bridge-rectifier to convert it to DC - regardless of frequency.

I considered a number of approaches (infra-red, power-line communication and radio) and came to the conclusion that the easiest method was to use radio. I used a number of RadioMetrix radio modems, which provided a transparent serial-based link. Essentially, the modules plugged in, and no further action was needed. With this, each component (or 'node') had the ability to both send and receive data with all other nodes at the same time. All the issues of signal processing were immediately solved.

The RadioMetrix TDL2A modems really were that simple to use. Considerable thanks must be expressed to RadioMetrix who gave them to me for free. These modules should be seriously considered for such work, they really are "plug and play"!.

RadioMetrix TDL2A

The network problem

The radio modems provided a physical data link, shared by all nodes, but that was all. Essentially, given that the medium is shared, this formed a 'bus' network.

A bus network needs two fundamental functions at a low level: media access control (to avoid two devices transmitting at once, and dealing with this if it occurs) and addressing (to ensure messages are only received by the appropriate host). Without this, messages become garbled when they collide and it is not clear who the recipient of a message actually is. Additionaly, it is necessary to mark the beginning and end of a message, this helps the recipient identify the start and end of a message.

To deal with this problem there were two approaches: try to implement an existing solution (such as Ethernet) or do it myself. Given the fact that I did not have time to experiment with automation, I decided on the later. This ensured that I had something to actually present and allowed me to get some experience first hand.

I chose to organise the networking components based on the industry-standard, and well understood, 'OSI' model. This comprises of seven loosly bound layers (Physical, Data, Network, Transport, Session, Presentation and Application). It is not necessary to understand this now, but fundamentally it divides responsibility into layers. It provides abstraction and allows for two applications to communicate without knowledge of how the other layers work.

Actually, as is also common, I bent the model slightly and came up with my own layers.

• Layer A: Responsible for media access control and marking start and end of messages.
• Layer B: Responsible for addressing and error detection.
• Layer C: Responsible for reliable delivery of messages and identifying the destination application.
• Layer D: The application layer.

The network was deliberately simplified, in particular observant networking experts will notice that sessions and message segmentation were completely left out. This is because the assumption was made that messages would be small and no handshaking would take place. Realistically, this is probably too simple, but the network model could always be changed later to support this in higher layers.

Layer A

A very simplified explanation:

• Messages start with a special character and end with a special character (a weakness: escape characters should have been used!)
• Devices do not transmit if a message is being received, this times out after a second to avoid data loss (ie. end character) jamming the network.
• When the network becomes free, each device waits for a differing period to avoid many devices transmitting simultaneously. Devices recheck the network after this period - in case somebody else has started.

The last point was a considerable weakness in terms of time determinism. In simpler terms, it is not possible to predict how long it will take for a message to be delivered, because a host could keep checking and waiting for an unknown period. It is sometimes necessary to get a message delivered within a set time. This problem was difficult to address given the decentralised nature: there is no master host and synchronisation of clocks is difficult. Dr Utz Roedig, Lancaster University, proposed a solution to this problem, with the f-MAC Protocol.

Layer B

Again, quite simple:

• Firstly the destination address is checked, the message is thrown away if this is unacceptable.
• Then the message length is checked, this must be done before the next step to avoid segmentation faults - and is a fast way to get rid of invalid messages.
• Finally, the message checksum is generated and compared with the one sent. This is done last, because this is time consuming. Some might argue this should happen first, but if the address has been corrupted in a message for this host - it might as well be thrown away.

In the opposite direction, the destination address, message length and checksum are added to the outgoing message.

This approach actually worked rather well and there was no evidence of unexpected operation within the network.

Layer C

Simply:

• Messages that have been received are acknowledged (except for acknowledgments!).
• The sender will keep sending the outgoing message, until it is acknowledged.

This approach had two fundamental limitations:

• If the host does not exist, or cannot be reached, the sender will keep trying forever.
• If the messages are buffered, there is a finite amount of storage that will eventually overflow.

To solve this problem, it is important to realise that the platform I worked with did not support concurrency. Put simply, unlike a PC, the system was not able to do multiple tasks at the same time. This meant that it was not possible to start a new task to resend messages, such messages had to be buffered and sent between other functions. It was not acceptable to wait until the message was sent, because the system had other functions to see to.

I implemented the simplest approach to this: discard messages. In order to prevent breaking many of the requirements, it was necessary to classify messages as 'urgent' and 'non-urgent'. 'urgent' messages were buffered until delivered, 'non-urgent' messages were deleted if not delivered after a few attempts.

This approach was rather weak in that the buffer could still overflow. The problem is covered in more detail in the IET Presentation.

Layer D

This was specific to the application, but essentially all applications worked the same way. A request is generated by one host which consists of a command number and an argument byte. The recipient did not need to return a response. To avoid the need for sessions, command numbers were organised so that responses could be sent back, but this had the obvious weakness that responses could not be linked to requests. This brought the limitation that requests had to be absolute, rather than relative; basically a speed change had to be specific (ie. move at 90mph), rather than relative (accelerate 10mph). This problem was amplified by the possibility that the Layer C confirmation gets lost, and the same request is delivered twice or more.

Motor Control

Each train had the ability to control the speed and direction of the motor. The direction was controlled by using a driver circuit, rather than an H-bridge, to avoid the possiblity of short circuits. Speed was controlled by using pulse-width modulation; this is a method which rapidly switches the power on and off, allowing the average speed of the motor to be controlled to changing the ratio of 'on' and 'off'.

Train: The CPU board is shown, the radio modem is plugged in behind the 9v battery, the next wagon holds the motor batteries and driver circuit. There were a lot of wires, its amazing the system worked! Train Detection

Each signal protected a section of track, which was isolated electrically from adjacent sections. A small voltage was applied to one rail, and a CPU pin was linked to the other (with relevant protection). The train axles were modified so that the wheels shorted the rails. Therefore, the program could detect a train when the CPU input was activated.

It was necessary to avoid problems with noise, introduced by moving parts, which would have caused rapid changes to the input as the train moved. This was implemented by ignoring changes to the state that indicated that the track was clear, for a set period. This stabilised the output.

NB:	This content was quickly written, and should not be taken as academic quality. Some errors may be present. I do not accept responsiblity for your use of this information.
	I am grateful for the support received from RadioMetrix, supplier of radio modules.
	This material is Copyright and not endorsed by the University of Essex or RadioMetrix.