Beyond Block Detection: Teaching Holgate to React
In the previous Holgate article , we looked at why reliable model railway block detection became increasingly important as the layout developed, and how that requirement eventually led us towards developing our own current-detection solution.
At first, the reason for wanting detection seemed fairly straightforward.
We wanted to know whether a section of track was occupied.
That information could be displayed to an operator, used for block signalling and, potentially, incorporated into the automation already being developed around DCC-EX and EX-RAIL.
But as we continued looking at how Holgate might use detection, a rather more interesting question emerged.
Once the railway knows that a train is there, what else can it do with that information?
That question has taken us beyond block signalling and into something much closer to the way the railway itself can participate in its own operation.
Knowing That Something Is There
At its most basic, block detection provides a remarkably simple piece of information:
Occupied or clear.
A current detector doesn't necessarily know which locomotive has entered a section, where that locomotive came from or where it is going.
It simply detects that sufficient current is being drawn within that section of track and reports that the block is occupied.
For conventional block signalling, that can be perfectly adequate.
If a train occupies the section ahead, the signal protecting that section can display danger. Once the section becomes clear, the signalling system can respond accordingly.
The identity of the locomotive isn't necessarily important.
Whether the train entering the block is a Class 37, an HST or Flying Scotsman, the fundamental signalling requirement remains the same:
The block is occupied, so another train should not enter it.
But Holgate isn't a small test layout with a single train moving between a handful of blocks.
At an exhibition there can be multiple trains running, operators preparing movements, storage roads being filled and emptied, routes being changed and, at the same time, members of the team talking to visitors.
Simply illuminating an LED to say that a block is occupied is useful.
We began wondering whether the same information could do considerably more.
Detection, Signalling and Train Control Are Different Things
One of the useful parts of researching this subject has been separating three things that are very easy to combine in our minds:
Detection. Signalling. Train control.
They are related, but they aren't the same thing.
Looking at an established system such as LocoNet provides a useful example.
A LocoNet-compatible block detector can report the occupancy state of a section onto the network. Other devices can respond to those messages, allowing block occupancy to influence signalling without necessarily requiring a computer to supervise everything.
That makes perfect sense.
The detector reports:
Block 4 occupied.
The signalling system doesn't necessarily need to know which locomotive caused it. It only needs to know that the section isn't clear.
The situation changes when we ask the railway to do something more ambitious.
Suppose another train is approaching that occupied block and we don't simply want to display a red signal.
We want the railway to stop the approaching locomotive.
Now we have another problem.
Which locomotive should we stop?
The Missing Question: Which Train?
A block detector fundamentally tells us:
Something is here.
For signalling, that's extremely useful.
For more sophisticated automation, however, another question appears:
What is it — and what should happen next?
Something therefore has to maintain an understanding of the movements taking place around the railway.
In many computer-controlled layouts, that higher-level intelligence is provided by software such as JMRI, iTrain or Rocrail.
The software receives occupancy information, maintains knowledge of the trains and routes being controlled and then sends the appropriate commands through the DCC system.
That can provide an extremely sophisticated control system.
But it also helped us understand something important about Holgate.
The detector isn't really the intelligent part of the system.
The intelligence comes from what interprets the information from the detector.
Why Didn't Holgate Simply Use LocoNet?
LocoNet was therefore worth looking at.
It is a mature layout-control network and demonstrates how detection, signalling and other layout devices can communicate extremely effectively.
So why didn't we simply use it?
Because that wasn't quite the problem we were trying to solve.
Holgate was already developing around DCC-EX and EX-RAIL. Points, routes, locomotive control and increasingly the operating logic of the railway were already becoming part of that environment.
Adding another network purely for detection would therefore mean introducing another control architecture alongside the one we were already using.
That wouldn't necessarily be a problem if it gave us something we needed.
But our interest in detection was already moving beyond simply reporting occupancy.
We wanted the information from those detectors to influence what the existing control system did next.
A LocoNet-based system can certainly achieve sophisticated computer control. Software such as JMRI, iTrain or Rocrail can provide the additional decision-making layer needed to combine occupancy, routes and locomotive movements.
For a permanent home layout, adding a computer to provide that higher-level control may present very little difficulty. Holgate, however, is an exhibition layout, and that changes the practical considerations.
A computer or laptop, display and associated equipment would become additional hardware that had to be transported, set up and connected every time the layout attended an exhibition. It would also mean dedicating a computer to providing the decision-making layer while the railway was operating.
With DCC-EX, there was another possibility. EX-RAIL is integrated directly into EX-CommandStation, allowing the automation logic to be handled within the command station itself. For Holgate, that meant the same DCC-EX system already controlling the railway could also respond to detection, manage routes and make automation decisions without requiring a separate computer to provide that decision-making layer.
This didn't make a computer-based approach inherently better or worse. For Holgate, however, being able to keep the automation within the DCC-EX system and reduce the amount of additional equipment required at exhibitions was a genuine advantage.
But that led us to a different question:
Could we keep that decision-making within the DCC-EX environment Holgate was already using?
That turned out to be far more interesting than simply choosing another method of block detection.
From Model Railway Block Detection to Automation
Consider a simple example.
A train enters a storage road and triggers its detector.
At the simplest level we have:
Detector → Block occupied
Add signalling and we have:
Detector → Block occupied → Signal changes
But if EX-RAIL can use the state of that detector as part of its operating logic, we can begin thinking differently:
Detector → Block occupied → Route protected → Appropriate action taken
Nothing about the detector itself has become more intelligent.
It still only knows whether the section is occupied.
What has changed is what the railway does with that information.
And that begins moving us from simple block signalling towards something resembling interlocking.
Protecting the Railway From Its Operators
That might sound slightly unkind to the Holgate operating team, but anyone who has operated an exhibition layout will probably understand the problem.
People make mistakes.
An operator may be talking to a visitor.
Someone may believe a storage road is clear when it isn't.
Two people may be concentrating on different parts of the railway.
On a sufficiently large layout, a train can simply be somewhere that isn't immediately visible from the operating position.
Detection can tell the operator that the road is occupied.
But why stop there?
If the control system already knows that the storage road is occupied, it could potentially refuse to establish another route into it.
Instead of simply telling the operator:
There's already a train there.
the railway can effectively say:
There's already a train there, so I'm not going to let you send another one into it.
The operator still decides what they want the railway to do.
The control system simply prevents an unsafe or impossible movement.
That distinction is important to what we are trying to achieve with Holgate.
Automation Doesn't Have to Replace the Operator
When we talk about model railway automation, it is easy to imagine the ultimate objective being a railway that operates entirely by itself.
Press one button, stand back and watch the trains run.
That isn't necessarily what we're trying to achieve.
Some of the most useful automation on an exhibition layout may actually be operator assistance.
The operator can still drive the train.
The operator can still request a route.
The operator can still decide what movement should happen next.
But the railway can provide safeguards around those decisions.
If a storage road is occupied, don't allow another train into it.
If a conflicting route has already been established, don't allow another route to be set across it.
If a train hasn't reached the detector where it was expected to arrive, don't simply assume that it has.
Suddenly detection isn't being used to replace the operator.
It is helping the operator.
Finding Somewhere for the Train to Go
Once we start thinking this way, other possibilities quickly appear.
Imagine Holgate has four storage roads:
Road 1 — Occupied
Road 2 — Occupied
Road 3 — Clear
Road 4 — Clear
An indication panel can show the operator that information.
But the control system already has exactly the same information.
So why shouldn't it use it?
A train requiring a storage road could potentially be directed towards the first suitable available road.
In our example, Road 3.
That decision isn't being made because someone programmed:
Send the third train to Road 3.
It is being made because, at that particular moment, the physical railway is reporting that Roads 1 and 2 are occupied while Road 3 is available.
That is a subtle but important change in the way we think about automation.
Responding to Events Rather Than Time
Consider another simple automated sequence.
We could tell a locomotive:
Run forward for ten seconds, stop, wait five seconds and change the points.
That might work perfectly during testing.
But it assumes the locomotive travels exactly the expected distance in those ten seconds.
What happens if it doesn't?
A dirty wheel, momentary loss of contact, a slightly different locomotive or even changes in the mechanism could alter the result.
Detection gives us another option.
Instead of:
Run for ten seconds.
we can begin thinking in terms of:
Run until the arrival section becomes occupied.
The physical railway now determines when the next event occurs.
Take that idea further and the sequence could conceptually become:
The train has arrived. Stop it. Check which storage roads are available. Set the appropriate route. Update the signals. Allow the next movement.
Automation begins responding to events rather than simply following a clock.
For an exhibition layout such as Holgate, that potentially makes the automation considerably more resilient.
The Railway Starts Becoming One System
This may ultimately prove to be one of the most important lessons to come from Holgate.
We tend to think about model railway electronics as individual systems.
There is the DCC command station.
There are point controllers.
There are signals.
There are block detectors.
There may be an indication panel.
And there are the locomotives themselves.
Each can be treated as an independent system.
But once information from one begins influencing the behaviour of another, those boundaries start disappearing.
A detector isn't simply there to illuminate an LED.
A signal isn't simply displaying red or green.
A point isn't simply responding to an accessory command.
They become inputs and outputs belonging to the operation of the railway as a whole.
And that changes the question we ask about block detection.
Instead of:
How do we detect a train?
we start asking:
What decisions can the railway make because it knows the train is there?
Beyond Block Signalling
When we began looking seriously at train detection for Holgate, signalling seemed like one of its obvious applications.
It still is.
But it is becoming increasingly apparent that signalling is only the beginning.
The progression we're now exploring looks much more like:
Detection → Information → Decision → Action
Reliable detection provides information about the physical state of the railway.
EX-RAIL gives us somewhere to interpret that information.
DCC-EX already has the ability to control locomotives and interact with other parts of the layout.
Bringing those elements together opens up possibilities ranging from simple block signalling through route protection and operator assistance to much more sophisticated event-driven automation.
And importantly, none of this means Holgate has to become a railway that operates entirely by itself.
Quite the opposite.
The objective is to see whether the railway can become a better partner to the people operating it.
A railway that knows when something has arrived.
A railway that knows when somewhere is occupied.
A railway that can prevent an obviously conflicting movement.
And perhaps eventually, a railway capable of helping decide what should happen next.
That is where our work with Holgate is now taking us.
Because detecting the train was only the first part of the problem.
The really interesting part is deciding what to do once we know it's there.
Following the Holgate project?
Read the previous instalment: How Holgate Solved Train Detection for DCC-EX Automation
Start from the beginning: How Holgate Helped Shape the DCC-EX CSB1
Next in the Holgate series:
From Detection to Interlocking: Teaching Holgate to Protect Its Routes
Our next Holgate article will explore how occupancy information could move beyond simply reporting where trains are, and begin protecting routes, preventing conflicting movements and helping operators manage the railway more safely.