Greg, I'm not really good at all this multi quote editing so I hope you can just follow my responses.
Do you mean there is no portion of the layout that is relatively complete to allow that area to be properly blocked and signaled? It does not have to be the whole layout.
I don't know how you build layouts, or how many you have built or been involved with, but many of us "old timers" tend to build benchwork, track, controls then scenery, in that order - and depending on layout size, break that down into moderate sized sections.
I know, and have known, lots of people with layouts that are/were "relatively" complete - that is completed trackwork, working control systems, all benchwork covered with some degree of scenery, etc.
The original control system used by Ed Ravenscroft, documented in MR, that my system is largely based on, was completely modular allowing each new section of the layout to be built, wired, signaled, operated and then intergrated into previous and following modules seamlessly.
But all that is different from just going off willy-nilly with 100 projects started and none complete.
"how do I know it's complete or correct" - not sure I understand that statement. I know its complete and correct because I know what I am modeling, I know what I want, I know how real trains work, I know what compromises I am willing to accept or not accept in my modeling - and I am not involved in "management by committee".
AND, I am using artistic license to create a believeable selectively compressed fictional model world, I am not building an inch by inch replica of a real life place, nor would I want to.
So it is complete and correct when I say it is.
I'm not downplaying the flexibility of using software, I get that. But the learning curve is too high for me after all these years being away from it. And I am not modivated to relearn new versions of it for any other purpose. Believe me, I considered a lot of options 15 or so years ago - DCC, computers, etc. I looked at everything that was on the market, and the available DIY solutions like Bruce Chubb's CMRI - THEN.
But I'm not into the planned obsolescence thing, I'm not replacing things that work for my needs just because something else has come along.
That goes for model trains and their controls, garden tractors, automobiles, vinyl records (making a strong comeback), paper books, and of course relays.
I think everyone should enjoy this hobby however it "happens" for them.
But for me that is not some willy-nilly constantly changing series of experiments. That was the first five or six years from age 10-16. After that I pretty much knew what I wanted from this hobby.
Several small sections of benchwork are up, the ceiling is ready in 1/2 of the whole space, my workshop is 90% operational, several major sections of benchwork will be next.
And, related to this conversation, another modeler asked me if I expected to make changes to the layout as it gets built. I explained that there will surely be minor adjustments as it goes along. But that this whole concept has been in use on previous layouts, and has been carefully refined. Major changes are VERY unlikely.
That is what planning is for......
Sheldon
ATLANTIC CENTRALHow do you build a partially designed signal system? Specifically how do you know what physical signal head configurations to put at each location, or even where those locations are, if you don't already know what aspects are required?
Sounds like by "signalling system" you mean having the blocks defined on a completed layout along with knowing the type of signal (multiple heads) at each block boundary and what aspects are needed for various conditions including route and block occupancy.
The club certainly doesn't have that, like most layouts
It started after seeing that the PSX has a block occupancy output and using one to control LEDs mounted on top of a building to alert members that a train was ahead of them. Then I was asked to make the signal in the photo work. We then moved a 2nd signal facing the tunnel to the other side of the tunnel and made that work after rewiring some blocks. Then we combined the outputs from an AR and 2 PSXs to signal a hidden reverse loop track and then added APPROCH because the next block was from a PSX on the same panel.
So "the plan" is evolving. signals are being added that aid members much like i imagine signals were first implemented on the railroads. Of course it will never be prototypical.
ATLANTIC CENTRALPersonally I would have solved the route selection issues BEFORE deciding on signal indications. That is what I do with my relay based system.
Of course, you don't want to rewire you hardware especially after it's installed
if it's not already clear, software changes are made at home, tested there by grounding inputs simulating block occupancy outputs. Once satisfied, it just takes a couple minutes on the layout to reprogram a node. Of course it takes longer if new connections to signals, PSXs or switch machines are needed.
ATLANTIC CENTRALBefore worring about how to control them, it would seem to me knowing what the desired aspect for each condition needs to be should be the first information gathered. Once you know that, then you can develope a simple truth table for each condition.
Once you know that, then you can develope a simple truth table for each condition.
As you know, the logic for a 3 aspect signal is trivial.
More complicated aspects can be implemented in software by matching a set of input conditions to a particular aspect. it can be table driven, not explicit logic and easy to correct
ATLANTIC CENTRALI'm just suggesting it makes more sense to know everything you want it to do first - then design and build it.
of course it does. but how do you know it's complete and correct? How much double checking do you want to do before building it? I spent a career doing this. Once all the challenging requirements are understood it's often faster to test and modify software.
2293
greg - Philadelphia & Reading / Reading
Greg,
How do you build a partially designed signal system? Specifically how do you know what physical signal head configurations to put at each location, or even where those locations are, if you don't already know what aspects are required?
OK, your New Haven East project is a passenger yard throat, correct?, I will guess that all the signals are dwarf signals. And I understand you were solving both route selection and signaling. And it is very complex.
Personally I would have solved the route selection issues BEFORE deciding on signal indications. That is what I do with my relay based system.
On most prototype systems, for the greater part of the history of North American railroading, Interlocking signals (speed or route based) have consisted of multiple stacked heads, two or three heads per incoming route is typical.
Before worring about how to control them, it would seem to me knowing what the desired aspect for each condition needs to be should be the first information gathered.
Then, software or hard wired logic is pretty easy to work out - but I will admit, I have not written any code in modern times. The last code I wrote was for a 1982 vintage Cutler Hammer PLC.
Now, in the case of simple block signals between interlockings, the red, green, yellow thing is pretty easy. And open non CTC turnouts put that block red, that is not a difficult wiring problem by any method.
I am not challenging the use of solid state or processor based systems here, I'm just suggesting it makes more sense to know everything you want it to do first - then design and build it.
That requires understanding the prototype system - AND, deciding if you need every feature of the prototype, AND, then making reasonable practical compromises for our model worlds.
DISCLAIMER - I know a fair amount about real trains, real train operation, real signal systems. I have no interest in modeling some very limited stretch of a real railroad down to the last inch (or complex signal aspect).
My system is full of short cuts and compromises, and few people would know that just to observe it in operation.
On the prototype, the default aspect is RED. All signals are told to be RED by Normally Closed (no power to the coil) relay contacts until they are told otherwise - that way broken rail, damaged wiring, stuck turnouts, burnt up detection relays and a host of other failures stop or slow the trains.
And again, I will make the point that most model layouts, even pretty large ones, have very little need for the typical permissive block signal used on the prototype - the distances between our Interlockings, or Control Points, are too short. How many signals do you need in 20' or even 50'? That is the typical length of a control/signal block on my new layout. And I use a signal mid way thru each block as well, so that makes it every 10' to 25'. My average train is 15'-20' long. That is actually a pretty realistic selective compression of typical practice in my 1954 era.
I have a folder full of logic diagrams for different track configurations, with signal head configurations based on typical prototype practice from my era.
My logic processor is my detectors, the relays that drive the turnouts, and "permission" from the Dispatcher. The turnout relays have multiple spare contacts to provide the necessary interlocking logic in both directions of travel thru each Interlocking or Control Point. You have already seen the turnout control schematic - there is a relay that repeats the postion of each turnout - some contacts are used for track power routing, some for the button logic of the turnout selection, and rest are used for the signal logic thru the interlocking. All the relays are 4PDT ice cubes.
It's not that complicated - it is a building block system. In a rare complex situation, I need a repeater or two.
ATLANTIC CENTRALI don't completely understand the approach you describe above?
i certainly understand that you don't want to start a renovation without having a fairly complete understanding of what is expected. the customer can't change there mind midway thru contruction and isn't likely to say that's good enough and stop construction before it is complete
but it's not obvious that for a new unique situation that a relay based electrical signaling circuit (see diagram) doesn't undergo changes during bench testing; that the paper design isn't flawless
at least with the last project i worked on, a femtoCell, much of it was implemented on signal processors where the software can easily be changed rather than hardware which can't be changed
the hardware for a signaling system i'm discussing is nothing but a processor, I/O expansion chips and connections to signal LEDs, block occupancy detectors and switch position indicators. All the smarts are implemented in software.
that software can start out as nothing but indicating STOP if the block is occupied. the next feature might be to indicate APPROACH if the "next" block detector is available. the feature after that may also force STOP if a particular switch is open, and that might be further improved by considering routes. And moving all the smarts to a central element doesn't require any hardware changes either.
there were many "mistakes" in the original New Haven East Interlock code at a friends layout, where you pressed 2 buttons on either end of a panel to align all the switches between them. Even after corrections, additional changes were made after using it.
and this has been my experience as an embedded firmware developer on data terminals, speakerphones, CDMA cell phones, optical transmission systems as well as the femtoCell radios i've worked on.
The software evolves as details, corner cases, become better understood during development and testing. There are just too many details to completely identify during the paper design phase and this is acceptable because software can easily be changed or just replaced. software changes are tested nightly. experienced developers have a good feel for what to worry about.
physical construction -- building renovations or electronic circuitry -- cannot be changed as quickly or easily as software and that's why the "approaches" are different
yes, model RR electronics are getting that complicated primarily because custom software can be developed for inexpensive generic processors used in household and industrial products
2051
gregc ATLANTIC CENTRAL Every layout is a work in progress, but my construction management background makes doing things "over", or half way, really difficult i don't see reprogramming a board as doing things over. Software testing begins as soon as basic features are available. Reprogramming requires connecting a USB cable between a laptop and the processor under the layout and downloading the new code. i see signaling on this layout evolving in stages independent nodes, driving local signals depending on PSX block detection available on the panel (club layout had 3 panels) linking nodes via WiFi to share block occupancy and add nodes without local PSXs moving control logic from nodes to central controller and adding additional features (switch control) with CTC this approach makes some capabilities available early before the system is more complete as well expectations to evolve there just one person that understands electronics in the club 1888
ATLANTIC CENTRAL Every layout is a work in progress, but my construction management background makes doing things "over", or half way, really difficult
i don't see reprogramming a board as doing things over. Software testing begins as soon as basic features are available. Reprogramming requires connecting a USB cable between a laptop and the processor under the layout and downloading the new code.
i see signaling on this layout evolving in stages
this approach makes some capabilities available early before the system is more complete as well expectations to evolve
there just one person that understands electronics in the club
1888
Greg, I respect and even admire your dedication to the club setting. I enjoyed the club, and later a round robin group, that I belonged to in the past.
I will invite everyone I know to come operate my layout when it gets to a reasonable point of operation.
But I no longer have any interest in being part of the "team" layout building experiance. I'm not interested in the compromises or politics of working on a club layout, and I'm not intersted in have any help in any serious degree on my home layout.
I don't completely understand the approach you describe above?
I had a much longer response here - but I thought better of it.
ATLANTIC CENTRALEvery layout is a work in progress, but my construction management background makes doing things "over", or half way, really difficult
gregc ATLANTIC CENTRAL but I don't get why people build stuff "half way", or temporary in the first place? what do you mean. the club layout is a work in progress (going on 17 years)
ATLANTIC CENTRAL but I don't get why people build stuff "half way", or temporary in the first place?
what do you mean. the club layout is a work in progress (going on 17 years)
So, the club I once belonged to reached a point where they wanted signals. The "signal committee" designed a complete working system, built the components, installed the system - with all the desired features, in about a years time.
40 years latter that system is still working.
Every layout is a work in progress, but my construction management background makes doing things "over", or half way, really difficult - especially when other projects have not been touched yet.
No offense intended to them or anyone, I just can't work like that.
SeeYou190Can you give me a few months?
At your convenience, sir.
I recall having some "bulb"-based signals way back when and on some of them the colored dye peeled right off so all three "colors" were clear.
It should be relatively simple to replace your incandescent lamps with LEDs. Sounds like a fun project
You know how to find me
Cheers, Ed
gmpullmanIf you were so inclined, you could send me a couple of those signals and I could see about converting them to LED and give you a pattern to follow for you to do the rest of them, Kevin.
I am VERY inclined!
Unfortunately they are somewhere in the "wall of boxes" that is currertly surrounding the room where my wife and I are sleeping waiting for the master bedroom to be completed.
Can you give me a few months?
-Kevin
Living the dream.
gregc ATLANTIC CENTRAL In most cases, both tracks of double track would/should be signaled in both directions the layout has some double headed signals. for now, the signal for the left track is just wired for STOP. the block detection is availble for both tracks from PSX circuit breakers. switch positions need to be wired into the processor to support use of the left signal. processor firmware can easily be changed as functionality grows over time. 1617
ATLANTIC CENTRAL In most cases, both tracks of double track would/should be signaled in both directions
the layout has some double headed signals. for now, the signal for the left track is just wired for STOP.
the block detection is availble for both tracks from PSX circuit breakers. switch positions need to be wired into the processor to support use of the left signal.
processor firmware can easily be changed as functionality grows over time.
1617
I understand, but I don't get why people build stuff "half way", or temporary in the first place?
ATLANTIC CENTRALIn most cases, both tracks of double track would/should be signaled in both directions
gregc gregc An Arduino can be had for ~$10, has 11 spare pins supporting 2 signals (blkOcc and 3 LEDs) with fairly simple code, the same on each board ATLANTIC CENTRAL whem you say "signals" are you referring to each individual "light"? or the whole 2 or 3 light assembly? a complete signal: 3 output pins for LEDs and 2 input pins for 2 possible block occupancy detection circuits ATLANTIC CENTRAL You don't really need real "approach" aspects on a model layout. the cost is possibly one extra input pin. None, if the the next block is signaled and the block detector is already being monitored and that status is shared. i think i missed your point about bi-directional signals. for single track, the block detection inputs would be used in both directions. the club has a double track mainline. 1552
gregc An Arduino can be had for ~$10, has 11 spare pins supporting 2 signals (blkOcc and 3 LEDs) with fairly simple code, the same on each board
ATLANTIC CENTRAL whem you say "signals" are you referring to each individual "light"? or the whole 2 or 3 light assembly?
a complete signal: 3 output pins for LEDs and 2 input pins for 2 possible block occupancy detection circuits
ATLANTIC CENTRAL You don't really need real "approach" aspects on a model layout.
the cost is possibly one extra input pin. None, if the the next block is signaled and the block detector is already being monitored and that status is shared.
i think i missed your point about bi-directional signals. for single track, the block detection inputs would be used in both directions. the club has a double track mainline.
1552
In most cases, both tracks of double track would/should be signaled in both directions. The whole idea of double track is flexibility of operations.
I'm not challenging the flexibility of the processor for this task, just being sure I understand the I/O count.
Point is signaling can be streamlined in model form and still look very realistic and provide practical info to operators.
SeeYou190However... I did buy these nifty signals... And signal bridges...
I have one each of those brass NJI signal bridges, Kevin. Good, sturdy structures.
IMG_2739 by Edmund, on Flickr
NJI signal bridge by Edmund, on Flickr
SeeYou190Ed posted some great information on adding LEDs to signal heads, and I am leaning towards doing that.
If you were so inclined, you could send me a couple of those signals and I could see about converting them to LED and give you a pattern to follow for you to do the rest of them, Kevin.
PRR_Motor-lineup by Edmund, on Flickr
I really enjoy having "functioning" signals on my layout and I'm always looking for places to realistically add more. These days with cab signals and PTC many trackside signals are vanishing. In the "glory years" sometimes blocks were only a ¼ mile apart and there were many more towers and track crossings demanding interlocking.
Nearly all my signals are animated using LogicRail simulators with direction of traffic and turnout interlocking overrides implimented.
Good Luck, Ed
gregcAn Arduino can be had for ~$10, has 11 spare pins supporting 2 signals (blkOcc and 3 LEDs) with fairly simple code, the same on each board
ATLANTIC CENTRALwhem you say "signals" are you referring to each individual "light"? or the whole 2 or 3 light assembly?
ATLANTIC CENTRALYou don't really need real "approach" aspects on a model layout.
BigDaddyAre those bulbs in the signals? I'm of the minimal effort camp too.
Yes, they are very "vintage" brass signals.
Ed posted some great information on adding LEDs to signal heads, and I am leaning towards doing that.
Bridge rectifier detectors are fine for DCC, not so useful with DC. They suck up too much voltage and do not detect stopped trains.
I use these:
https://www.dallee.com/Trak-DT-Basic-Current-Detector-limited-stock-check-before-ordering--365
I bought mine before they got so pricey..... actually they have always been a bit pricey.
They are inductive. They will detect parked trains by simply adding a high frequency carrier signal on the rails which does not effect the DC propulsion circuit.
They have relays on board which allow basic signaling with no other logic or hardware (helps justify the high cost).
Their only limitation is they will not detect very small currents like resistor wheelsets.
So all my cabooses have lights, and so will most of my passenger cars. Saves the cost of resistor wheelsets for 800 freight cars....
gregc ATLANTIC CENTRAL what would you use for detection? on the club layout we're working on, we discovered that PSX circuit breakers and ARs have a block occupancy output and are used on each block. but i've worked with the bridge rectifier and transformer type detectors ATLANTIC CENTRAL By two signals do you mean two blocks or bi directional? not sure what you're asking. only 3 block inputs are needed for two signals in same direction that indicate APPROACH. but it makes sense to control two signals in opposite directions that are close to one another with the same board and each signal would need 2 block inputs for APPROACH. there are a sufficent # of pins, 5 for each signal I/O expanders can increase the # of signals controlled by a single board, but multiple "nodes" would reduce wiring 1358
ATLANTIC CENTRAL what would you use for detection?
on the club layout we're working on, we discovered that PSX circuit breakers and ARs have a block occupancy output and are used on each block. but i've worked with the bridge rectifier and transformer type detectors
ATLANTIC CENTRAL By two signals do you mean two blocks or bi directional?
not sure what you're asking. only 3 block inputs are needed for two signals in same direction that indicate APPROACH.
but it makes sense to control two signals in opposite directions that are close to one another with the same board and each signal would need 2 block inputs for APPROACH. there are a sufficent # of pins, 5 for each signal
I/O expanders can increase the # of signals controlled by a single board, but multiple "nodes" would reduce wiring
1358
Greg, whem you say "signals" are you referring to each individual "light"? or the whole 2 or 3 light assembly?
Each light is typically called an aspect.
Yes, to get a true "approach" or "yellow" you need input the next block, and from the block on either side for bidirectional signals.
This why original relay based systems on the prototype used one detection relay circuit but had separate east and west circuits to actually light the aspects.
But easy enough to do with logic if you have enough inputs.
The problem with model train layouts is distance vs train length vs high percentage of turnouts per distance.
In the case of a layout like mine, approach signals are meaningless, what is going on two blocks away may as well be the other side of the world, UNLESS you make your signal blocks extreemly short. Back in the day, on busy east coast railroads signal blocks are generally short - 1 to 3 miles, in a time when the average freight train was only 1/2 to 1 mile long.
That block distance gave good location reporting to CTC dispatchers, and allowed pretty dense traffic.
How much should we selectively compress blocks on a model layout?
On my new layout, the signal blocks vary from 20' (1750 scale ft) to 50' (4350 scale ft) and there is only a few places where there is more than one block between interlockings, making almost all my signals "absolute".
So permissive block signals with "approach" or "approach medium" aspects simply don't exist. And of course using DC, I do need absolute boundries for control purposes.
Point of all this? You don't really need real "approach" aspects on a model layout. Have fewer longer signal blocks. Put a signal half way thru each actual electrical block. When the signal ahead is green, that "dummy" block signal is green. When the signal ahead is red, the dummy block signal is yellow. The dummy block signal never goes red. Saves a lot of wiring or programing and saves outputs.
My interlocking (absolute - speed or route) signals never show approach for the main route, they only show clear or stop. Diverging routes with restricted speed only show "yellow" or red to indicate speed restriction or stop.
My signal heads are two an three aspect color light style as needed.
So the typical interlocking signal has two or three heads for each track in each direction depending on the number and speed restrictions of the routes, just like the prototype mostly did.
Lots of lights (some that never light) but easy to configure logic, just like the original systems on the prototype.
So detection and simple logic, with a processor or relays can provide basic signaling that looks realistic "most of the time", and actually applies to the movements of the trains.
The trick is to focus on the interlockings - where the action is....
ATLANTIC CENTRALwhat would you use for detection?
gregc ATLANTIC CENTRAL A simple system like that can be done for considerably less cost than the Atlas system. An Arduino can be had for ~$10, has 11 spare pins supporting 2 signals (blkOcc and 3 LEDs) with fairly simple code, the same on each board 1203
ATLANTIC CENTRAL A simple system like that can be done for considerably less cost than the Atlas system.
An Arduino can be had for ~$10, has 11 spare pins supporting 2 signals (blkOcc and 3 LEDs) with fairly simple code, the same on each board
1203
Understood and agreed, what would you use for detection? By two signals do you mean two blocks or bi directional?
ATLANTIC CENTRALA simple system like that can be done for considerably less cost than the Atlas system.
Are those bulbs in the signals? I'm of the minimal effort camp too.
Henry
COB Potomac & Northern
Shenandoah Valley
My interest in signals is marginal at best, and since I intend to run the layout alone, it is completely unnecessary.
However... I did buy these nifty signals... And signal bridges...
-Photographs by Kevin Parson
If I am ever going to use one for anything except turnout position, it will need to be something that requires minimal effort to install.
I might choose Atlas when the time comes... Or... I might just hook them up to toggle switches and only illuminate them for photographs.
SeeYou190 I think the Atlas system would work well for me. Having mainline signals change as the train passes would be a nice feature, even if it has nothing to do with actually controlling train movement. Most of my signals are just there to show turnout position. -Kevin
I think the Atlas system would work well for me.
Having mainline signals change as the train passes would be a nice feature, even if it has nothing to do with actually controlling train movement.
Most of my signals are just there to show turnout position.
A simple system like that can be done for considerably less cost than the Atlas system.
nealknows Sheldon, I do run DCC. I have a two track main with two tracks that go to and from the freight yard and my lower level via a helix. While the signals are controlled manually at my interlockings, there is an override with the relay if the turnout is against the route. On the mainline I have a few areas when the signal is controlled by the turnout position. The layout is mid-sized (20' x 20') on two levels. Works well and op sessions are enjoyable. I don't want to get too dependent on automation (CTC or auto block control), although I did have the opportunity to get a custom made signal system for my layout. Good luck with your layout! Neal
Sheldon,
I do run DCC. I have a two track main with two tracks that go to and from the freight yard and my lower level via a helix. While the signals are controlled manually at my interlockings, there is an override with the relay if the turnout is against the route. On the mainline I have a few areas when the signal is controlled by the turnout position. The layout is mid-sized (20' x 20') on two levels. Works well and op sessions are enjoyable.
I don't want to get too dependent on automation (CTC or auto block control), although I did have the opportunity to get a custom made signal system for my layout.
Good luck with your layout!
Neal
Well just to be clear, my system does not automate train movements, it just works like a real CTC or tower authority system, but the CTC is not the full blown version, it is simplified.
Under CTC operations the dispatcher gives all mainline train permissions, operators only have to control the speed and direction of their train, they do not assign control sections (electrical blocks, not signal blocks) to their throttles or throw turnouts. Engineers need only to obey the signals. BUT, since it is DC, it is cleverly wired so that if they run a red/red signal, their train just stops - it never runs into someone else's control.
Under local tower operation mode, the train crews can be their own tower operators and then at each interlocking they do assign control sections to their throttles and select turnout routes. This typically requires only pushing two or three buttons and there is no need for them to relinquish control of prior sections or reset prior routes - the next crew will be doing that right behind them.
While all this happens signals indicate route permissions and occupancy automaticly.
nealknows I think it depends on how much 'realism' one wants on their layout and what their goal is with them. Are they operating or are they looking to have trains run with some type of electronic system controlling it? I bring this up as I host operating sessions with a crew of 6. I have signals at interlocking areas and the signals are controlled manually and with a relay that overrides the rotary switch when there's a switch thrown against the signal. Tower operators in the day (and maybe now) would control signals as trains entered the next block. That's what I do. My relays are very inexpensive (Atlas relays) and I have my signals hooked up to them and my rotary switch. This system works well for my layout, and is a reminder to the dispatcher (usually me) that someone forgot to normalize the turnout in the next block.
I think it depends on how much 'realism' one wants on their layout and what their goal is with them. Are they operating or are they looking to have trains run with some type of electronic system controlling it?
I bring this up as I host operating sessions with a crew of 6. I have signals at interlocking areas and the signals are controlled manually and with a relay that overrides the rotary switch when there's a switch thrown against the signal. Tower operators in the day (and maybe now) would control signals as trains entered the next block. That's what I do. My relays are very inexpensive (Atlas relays) and I have my signals hooked up to them and my rotary switch. This system works well for my layout, and is a reminder to the dispatcher (usually me) that someone forgot to normalize the turnout in the next block.
OK, Neal, I guess I agree and it sounds like you have a simple and practical system. Are you running DCC?
I am just starting a new layout, but have designed and used before the system I will use. I will have the option to operate much like you do, or to have a CTC dispatcher for the whole mainline.
I run DC, but with an advance cab control system and wireless throttles, so there are not "block toggles" in the traditional sense.
My signals do not require manual input, they respond correctly to three inputs:
ONE-Cab assignments performed at the dispatch panel or at local tower panels - these are done with pushbuttons, not toggles, and many blocks are powered automaticly based on turnout position.
TWO-Turnout route selection. Routes are are controlled by pushbuttons that are duplicated at both tower panels and the CTC panel. One button selects a whole route thru the interlocking and normalizes all other turnouts in that interlocking not effected by that route.
THREE-Dectection. Detection sets a given route red as each block becomes occupied.
So the indications are both largely prototypical and truely functional for operators.
I do skip some prototype aspects, or have them "dummied in" using what would be called "approach logic". Basically some "yellow" aspects are simply omitted or simulated.
In most cases there is only one or two blocks between interlockings.
Here is the track plan: