Lastspikemike In computing terms DCC is already seriously outdated. The NMRA standard has proved to be a double edged thing, as these standards often turn out to be. Using Function keys isn't even convenient for actual computer work. DCC still requires some understanding of the concept of programming at the level of the bit. It isn't necessary now to run power as an AC mimic and the control signal as DC piggybacked on the same wires. Each locomotive only needs a variable DC voltage throttle and wireless link. The rest of the DCC control software isn't necessary at all. The iPhone throttle is just the thin edge of this technology wedge. The problem is the heavy financial investment made when NMRA governed DCC got started in the 90's which, unfortunately, could not look far enough down the road at that time. Changing over to bluetooth or Wifi LAN software now would be very expensive but ideal. Recall that the Windows 95 era is contemporaneous with the currently valid NMRA DCC....
In computing terms DCC is already seriously outdated. The NMRA standard has proved to be a double edged thing, as these standards often turn out to be.
Using Function keys isn't even convenient for actual computer work. DCC still requires some understanding of the concept of programming at the level of the bit.
It isn't necessary now to run power as an AC mimic and the control signal as DC piggybacked on the same wires.
Each locomotive only needs a variable DC voltage throttle and wireless link. The rest of the DCC control software isn't necessary at all.
The iPhone throttle is just the thin edge of this technology wedge. The problem is the heavy financial investment made when NMRA governed DCC got started in the 90's which, unfortunately, could not look far enough down the road at that time. Changing over to bluetooth or Wifi LAN software now would be very expensive but ideal. Recall that the Windows 95 era is contemporaneous with the currently valid NMRA DCC....
Well from someone on the fence still about DCC, I can tell you this. Pro's about DCC, sound (love that feature), two or more trains on same track and no turning off a side track just so the main engine can be used. Con's, much more fussy and prone to damage from operator error. Also DCC can be way more expencive than DC but has powered frog options that are much better and better automatic y controls for those that have that type of trackwork, These things have to be done manually in DC but can be done.
Whereever did you get the idea that DCC uses an AC power source with a DC control signal superimposed? That's actually opposite what most pre-DCC command control systems used - steady DC power with an AC pulse superimposed.
The DCC power IS the signal - full amplitude, there is no little tiny signal to pick out from the noise of brushed DC motors operating.
Wayne - as I said, sound on DC is just a non-starter,. I think it was a silly idea to even bother - and I'm sure I'll get plenty of responses that "I do it allt he time, it works fine". The only people I can imagine are actually satisfied witht he way sound locos work on DC are those who don't know any better. It's pretty simple - the electronics need around 5 volts to operate. The only way to get 5V or more to the loco on DC is to turn up the throttle. Unless a loco is relatively poor quality, by 5-7 volts, it should eb moving. However, if a sound loco behaved like that, it would be moving, with no sound since the voltage is high enough to turn the motor but not run the sound electronics. So they are set up not to move until a relatively high track voltage, leaving enopugh for the electronics plus some dead band because not all (more like most common) DC throttles aren;t particualrly precise, so a dead band is necessary to allow you to actually stop the thing but keep the sound going. Only once the voltage gets above that point does it start moving - but at 7-8 volts, you're already 2/3 of the way to full throttle. So you have a limited range of control for the sound loco to go from stopped but making noise to running full speed. And any other locos, without sound, at 2/3 throttle are probably already going faster than is realistic. If you want sound, go DCC, period. There are workarounds, like the MRC Tech 6, but when running that sound loco, it's using DCC, and when running a DC loco, you're now using the MRC pack and not that nice PWM DC throttle.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
LastspikemikeI point out that it is in fact a very primitive software system not readily accessible to current computer users with very little interest in "coding".
I'm not clear on what you mean.
I know absolutely nothing about coding or computer languages.
Yet referring to a one page sheet containing commands (since I don't remember them), with two or three buttons pushed on my handheld control, I can change virtually hundreds of different commands to my locomotives.
What am I missing by using this primitive software? What am I missing by using a handheld control rather than a laptop or phone? Why should I worry how easy or difficult it is to access?
York1 John
Lastspikemike I'm not advocating replacement of DCC. I point out that it is in fact a very primitive software system not readily accessible to current computer users with very little interest in "coding". I have a two BLI, a paragon 2 mikado and a paragon 3 pacific. I note that the pacific is very sensitive to the slightest voltage drop out while the Mike is not. My understanding of DCC, limited as it is, is that the main power is not a true AC but it does differ from the control signal and that both sets of power are transmitted down the rails concurrently. The decoder picks out the control signal and also converts the pseudo AC into DC (I guess "rectifies" is the term) with the variations in voltage required to control motor rpm. The power is phased and the alternating aspect is alternating the voltage in tiny amounts but not the polarity. So, the technical problem solved economically by DCC in the 1990's was standardizing the technology required to deliver power and the control signal down the same two conductors, which effectively froze development of the supporting software.
I'm not advocating replacement of DCC. I point out that it is in fact a very primitive software system not readily accessible to current computer users with very little interest in "coding".
I have a two BLI, a paragon 2 mikado and a paragon 3 pacific. I note that the pacific is very sensitive to the slightest voltage drop out while the Mike is not.
My understanding of DCC, limited as it is, is that the main power is not a true AC but it does differ from the control signal and that both sets of power are transmitted down the rails concurrently. The decoder picks out the control signal and also converts the pseudo AC into DC (I guess "rectifies" is the term) with the variations in voltage required to control motor rpm. The power is phased and the alternating aspect is alternating the voltage in tiny amounts but not the polarity.
So, the technical problem solved economically by DCC in the 1990's was standardizing the technology required to deliver power and the control signal down the same two conductors, which effectively froze development of the supporting software.
You must stop thinking in terms of Analog DC.
The DCC signal is not AC. Never was. It looks like this: DCC Power. The waveform is the data and the power are combined.
The decoder picks off the pulses from one rail, at full voltage, so there is no mistake which logical state the rail is in at that point in time. It takes the pulses and routes them through a rectifier to provide power for the microcontroller and the motor.
The motor is driven using full voltage PWM. There is no phasing or polarity needed, the motor's drivers determine speed and direction by their switching sequence.
How did the standardisation of the control/power signal on the track lead to stagnation in the software?
Decoders and throttles have advanced enormously since the mid 90s as the microcontrollers became more powerful and the components got cheaper.
Television wasn't frozen in the 1950s. If it was, we would still have monochrome sets with a small CRT. Many engineers of the day would consider today's 4k televisions witchcraft. They considered the bandwidth needed for video to be excessive.
LastspikemikeI'm not advocating replacement of DCC. I point out that it is in fact a very primitive software system not readily accessible to current computer users with very little interest in "coding".
curious what type of modern software system you might be suggesting? (is your background in software)
DCC users don't need to know how to code, they need to understand configuration options described in CVs.
and DCC only describes the electrical signals on the track, not the user interface which you may be referring to
greg - Philadelphia & Reading / Reading
doctorwayneThe only DCC loco I've run on my layout was a BLI Mikado that I detailed and painted for a friend. While it ran not too badly, the sound feature would cut-in and out, as if it were re-setting itself. Perhaps that had some influence on my disinterest in sound, but after almost 40 years in a steel mill, sound isn't an attractive feature.
If you were running it on DC, most likely you were running it right on the edge of where it was just getting enough power for the sound to be on and the engine would move. If you ran it on DCC, the sound would be constant - unless you have really dirty track.
rrebellCon's, much more fussy and prone to damage from operator error.
Only problem I've had came with trying to solder connections to a 'lightboard replacement' decoder, too much heat can hurt the decoder. Other than that, there's not much you can do to damage a decoder unless say the engine derails and you allow the resulting short circuit to continue long enough to burn something out. If you mess up the decoder programming, you can always do a re-set to the factory defaults and start over. BTW, since decoders come with pre-set defaults built in, the only thing you really need to 'program' is to change the ID number to the engine number. The engine then will run basically the same as it had on DC - unless the decoder has a "keep alive" function built in it; then the engine will go over dead frogs and dirty track that would stop it on DC.
All this from mentioning that the suggested replacement system of direct wireless to the loco uses ironically the more primitive common negative connection for the function outputs. Open collector common positive current sinks in general tend to be more efficient.
At least Sheldon and some others understand DCC, and have their own reasons for not using it.
rrinkerrrinker wrote the following post 3 hours ago: All this from mentioning that the suggested replacement system of direct wireless to the loco uses ironically the more primitive common negative connection for the function outputs.
I'm delighted to see reasons why DCC's convention is more efficient, but the original point of why LocoFi reversed it remains a WTF moment... now, in fact, even more of one.
Overmod rrinker rrinker wrote the following post 3 hours ago: All this from mentioning that the suggested replacement system of direct wireless to the loco uses ironically the more primitive common negative connection for the function outputs. Well, not precisely, the original issue was that LocoFi wired that, in a standard plug mind you, backward from the way DCC does it. I'm delighted to see reasons why DCC's convention is more efficient, but the original point of why LocoFi reversed it remains a WTF moment... now, in fact, even more of one.
rrinker rrinker wrote the following post 3 hours ago: All this from mentioning that the suggested replacement system of direct wireless to the loco uses ironically the more primitive common negative connection for the function outputs.
Well, not precisely, the original issue was that LocoFi wired that, in a standard plug mind you, backward from the way DCC does it.
I think that's what I said - the LocoFi makes the blue common the negative, the individual function wires are positive, which is backwards from DCC, yet they designed their controller to plug in to a standard DCC format socket. At least one responder mentioned that this sort of direct wifi is how things ought to be done, a lot less "primitive" than DCC, yet the irony here is the "advanced" device is using a more "primitive" circuit design.
I did start this thread, after all.
LastspikemikeI point out that it is VERY primitive and not at all plug and play user friendly. It should be but it isn't.
plug and play certainy by itself won't make it less primitive. can you be more specific about it's shortcoming? provide some examples?
rrinker I think that's what I said -
Both your comments stand, despite any discussions with different 'interpretations'.
Lastspikemike gregc Lastspikemike I'm not advocating replacement of DCC. I point out that it is in fact a very primitive software system not readily accessible to current computer users with very little interest in "coding". curious what type of modern software system you might be suggesting? (is your background in software) DCC users don't need to know how to code, they need to understand configuration options described in CVs. and DCC only describes the electrical signals on the track, not the user interface which you may be referring to My background is definitely not in computing, that would be my brother with his PhD in artificial intelligence. I am completely self taught, I know my way around a motherboard enough to have "upgrade" them. I can install software most times. I know a little bit about networks but much of that is from the days when you had to do all the network programming yourself. Now it's pretty much plug and play even for network stuff. I repeat, I am not advocating abandoning DCC. I point out that it is VERY primitive and not at all plug and play user friendly. It should be but it isn't. The description of how it works is useful for me. It brings to mind my Spectrum DCC Santa Fe which wil only run in one direction when powered by the MRC Tech 6 used in DC mode.The reversing switch has no effect. It works correctly in DCC ("dual") mode and when run in DC only with MRC Tech 7 which is very interesting to me.
gregc Lastspikemike I'm not advocating replacement of DCC. I point out that it is in fact a very primitive software system not readily accessible to current computer users with very little interest in "coding". curious what type of modern software system you might be suggesting? (is your background in software) DCC users don't need to know how to code, they need to understand configuration options described in CVs. and DCC only describes the electrical signals on the track, not the user interface which you may be referring to
Lastspikemike I'm not advocating replacement of DCC. I point out that it is in fact a very primitive software system not readily accessible to current computer users with very little interest in "coding".
My background is definitely not in computing, that would be my brother with his PhD in artificial intelligence.
I am completely self taught, I know my way around a motherboard enough to have "upgrade" them. I can install software most times. I know a little bit about networks but much of that is from the days when you had to do all the network programming yourself. Now it's pretty much plug and play even for network stuff.
I repeat, I am not advocating abandoning DCC. I point out that it is VERY primitive and not at all plug and play user friendly. It should be but it isn't.
The description of how it works is useful for me. It brings to mind my Spectrum DCC Santa Fe which wil only run in one direction when powered by the MRC Tech 6 used in DC mode.The reversing switch has no effect. It works correctly in DCC ("dual") mode and when run in DC only with MRC Tech 7 which is very interesting to me.
I'd possibly take that up with MRC, no idea why that should be, the decoder appears fine, working on DC if it works with the Tech 7. Possibly a difference in the way the two systems do their pulse output in DC. Not a DCC issue.
I've found DCC to be pretty much plug and play - not sure what you see that makes it not. I bought my original system, then I added a walkaround throttle which also added support for more functions, and all I did was plug it in. No configuration, no setup. OK, I soldered my track feeders - but I did that for DC layouts before DCC was available too. I've run locos with decoders from all sorts of manufacturers, they all just work.
Installation of decoders can vary, but there are plenty of locos where it is as simple as plugging it in. Using a different control method such as direct radio to a board in the loco isn't going to change that installation issue for older locos. You have to do the same sort of work to install a DCC decoder as you do a WiFiTrax board as a Railpro board. Sometimes more - the direct radio boards are almost universally larger than a DCC decoder, simply because they need everythign the DCC decoder has PLUS a radio module. That may change and they will make the radios smaller, but the antenna trace on the PCB needs to be a specific length to work, so it's not going to get that much smaller. ANd the same improvements that make the radio boards smaller will also make DCC decoders smaller, so the direct radio system will always be at a disadvantage where space matters. There's already been major improvements over the years - the first sound decoders were more suitable for S scale than HO and N, and were ONLY sound - the motor control had to come from a second decoder. Now N scale has sound and motor combined decoders, and there are ones barely larger than a dime.
I'm not sure what you see that is so primitive about DCC. If DCC is primitive, then DC must be prehistoric. DCC is a very robust system that works from small switching layouts to things the size of small aircraft hangers. It's also quite reliable. Not once piece of my equipment has failed in nearly 20 years of use, nor have I EVER blown a decoder in the time since I got my first system.
How else do you propose activating functions? Seems pretty user friendly to me that the button with the light bulb symbol turns the lights on and off, the one with the picture of the bell makes the bell ring, and the one with the whistle on is sounds the whistle. Turn the knob clockwise, the loco goes faster, turn it counter-clockwise, it slows down, just like most every DC throttle. Sliding my finger up and down a touch screen has zero appeal to me. But if you like that, it works with DCC. Yes, that primitive system can easily use a modern smartphone for a controller, if that floats your boat.
LastspikemikeThe one example that came to mind was changing cv29.
what about it? what's so primitive? what are the shortcoming?
Lastspikemike,CV29 programming is a simple as can be. They made a chart; it's in every manual. Don't worry about what bit equals what value, just follow the chart. And even then, you're only going to be using two values in the vast majority of locos.CV29 controls 2 or 4 digit addresses, Normal Direction of Travel (NDOT), Speed Steps/Speed Table, and Analog/Digital mode.99 times out of 100, you're going to use one value for CV29 and one value only. For me, that value is 34. That means a 4-digit address, NDOT = Forward, 128 Speed Steps, and Digital-only mode. CV29=34 is such a basic number to know that at my club we have signs on the programming track telling people to use it.
The only real exceptions at my club are for locos set up to run long hood forward instead of the standard short hood. In that case, add 1 to the CV29 value and make it 35. Now the engine will run in the other direction compared to what it did from the factory.
Only a handfull of the 2000 engines at our club use a speedtable and only by our DCC experts who like to play around with it. Two digit DCC addresses are reserved for club use only, so the two digit number values for CV29 are never used by members. And it is highly recommended that all DCC decoders used at the club have analog mode turned off (DCC-only) because analog mode can lead to runaways with a short circuit.Out of the 2000 engines on the roster, probably less than 20 of them use a CV29 value that isn't 34 or 35. That's how rare it is to use any other value for CV29.
You don't even need a chart. All the popular DCC systems take care of it automatically, based on how you answer a question or two on the display.
There are other CVs used in a similar manner. From an engineering point of view - why would you use a full 8 bits to represent ONE item being turned on or off? One CV can control 8 individual on/off options. Otherwise, you would use 64 bytes to represnet what can be contained in 1 byte. That's just good design, not primitive. Unless by primitive you mean conserving system resources. Who cares, my computer has 32GB RAM, no need to make the program small and efficient. That seems the attitude of most modern programmers, and frankly, I hate it. I'm no fan of the super expert who rolls a whole routine into one line which is unreadable, either. Big and bloated just because it's there - just no.
In addition to easily setting bitmapped CVs like CV29 right in the system, there's walways JMRI. Now you have a whole screen of check boxes with full explanations to set CV29 (and pretty much every other CV in a decoder). All settings clearly defined and explained, and the displays change based on the specific decoder you are working with, so you only see options for features supported in the specific decoder. Definitely not primitive.
LastspikemikeDCC is new to me and puzzling even though modern computing is no mystery.
do you realize that DCC is a communication protocol across the tracks. not a human interface provided by the command station vender such as NCE or DigiTrax
Alton Junction
"You keep using that word. I do not think it means what you think it means."
Disclaimer: This post may contain humor, sarcasm, and/or flatulence.
Michael Mornard
Bringing the North Woods to South Dakota!
LastspikemikeI repeat, I am not advocating abandoning DCC. I point out that it is VERY primitive and not at all plug and play user friendly. It should be but it isn't.
LastspikemikeDCC is new to me and puzzling even though modern computing is no mystery. I've been tinkering with hardware and software for 30 years now and my introduction to DCC has not been transparent, shall we say.
Mike,
With that being the case, why not spend more time studying and learning about DCC and less time drawing and stating erroreous conclusions about a technology you admittedly have limited experience with. We all have 2 ears and one mouth for a reason. This might be a good opportunity to take advantage of that truism in order to learn so that you can make a wise and informed decision should you choose a DCC system down the road at some point.
And feel free to ask questions along the way. Most folks here are more than happy to pass along their wealth of knowledge and experiences; as much as you have about your own.
Tom
https://tstage9.wixsite.com/nyc-modeling
Time...It marches on...without ever turning around to see if anyone is even keeping in step.
LastspikemikeI predict DCC will develop into a more effective and user friendly TCS
OK, Mike, I'm going to ask this, and I'm not looking to argue or say you're wrong. I'm genuinely interested in how you consider DCC to be less effective or not user friendly.
I just started a railroad two years ago when I retired. I know nothing about computers, computer languages, or much of anything else, for that matter.
I bought an NCE DCC system. I learned to run trains in 30 seconds. I learned to adjust various commands to the locomotives in about five minutes. It took me ten minutes to adjust the speeds of two different locomotives with two different decoders so the locomotives travel in a consist at the exact same speed. It took me 30 seconds to set up the consist.
I guess that's why I'm wondering what you would do to improve the system.
As with everything else, one day I may look back at what I'm doing now and wonder how I ever used something so primitive. I guess I just don't see it right now. I'm not much of a visionary.
Lastspikemike I predict DCC will develop into a more effective and user friendly TCS in the not too distant future unless the current generation of new entrants dries up.
I predict DCC will develop into a more effective and user friendly TCS in the not too distant future unless the current generation of new entrants dries up.
You need to look at that the European DCC manufacturers are doing.
TCS is a private company that makes decoders and is working on their own command station. So you can't use a tradmarked name to describe your advanced train control system, it's already taken.
LastspikemikeI predict DCC will develop into a more effective and user friendly TCS in the not too distant future unless the current generation of new entrants dries up.
as i said, Digital Command Control is a protocol across the rails that modulates power polarity. it doesn't define the user interface. venders like NCE, Digitrax provide a command station that provides power to the track and impose communication on the power to communicate with DCC compatible decoders
venders also provide control units users use, the "user interface", that communicates using a proprietary bus (e.g. NCE cabbus, Digitrax loconet) with the command station. Jmri can also be used as an intermediary between a wifi controller such as on an android phone or i believe TCS and various command stations.
jmri decoder Pro can be used to configure a decoder (e.g. CVs), presumably more "user friendly"
you might prefer BlueRail which uses wireless tech to communicate with the loco and a graphical user interface on their controller.
consider that your phone, that you replace every few years, provides a "user interface" and uses 3g, 4g, 5g to communicate with nearby tower but communication with the endpoint is thru various older communication tech (sonet fiber, undersea cable, satellite, ...)
I hope that lastspikemike is just playing with us. Otherwise, I am worried.
Rich
While I'm not a user of DCC on my own layout, I have run trains on friends' layouts using it, and have done a DCC installation for one of those friends.
Lastspikemike...A brief look at the current state of dead rail (could you invent a worse name for exciting new technology?). Looks like the main limitation at the moment (or at least in 2019) is the circuit board size in order to get the wireless onboard, which frankly surprises me a lot....
I'm currently installing "dead rail" technology in a Bachmann tender for another friend (a die-hard user of DC, even moreso than myself) and it looks like everything will fit just fine, including stuff to allow re-charging the battery without disassembling anything.He's simply interested in seeing how it works. The controller is wireless and appears to be similar to the DCC stuff that other friends use.
Wayne
York1 one day I may look back at what I'm doing now and wonder how I ever used something so primitive. I guess I just don't see it right now. I'm not much of a visionary.
Part of what he's saying is that the modulation and data rate from the early Nineties, and a reliance on a registry-style list of assigned bit values, is old-fashioned whether or not it's familiar or 'as easy to learn as programming the IBM System/36' or knowing how to dial long distance.
The modulation on track power is already something of an artifact, as is the idea that switching power rail-to-rail with a square wave is an easy technical solution for a combination of high data rate and low effective bit error rate. Thing is, as with early SCADA there are advantages to that powerline approach that don't require enormous bandwidth, and if you're synthesizing the electricity to the different hard-wired functions, your power and power line modulation can well stay 'primitive'.
In any case that stuff is down in the physical layer; it's like the old Unix International joke that if your users ever saw a command-line prompt you'd failed utterly as a systems designer.
There is the hardware, and then there is the HMI, and running on top of that is the UI, and over time there is the IxD. Note that not only is this radically different from the OSI telecommunication model, in many cases you can't translate from one to the other effectively.
Of course, the moment you use a knob to adjust locomotive speed, you're unprototypical wherever the PWM and waveform modulation to control a motor speed is performed. As noted in recent posts, there are people who like it that way ... and they can 'get it from Walthers'. Meanwhile a company like ESU tinkers with defaults so that engines run more like the prototype, and there are people who prefer that, too. The interesting question that is only peripherally being asked is just how much UI and IxD design needs to be accommodated in the DCC modulation restriction... I would argue that it's 'good enough' to be retained, and that any future more sophisticated system -- we're sure to see them for 'dead rail' and wireless communication -- have at least a compatibility mode to work with DCC standards.
Now of course it also ought to work with the various proprietary end-runs and imperfectly realized alternatives that, ahem, certain manufacturers try. A combination of ESR-style 'bazaar programming' and a Linux-style approach would easily get you to open-source interworkability where that is technically possible. The problem lies slightly but significantly elsewhere.
Does anyone remember the word-processing program LeBlond Software published in the '80s that ran inside Lotus 1-2-3 v.2.01? That was perhaps the greatest 'road not taken' of anything in my experience: it had a very long emulation menu of then-popular word-processing programs and would work just like the chosen program once that simple choice was made. You won't be surprised that this has disappeared almost without a trace, but it's still a high-water mark of user convenience of an important kind -- a highly relevant kind in the current discussion here. Many people want to keep what they know, and in some cases that does mean a great deal of technical sophistication goes into the equivalent of thrashing or nonoptimized emulation.
The key, though, is to let even the hidebound get help, and if necessary consulted advice, without necessarily knowing all the timing conventions and pulse offsets in the legacy standard... for that you need special care not always as implicit in 'standards-making' as I thought it ought to be.
I wish I knew what you are talking about.
I do know this: I turn on the power, push a button, and my Kato BNSF locomotive moves.
York1I do know this: I turn on the power, push a button, and my Kato BNSF locomotive moves.
Lastspikemike http://cs.trains.com/mrr/f/88/t/275672.aspx http://cs.trains.com/mrr/f/88/t/275672.aspx
http://cs.trains.com/mrr/f/88/t/275672.aspx