gregci thought the idea was all the smarts was in the PC that could be reprogrammed? as if a new protocol that replaces DCC could be implemented with a software update without replacing the decoders
The genius of the system is in the method of modulation, not the transmitted code. Instead of imposing a control signal on DC-carrying wires, the Lenz/DCC system provides what is essentially long-period square-wave "AC" with square-wave binary PCM switching the voltage. (And the signal repeated across one 'reversal of AC polarity' so information is not lost...)
You could easily change the modulation scheme transmitting the data, limited only by the effective slew rate of the square wave generation. If you use any kind of wireless at all, you can transvert that information to compatible DCC to continue using older decoders and equipment. Or about equally easily, you could take a DCC signal and transvert the information to a suitable wireless protocol or instantiation.
The key -- as usual with these sorts of things -- is to have an effective and well-maintained flexible set of standards first. My opinion is that continuing to use the operating or charging power applied to the track to send modulation to and from the powered devices is highly sensible, including any cases where you also send wireless modulation as well, but to me that's just common sense.
OvermodIf you were actually doing this with (somewhat) modern hardware, your 'peripherals' would all be designed to use USB or USB-C, or to bridge to WiFi or Infiniband or whatever
for a while now ... Digitrax supports Wifi. a UR92/93 transceiver can be installed like a UTP panel. newer wifi capable throttles are available. existing throttle can be sent back a upgraded.
this is an example of
gregcsystems architectures distribute intelligence and share data. components are easily upgradeable without needing to replace/disrupt the entire system
software upgrades are limited to hardware capabilities. the hardware of monolithic systems (i.e. PC) become obsolete and expensive to replace
greg - Philadelphia & Reading / Reading
DCC
OvermodInstead of imposing a control signal on DC-carrying wires, the Lenz/DCC system provides what is essentially long-period square-wave "AC" with square-wave binary PCM switching the voltage.
it does impose a control signal on a DC power. it simply modulates the polarity of the DCC. The decoder detects the polarity reversal and measures the time between them to decode bits. the cost is the need for a bridge to rectify track power to DC
i can't imagine an easier and inexpensive approach.
OvermodIf you use any kind of wireless at all, you can transvert that information to compatible DCC to continue using older decoders and equipment.
if you mean wireless communication with the decoder, why would you need to impose the signal on the track ?
if by wireless you mean communication between a controller and command station, why shouldn't the command station continue to use DCC?
it simply modulates the polarity of the DCC.
if this puzzles anyone, it uses the same circuit, h-bridge used in the decoder to control the motor
Are any of you guys familiar with what this guy does?
https://www.cti-electronics.com/
Sheldon
gregc Doughless I understood your original post to infer that the PC should have been the brains of DCC rather than the Command Station. That the technology should have developed around loading Train Operating Systems software into a PC...rather than developing a stand alone technology. so instead of having a command station, boosters and controllers, you would have PC, boosters (track interface) and controllers (human interface) a PC instead of a command station? how are the terminal/controllers connected to the PC? (please don't suggest rs-232) is the terminal/controller just a button box like the NCE terminals? i thought the idea was all the smarts was in the PC that could be reprogrammed? as if a new protocol that replaces DCC could be implemented with a software update without replacing the decoders how long does this discussion before the as yet undefined external components evolve into the systems we have today. this has become a new debate, not about DC/DCC, about loco/layout control in one box. systems architectures distribute intelligence and share data. components are easily upgradeable without needing to replace/disrupt the entire system and DCC is not even a component in todays systems, it's simple a protocol. ... not long Overmod You could always build a custom PC that had DCC control on the motherboard, or on something in an expansion slot.
Doughless I understood your original post to infer that the PC should have been the brains of DCC rather than the Command Station. That the technology should have developed around loading Train Operating Systems software into a PC...rather than developing a stand alone technology.
so instead of having a command station, boosters and controllers, you would have PC, boosters (track interface) and controllers (human interface)
a PC instead of a command station?
how are the terminal/controllers connected to the PC? (please don't suggest rs-232)
is the terminal/controller just a button box like the NCE terminals?
i thought the idea was all the smarts was in the PC that could be reprogrammed? as if a new protocol that replaces DCC could be implemented with a software update without replacing the decoders
how long does this discussion before the as yet undefined external components evolve into the systems we have today.
this has become a new debate, not about DC/DCC, about loco/layout control in one box.
systems architectures distribute intelligence and share data. components are easily upgradeable without needing to replace/disrupt the entire system
and DCC is not even a component in todays systems, it's simple a protocol.
... not long
Overmod You could always build a custom PC that had DCC control on the motherboard, or on something in an expansion slot.
I think PRM was simply saying that it would have been better to develop an operating system that was able to run off of a standard household PC. I assume the engineering of that would have designed specific controllers and interfaces, etc. to meet the goal of using a PC. I would think those pieces would be the less complex part of the system, where the software would be where the real engineering was.
I would have no idea about how to go about designing/engineering that. Apparently, not many others did either since that isn't the direction it went back in the 1990's.
- Douglas
xboxtravis7992 Doughless xboxtravis7992 Serious question, why is this the hill people want to die on?Personally I do favor DCC systems, but I can consider some design situations where I would consider a DC set up as well (i.e. building a small diorama or setting up a Christmas tree loop). To be fair to both parties it is worth pointing out DC is not going the way of the dodo as many DC locomotives continue to be produced, and likewise DCC is not some magic newfangled black-box new technology as the NMRA DCC standards date back to the 1980's. Both of these are mature technology options If we consider this as a design question at its core, why must we write pages of diatrabe over something which objectively has no correct answer? If DC isn't going away, is it because there are so many folks that conceptualize layouts like you do, and if they run DC, they have either a small diorama or a Christmas tree loop? Is DC still around because there are that many of those kinds of hobbyists? Or is it because they understand that DCC is not that complicated, no big deal, but have made reasonable choices about what they want to use for their layout and realize it offers them no usuable advantages in their situation. The advantages have to be able to be used on the layout, or else there is no common sense reason to have it. When the railroad that is modeled is 10 miles long, 50 miles long, 80 miles long; and you Google Earth the Right of Way, oftentimes what you see is a single string of track snaking through the countryside with 3 or 4 major industries along the way....usually a big one at the end of the line....and maybe two runaround sidings along the entire line (Real railroads HATE complex track arrangements), you quickly realize that reducing this railroad to modeled size does not require complex DC wiring...and therefore...never presents the problem that DCC was designed to solve. Its much more than a diorama or Christmas tree loop. Model Railroading isn't either about 3 different railroad mainlines looping over each other, criss crossing over each other, circa 1950...a complete wiring mess...or else its a loop of track around a Christmas tree. There is lots of it in between. Counterpoint, many of those small railroads lines would still present opportunities where DCC might be advantageous to replicate them. Many modern branchlines/shortlines run with consisted diesels back to back, with one cab on each end (as seen on the SLGW in my photos above). With dummy locomotives not being produced anymore; somebody who wants to run a consisted set with modern equipment might find DCC simpler for that purpose. Or the ability to keep multiple trains on the track if modeling a rural branchline that has to send out a speeder or hi-railer ahead of the train before it comes through to check track conditions could also be useful as it creates a situation where two moving vehicles would be on the same "block" so to speak. I have also seen some switching operations where two locomotives come in via consist, then split into different trains to work the same yard or industry from different angles. It is not super common but it is a real world practice that DCC would be a simple approach to take to replicate. Certainly though in many cases DC can be used; but there are arguments that might persaude people to chose one or the other. In my own case, dioramas and Christmas tree loops are the most appealing places for DC though since if I were to model that branchline/shortline you described, I would be building it with DCC (although I fully understand it would be equally functional in DC). Personal design preferences and my desire to have some operational flexibility come into play with that, although building such a layout in either DCC or DC cannot be seen as making a "wrong" choice. Also the cost advantage of DC is a huge benefit, but it does restrict what type of "visitor locomotives" can come to the layout as DCC has taken up a large majority of the hobby. If social factors are considered for club, modular layout (particularly Free-Mo) and just operating at a friend's place DCC with its growing popularity does have a leg up over DC systems. The amount of home layouts I have visited that operate a DC system is a big fat zero in my own personal experience (although I guess the Lionel three rail layout with its AC system sort of counts as something more akin to traditional DC at least in how its controlled via a fixed throttle). I am not saying DC only layouts don't exist nor that there are any in my area, but if I as an operator wanted to bring my own locomotive to an ops session at these other layouts it would need to be DCC equipped to function. But that is again a design choice. Functional layouts can be made with both systems, with real trade-offs and advantages for both. A solo modeler might not see the appeal of having guest locomotives or taking their equipment to somebody else's layout either. The cost factor of DCC is still a massive barrier to entry (although I will point out the cost barrier to all of model railroading right now is a huge barrier to entry regardless).My confusion though ultimately stems from what I feel is a persistent myth that DCC has some inherent difficulty to learn or master since it is "digital" has "programming" and is some new technology; which is not exactly true anymore. The only difficult thing with DCC is the process of installing decoders into locomotives not designed to take them, and I fully understand that is a legitimate concern since the process can be tedious and painstaking especially when DCC chipping a large fleet. That is a very valid reason to stick to DC in my opinion; however for most new modelers with many locomotives coming out of the factory with DCC and DC options there are less reasons not to consider DCC out the gate outside of the cost argument. DCC Ready locomotives offer a great compromise as well, being DC but ready for easy DCC installation of the owner decides to upgrade in the future (or even removing the DCC to convert back to DC if the owner wishes to). Believing DCC to be harder because it has "programming" feels myopic, and not giving it a fair shake since as others have already mentioned in this thread DCC programming is no more complex than using a television remote.
Doughless xboxtravis7992 Serious question, why is this the hill people want to die on?Personally I do favor DCC systems, but I can consider some design situations where I would consider a DC set up as well (i.e. building a small diorama or setting up a Christmas tree loop). To be fair to both parties it is worth pointing out DC is not going the way of the dodo as many DC locomotives continue to be produced, and likewise DCC is not some magic newfangled black-box new technology as the NMRA DCC standards date back to the 1980's. Both of these are mature technology options If we consider this as a design question at its core, why must we write pages of diatrabe over something which objectively has no correct answer? If DC isn't going away, is it because there are so many folks that conceptualize layouts like you do, and if they run DC, they have either a small diorama or a Christmas tree loop? Is DC still around because there are that many of those kinds of hobbyists? Or is it because they understand that DCC is not that complicated, no big deal, but have made reasonable choices about what they want to use for their layout and realize it offers them no usuable advantages in their situation. The advantages have to be able to be used on the layout, or else there is no common sense reason to have it. When the railroad that is modeled is 10 miles long, 50 miles long, 80 miles long; and you Google Earth the Right of Way, oftentimes what you see is a single string of track snaking through the countryside with 3 or 4 major industries along the way....usually a big one at the end of the line....and maybe two runaround sidings along the entire line (Real railroads HATE complex track arrangements), you quickly realize that reducing this railroad to modeled size does not require complex DC wiring...and therefore...never presents the problem that DCC was designed to solve. Its much more than a diorama or Christmas tree loop. Model Railroading isn't either about 3 different railroad mainlines looping over each other, criss crossing over each other, circa 1950...a complete wiring mess...or else its a loop of track around a Christmas tree. There is lots of it in between.
xboxtravis7992 Serious question, why is this the hill people want to die on?Personally I do favor DCC systems, but I can consider some design situations where I would consider a DC set up as well (i.e. building a small diorama or setting up a Christmas tree loop). To be fair to both parties it is worth pointing out DC is not going the way of the dodo as many DC locomotives continue to be produced, and likewise DCC is not some magic newfangled black-box new technology as the NMRA DCC standards date back to the 1980's. Both of these are mature technology options If we consider this as a design question at its core, why must we write pages of diatrabe over something which objectively has no correct answer?
Serious question, why is this the hill people want to die on?Personally I do favor DCC systems, but I can consider some design situations where I would consider a DC set up as well (i.e. building a small diorama or setting up a Christmas tree loop). To be fair to both parties it is worth pointing out DC is not going the way of the dodo as many DC locomotives continue to be produced, and likewise DCC is not some magic newfangled black-box new technology as the NMRA DCC standards date back to the 1980's.
Both of these are mature technology options
If we consider this as a design question at its core, why must we write pages of diatrabe over something which objectively has no correct answer?
If DC isn't going away, is it because there are so many folks that conceptualize layouts like you do, and if they run DC, they have either a small diorama or a Christmas tree loop? Is DC still around because there are that many of those kinds of hobbyists?
Or is it because they understand that DCC is not that complicated, no big deal, but have made reasonable choices about what they want to use for their layout and realize it offers them no usuable advantages in their situation.
The advantages have to be able to be used on the layout, or else there is no common sense reason to have it.
When the railroad that is modeled is 10 miles long, 50 miles long, 80 miles long; and you Google Earth the Right of Way, oftentimes what you see is a single string of track snaking through the countryside with 3 or 4 major industries along the way....usually a big one at the end of the line....and maybe two runaround sidings along the entire line (Real railroads HATE complex track arrangements), you quickly realize that reducing this railroad to modeled size does not require complex DC wiring...and therefore...never presents the problem that DCC was designed to solve.
Its much more than a diorama or Christmas tree loop.
Model Railroading isn't either about 3 different railroad mainlines looping over each other, criss crossing over each other, circa 1950...a complete wiring mess...or else its a loop of track around a Christmas tree. There is lots of it in between.
Counterpoint, many of those small railroads lines would still present opportunities where DCC might be advantageous to replicate them. Many modern branchlines/shortlines run with consisted diesels back to back, with one cab on each end (as seen on the SLGW in my photos above). With dummy locomotives not being produced anymore; somebody who wants to run a consisted set with modern equipment might find DCC simpler for that purpose. Or the ability to keep multiple trains on the track if modeling a rural branchline that has to send out a speeder or hi-railer ahead of the train before it comes through to check track conditions could also be useful as it creates a situation where two moving vehicles would be on the same "block" so to speak.
I have also seen some switching operations where two locomotives come in via consist, then split into different trains to work the same yard or industry from different angles. It is not super common but it is a real world practice that DCC would be a simple approach to take to replicate. Certainly though in many cases DC can be used; but there are arguments that might persaude people to chose one or the other. In my own case, dioramas and Christmas tree loops are the most appealing places for DC though since if I were to model that branchline/shortline you described, I would be building it with DCC (although I fully understand it would be equally functional in DC). Personal design preferences and my desire to have some operational flexibility come into play with that, although building such a layout in either DCC or DC cannot be seen as making a "wrong" choice.
Also the cost advantage of DC is a huge benefit, but it does restrict what type of "visitor locomotives" can come to the layout as DCC has taken up a large majority of the hobby. If social factors are considered for club, modular layout (particularly Free-Mo) and just operating at a friend's place DCC with its growing popularity does have a leg up over DC systems. The amount of home layouts I have visited that operate a DC system is a big fat zero in my own personal experience (although I guess the Lionel three rail layout with its AC system sort of counts as something more akin to traditional DC at least in how its controlled via a fixed throttle). I am not saying DC only layouts don't exist nor that there are any in my area, but if I as an operator wanted to bring my own locomotive to an ops session at these other layouts it would need to be DCC equipped to function.
But that is again a design choice. Functional layouts can be made with both systems, with real trade-offs and advantages for both. A solo modeler might not see the appeal of having guest locomotives or taking their equipment to somebody else's layout either. The cost factor of DCC is still a massive barrier to entry (although I will point out the cost barrier to all of model railroading right now is a huge barrier to entry regardless).My confusion though ultimately stems from what I feel is a persistent myth that DCC has some inherent difficulty to learn or master since it is "digital" has "programming" and is some new technology; which is not exactly true anymore. The only difficult thing with DCC is the process of installing decoders into locomotives not designed to take them, and I fully understand that is a legitimate concern since the process can be tedious and painstaking especially when DCC chipping a large fleet. That is a very valid reason to stick to DC in my opinion; however for most new modelers with many locomotives coming out of the factory with DCC and DC options there are less reasons not to consider DCC out the gate outside of the cost argument. DCC Ready locomotives offer a great compromise as well, being DC but ready for easy DCC installation of the owner decides to upgrade in the future (or even removing the DCC to convert back to DC if the owner wishes to). Believing DCC to be harder because it has "programming" feels myopic, and not giving it a fair shake since as others have already mentioned in this thread DCC programming is no more complex than using a television remote.
Yes, its a design choice. From my point of view, the simplicity (or not) of the design is dictated by the operations of the railroad modeled.
Thanks for elaborating on the possibilites and things to consider.
Generally, modern shortlines don't really mix and match locos around with others very often. They will keep multiple locos together for their heavier trains, and have single units for the smaller trains. They don't have that many different trains on a weekly basis as to need to constantly shuffle power around. And, they prefer to keep their equipment similar around the roster. The two pics you shared are running the same type of locomotives together. Its not a problem to run two Atlas or two Athearn GP40-2s together on DC.
(And keeping it simple is always the goal, even back in the 1950s. I'm sure a railroad that ran a consist of an FM H16-44, Alco RS-3, and a EMD GP9 would have more "speed matching" issues than if they mu'ed 3 GP9s.)
In addition to onboard sound, lighting effects are best used with DCC. But the discussion is more about DCC as a pure opertating system, which is what it was up until about 10 years ago.
Personally, I never understood the cost argument. Where to spend your money in this hobby is also a choice.
ATLANTIC CENTRALAre any of you guys familiar with what this guy does? https://www.cti-electronics.com/
it's like C/MRI, using nodes connected to a PC thru a bus to control/monitor the layout: turnouts, signals and read block detector and turnout feedback, ... replacing a lotta wire
it's not a replacement for DCC or DC.
Doughless(And keeping it simple is always the goal, even back in the 1950s. I'm sure a railroad that ran a consist of an FM H16-44, Alco RS-3, and a EMD GP9 would have more "speed matching" issues than if they mu'ed 3 GP9s.)
Not really, unless one of the engines had it's gear ratio set for high speed passenger service. Otherwise, if the three engines were set to the same gearing, they would all run together fine.
PM RailfanWOW! DCC really missed the mark there! Its my own sad fault for thinking this would have turned out correctly. I cant fathom, with the control and power available in a PC, why anyone would use anything else to control your model railroad. Waybills, switching, forwarding, inventory, video monitoring, programming, automation, i mean the list goes on and on for what a PC could do..... compared to the puny lil paddles you have.... that only enter rudamentery numerical keystrokes
Waybills, switching, forwarding, inventory, video monitoring, programming, automation, i mean the list goes on and on for what a PC could do..... compared to the puny lil paddles you have.... that only enter rudamentery numerical keystrokes
PM RailfanDCC systems are finite in that they can only do what they do from the factory. Thats it. A PC can be programmed to do that, and so much more. Its infinite compared to finite.
DoughlessI think PRM was simply saying that it would have been better to develop an operating system that was able to run off of a standard household PC.
if i don't respond, does everyone think i agree?
(you mean a PC application not an operating system like Windows, Linux)
as mentioned, PCs were expensive in the late 80s when DCC was developed and hardware interfaces would need to be built to interface to the track and controllers (no one has suggested what the controller might be).
how many people had PCs in the 80s? even at work?
PCs made DCC possible because you could run cross compilers and code development systems on them to develop the DCC code in the command stations, controllers and decoders.
and if you're imagining a fancy windows GUI, a useful Windows interface didn't become available until 1987
i'd like to know what people think is the biggest deficit of DCC?
gregc as mentioned, PCs were expensive in the late 80s when DCC was developed and hardware interfaces would need to be built to interface to the track and controllers (no one has suggested what the controller might be). how many people had PCs in the 80s? even at work?
We used mini-mainframe computers at work in the 70s with 256 baud dialup modems and teletype keyboards. We migrated to first generation desktop PCs around 1980. I'm wearing a wristwatch right now that is probably 1000 times more powerful than those early PCs.
gregc i'd like to know what people think is the biggest deficit of DCC?
LINK to SNSR Blog
gregc PM Railfan WOW! DCC really missed the mark there! Its my own sad fault for thinking this would have turned out correctly. I cant fathom, with the control and power available in a PC, why anyone would use anything else to control your model railroad. Waybills, switching, forwarding, inventory, video monitoring, programming, automation, i mean the list goes on and on for what a PC could do..... compared to the puny lil paddles you have.... that only enter rudamentery numerical keystrokes PM Railfan DCC systems are finite in that they can only do what they do from the factory. Thats it. A PC can be programmed to do that, and so much more. Its infinite compared to finite. Doughless I think PRM was simply saying that it would have been better to develop an operating system that was able to run off of a standard household PC. if i don't respond, does everyone think i agree? (you mean a PC application not an operating system like Windows, Linux) as mentioned, PCs were expensive in the late 80s when DCC was developed and hardware interfaces would need to be built to interface to the track and controllers (no one has suggested what the controller might be). how many people had PCs in the 80s? even at work? PCs made DCC possible because you could run cross compilers and code development systems on them to develop the DCC code in the command stations, controllers and decoders. and if you're imagining a fancy windows GUI, a useful Windows interface didn't become available until 1987 i'd like to know what people think is the biggest deficit of DCC?
PM Railfan WOW! DCC really missed the mark there! Its my own sad fault for thinking this would have turned out correctly. I cant fathom, with the control and power available in a PC, why anyone would use anything else to control your model railroad. Waybills, switching, forwarding, inventory, video monitoring, programming, automation, i mean the list goes on and on for what a PC could do..... compared to the puny lil paddles you have.... that only enter rudamentery numerical keystrokes
PM Railfan DCC systems are finite in that they can only do what they do from the factory. Thats it. A PC can be programmed to do that, and so much more. Its infinite compared to finite.
Doughless I think PRM was simply saying that it would have been better to develop an operating system that was able to run off of a standard household PC.
I can't really answer your questions specifically. I'm not in that business. But my observation was that PCs didn't really start to get competent until the 1990's, and they were probably as rare in the common households as DCC was rare in the common layout. Not much difference as a starting point.
My company started using PCs, as did I, in the late 80's so I have been around them every day for that long....as a user, not a designer of course. Still not the slightest interested in how they work.
Edit: In our traveling job, we used portable PCs. Made by COMPAQ. The size of a suitcase, and still the screen was about an 8 inch diagonal TV. Two floppy disc drives. Floppy, not the harder smaller versions that came out years later.
I don't know that this discussion was about deficits of DCC. This isn't a thread that is critical of DCC, AFAIK.
To the extent that PRM was critical of the system from a technical standpoint, that's for him to explain.
My only take in this convo between you and him is that the idea of train operating systems using a PC as the basis makes some sense. Whether it was ever really doable, I don't know.
Interesting what that would have looked like by now with the exponential increase in the competency of the PC since the time PCs and DCC came to be.
gregci'd like to know what people think is the biggest deficit of DCC?
Back in the day, it would make sense to conserve memory by using the individual bits of a binary number as 'flags' to toggle or activate certain functions. Most humans don't count well in binary, and in any case expecting them to type or enter long strings of 1s and 0s where a single bitwise error does... well, unexpected random things that might then affect what other 1s or 0s mean. There is no simplification by encoding in hex, as there is in a legacy code editor, because that hides the fact that the individual bits are switches, rather than the number corresponding to a function call or whatever.
What's necessary is a function or program that takes a CV, parses it, and puts up in clear language what each bit is, how it is set, and how to flip it as a plain-language response, not bitwise manipulation in decimal (often without explaining why you add 16 to some CV 'value' to change a DCC function). It just so happens that this is one of the deterministic things that a typical very fast, very dumb, and very literal finite-state machine like a PC can be programmed to do, with an appropriate UI/ExD defined for it.
I come from the now-obsolescent opinion partly formed by Vail's dictum for the telephone company: that no piece of equipment I own, or have paid to acquire, should be made worthless by some flag day or OS reconstitution or change in peripheral protocols. I still find my blood pressure going up a bit when I remember the crApple response to support in, I think it was OS 8.something, for the Orange Micro 'PC board' for Macs. Their comment was 'it is no longer supported'. Do I get to know why? Do I get reimbursed for having gone with Mac to emulate IBM hardware or functionality? Not supported.
If you have decoders that run DCC code, then there should be some combination of software and hardware enablement that takes wireless commands, from whatever device, and translates and bridges them across to configure or operate those decoders. Likewise if I had some battery locomotive responding only to wireless, then there should be some combination of hardware and software that would translate the wireless datastream into something DCC-equivalent and inject it appropriately onto DCC track. There doesn't need to be some One True Modeler argument about which control protocol I have to use...
...and, I think, there ought to be some way to reconfigure data so that it can be used, with appropriate hardware and control programs, to operate DC layouts via complex switching, or selective powering of relay logic, or appropriate PWM motor or device control, etc.
wjstix Doughless (And keeping it simple is always the goal, even back in the 1950s. I'm sure a railroad that ran a consist of an FM H16-44, Alco RS-3, and a EMD GP9 would have more "speed matching" issues than if they mu'ed 3 GP9s.) Not really, unless one of the engines had it's gear ratio set for high speed passenger service. Otherwise, if the three engines were set to the same gearing, they would all run together fine.
Doughless (And keeping it simple is always the goal, even back in the 1950s. I'm sure a railroad that ran a consist of an FM H16-44, Alco RS-3, and a EMD GP9 would have more "speed matching" issues than if they mu'ed 3 GP9s.)
That's good to know. I know little about that era...and forget some of what I know every day. I could see if a person were to try to model that, it might require different locos from different model manufacturers, in which case DCC decoders in each loco might help smooth out the differences. Especially back 20 years ago when the DC/DCC Ready light boards and starting speeds changed a lot.
Fortunately for modern modelers, there isn't as much variety in the kinds of locos prototypes use. Its probably easier to build a model roster from one model manufacturer.
Doughless Personally, I never understood the cost argument. Where to spend your money in this hobby is also a choice.
Seems logical, everyone needs a power supply, a throttle, and a locomotive. I started out with an MRC1370, a BB locomotive, and later added an AC Train Engineer. The total cost was $105, probably double that with today's prices. Adding locomotives only added the cost of the locomotive.
If I were to start with DCC today, I'd purchase a YaMoRC 7100 command station, a locomotive with DCC sound, and a TCS UWT50 throttle. The CS includes a power supply and wifi (no need for a router or connection to a computer). Total cost ~$640. I would consider the cost of the decoder + locomotive when adding to the roster.
Which system if starting today? Both have walk-around control (a must have for me). Depends on budget, goals, etc. If I went with my original operating scheme (at today's price $210), I would have more dollars available for rolling stock, turnouts, flex track, building supplies, etc. For my goals, I would go basic system and add DCC later.
It's many years later and now to consider possible changes in operation. Frankly, at this time, I think $660 is too large of a chunk of my model railroad budget. However, for starters, I could purchase the command station, use an old cell phone for walkaround control, and purchase motion decoders (old locos are dcc ready but not sound ready). Next year decide if I wanted to upgrade the throttle or add a sound-equipped locomotive.
So unless one has an unlimited budget, operating system cost will be an important consideration in decision-making.
Greg asked:
I'd like to know what people think is the biggest deficit of DCC?
Can it be a list?
But when it came out they said you would only need two wires......
So you can see my list is mostly about the user interface, with only a few concerns about the core technology.
gregc ATLANTIC CENTRAL Are any of you guys familiar with what this guy does? https://www.cti-electronics.com/ it's like C/MRI, using nodes connected to a PC thru a bus to control/monitor the layout: turnouts, signals and read block detector and turnout feedback, ... replacing a lotta wire it's not a replacement for DCC or DC.
ATLANTIC CENTRAL Are any of you guys familiar with what this guy does? https://www.cti-electronics.com/
Yes, I looked into it to see if it was something I would find useful. My conclusion, too expensive for what it does. Too much stuff to learn.
BUT, that is largely because I do not want my CTC panel on a computer screen.
IF I was willing to put the CTC panel on a screen, then it would make COMPLETE sense to use a processor based digital communication system.
But, since I want my lighted push buttons on the CTC panel, it makes no sense to me to convert a couple hundered analog inputs and outputs into data, just to unconvert them on the other end.
That would create MORE wires to terminate, not less?
Again, I don't care how long the wires are, the equipment is de-centralized, so most wires are short. ONLY my throttle feeds (buss if you will) and the repeated controls on the CTC panel need to go any real distance - the controls only require CAT5 cables.
24 volt ice cube relays don't care if the wire is 30', or 50', or even 100' long. But the CTC panel will be centrally located and wire runs will only be in the 20' to likely 50' max. Some will go up into the ceiling and then back down to the layout keeping runs as short as possible.
IDRickSo unless one has an unlimited budget, operating system cost will be an important consideration in decision-making.
I was coming from the point of view that different people get interested more deeply in some parts of the hobby than others do. We each have our deeper interests.
Some might be interested in the prototype fidelity of their models. It seems to me that some are interested in the technical aspects of operating systems, and might be attracted to the most advanced system (and change to it) because of that interest. How people allocate their budget will be based on what they prioritize.
Give each person $3000 to spend on the hobby and ask how they would spend it. (Hey this might be an interesting survey).
Some might choose the state of the art op system. Some might choose expensive models. Some might choose expensive paints and tools with which to scratchbuild.
That's why I said I don't understand the cost argument. Sure, one op system might be less expensive than the other, but eveybody has a limited budget and what they spend on op systems is going to depend upon how important they are to their enjoyment of the hobby. Not everybody cares which one is the least expensive.
OvermodIf you have decoders that run DCC code, then there should be some combination of software and hardware enablement that takes wireless commands, from whatever device, and translates and bridges them across to configure or operate those decoders.
wasn't this already mentioned
that, Digitrax, for example, has WiFi throttles that communicate to the command station: selecting a loco, changing speed, operating hedalight, horn, ... and the command station sends DCC commands over the track telling the loco what to do
jmri has engine driver which accepts commands over WiFi to control locos, that are translated to the appropriate protocol to a command station, which then ...
is this what you meant by "transvert"?
OvermodLikewise if I had some battery locomotive responding only to wireless, then there should be some combination of hardware and software that would translate the wireless datastream into something DCC-equivalent and inject it appropriately onto DCC track.
if you had a wireless decoder in the loco, why would it need to inject the DCC command onto the track? (would it even support DCC)?
i can understand having a WiFi device in a loco that translates commands it recieves to DCC signals used to modulate the battery voltage to the DCC decoder which wouldn't know about the WiFi device or that it's not connected to the track
again, i'm not sure there's a clear understanding of what DCC does and doesn't do
Doughless That's why I said I don't understand the cost argument. Sure, one op system might be less expensive than the other, but eveybody has a limited budget and what they spend on op systems is going to depend upon how important they are to their enjoyment of the hobby. Not everybody cares which one is the least expensive.
IDRick Doughless That's why I said I don't understand the cost argument. Sure, one op system might be less expensive than the other, but eveybody has a limited budget and what they spend on op systems is going to depend upon how important they are to their enjoyment of the hobby. Not everybody cares which one is the least expensive. I'm more interested in "bang for the buck'' which will differ between MRRs, rather than least expensive. Cost clearly enters the bang for the buck equation.
I'm the same way, I will spend a dollar in flash if I think it is a good value/investment.
But buying things that don't fit my intended goals - not so much.
Once I own a good quality product that does what I need, I'm not much for replacing things until they are unserviceable, or the new product is significantly better for my needs.
So at this stage, I'm not replacing the Aristo throttles, the hundreds of relays bought really cheap, the lighted pushbuttons, also bought bulk and many are still brand new, the Atlas turnouts many still new in the package from the last layout that did not get completed, the 60 or 70 Tortoise machines, or any of the locos and rolling stock that I was happy with when I purchased them, and am still happy with now.
Building a large model railroad is a task, a task that cannot be completed if you keep starting over every time some new product comes along.
ATLANTIC CENTRALBut, since I want my lighted push buttons on the CTC panel, it makes no sense to me to convert a couple hundered analog inputs and outputs into data, just to unconvert them on the other end.
node architectures, like C/MRI or LCC doesn't require a PC. LCC nodes, for example, are intelligent like you're circuit blocks and share information (e.g.block occupancy turnout position) between one another to control turnouts and signals.
a CTC panel with mechanical switches and lamps could be served by one large node and several smaller ones
the node architecture, linked by a small serial bus has two benefits: reduces wiring and provides a reasonable interface to a PC. todays nodes can be linked by WiFi
ATLANTIC CENTRALAgain, I don't care how long the wires are, the equipment is de-centralized, so most wires are short.
the longer connections are between the CTC and your relay circuits
i'm curious what your CTC panel does? doesn't it control turnouts, affect signals and indicate block occupancy and turnout positions? do you have a picture?
gregcis this what you meant by "transvert"?
Ican understand having a WiFi device in a loco that translates commands it receives to DCC signals used to modulate the battery voltage to the DCC decoder which wouldn't know about the WiFi device or that it's not connected to the track again, i'm not sure there's a clear understanding of what DCC does and doesn't do
You would have to reconstruct at least half the DCC waveform between the battery and the decoder to work that way, which defeats both the point of using powerline modulation in the first place, and any reduction of switching heat or other problems involved in generating all that square-wave modulation on board.
The idea here is to change the wireless signal into something the 'legacy' DCC decoder can read off the track. That means receiving it not on the locomotive, but in appropriate 'connected equipment'.
Note that it is possible for a locomotive to be powered by a substantial battery, like a large keep-alive, and to charge that battery from DCC track voltage. This would extract and decode only the modulated signal from the DCC, not taking any power from the DCC track voltage other than that used to charge the battery.
No, again no pictures. I never finished the last one because I never finished the layout. When we decided we were not staying in the big house, I stopped working on that layout, and tried to design some modules to build - that idea failed.
The CTC panel - the sketch I made earler of the single interlocking, that is what a typical tower panel might look like, although most are a little more involved with a junction or two in addition to the double track mainlne.
The CTC panel is the same, it is just all the tower panels strung together in one place. It is just lighted pushbuttons for the throttle assignments, and turnouts, and LED indicators for block occupancy.
There are additional controls, lockouts for tower panels, etc.
There is no "logic", or relays at the CTC panel. That happens locally near each tower panel. That is where detectors, turnout control relays, and cab selection relay boards (the large board with eight relays from my other photos) are located - close to the trackage they control.
Repeater controls run to the tower panels east and west, and to the dispatchers panel. Actual signal wiring runs from the tower panel relay boards out to the signal locations. This is just a single line drawing of the cab control circuits but it might help you visualize.
Again, every time three or more blocks come together there is an interlocking territory and a tower panel.
The dispatchers panel has them all so he can control the whole mainline regarding turnouts, cab assingments and "permission". Cab assignments and permission are intergrated. You get permission (clear signal) any time you are assigned two consecutive blocks and the turnout route is correctly aligned to connect them.
The cab selector circuits for one block with 4 cabs require one 4pair CAT5 cable. And can be repeated as many places as desired.
The permission circuit is a separate control "chain" that does not go out to any panel, it is fully located on the relay panels.
Turnout controls require 1 wire per route at the control panels, the rest of that wiring is on the relay panel and goes out to the Tortoise machines.
There are lots of wires on the relay panels, lots. They are wired on the workbench.
Then control button cables, wires to the track, wires to the switch machines, throttle buss around the layout, signal feeds are tied into the relay panels.
The "average" interlocking on the layout is 5-6 blocks coming together and about 8 turnout routes. That means 3 cab selector modules, three detectors and 8 turnout relays on the average relay panel.
Because - each block only needs one cab selector module, it will be at one end or the other, not both ends. Or it could be like the drawing and be in the middle.
The problem with using "nodes" is the relays are all 24 volts? So now what, more "layers" in interface the relays with the nodes?
Why are the wires such a big deal? I don't get it. I would still have to build the control panel with the same wire count? Why not just hook them up once at each end rather than insert a bunch of additional hardware in between?
IDRickI'm more interested in "bang for the buck'' which will differ between MRRs, rather than least expensive. Cost clearly enters the bang for the buck equation.
Yeah I get that.
Some like to have the latest technology because that's what they like. Others see it as a tool to accomplish a goal. Some folks like to have cars with more horsepower than they need. Its all good. Spending money is also about enjoyment and not just pragmatism, especially in hobbies like trains, computers, or cars.
I was trying to say that a buck gives different people different bangs. So the cost-effectiveness angle is not the same for everybody.
So I took a quick count.
25 cab selector circuits on the CTC panel needs 25 cat5 cables - going to 13 different locations.
116 turnout routes requires 118 wires/8 = 15 cat5 cables also with destinations spread out over those 13 relay panels, just over one cable per panel.
On the CTC panel end, each tower panel can be wired as a stand alone clone of it the local tower panel.
38 cables with 13 different destinations.
Actually, until work got real busy, I had been starting to layout the wiring for each interlocking and tower panel. Hope to get back to both benchwork and wiring design in a few weeks when the current large work project is complete.
Doughless IDRick I'm more interested in "bang for the buck'' which will differ between MRRs, rather than least expensive. Cost clearly enters the bang for the buck equation. Yeah I get that. Some like to have the latest technology because that's what they like. Others see it as a tool to accomplish a goal. Some folks like to have cars with more horsepower than they need. Its all good. Spending money is also about enjoyment and not just pragmatism, especially in hobbies like trains, computers, or cars. I was trying to say that a buck gives different people different bangs. So the cost-effectiveness angle is not the same for everybody.
IDRick I'm more interested in "bang for the buck'' which will differ between MRRs, rather than least expensive. Cost clearly enters the bang for the buck equation.
Yes, I drive a fast car, 3.5 liter twin turbo, 0-60 in 5 seconds - it is also practical, carries 7 comfortably, we have grandchildren.
ATLANTIC CENTRAL Doughless IDRick I'm more interested in "bang for the buck'' which will differ between MRRs, rather than least expensive. Cost clearly enters the bang for the buck equation. Yeah I get that. Some like to have the latest technology because that's what they like. Others see it as a tool to accomplish a goal. Some folks like to have cars with more horsepower than they need. Its all good. Spending money is also about enjoyment and not just pragmatism, especially in hobbies like trains, computers, or cars. I was trying to say that a buck gives different people different bangs. So the cost-effectiveness angle is not the same for everybody. Yes, I drive a fast car, 3.5 liter twin turbo, 0-60 in 5 seconds - it is also practical, carries 7 comfortably, we have grandchildren. Sheldon
Nice car.
If you or your wife don't need the space, the MAZDA 2.5L Turbo supplies more than plenty of giddyup in its MAZDA3, MAZDA6, CX30..and even the CX-5 and CX-50. They use their tried and true 6 speed automatic (no fancy 8 speeds) and offer a 6 speed stick in most cars. They are a little slow with the migration to EV, which is another reason to like MAZDA.
Got any new pics of the train room? Or new pics of the house will do to.....
Overmod if you had a wireless decoder in the loco, why would it need to inject the DCC command onto the track? (would it even support DCC)? If I had a locomotive with a wireless decoder but I wanted to use DCC equipment to control it, I'd need some way to translate the DCC command structure to wireless.
If I had a locomotive with a wireless decoder but I wanted to use DCC equipment to control it, I'd need some way to translate the DCC command structure to wireless.
now i think i understand. you're suggesting that if there's no WiFi "connection" to translate the DCC signal from the track to WiFi and into the WiFi translator.
why not connect the DCC decoder to the track. DCC tech knows how to switch/break power connections (e.g. AR)
OvermodAnd if there were any control or information backchannel, it would likewise need to be translated to work with the DCC enablement used.
you want to send information from the loco thru WiFi to something
Overmod I can understand having a WiFi device in a loco that translates commands it receives to DCC signals used to modulate the battery voltage to the DCC decoder which wouldn't know about the WiFi device or that it's not connected to the track again, i'm not sure there's a clear understanding of what DCC does and doesn't do I don't have a particularly clear idea of what this sentence is supposed to mean. It starts out one way, then seems to go somewhere undefined.
I can understand having a WiFi device in a loco that translates commands it receives to DCC signals used to modulate the battery voltage to the DCC decoder which wouldn't know about the WiFi device or that it's not connected to the track again, i'm not sure there's a clear understanding of what DCC does and doesn't do
I don't have a particularly clear idea of what this sentence is supposed to mean. It starts out one way, then seems to go somewhere undefined.
WiFi messages need to be translated to a (binary) DCC format signal, used by an h-bridge to modulate the battery polarity to the decoder. (a binary (0/5V) DCC signal is typically an output from a command station to 1+ boosters)
(that means for one polarity, the decoder A/B inputs are bat+/bat- (ground). the other polarity is bat-/bat+.)
the DCC decoder wouldn't know that there's a battery, the WiFi device nor that it's not connected to the track
Doughless ATLANTIC CENTRAL Doughless IDRick I'm more interested in "bang for the buck'' which will differ between MRRs, rather than least expensive. Cost clearly enters the bang for the buck equation. Yeah I get that. Some like to have the latest technology because that's what they like. Others see it as a tool to accomplish a goal. Some folks like to have cars with more horsepower than they need. Its all good. Spending money is also about enjoyment and not just pragmatism, especially in hobbies like trains, computers, or cars. I was trying to say that a buck gives different people different bangs. So the cost-effectiveness angle is not the same for everybody. Yes, I drive a fast car, 3.5 liter twin turbo, 0-60 in 5 seconds - it is also practical, carries 7 comfortably, we have grandchildren. Sheldon Nice car. If you or your wife don't need the space, the MAZDA 2.5L Turbo supplies more than plenty of giddyup in its MAZDA3, MAZDA6, CX30..and even the CX-5 and CX-50. They use their tried and true 6 speed automatic (no fancy 8 speeds) and offer a 6 speed stick in most cars. They are a little slow with the migration to EV, which is another reason to like MAZDA. Got any new pics of the train room? Or new pics of the house will do to.....
Mazda builds a great product, but we will never own one. Neither of us like small cars.
My wife has Rheumatoid Arthritis, she cannot get in and out of vehicles that are low to the ground.
The FLEX has upright seating where the seat is nearly exactly at your knees as you get in.
The FLEX has a six speed auto with paddle shifters and is full time All Wheel Drive. It does a 15 sec 1/4 mile. There is a guy on YouTube who has one doing 12's with no engine mods, just remapped the engine computer.
Personally, even though I am a car guy of sorts, I have never liked low to the ground sports cars either.
The FLEX is fast, and handles well even though it is big. And VERY comfortable.
I have driven full sized cars and trucks most of my life.
Only owned one 4 cylinder car in my whole life......
I restored and hot rodded a 1963 NOVA in 1976 when I got out of high school, then drove it 8 years. That was a small car in those days, but would be mid sized today.
It was fast, built up 283 V8, four speed, etc.
Owned and built a lot of hot cars over the years, but not always the typical stuff.
I learned to drive on one of these and owned three of them over the years - Checker Marathon.
If I had the time, I would find another Checker.
Our family had a bunch of them, put 250,000 plus miles on every one. Built Taxi tough.
And they can be made to go fast, there are a bunch of them hot rodded on facebook. One of them races at a drag strip near me.
The train room has a big pile of materials, framing, plywood and homasote, waiting for my tools to come home from a current large job. Then I'm planning a big benchwork push.
thanks for the description
ATLANTIC CENTRALThe problem with using "nodes" is the relays are all 24 volts? So now what, more "layers" in interface the relays with the nodes?
open collector transistor driver IC can be used to control higher voltage devices.
ATLANTIC CENTRALWhy are the wires such a big deal? I don't get it. I would still have to build the control panel with the same wire count? Why not just hook them up once at each end rather than insert a bunch of additional hardware in between?
people like Bruce Chubb disagreed. they preferred to move the logic into the PC where it could more easily be changed, as PM suggested, and not have "buried" under the layout.
The LCC crowd puts the intelligence in the nodes connected with a non-polling CAN bus
and yes, i agree a node architecture in addition to what you're doing doesn't make sense considering that all the intelligence for your CTC panels in under the layout
ironically, what i'm doing at the club is similar to what you're doing. nodes currently implement ABS for 1+ signals, but easily reprogrammed.
i think architectures may change, less centralized, now that the processors used in DCC and node components can easily be reprogrammed, as PM suggested
as i learn more about how you do things, it's another thing on a growing list of ways to do MR that hasn't been discussed in magazines or forums