https://tstage9.wixsite.com/nyc-modeling
Time...It marches on...without ever turning around to see if anyone is even keeping in step.
ULTRACREPIDARIANISM: Expressing opinions outside of your knowledge.
Disclaimer: This post may contain humor, sarcasm, and/or flatulence.
Michael Mornard
Bringing the North Woods to South Dakota!
Are you really that hung up on terms? No, you aren't "programming" the decoder in terms of writing a computer program. Neither is the DCC system, the decoder comes pre-programmed with firmware to respond to the DCC protocol, along with various user-controlled variables to adjust the behavior - hence why they are called Configuration Variables.
As for your responses to the idea the DCC is just a protocol - I don;t undersstand what you are missing. DCC only specifies the packet format for the data transmission and the waveform used on the rail signal. When you get down to it, that's ALL it specifies. It does not specify how the user interface devices connect to the command station to tel lit what data to send, it does not specify anything about what the user interface devices look like. You've got everything from a handheld miniature lcomotive control stand (Proto Throttle) to touch screen smartphones to simple LCD display screen devices with knobs to very simple devices that just have a knob and some buttons, no screen whatsoever. Or even a full blown computer - running Windows, Mac OSX, or Linux. They connect via numerous wired formats, proprietary radio formats, and WiFi.
The NMRA controls and defines none of that. They only care about what comes out of the track connections, and how the decoder in the loco responds.
You still haven't explained 'primitive'. At the same time you praise truly primitive locos that didn't need instruction manuals (because they just basically had wires from the track pickups to the motor and no other features), you condem a modern loco as 'primitive' because it requires an instruction manual to exolain all those advanced features.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
A kitchen stove is extremely primitive technology if you spend under $500.Yet nobody complains.
richhotrain York1 I wish I knew what you are talking about. No you don't, and you don't want to. It is a whole lot more fun just "running trains", and not worrying about what makes them run. I just don't know why some guys just want to try to make model railroading tantamount to building a super computer. Rich
York1
I wish I knew what you are talking about.
No you don't, and you don't want to. It is a whole lot more fun just "running trains", and not worrying about what makes them run. I just don't know why some guys just want to try to make model railroading tantamount to building a super computer.
Rich
York1 I wish I knew what you are talking about.
Alton Junction
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
York1I do know this: I turn on the power, push a button, and my Kato BNSF locomotive moves.
I do know this: I turn on the power, push a button, and my Kato BNSF locomotive moves.
York1 John
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.
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
I hope that lastspikemike is just playing with us. Otherwise, I am worried.
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, ...)
greg - Philadelphia & Reading / Reading
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
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.
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
"You keep using that word. I do not think it means what you think it means."
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'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".
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
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.
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.
LastspikemikeThe one example that came to mind was changing cv29.
what about it? what's so primitive? what are the shortcoming?
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
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.
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.
rrinker I think that's what I said -
Both your comments stand, despite any discussions with different 'interpretations'.
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?
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'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.
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.
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.
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.
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.
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.