Greg,
Before Bruce Chubb built his first computerized system, he build a cab control/CTC/fully signaled system with relays, published in MR is the late 60's or early 70's.
My signal system borrows some of his methods.
Another pioneer in early advanded DC control was Ed Ravenscroft who's work is the foundation for the single track mainline version of my system.
Paul Mallery suggested some of the ideas used in my system in his Electical Handbook for Model Railroads - Vol 2, but admitted he had not tried them. The fundimental idea of the pushbuttons for the cab assignments came from him, but his circuit suggestions were aimed at using as few relays as possible rather than the best circuit which is similar to full scale industrial motor control circuits - something I know a lot about.
What I did was apply all these old control ideas to a system built around a wireless radio throttle and a modern solid state inductive detector. That is a whole area we have not explored - why I use inductive detectors - more on that another time.
And I had the advantage of better, smaller and less expensive relays than what they had to work with.
The common relay used before the 70's were surplus 48 volt telephone relays. Big clucky rotary relays that took up lots of space. They were often used as switch machines as well.
I use 24 volt DC industrial ice cubes, 4PDT. 15-20 years ago you could buy good quality ones for $2-$3 each, and used ones (often not really used, surplus actually) for $0.50 to $1 each. Often the bases cost more than the relays..... But I found some deals.
Keep in mind, I could do even more with my type of system, but I choose to "selectively compress" and simplify things like the signaling, or the CTC physical switches, not so much to make the wiring simpler, but to keep it more user friendly.
It does however make the wiring simpler to do stuff like elinimate occupancy yellow signals. Here is the thing, the train ahead is too far away to matter to the train behind.
It is a lost idea today, but back in the old days, lots of experianced modelers who built signal systems recommended not modeling permissive block signals and only modeling the interlockings or "absolute" signals.
My propulsion circuit is completely discrete - each throttle has its own 4.5 amp regulated power supply. There is no common wire/rail wiring, both wires are switched by the cab selector.
Sheldon
gregcI'd like to know what people think is the biggest deficit of DCC?
For me, it is the requirement to install decoders into locomotives that were never meant to have them.
Athearn BBs, L-L Proto 2000, Stewart/Kato F units, and brass steam locomotives make up 80% of my operational fleet.
That is the deal breaker for me. I am not sure it is really what you would term as a deficit because it is not a deficciency in the DCC system.
DoughlessDifferent people get interested more deeply in some parts of the hobby than others do. We each have our deeper interests.
I tried to have a thread where people shared what their deeper interests in the hobby were. I got called an elitist because I enjoy building craftsman kits and scratchbuilding structures.
It was more caustic than any DCC thread I have seen.
I still think it would be an interesting subject.
-Kevin
Living the dream.
Hello Railfans!) OK, the work week is done, and I can spend more quality time explaining my 'view' of DCC 'or' DC (not versus).
First, lets remind ourselves this is a text forum. No genuflections, or innotations can be observed. So, dont take everything I say with a grain of salt. I 'presume' (not assume) most of you can follow my intent. As I deem you all like minded, and since I consider myself purty un-dumb, Its my perception you follow my thinking without much explanation. My appologies if this is not the case.
Now, Lets start where I left off. That would be with GregC and his post of 6:48am 7/12/2023.....
Its seems I need to clarify what the DCC system I envision (using a PC) would look like. Well, much like DCC, there has to be a reciever in the loco, or other accessory your driving. Thats a given no matter what type of system your using (except DC).
I would utilize the old MRC handheld controllers with throttle, direction, brake, momentum, adding whistle and bell. Lighting was never a concern to me as its pretty simple to use directional lighting which is one less thing the DCC side has to worry about. Unless you want it.
Since memory controlled power is the choice of choices for walkaround train control i figured add an IC to the handheld throttle. Essentially - a decoder for your throttle. The PC could match throttle to anything - or vice-versa.
Programming.... again, either with a PC or todays DCC you still have to assign 'designations' to anything your going to control. So this is pretty much the same, and once again.... is a given. But with a PC... it can be inventory based! or not. So this lends to used data vs raw data entry. (less programming).
Now weve established loco control, and the control to do it with. Memory walkaround inflects the system must use a bus wiring. Well DC or DCC..... thats a given one more time.
in todays world, PCs are plug and play and have been since the mid 90's (Win95). So it is easy to see if you want 300 throttles, you use a 'Hub'. Todays its USB, yesteryear we used the same thing, just not plug and play nor was it USB. We used daughter boards if not hubs. Com ports, Prtr ports, etc.
Computers for home use have been around since the late 1970s. Expensive? I dont remember it being that bad. Having seen what Bruce Chubb and others were doing, plus by 1980 i was already writing programs on commadores (at home!), it was a natural progression to think DCC would be PC based. Who knew!
All in all Greg, todays DCC system, as opposed to a PC system isnt really all that different. This is why I didnt elaborate in detail because it would have been redundant.
All the other mentions about paperwork, sound, inventory etc etc, is just the icing on the cake that a Railfan could do, if the DCC of today was PC based. You cant do that stuff with a Pure DCC system. Its for layout control only.
The part about updateability, operability, etc etc. Well, take the shell of a PC, youll see ALOT of empty space and unused componants. Not so in a DCC system. That right there shows you that the PC is such an untapped power source its begging to be a DCC controller! All the controllers you have around your layout are now on one daughter board (or two or three dpepending) in one PC. Connected by cables or buses to the layout. Different, but not all that different.
Next in line was Douglas #1 from 8:25am 7/12/2023.....
Brilliant repose! From first paragraph to signature. I especially liked the comparison betwixt mainframe in a back room (which is where youd find me back in the day) and cubicles.
Right down to the function key example. I dont know how you can read something so small, but your reading my mind now!
The appology is mine as said above, sometimes my point doesnt carry if I cant intonate my ideas better. Though weve managed to give Sheldon some time expending literature to read.
On to Dehusemans post of 8:48am same day....
Yeah, i coulda worded that better. Using a PC based DCC system "would be alot less equipment needed" instead of "wouldnt require additional hardware".
In other words, you dont need a controller for your throttles - just the throttles, a controller for your accessories, a controller for your signalling, a controller for your block detection. The PC could be all those controllers in one. Youd still need the sensors though. Thats a given.
The software being the "overwatcher" that can run in background doing who knows what while you run trains.
DCC IS plug and play.... now. But PCs had it first. And they still do it the best.
Again, better wording on my part and less presuming.
OverMod stated at 9:37am 7/12/2023 that....
"... build a custom pc that had DCC on the MBoard, or something in an expansion slot."
YES! expansion slots!!! daughter boards! These existed way before DCC ever sold its first system. Thus why I figured this would be how DCC would grow. It was natural to use pre-existing computer power with only a few minor electronic boards added and a software program. Instead, we got whole custom designed, commercially produced, specific systems.
Putting DCC on a MBoard would be futile. Leave the MB as they are today, and just use expansions/daughters as the DCC part. This lets ANYONE with a PC past present and future run DCC. Thats the versatility part of a PC based system. So you see what I was after too!
In General) Aside from actually drawing a picture I hope now it is clear what the intent of a PC based DCC system would be like.
Not much different than what we have, yet more powerful, and way more versatile.
Setting everything aside, my original post to Sheldon was to toss in a view (not description) that no one has heard before. Its usually the price/quantity reason, or its not suitable for the size of railroad being built. Surely it cant be that hard to imagine a PC could have been the brains behind it all. And thus, my unique view on DCC 'or' DC.
Yall have a wonderful evening, Im gonna go put my feet up, them dogs is barkin!
PMR
ATLANTIC CENTRALBefore Bruce Chubb built his first computerized system, he build a cab control/CTC/fully signaled system with relays, published in MR is the late 60's or early 70's.
why do you think he replaced that approach with one using processor based nodes and a serial bus connected to a PC? (are you reading this PM Railfan)?
greg - Philadelphia & Reading / Reading
gregc ATLANTIC CENTRAL Before Bruce Chubb built his first computerized system, he build a cab control/CTC/fully signaled system with relays, published in MR is the late 60's or early 70's. why do you think he replaced that approach with one using processor based nodes and a serial bus connected to a PC? (are you reading this PM Railfan)?
ATLANTIC CENTRAL Before Bruce Chubb built his first computerized system, he build a cab control/CTC/fully signaled system with relays, published in MR is the late 60's or early 70's.
Well, partly because he could. That was his profession, like you, so it was a great test bed for his own work.
Look, I understand all the reasons why in the real world today we use what we use. And I would agree that the next level of complexity above what I do is likely better served by more advanced approaches.
But there is something fascinating about the old way. The relay based detection and signaling on the prototype lasted a long time and is just now being fully upgraded.
But I simply don't need more than what my system does. And lots of people in this hobby don't even need or want as much as I have.
And one of my big driving factors originally was the cost and extra work of DCC for what I knew would be features of little importance to my interests.
And again, it would not have made the signaling question any easier.
ATLANTIC CENTRALBut there is something fascinating about the old way.
like steam locomotives
Computers, too, started out using relay logic... and you could find surprisingly complex (and expensive) equipment using it rather than 'microprocessors'. If you have ever tried to troubleshoot or initialize a '60s jukebox, you can appreciate why replacing relays with solid-state logic can be a remarkable simplification.
DCC was developed in a comparatively primitive era of microprocessor-based development, and early attempts at equipment were klunky, often proprietary in wacky ways, and had the same user hostility and compression of command representation we find in some of the more dubious flavors of xNIX. As features were added by some manufacturers the representation only became more arcane, only peripherally helped by things like those talking decoders. JMRI was a good and reasonable step toward supporting all the different types of legacy equipment in one UI... but it, itself, is based on an obsolescent technology.
Indeed, it would make little sense for any advanced DC user to tear out the structure of relays and switches to replace it with a pure PC-controlled system. But by the same token, it would be nonsense for a new user to replicate all that wiring and device cost -- even possessed of materials lists and wiring diagrams. One problem is that there STILL isn't any standard from NMRA for how devices report their state to control equipment, leaving us to use somewhat wacky and unsophisticated European implementations if we want bidirectional communication. It remains to be seen how this gets addressed with NMRA standards for broadband wireless control.
SeeYou190I tried to have a thread where people shared what their deeper interests in the hobby were. I got called an elitist because I enjoy building craftsman kits and scratchbuilding structures. It was more caustic than any DCC thread I have seen. I still think it would be an interesting subject.
How about a question thread: If $3,000 dropped on your head that you could only use for MRR in the next 6 months, how would you spend it?
That's a lot of money. But a person could use it up quickly depending upon how the spent it.
- Douglas
Doughless SeeYou190 I tried to have a thread where people shared what their deeper interests in the hobby were. I got called an elitist because I enjoy building craftsman kits and scratchbuilding structures. It was more caustic than any DCC thread I have seen. I still think it would be an interesting subject. How about a question thread: If $3,000 dropped on your head that you could only use for MRR in the next 6 months, how would you spend it?
SeeYou190 I tried to have a thread where people shared what their deeper interests in the hobby were. I got called an elitist because I enjoy building craftsman kits and scratchbuilding structures. It was more caustic than any DCC thread I have seen. I still think it would be an interesting subject.
Easy, a few more cases of flex track, a brass WESTERN MADYLAND Pacific, structure kits and scenery materials. Equipment for several sets of working crossing gates.
ATLANTIC CENTRALBut I simply don't need more than what my system does. And lots of people in this hobby don't even need or want as much as I have.
That is the root of the subject, IMO.
PM RailfanIts seems I need to clarify what the DCC system I envision (using a PC) would look like. Well, much like DCC, there has to be a reciever in the loco, or other accessory your driving. Thats a given no matter what type of system your using (except DC). Etc, etc
Etc, etc
Nothing you have described is any different from DCC.
You are focused on hardware. DCC isn't hardware.
A commercial DCC system is more or less command station, running DCC software, that converts the analog "commands" from the throttles into digital commands, a power supply to superimpose the digital commands on the track power.
You can ditch the proprietary throttles by using Bluetooth and a smart phone.
You can ditch the power supply by using batteries and either a radio system or Bluetooth.
In any case you need a "decoder" in each engine.
Really the only thing you want to change is load the DCC software on a microprocessor in a PC rather than have it on a microprocessor in a proprietary command station.
I'm pretty sure you can do that now since you can run DCC off a Raspberry Pi.
Everything you want to do can be done today. I have no idea on how to do it because I have no interest in a "roll your own" DCC system, but there are modelers in my area that are running DCC without a commercial system.
Here might be some ideas:
Do-It-Yourself DCC projects (dccwiki.com)
Dave H. Painted side goes up. My website : wnbranch.com
DoughlessHow about a question thread: If $2,000 dropped on your head that you could only use for MRR in the next 6 months, how would you spend it?
Buy some 3D printed cars and stuff to complete them. The TOTO cost ("turn over to operating") is about $75-80 per car. That would be about $1500. The rest would go to a TrainTraxx RFID system to start experimenting with making an RFID system to automate OS's for dispatching.
dehusman Doughless How about a question thread: If $2,000 dropped on your head that you could only use for MRR in the next 6 months, how would you spend it? Buy some 3D printed cars and stuff to complete them. The TOTO cost ("turn over to operating") is about $75-80 per car. That would be about $1500. The rest would go to a TrainTraxx RFID system to start experimenting with making an RFID system to automate OS's for dispatching.
Doughless How about a question thread: If $2,000 dropped on your head that you could only use for MRR in the next 6 months, how would you spend it?
DoughlessHow about a question thread: If $3,000 dropped on your head that you could only use for MRR in the next 6 months, how would you spend it?
I would buy the best new PC and 3D printer I could get for $3,000.00.
If the question was $1,000.00 I would have a different answer.
Doughless How about a question thread: If $3,000 dropped on your head that you could only use for MRR in the next 6 months, how would you spend it? That's a lot of money. But a person could use it up quickly depending upon how the spent it.
gregcI thought ATC is partially aligning routes on a schedule, starting trains on a schedule, slowing and stopping trains at stations and at stop signals and stopping trains at their destinations.
The original systems of 'automatic train control', dating back at least as far as the Vogt system in the 1880s that Frank Sprague took notes about as a teen, all involved stopping a train that went 'where it wasn't supposed to be'. Interestingly, most of these involved steam, but didn't provide automatic control of throttle or cutoff: they applied service or 'penalty' braking to get the train stopped, often by reference to automatic block signaling of some kind.
You see this coming to be referred to as ATS when the functionality of speed control was added to the 'stop' function. C&NW for example used a system that defined a small number of speeds and could enforce slowing to reach a 'target' speed without actually stopping the train and requiring a reset. But it still didn't involve powered control of a locomotive throttle or cutoff -- that could have been incorporated technically, of course; a perfectly good autonomic cutoff control for a different purpose was implemented and tested by 1922, essentially at the same time as the Esch Act, but it would have cost too much and likely caused too many problems for the 'state of the art' in the early '20s.
Even when you get to the '80s, the PTC developments on NJT and (more abortively) in the NAJPTC development 'project' remained reactive: they responded only when prompted to do so, not predictively. A number of institutions have developed predictive systems (Carnegie-Mellon, for example, which also included GPS/GIS data in the predictive logic for train handling) and, as I recall, the French TVM which in some respects is still a 'gold standard' for what high-speed train control should provide.
The simple and primitive way to provide ATS on an electric model railroad is to ensure that power is cut to a 'block' at least the length of a locomotive's pickup past a "red signal" or improperly-set block. Aside from being unprototypical-looking as hell, it won't as noted work if you have any sensible level of keep-alive power in a locomotive. To do ATS braking prototypically would involve far more tinkering and complexity than the idea is probably worth; for DCC it would involve some device that could issue an appropriate stream of voltage reductions to the locomotive's motor (while presumably instructing the throttle or other control that it was being reduced and overriding what the throttle was commanded to do, or what the person running the throttle might try to do). If you thought relay logic was complicated to design and implement... I wish you luck figuring out how that one would be done.
An alternative might be to have separate blocks of DCC power, all fed with a common control modulation. That would allow controlled reduction of track power down to a voltage that would not permit locomotive movement (while at least in theory keeping sound, lighting, and reception of other commands still running). Again with a keep-alive much of this "functionality" falls to the ground.
On the gripping hand if you have a PC issuing the DCC commands, it's a relative cinch to compare the block location, signal indication, and any other things that are reported as inputs... and simply command the locomotive to execute an appropriately selectively-compressed braking run to a stop. And then requiring whatever control action corresponding to unlocking the ATS 'from the ground' a user might find appropriate before that train could proceed...
I recommend a new thread actually be started for the '$3000 question'... and, if possible, that moderation move all the replies to it here to that new thread, arguably including those involving acquisition of some DCC hardware.
The big difference between many of the earlier systems (ATC, ATS) and PTC is that they, in many cases, stop the train if it violates stop signal, and PTC will stop the train before you violate a signal (or authority).
OvermodNone of that is either ATC by any of the older definitions
understood. but acronyms do have multiple meanings, see ATC
OvermodThe simple and primitive way to provide ATS on an electric model railroad is to ensure that power is cut to a 'block' at least the length of a locomotive's pickup past a "red signal" or improperly-set block.
on the Pacific Southern (model) Rwy, these were called "stopping blocks". they preceded the signal and power was cut when occupied and the signal is STOP
ATC implemented on the Pacific Southern was to control trains directly via DCC -- tracking them by ID from block to block. the stopping block just mentioned were now used to detect a train approaching a STOP signal and slow it to a stop. the train was allowed to proceed when the signal cleared
gregc Overmod None of that is either ATC by any of the older definitions understood. but acronyms do have multiple meanings, see ATC Overmod The simple and primitive way to provide ATS on an electric model railroad is to ensure that power is cut to a 'block' at least the length of a locomotive's pickup past a "red signal" or improperly-set block. on the Pacific Southern (model) Rwy, these were called "stopping blocks". they preceded the signal and power was cut when occupied and the signal is STOP ATC implemented on the Pacific Southern was to control trains directly via DCC -- tracking them by ID from block to block. the stopping block just mentioned were now used to detect a train approaching a STOP signal and slow it to a stop. the train was allowed to proceed when the signal cleared
Overmod None of that is either ATC by any of the older definitions
Overmod The simple and primitive way to provide ATS on an electric model railroad is to ensure that power is cut to a 'block' at least the length of a locomotive's pickup past a "red signal" or improperly-set block.
Meanings that get redefined on a regular basis as things evolve. I'm sure in my vast railroad library I can find multiple use of ATC to mean the original 1920's inductive train stop system.
But the modern rail industry has apparently usurped that name and acronym for a new definition and arbitrarily renamed the old system Automatic Train Stop.
Who knew until I tried to look it up recently.....
Are you asking me the same question? I'd say because the single processor PC was better. Certainly it was much faster than the scratchbuilt electronics (clock/bus speeds). A big time saver in putting the system together (pc already made).
If Im reading you right, thats my answer. But i never met the man, so it is an educated guess.
dehusman PM Railfan Its seems I need to clarify what the DCC system I envision (using a PC) would look like. Well, much like DCC, there has to be a reciever in the loco, or other accessory your driving. Thats a given no matter what type of system your using (except DC). Etc, etc Nothing you have described is any different from DCC. You are focused on hardware. DCC isn't hardware. A commercial DCC system is more or less command station, running DCC software, that converts the analog "commands" from the throttles into digital commands, a power supply to superimpose the digital commands on the track power. You can ditch the proprietary throttles by using Bluetooth and a smart phone. You can ditch the power supply by using batteries and either a radio system or Bluetooth. In any case you need a "decoder" in each engine. Really the only thing you want to change is load the DCC software on a microprocessor in a PC rather than have it on a microprocessor in a proprietary command station. I'm pretty sure you can do that now since you can run DCC off a Raspberry Pi. Everything you want to do can be done today. I have no idea on how to do it because I have no interest in a "roll your own" DCC system, but there are modelers in my area that are running DCC without a commercial system. Here might be some ideas: Do-It-Yourself DCC projects (dccwiki.com)
PM Railfan Its seems I need to clarify what the DCC system I envision (using a PC) would look like. Well, much like DCC, there has to be a reciever in the loco, or other accessory your driving. Thats a given no matter what type of system your using (except DC). Etc, etc
OK, we need to stop right there. We'll go top down.
Yes, what I described is different. Totally different hardware and software. Controls look different. Your confusing the fact they do the same exact job.
Like cars tires, two different companys make their tires two different ways. But they both are still round, both still roll. Ones a white wall, one isnt. They look different, have different compounds of rubber/steel in them but do exact same job. And obviously, one tire would be better than the other.
DCC isnt hardware??? WHAT??? DCC is nothing BUT hardware! And only a trace amount of software. DCC is 90% hardware. And only 10% software because the electronics in a commercial DCC system are 'limited' to what they can do by design..... run trains! PC system which is more like 60/40 hardware to software can utilize its electronics in many more ways. ( i wont even touch what the software side can do compared to a limited DCC system).
Your tiny lil arduinos, Pi's, cell phones, all use ARM tech and chips. While they are everyday getting better they still cant match the power of pc hardware or chips. Clock/bus speeds are still higher in pc's vs the afore mentioned smaller things.
DCC systems arent designed with the biggest bestest fastest electronics because they dont need to be. This keeps the price down (in theory, but its still overpriced!). PC's on the other hand, use the latest, greatest, fastest electronics because 'they have to'! Thats the whole idea behind PC's. Not DCC's.
I would never use any kind of 'open communication' for trains (or anything else for that matter). You mnetioned radio, bluetooth, and smart phone. Yes, that can be done, but thats just a bad idea! BAD BAD BAD!
Yes, everything I mentioned can be done today. That wasnt the question. And we certainly werent talking about 'today'. The que is DCC 'or' DC..... which? I made that choice decades ago, not today.
PM RailfanA big time saver in putting the system together (pc already made).
not sure you're familar with C/MRI nodes which he designed.
not sure it saved him much time rewiring his layout. and i'm not sure it saves time putting the system together, if you know what you want it to do and have a small set of circuits to do so ... ask Sheldon
for Chubb, he not only had to replace the logic hardware with his nodes, he now had to write the PC software to communicate with the nodes as well as the logic for the various trackage.
i believe the big advantage is that it allows the system to start small and grow, be easily modified, then add features, as well as add to the layout itself. features may include a graphic user interface and improvements to it, interlock logic, basic and advanced (speed) signals, ...
but even if you start with what Chubb offers, there's the need to purchase, install, wire the nodes and connect it all to a PC. your system will start small, grow and morph as it gets built up and software makes this easier
from my understanding of a similar system on the Pacific Southern Rwy which took decades to build, the initial nodes just provided better connectively between towers from/to which train control was passed (pre DCC, just tower operators). eventually portions of the layout were controlled from the dispatcher PC: block detection and turnout position were monitored/reported on a screen and turnouts were controllable. the system was expanded, placing more of the layout under dispatcher control. Signals were added much later and to this day, not all of the layout is under dispatcher control.
PM RailfanDCC isnt hardware??? WHAT??? DCC is nothing BUT hardware! And only a trace amount of software. DCC is 90% hardware. And only 10% software because the electronics in a commercial DCC system are 'limited' to what they can do by design..... run trains! PC system which is more like 60/40 hardware to software can utilize its electronics in many more ways. ( i wont even touch what the software side can do compared to a limited DCC system).
DCC booster hardware is mostly an h-bridge circuit used to control the direction and speed of a DC motor to reverse the polarity of track voltage (see DCC++)
DCC bits are communicated by the time between polarity reversals of track voltage.
a relatively simple and inexpensive 8-bit controller (Pic/Atmel) processor (simililarly used in Arduino Uno) can be used to process a queue of commands that need to be repeatedly transmitted onto the track. each bit in the command dictates the time between two polarity reversals (one cycle).
the other thing the processor needs to do is communicate with controllers which can use built in serial controllers (UART) which can be serviced at lower priority. similar processors can be used in the controllers, just as they are used in decoders.
I would like to thank everyone for an interesting and civil discussion.
I think some exceptional points were made about understanding why people make different choices in their modeling.
And great technical and philosophical side bars also offered insight into how and why we build our layouts the way we do.
And maybe this has helped the group reach a new level of understanding of the differing views on this topic and on the hobby in general.
ATLANTIC CENTRAL I would like to thank everyone for an interesting and civil discussion. Sheldon
Rich
Alton Junction
Sheldon) Ditto what Rich said. As to what you mentioned about sidebars etc., there could be many threads started just from this one.
Definately a topic that would light up the 'Electronics' part of the forum.
A#1 North!
Douglas
PM Railfan Sheldon) Ditto what Rich said. As to what you mentioned about sidebars etc., there could be many threads started just from this one. Definately a topic that would light up the 'Electronics' part of the forum.
dehusmanReally the only thing you want to change is load the DCC software on a microprocessor in a PC rather than have it on a microprocessor in a proprietary command station. I'm pretty sure you can do that now since you can run DCC off a Raspberry Pi. Everything you want to do can be done today. I have no idea on how to do it because I have no interest in a "roll your own" DCC system, but there are modelers in my area that are running DCC without a commercial system.
How much power can they run through one of those? I've got an Arudino that I use as a JMRI interface, but limited to a decoder programmer. I can run enough power through it to move two locomotives around a christmas tree loop but not much else.
NittanyLionHow much power can they run through one of those?
Not much. That's why I say "using a PC" is pretty much just choosing a different "command station". You STILL need something that powers the tracks. The people using something other than a commercial system still have to have some sort of "module" that interfaces with the DCC "brains" and provides enough power to run the railroad. I don't use a roll your own system so I don't know what all the components are called and exactly how they are hooked up.