Funny just to funny. Hahahawhawhaw and still LOL'ing AC on the tracks. You can spell it out anyway you want, it's still AC...on the tracks. There are two simple tests to prove it is A.C. One can be done with a Radio Shack voltage meter and the other with your analog DC locomotives. If the locomotive hums, the voltage on the track is AC. The hum is simply the motor being jerked back and forth at a high rate of speed. DCC may (and I don't know) send out computer language to the decoder through another means but that doesn't change the fact it is AC on the tracks. Perhaps over simplified here but that is what it is and it is what it is.
It most certainly does. Taken from your own quoted definition of AC(emphasis mine): "The usual time-dependence of an AC circuit is a sine wave. In certain applications, however, different waveforms might be used, such as triangular or square waves." DCC is square wave AC. I still have not seen anything to disqualify it from being so. It alternates direction cyclically, making it AC. It is a square wave, but that does not disqualify it from being AC. It also has a varying frequency, but that also does not disqualify it from being AC(try googling variable frequency AC drive, or check out the many references to an audio signal, which of course has a varying frequency, as being AC). I have never seen a single compelling argument as to why DCC is not AC, all I have seen is "it's different from household AC or 'traditional' AC", but nobody here has said otherwise.
The problem with this suggestion is considering that the original poster has spent 8 pages arguing that DCC is not AC, I doubt that he would have corrected his post after receiving a private message informing him that it is AC.
Decoder block diagram This discussion pops up on different forums every so often. Below is a block diagram of a typical decoder, just no sound chips shown. The bridge rectifies the DCC to produce the operating DC voltage and the DCC signal is picked off before the bridge and sent to the logic chips. With dual mode decoders, the micro-processor looks for DC or DCC voltage to run the loco. The photo comes from a site about using Stay Alive for decoders aand dirty track or not so good pickups. Rich
I see the problem with this thread. The OP is using the NMRA as the basic definition. God bless those guys, but they, as a group don't know anything about anything. If you want a definition on track spacing and flanges and stuff, ask the NMRA. If you want a definition of electrical signaling, you ask someone who knows about that stuff and that isn't the graybeards at the NMRA. With apologies to any members, I'm somewhat surprised they had the ability to Pick Lenz much less describe it in a meaningful way.
I spoke to a NMRA rep two months ago. There are two paid employees but this stuff was written some years ago. I have befitted a lot because of the NMRA. I cannot knock the group but they do provide fodder for Ranters I see every so often in different forums. Maybe some of the writers at the time were lawyers. Who knows? Rich
It's not a knock against the NMRA per se, but complex electronics are complex electronics and writing meaningful information about it is a skill unto itself.
Just suggesting...this might of worked...causing the OP less embarrassment. Humm, me thinks I don't want to argue a case against Robert. I've argued for the plaintiff or defendant in employee hearings but never outside of that realm. I'm no lawyer. We can quite often talk ourselves into a corner and discover there is no way out. Tough spot for sure. I would advise against doing such.
With all due respect, (and not meaning to offend, but I feel an additional perspective would be useful.......) Certainly most of the greybeards at NMRA aren't electronics types.... but some of them actually *are* wizards at electronics. NMRA has been fortunate to have members who have contributed hugely to our hobby over time, who have been electronics wizards: Paul Mallery, John Armstrong, Pliny Holt.... among those still with us and vibrant as ever include Bruce Chubb, Jim Scorse, Dick Bronson, and many more. There are many unsung heroes who in the past 20 years, as model railroaders first, (who volunteered to work on the NMRA DCC Working Group) who have put in countless hours working on DCC standards back when there were no worldwide standards for American profile model railroading. They played an important role in all of us enjoying the worldwide model RR DCC that we enjoy today. They didn't do it because they wanted to pump up NMRA. They did it because they rightly felt that progress had to be made in setting standards for DCC in in the American model railroading. They did pick a very good technology (and Bernhard Lenz is to be so commended for lending his technology for the express purpose of promoting a standard... he didn't have to do it that way but he did because it was a win-win for all). This work is still continuing. I am not saying they are perfect.. of course they aren't, no technology advance these days can be predicted precisely. But... have you heard of NMRANet? Have a look at what the electronics volunteers at NMRA are currently working on : NMRA - DCC Working Group Discussion Topics http://nmranet.sourceforge.net/ Of course, NMRANet isn't perfect either. But it is pushing progress in the correct direction. There are geek-wizards in Silicon Valley where I live, and elsewhere, that are working (for free) on providing a better way for the future of model railroading. There is some serious engineering in this DCC working group - no lightweights there. And this group works in concert with non-NMRA but beneficial to us all developments like JMRI and Decoder Pro. The fact that you can take a decoder from any good DCC manufacturer, put it on any good DCC system, and it will run superbly.... and this is true worldwide on planet Earth... is a testimony to what has happened. NMRA isn't the 'cause' nor the 'master'... but they do play an important role in the overall wheel of progress of DCC. Just my 2 cents worth. I wonder why I got so persnickety and felt the urge to write this post. Maybe it's the coffee Just trying to help, not trying to offend, just offering an additional perspective that may be understandably harder to see. Have a good evening, all, and enjoy our trains .
You know I was going to leave it! Then you JACK @SSES started in on NMRA. You UNGRATEFUL ....................................... It was ok belittling me because I was trying to point something out but to start on the guys that worked hard for us (NMRA) is something else. I told you that it is the intent! Intent of the developer or inventor. They dictates the pretext and context of their development. Not your nor my interpretation. Signaling techniques for DC track powered model railroads Patent 5448142 Claims We claim: 1. A model train locomotive for use on a model railroad track that is coupled to a power supply for controllably applying a polarity-reversible DC track power signal to the track, the locomotive comprising: a motor for driving the locomotive over the track; means for isolating the motor from the track so as to allow use of polarity-reversals on the track power signal for controlling remote effects; and means responsive to polarity-reversals on the DC track power signal for controlling remote effects without reversing the motor. 2. A model train locomotive according to claim 1 wherein the means for controlling remote effects includes: an on-board electronic state generator for indicating a present state that is one of a predetermined series of states, at least one of the states having a corresponding remote effect associated therewith; means coupled to the electronic state generator and responsive to a first remote control signal conveyed to the locomotive over the track for changing the present state of the state generator to a present state that corresponds to a desired remote effect, thereby selecting the desired remote effect; and means coupled to the electronic state generator and responsive to a second remote control signal conveyed to the locomotive over the track for operating the selected remote effect, whereby multiple remote effects are controllable through use of the first and second remote control signals. 3. A model train locomotive according to claim 2 wherein one of the first and second remote control signals includes a reversal in polarity of the DC power signal applied to the track (PR). 4. A model train locomotive according to claim 2 wherein one of the first and second remote control signals comprises two reversals in polarity of the DC power signal applied to the track, the two reversals occurring within a predetermined time interval so as to form a polarity reversal pulse (PRP). 5. A model train locomotive according to claim 2 wherein one of the first and second remote control signals includes an interruption in the DC track power signal having a duration greater than a predetermined minimum duration. 6. A model train locomotive according to claim 2 wherein one of the first and second remote control signals includes a track power signal having a voltage magnitude in excess of a predetermined level (HV). 7. A model train locomotive according to claim 2 wherein one of the first and second remote control signals includes a high voltage pulse (HVP) on the track power signal. 8. A model train locomotive according to claim 1 further comprising a motor reverse unit for driving the motor according to a selectable direction state, whereby the motor direction is controllable independently of the polarity of the DC power signal applied to the track. 9. A model train locomotive according to claim 8 wherein the motor reverse unit has a plurality of selectable direction states including forward, reverse and neutral direction states, and further includes means for changing the direction state in response to an interruption in the DC track power signal having a duration greater than a predetermined minimum duration. 10. In a DC powered model train locomotive having a motor, a method of using polarity reversals of the DC track power signal as a remote control signal, the method comprising the steps of: receiving the DC track power signal through the wheels of the locomotive; rectifying the DC track power signal so as to form a DC output signal having a predetermined polarity independent of the polarity of the DC track power signal; selecting a direction state that is one of a predetermined series of direction states including forward, reverse and neutral states; selecting a DC signal polarity for driving the motor in a motor direction corresponding to the selected direction state; and applying the DC output signal to the motor with the selected DC signal polarity, thereby driving the motor in the motor direction corresponding to the selected direction state notwithstanding a reversal in polarity of the DC track power signal. 11. A method according to claim 10 further comprising: detecting a polarity reversal of the DC track power signal; and controlling a remote effect in response to the detected polarity reversal. 12. A method according to claim 10 further comprising: selecting a desired remote effect; and operating the selected remote effect in response to a polarity reversal of the DC track power signal. 13. A method according to claim 10 further comprising: in response to an interruption in the DC track power signal having a duration greater than a predetermined minimum duration, resetting the on-board electronic state generator so as to select a .reset state as the present state. 14. A method according to claim 10 further comprising, in response to an interruption in the DC track power signal having a duration greater than a predetermined minimum duration, changing the selected direction state. 15. A method according to claim 10 further comprising changing the direction state in response to a polarity reversal of the DC track power signal. 16. In a DC powered model train locomotive having a motor, a method of using polarity reversals of the DC track power signal as a remote control signal, the method comprising the steps of: maintaining a selected one at a time of a series of On-Board State Generator (OBSG) states, at least one of the OBSG states having a corresponding remote effect associated therewith; changing the OBSG state by applying a first remote control signal to the locomotive; and repeating said changing step so as to select the OBSG state that has a desired remote effect associated therewith. 17. A method according to claim 16 wherein each of the OBSG states has a corresponding one of a series of direction states, the series including a forward state, a neutral state, a reverse state and a reset state; and further comprising: advancing the direction state to a next one of the series of direction states in response to an interruption in the DC track power signal having a duration longer than a predetermined minimum duration. 18. A method according to claim 16 wherein the first remote control signal includes a polarity reversal of the DC track power signal. 19. A method according to claim 16 wherein the first remote control signal includes a high-voltage pulse on the track power signal. 20. A method according to claim 16 further comprising operating the selected remote effect in response to a second remote control signal. 21. A method according to claim 20 wherein the second remote control signal includes a polarity reversal of the DC track power signal. 22. A method according to claim 20 wherein the second remote control signal includes a polarity reversal pulse on the DC track power signal. NOT ONE PLACE IN THE CLAIM DOES IT STATES ALTERNATING CURRENT! It is DC current that happens to alternate. SO now are you going after the Patent Examiner? NOW I AM DONE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Inobu
Keep it Civil Everybody take a deep breath. This thread is analogous to the one about whether or not flanges keep the train on the track. It's an engineering discussion you could have with an academic and not so important except to prevail with our own point of view. Lets drop the tone a notch.
Please watch your language, this is supposed to be a kid friendly forum. Maybe I missed it, but I don't remember anyone belittling you anywhere. Sorry, but that patent is not talking about DCC. It is refering to the QSI Quantum Engineer controller, which is NOT a DCC controller. QSI decoders will also respond to DCC, but when used with the Quantum Engineer, you are not using DCC. The Quantum Engineer uses occasional momentary reverse pulses to send signals to the decoder, not a continuously reversing stream of pulses like DCC. DC current that "happens to alternate" in a continuous and cyclical pattern IS AC.
inobu, at the top of page 8 you quoted the NMRA - Beginner's Glossary: DCC — Digital Command Control — the NMRA sponsored command control system .... An alternating current of constant voltage is placed on the track with a control signal of varying frequency impressed upon it. So even they have called it AC with a superimposed control signal. It's no different in principle to those powerline ethernet devices which transmit data between computers in the same house by superimposing the data signal onto the mains AC. It doesn't mean the mains AC in the house is suddenly not AC any more.
This is what I get for opening my big mouth. I apologize for besmirching the names of those who worked within the NMRA it was not my intent.(Well, it kinda was, but not to besmirch their technical skill) Still all that hard work didn't stop them from writing something poorly. I looked through the sourceforge working groups. It's interesting stuff to be sure and I was suitably intrigued, but I was also remarkably disappointed. They seem intent on working on a custom defined protocol and interfaces. I didn't see much beyond a few references to a change in Phy and certainly nothing about User interfaces which is where they should be focusing. Developing custom protocols that are tailor made to the task sounds great in theory, but is usually not the best in practice. I worked on Cable modems, some of you may remember the early proprietary modems from the mid 90s. Custom designed, tailored to the specific network and absolutely wasteful. Expensive and dumb. DOCSIS comes along. Standards based. Extensible, universal, based on Ethernet and BAM! not only is it successful, but it is the fundamental standard that informed WiMAX and LTE and it killed the IEEE Cable modem standard attempts. What's wrong with UDP/IP over existing phy guys? 48 bit unique addresses? How about MAC addresses based in the Ethernet stack on the ethernet chip in the decoder? The work has been done already. I agree there is an advantage to being cross medium. Something S9.6 proposes, but even there, the work has been done. Ethernet over powerline, WiFi, Wired Ethernet. Sure custom protocols could decrease overhead bandwidth, but in a private network such as what this would be, WiFi and ethernet bandwidth would be cheap. There is a perfectly good Phy and stack. I'd like to see them working with that as a baseline and then develop this as layer 5-7 protocol. They are trying to reinvent the wheel which will raise development costs and reduce future proofing. I need to put together a manifesto on what I would like to see. I probably wouldn't change anything, but man. I could care less about CAN and Producer/Receiver and all that crap. UDP/IP that bugger and give me an API. Wireless decoders, Done.
NMRA net is also not a replacement for DCC, but is for non Track control. IE, the throttle will be NMRA net which translates to DCC I notice that the initial instructions were to be independent of transport medium, but then the 9.5 working group got busy on CAN. At least 9.6 is working with all media, but again, I think it is a mistake. That's it, I'm writing this up.
Hello, Yoho, thanks for the comments, and no offense was taken. I'm far from an expert on NMRANet, so I can only report on what I hear as I sit across the table from the portion of the volunteers who happen to live and work in Silicon Valley where I live... who are working on this proposal (and please note, it is just that, a proposal, it is far from a standard yet)..... But thought this might be helpful as well, see below. ====> BTW, how does this relate to this "DCC Simplified" conversation? <===== The goal of the NMRANet proposal (and it is just that, a proposal), is to create an infrastructure component that in the end, will support other functions that result in a much more plug-and-play PNP level of signaling and function than we have today. Wouldn't it be nice in the future, to have plug-and-play signaling that you just plug into a NMRANet-derivative, and start having signaling that just automatically starts working at some level. And, it would play nicely with other manufacturer's PNP NMRANet equipment, and would interface to things like JMRI and PanelPro as well. Think of how cool and simplified that could be! Just like we can pick basically any DCC decoder we want, and run it successfully on just about any DCC system that we want. ----------------- If you are interested in reading further, continue on, otherwise, the above is a good summary of what I'm trying to offer. ----------------- So, some additional words that I hope will be helpful: The folks that are working on the NMRANet proposal are some of the same folks that have brought us JMRI and DecoderPro (which are a great benefit to all of us). By design, NMRANet is not a user interface layer component, it's meant to be an infrastructure component. By infrastructure component, I mean that you could think of three layers in any application stack: 1) Human user interfaces (which is what we see, i.e the final outcome or the original input that we as humans give the system) 2) Analytical processing and intelligence (the layer that is the smarts and logic, and takes input from the user interfaces, and sends output back to the user interfaces) 3) Infrastructure layer - the physical interconnects, servers, storage, and *network* that that provides a standards-based, common powerful foundation upon which multiple analytical components (measuring into the thousands or more) can connect, interact, and work in unison to produce a user-interface-desirable result NMRANet is a proposal for an infrastructure layer component. True, NMRANet it is never meant as a replacement for DCC. It's a supplementary functionality, so that things like signaling, block detection, etc. all have a proposal that may help these functions in the future. Part of the proposal discussion is what to leverage in terms of technologies.... i.e. would CAN (controller area network) be a good technology to use... as it is the beneficiary of worldwide development since it is a fundamental piece of automotive manufacturing research and development. The idea is to recognize that it was worldwide commodity cell phone technology development that basically drove the digital signal processing chips that make up our so affordable DCC decoder wonders that we buy for than $30 or less today.... technical wonders that they are... And therefore, a proposal that leverages a analogous worldwide commodity technology development curve on technologies like CAN may be useful for our model RR purposes as well. As the pace of development is continually amazing on what automobiles and other real time controllers do on a worldwide level successfully today. For example, worldwide today, every new car has multiple computers and a local area network that fundamentally works at amazing levels of reliability. People's lives are at stake to make an automobile's brakes/ignition etc working properly, and worldwide we have that today, for example: Controller area network - Wikipedia, the free encyclopedia And of course, these kinds of real-time networks are not just for automobiles. The NMRANet project itself has lots of internal discussions about CAN, both yeah and nay, .. but whether it ends up being CAN or not, the idea is to work together (volunteering) to push the envelope and create a foundational infrastructure component for this aspect of model railroading. We may remember the early days before the DCC standard came out...... how there were different incompatible command control systems....... and then, think about what things today in model railroading electronics are diverse and incompatible.... Foundational in the sense that it is an infrastructure component. Again, this idea of application stack, in three layers, may be useful to conceptualize where things are located in the stack: 1) Human user interfaces (which is what we see, i.e the final outcome or the original input that we as humans give the system) 2) Analytical processing and intelligence (the layer that is the smarts and logic, and takes input from the user interfaces, and sends output back to the user interfaces) 3) Infrastructure layer - the physical interconnects, servers, storage, and *network* that that provides a standards-based, common powerful foundation upon which multiple analytical components (measuring into the thousands or more) can connect, interact, and work in unison to produce a user-interface-desirable result NMRANet is a proposal for an infrastructure layer component. So the goal is to, in the end , to produce a infrastructure component that supplements the DCC control of locomotives and accessories, and makes possible a better future for all of us model railroaders. We and they don't pretend to know where it will all end... but the idea is that this will help propel all of us model railroaders toward where ever it does land. Hope this is helpful to all.
Oh, man. That horse died and was beaten to a bloody, unrecognizable pulp about nine pages ago. I'd suggest that we should start a new thread to talk about NMRANet, CAN, WiFi and so on ("The Future of DCC") but this thread has strayed so far from its original purpose we might as well just keep on riding it into the sunset. More (less?) seriously, the thread is finally turning to something interesting... an exploration of the efforts underway to improve DCC. I need to read up on the stuff that's ongoing (I'm just getting familiar with DCC in general), but I see a real definite need for *somebody* to focus on the usability and simplicity of installation (including cost) of the hardware. JMRI and DecoderPro and RocRail and so on are great tools, but they're still hamstrung (IMHO) by the stuff they rely on to talk to the locos. The track signaling itself is probably the least of the problems. It's the human interface that needs work.
Agreed. This thread, due to the divergent paths it has taken, I'm not sure the value that is clearly present in it, contributed by many, is visible to most readers.
As requested by those remaining sane thus far, I started a new thread with the last four posts. Click here for the link. I would like to hear more about the DCC future as I certainly know nothing about it. Others may remain on this thread.
