Test railway track-plan

I changed the example of building a large railway layout. Now it is represented by a series of successive modifications. The figure shows the final track-plan. Sketches are adapted for URB 2 FINAL units, but you can complete these schemes using your Arduino equipment.

Also in this layout will be integrated various mechanisms and lighting systems of houses and streets. The sketches are written for the application of the DUO application, but will be partially works by all my other applications.

Adding Switch Machines

The URB project supports all types of switch machines. In this experiment, you can download two archives with sketches. The first for point-motors on servos, the second for point-motors on electromagnetic coils. I do not recommend connecting turnouts to the COMM URB unit, do I use two units here (as in the example for Train Junior Pro).

For this experiment, you need two URB units, one ULN2003, two Bluetooth modules HC-06, two Arduino NANO and a Motor-Driver L298.

3 Coil machines 3 Servo machines
Connect switch machines to URB unit

Connect servo machines to URB unit

Power supply

In the following examples, we will create an extensive network of many URB units and a large number of railway peripherals connected to them. Because of this, the load current on 5V can become significant, so we need more powerful power sources compared with the charger for phone. I highly recommend a 5V power supply with a current of at least 2 amps.

The ideal solution can be a computer power supply, it immediately gives out voltges both 5 and 12V with protection. Also included in the set of railways are usually 9-12V power supplies. Also you can apply two standard power supplies, to 5V and 12V, by combining their negative wires together.


When connecting the cable USB Arduino located on the board receives 5 Volt power through the cable directly from the computer
(see MBR0520 +5V AUTO SELECTOR on the Arduino NANO circuit).

If you do not want to broke the USB port of your computer, BEFORE connect the USB cable TURN POWER ON the layout from it's power source!


I2C Bus

The I2C bus is addressable, which is similar to what happens when you dial a subscriber number on the phone. That is, you can transfer data to a specific Arduino on your layout, ignoring the rest.

The bus I2C works with addresses in master-slave mode. This means that only the main device can send data, other I2C blocks on the bus can only respond to requests from the main, or simply execute commands. On the project URB, the master is always a unit with bluetooth modules, and it is called COMM. The remaining units are slaves, having addresses from 2 to 255 and are named LOCAL.

The URB bus is organized by connecting 4 wires to screw terminals SP2 and/or SP3. It is necessary to add pull-up resistors to the COMM unit.

Testing from computer

Connecting a computer directly to URB unit is a very important feature. You can debug your sketches on time on the layout, or test the circuits separately by functional blocks.

Big layout is a lot of wires, the complexity of connecting devices and their compatibility among themselves, and most importantly the inability to add or change something in the finished layout without dramatic changes in the wiring. These shortcomings are absent in the URB concept.

All wiring between the blocks is made up of four wires. For example, if you need to put a few new junctions or sensors or streetlights on the layout, you just cut the four-wire bus in the nearest place and insert another URB. It remains only to upload the sketch, and your newly installed pieces are immediately integrated into the layout. At any time you can reprogram already installed URBs directly on a layout, you just need to leave the opportunity to reach it with a mini-USB cable. This way you can change the control or setting of any layout's devices, and replace it if necessary.

Another plus is the ability to experiment with each the URB unit independently of others, and it's still an easy way to look for possible malfunctions in electrical parts on layout. It is also possible to assemble URBs with peripheral modules separately on the table. You'll tune the prototype and then will transfer it to the layout. This allows you to realize your ideas much faster.

Relay example

Logical Comparison Operators & Boolean Variables

You have already met with the comparison operators IF and ELSE. By adding to them boolean variables (having only two states), you can very simply describe the behavior of your layout.

I apply the following rule to junctions: if the junction has a direct position, then the value of the variable "1" or TRUE, if the direction of the junction on the branch is the variable "0" or FALSE. For the active / passive the path state, respectively: 1 (TRUE) / 0 (FALSE). See also a Experiment 6 COMM sketch.

By using these variables, the COMM URB unit remembers the state of all lines and paths, and you can use comparison operators to program the logic of the behavior of signals, relays and other things.

Comparing boolean variables using the AND, NOT and OR methods is the main way to create control algorithms that will be used later.

Relay example
Test railway track-plan

Let's bring all of these pieces together

The flexibility and universality of the project URB gives you the opportunity to make decisions about the organization of the behavior of devices on your layout. Therefore, before I start the Example of programming Big Layout, I must describe the logic of the behavior of the layout example.

On the general picture of the experimental layout I drew the basic details, it is convenient for his presentation. But to understand the details need more schematic drawings. A few of the following pictures will be convenient for you to move from from generalities to specifics.

Lines description

This experiment consists of two independent loops (green and purple) with branches and one transition (black) line with a deadlock, connecting the loops with each other. You see 12 turnouts, and I assigned them alphabetic indexes pursuant to the picture. In doing so, I adhered to the rule of sequential assignment of indices from Line A to Line B. I remind you that you can assign any convenient index to any junctions on the layout in sketch at the COMM URB unit.

The layout controlled in DC mode, which means that we need nine relays. Seven for blocking tracks and two for transferring power to the Transition Line. The direction of turnouts determines the state of the relay. Relay contacts T and T_ provides switching between loops.

Pressing the button EMERGENCY immediately stops all trains on the layout, bypassing the train control from the mobile application.

Logic & Algorithm

Now we define state boolean variables for Tracks and Turnouts. By using these variables, the COMM URB unit remembers the state of all lines, and you can use comparison operators to program the logic of the behavior of signals, relays and other things. You can use much more complex logical constructions and dependencies, for example for automatic train movement on a schedule or use scripts. The task of this example is to show you these possibilities.

The variable name here corresponds to the name of switches in the App. Now we can draw up a table of correspondence between the positions of junctions and the state of lines. In general, you can arrange turnouts in pairs, or in other ways, but in this experiment, each the turnout is controlled individually.

I accepted the condition that only when all the correspondences for each path are observed, it's becomes active. Line Transition switches to power from Line A only if switches A, C, G, H and K are in a certain position. And accordingly vice versa. The same rules apply to a pairwise combination of junctions and the path, for example turnouts A and E to path A2.

Test railway track-plan
Switches A B C D E F G H I J K L
Path A1   0                    
Path A2 0       0   1          
Path A3 1   1   1   1          
Line A occupy TRANS 1   0 0   0 0          
Line B occupy TRANS       1   1   0 0   0  
Path T1                 1      
Path B1               1     1 1
Path B2                   0 1 0
Path B3                   1 1 0
Just look at your layout railpaths and fill out the table. Please do not try to build an algorithm without creating a rail lines state table. If the railpath does not depend on the position of the particular turnout or if the position of the turnout blocks the track, then the table cell does not fill out.


I streamline the table in two ways: applying the rule described above and changing the connection scheme of the relay directly to the railway tracks. You also can use the Karnaugh map method to optimize.

Relay block# 1 on the URB#2 will be controlled locally, depending on the positions of turnouts connected to this URB unit. Thus, we exclude the lines A1 and T1.

After optimization the lines becomes very simple. And adding the dependence of the power supply to Transition Line from only one Turnout F, I got all the information for programming the logic.

Periodically changing the logic in the sketch, you can change the behavior of your layout. Therefore, playing with your railway will not become boring with alltime.

Test railway track-plan

Sketches snippets

In Arduino IDE, a sketch consisting of several files is supported. When compiled, they are combined into a common firmware. Therefore, the snippets library zip-archive contains a file structure.

In a simple example above, all the files are easier to unite into one sketch, which I did. The following example is quite large, so I'll use this feature of Arduino IDE in it.


At the beginning of each sketch, the state of Arduino pins and the periphery connected to them are described. Therefore, based on your plan and the table, you already know you have the combined behavior of the elements of your layout. This is a good starting point for creating a logical algorithm.For example, you can connect the motor driver to any URB local unit, for this it is enough to convert the input command from the application into a byte code and pass it through the bus to this local unit. But in this example I will demonstrate first of all the practice of using snippets, so the motor driver is connected to the communication station. And as you can see below, the sketch is almost the same as the example of a simple layout, only this you have two control channels.

I also consider it important to have a draft of connections, as in the figure. Even if you mix up contacts, it's later you easy to fix it right in the code. The main thing that gives you the use of the project is end-to-end standardization of methods, in other words you can not make a gross mistake.

The description of the commands and functions I place directly in the comments in the sketch code. But the known function DELAY in the URB project has a strictly limited applying, and therefore I presented it's description here.

Since the DELAY function stops the execution void loop() cycle (i.e., the Arduino processor simply stops at the delay time), the data stops being transmitted via the bus and the commands are lost. Therefore, you can only use this function in the code the void setup() block.

I also use the DELAY function when transferring data from the master to local units via I2C bus ONLY at the Communication station. These delays are necessary for reliable data transmission. In this case, since the master initializes data transfer, no loss of commands occurs. In all other cases, use the millis() function, or a library based on it.

Also, if you connect the motor-driver to COMM URB, then I recommend not to use the ULN2003 current booster chip and, accordingly, the point-motors connected to this unit. This not only makes it easier to write a sketch for a communication unit, but also provides more options for connecting sensors and other devices (buttons, encoders, etc.).


Big Layout COMM URB
COMM URB connections

Local URB#2

A minimum number of devices are connected to this URB unit. This is a clear example of a local unit with a minimum sketch code.


Big Layout URB #2

Local URB#3

Firstly, if you remember, I was writing on local logic processing. A relay is connected to this unit, which, depending on the position of the turnout B, turns on the power on the path A1, as well as the signal. That is, in the main logic block on the COMM station, we exclude the processing of these devices.

Secondly there is a sensor AWS. And this is an example of its application.

It was possible not to use this URB unit. But this is a good example of adding an additional module to the finished layout, for example when updating it with the addition of new buildings. It also shows the use of external power supply 12 volts for standard LED stripes.


Big Layout URB #3

Local URB#4

A typical sketch for a local URB unit. A small recommendation – do not save on number of URB units (it is very cheap), do not try to use all the outputs of Arduino. Better add one more local unit. This approach greatly simplifies programming and error detection.


Big Layout URB #4

Local URB#5

Since the relay unit and signals depends on the algorithm performed by the COMM Station, this URB unit not operates logic locally. Signals are connected in the same way as on URB#4.

Test railway track-plan

As you noticed from the figures, it is not necessary to install all the components and connectors to the URB board, it is necessary to solder only the components necessary for a particular case.


Big Layout URB #5

Local URB#33

It was possible not to use this URB unit. But this is a good example of adding an additional module to the finished layout, for example when updating it with the addition of new buildings. You can also change the voltage for the LEDs, for example, connect them to 12 volts for standard LED stripes.

Also here is the algorithm of the RANDOM function, which ensures the random inclusion of lighting elements on your layout.


Lights URB #33


After successfully launched an experiments, even if you did simple layout with control over 4 servos and used two URB units, you already noticed some confusion. For example, typed the command: "jd0z" and the servo rotate to another angle instead of the expected one. Really the chain: the command on the serial port → its conversion to the byte-command and resend it via I2C → again processing already on the local URB → and at the end the rotation of the servo-drive – quite long way. And at every stage you can mix up something. So, the rule is the following: setting the final position of the servo (adjustments rotate angle) or the color of the signal should be made on the final URB unit to which they are connected.
In other words, you can build the correct logical model, but signals sent from the communication station cause an inverted response – instead of the expected red signal, is turned on the green signal. To fix this, you can change the state of the variable in the main logical block on the Communication station, or change the state of the outputs of the local URB (by changing the description of the outputs in the header of the sketch). I suggest, in order to avoid mistakes, always use the second method.

Soon new experiments