Hello again, As stated in my introduction, I am building the prototype of a new signaling & scripting system in DCC and without computer. It is made of electronics boards only. They are programmed using CV as another decoder. You can access my YouTube channel for several video clips: https://www.youtube.com/@jurasecondairen/videos Few words about this prototype... The challenge is to be able to draw the signals along the layout without using a computer and a software. Each section is equipped with a single board which manage: the detection, the turnouts, the signals... When all boards are linked together with a control bus, they are communicating altogether to manage the traffic on the layout. The scripting module is used to drive trains automatically with different scenario (shuttle for example). While doing so, a user can control one manual train in the middle of the traffic without any risk of collision, all automatic trains following the signals. If you are interested in such project, feel free to ask questions... Also, I will be attending Springfield-Amherst (MA) show at the end of the month. You can come by my little test layout and have a live demo of the prototype. (Mallary, booth 155 with the On30 Dirty 30 group). See you there, Patrick
Interesting concept of using decoders to control signals. I am mostly electronically and electrically inept. I have the most basic knowledge and skills in these fields, but seek to make my signals operational. I really don't know how to do it and where to start. I have built the signals, tested and installed them, but nothing else. It's N scale, and here's the signals.
Hello, First, very nice setup! So your idea is to electrify those signals and control them according to the position of the turnouts I guess? I am not very familiar with US signaling system... What are supposed to be the aspects here: only red and green?
Are you familiar with LCC (Layout Command & Control?) It is an NMRA standard system/bus for modules controlling switches & signals, occupancy detection, and even throttles. I don't know of any available LCC modules that can perform occupancy identification (vial Railcom), and also perform throttle commands to control the detected occupant, but theoretically, one could be developed. There are commercial LCC modules that control trackside signals, switches, and monitor occupancy. I don't know of any Railcom detectors that use LCC to to communicate the identity of the occupying locomotive(s), but it is technically feasible. ...Scratch that, a TCS DCC booster could perhaps do that, but that's really expensive to use for zone occupancy identification. I am curious about your desire to avoid software. Is that simply avoiding software development, or using any software to configure a system, or use any software to operate that system? Or are you simply seeking to have a system that does not require a computer running JMRI software, or similar, to control and operate this system?
Hello, I know LCC but never had a chance to get my hands on it. But I guess that your point is to use this as the data bus instead of the one I am using today? The main ideas behind this project: get rid of a computer and a software, so any user can install those programmed boards along the track with few CV without having any computer knowledge the challenge of this electronic project: create autonomous and standalone boards that fit almost all the cases and in DCC the signaling system and the scripting system combined together to be able to run automatic trains and play with a manual one in the middle of the traffic, especially during shows... and avoid any collisions... put the foundations (this generic system) for other smaller systems (single board) to be able to have a shuttle on a DCC layout for example create scripts and run them without computer: for example, train A go there! train B go there! and let the system manage the signals and drives the locomotives automatically. After all, it is almost for the challenge of having an integrated system, electronic based... And imagine: install the boards on each section, few CV to program, and the signalization is working on the layout. Also, being a software developer, I didn't want to play with my train and a computer together... so the electronic boards. Cheers, Patrick
Thanks! Ultimately I would like to have routing via switch position, and red, flashing yellow, solid yellow and green for colors. Tricolor LEDs installed.
As far as I understand, it is just a matter to drive LEDs depending on the position of the turnouts. Also these turnouts are controlled by simple "left/right" switches. If a switch is "left" then opposite LED (right) is red and previous LEDs on the layout are displayed accordingly by cascading the information (red/flashing yellow/yellow/green). So you have two "sub-systems": controlling the signals based on the turnout position and controlling the signals depending on the train position. Nothing impossible here. The only thing to do that might be difficult is to add occupancy detectors for realism to follow the passing train. Or me can simply have a script (like a timer) that displays the different aspects as soon as the train has past the signal. If you are interested, we can continue discussing this project together... Patrick
Some switches (e.g. Unitrack) are controlled by momentary (center-off) electrical switches, and do not maintain an electrical indication of which way the switch is thrown. If you use the power-routing feature of the switches to power the following tracks, then you can use the powered condition of those tracks to indicate switch position. You can also use series capacitors with static (not momentary) electrical switches to throw these track switches. Thus you have continuous electrical indication of the commanded switch condition, without burning out the switch machine's coil. *Note: "commanded switch condition" may not always be the "actual switch condition," particularly after a power cycle.
Folks, I was pointed at this thread by a friend of mine. It seems that Patrick here shares similar visions in controlling layouts as I do. I also develop electronics both for hobby as well commercially. So I am curious to what he has came up with. I have ofcourse many ideas and designs of my own for analogue and DCC layouts. But I am not here to steal Patrick's thunder here I do like to discuss and spar about these kind of things. For now I do want to share one technology I have been developing. I have made an arduino library with which I can record and replay all kind of actions on a I2C EEPROM. This could be an analog train shuttle but I can also interact with commerical centrals via their bus systems such as loconet. This video demonstrates an automated decoupling and coupling action. I teach the actions by doing the operation myself and let my PCB replay it. It is quite versatile. You can also record several programs and play them at once. Occupancies and button switches are also recorded. I haven't done it yet, but theoratically you can automatically run around your wagons with the press on a single button. I came to believe that this method has a lower threshold for a-technical people than a scripted program. There seems to be a barrier between typing words and making trains go, despite how easy the syntax is. If you are interessted I am willing to share the library. Also if you want dedicated UNO Rs485 shields or some other kind of PCB or shield. I can supply you with gerber files. I can also supply files for SMT assemly at JLCPCB. Kind regards, Bas
Hello Patrick, Excellent presentation, any chance of getting some details I.e. the script, hardware used and any other relevant information that may be of use to ‘novice’ like me! Thanking you in advance, Jay
Nice Layout, kinda what I'm shooting for as far as the signal types and scenery being SP style. I was originally looking into the CSS signal system modules, but come to find out when I called to order some, that that portion of their business had been sold. I played with some automotive relay matrix and 3-blocks of track when I was quarantined for a couple weeks and got it to work prototypically green yellow and red. It's a series of 2 normally closed (NC) SPST relays switched through each other to provide prototypical operation. In my case, the area I'm modeling displayed a constant green as clear and would go yellow then red as trains entered nearby blocks so I wanted to copy this. So the NC on relay 1 went to green. The (NO) side then *powered* relay #2 and when triggered lit yellow and dropped the green. Finally, when the train entered the near block, relay #2 would close, drop the yellow and red would be lit. So each signal in each direction required two SPST normally closed relays, or you could wire two signals in opposing directions with one pair of relays. My "train" was a nail and I have not selected a block detector or know if I'll use DCC or not yet. Note: This is a "dumb" setup and just makes the signal display properly for the train, it does not define operations and you could end up with two oncoming trains "arguing" over a block. Another function like a 2-head signal with a turnout or a flashing yellow added into the mix= add another SPST relay into the series at each signal. So if one had a turnout with a diverging route selected, that would trigger a 3rd relay which dropped the lower signal red for yellow AND requires a diode and jumper to change the upper signal head to red. Just remember, as you have more signals and trigger wires in adjacent blocks you can end up having multiple lights lit at the same time via back-feeding so diodes will be required on trigger wires on a case by case basis. You can, of course, jump these back to your control panel if you wish to display signal and turnout positions. I've just purchased some small NC SPST relay modules and am planning to build a little signaled test track with 3 blocks and a turnout and get it all working properly.
Some thoughts... DCC is not a good choice for communications to anything but locomotives. It is subject to outages caused by track shorts (caused by derailments, running against a switch, etc.) For example, controlling switches using DCC, at least on the track bus*, is not a good solution because once a switch is shorted (e.g. by a locomotive running against it,) the short cannot be cleared by throwing the switch, since the means to throw the switch are down as well. I would encourage you to work with LCC, which is an NMRA standard, wired (CAN bus) or wireless (WiFi) protocol, for communications between all the pieces of your model railroad system. LCC protocols incorporate switch control, occupancy detection and identification, signal control, throttle/CS control, and more. *A separate booster for the track DCC bus allows the CS DCC bus to be immune to track shorts, and still able throw switches which might clear the track short. But then, if you're gonna have to wire a separate bus for track control, etc., you might as well use a bus better suited to two-way communications.
Andy I can see that as a possibility but if there is a short due to a loco shorting the switch chances are you can't just reset the switch. When I've had that problem I've had to get the loco back on the track. For most of us who are single operators having things reset (usually automatically) I don't think is that big of a deal. On a larger layouts (basement type) with multiple operators yes it can be a bigger deal. Usually there and even in my case being a single operator with a 6' x 24' layout (not finished) you divide the layout into power districts (I have 8). Multiple districts also help deal with situations like what you described when you have multiple operators. If one has a problem he probably isn't effecting others. A problem in one district isn't going to shut the whole layout down. I can see where LCC has some advantages in some situations but can't see it for most of us due to the learning curve and cost. A number of command stations can now handle most of the needs most of us will ever have. DCC-EX can now handle signaling, turnouts, servos, block occupancy, automation and more via the command station. In most cases one has the option to use commercial products and/or inexpensive components if you are more the DIY type. DCC-EX isn't the only one with these capabilities. Sumner
No doubt about it, DCC-EX has come a long way. But, DCC-EX still does not allow you to program & verify a loco on the mainline, while other locos are running unencumbered. RailCom, an NMRA standard supported by multiple encoder and command station manufacturers, can do that. There is a 2020 DCC-EX Issue to add support for RailCom, but only one commit tagged it (to create the cut-out in the DCC waveform), and that commit never made it to the product. There are no issues to actually implement RailCom, but that may be beyond the capabilities of the DCC-EX hardware. You mentioned that DCC-EX can now handle signals, turnouts, servos, block occupancy, etc. The support appears to require running wires from all these track peripherals back to the DCC-EX board stack. That's a lot of wires, and is definitely not modular-friendly. NMRA-standard LCC (Layout Command Control) provides a separate bus for such trackside accessories and functions, for things like switch control, signals, occupancy detection, etc. You don't have to run all the wires back to the CS, you run one LCC (CAN) bus via Ethernet cables between the LCC nodes, which are themselves distributed controllers for given functions. One LCC peripheral can tell other LCC peripherals that it has changed state, and to react accordingly (e.g. switch-thrown or occupancy-detected to update-signal.) Since LCC is itself physically modular, it also fits well in a modular MRR environment, though to my knowledge there are no standards for incorporating LCC connections on modules.
A couple things to maybe clear up. You can now write to an individual loco on the main with other locos on it (EngineDriver also now has the feature) but no you can't verify. I think it is coming along with RailCom from reading recent posts on Discord. Do I think I'll ever use either? No and wonder if anyone on here is using RailCom on a home layout? Again I can see it for some situations but not probably a big deal for over 90% of the people on the forum but maybe I'm wrong. Very easy to build a small oval test track (got the idea from Mike Fifer) and use it for decoder programming, testing and speed matching without the worry that you did something wrong and reprogrammed all the locos on the main. It can be something that can be setup or put a way in a minute or so. Mine rolls under the layout when not in use. I'd go back to the command station as you mentioned above on a small layout but on a larger layout you can use the I2C buss to do that. Run two wires to a $6 servo controller board 20 feet down the layout and control up to 16 servos off if it and daisy chain to more of them if needed. How much would that cost to do with LCC? Also you don't have to buy anything else to do it whereas with LCC you have a lot more upfront cost before you are controlling anything. Also DCC-EX will work with any DCC accessory decoder that one would want to buy to control a turnout or something else. There is also work going on with EX-IOExpander that will also work on the I2C buss to expand the pins that are available for use past what is in the command station. I'm not saying LCC isn't for anyone just that the majority of us don't need it or will ever use it so wouldn't buy a command station or throttle just because it can use it. A throttle with LCC doesn't do anything unless one puts in a LCC system running along with their DCC system Sumner
I would not trust I2C over wires more than a few inches long. Never over a foot long, even for testing. I2C is a chip-chip communication protocol for devices on the same board or between boards in a common backplane or stacked configuration. I designed embedded electronics professionally for 30+ years, and used I2C many times, either on-board or between boards in a chassis with a common ground. I'd have been laughed out of my design reviews if I used I2C over a two-wire connection. In the right applications, I2C is very reliable. Unfortunately, between a command station and devices on a layout is not one of them.
MRC and TCS are betting against you. Others to likely follow suit. There are different media over which LCC operates: Ethernet/WiFi and CAN bus. Systems or peripherals need not necessarily implement both. Like RailCom, I predict DCCEX will eventually support LCC, on both media. And when they do, if I need another command station, I'll strongly consider DCC-EX. I hold few grudges, at least for very long...
