Hi I got the following e-mail on the NDCC groupo on yahoo. "[ndcc] NMRA convention NMRAnet Show and Tell Hi all- DCC has a limited capacity and it has difficulties with large numbers of accessories attached. One way around this is to have a dedicated second DCC for accessories only, and use the first for loco control only. The other problem is feedback from accessories on the DCC. The NMRA has had a working group to develop a local control bus (LCB) that would supplement DCC, or for that matter DCC, train control with a parallel system designed for two-way communication with accessories. There are several commercial LCBs, but they are proprietary and incompatible. The NMRA wanted to develop a standard which would do for accessory control what DCC did for train control: ensure compatibility between manufacturers. The discussions over the last 4-5 years have spun of a series of efforts. These all include some features that were agreed to be useful: use of the Producer/Consumer Model and the use of the CAN bus standard. The first of the spin-off LCBs was CBUS, designed by Mike Bolton and Gil Fuchs for UK MERG. A second LCB was spun of CBUS and is called At-bus, designed by Roger Edwards, again in the UK. The NMRA working group split into two groups which developed two proposals. S9.5 was designed by Don Voss, while S9.6/OpenLCB was developed by Alex Shepherd, Bob Jacobsen, Alan Robinson, and myself. Didrik Voss has organized a 'show and tell' at the NMRA convention in Rm 103 on Thursday next week. Materials for all four of the above systems will be presented. I would like to invite you to come and see, and to discuss these different proposals for a NMRAnet. David .... (dpharris@telus.net)" And after reading this, I was amazed. So it appears that they did not do a very good job implementing DCC. This is evident since you can not reall use most devices other than decoders between manufacturers without a loss of functionality. Furthermore that admit they are not sure how to handle it just yet but they are looking for a solution. So I thought we could also discuss this here and see what we think, and possibly come up with a way to help out the NMRA. Sorry if my Defense Systems references are not understood, but this is where I draw my experience from. Next, my examples are based on Digitrax because that is the system I know the best and use daily. First - We can not really call it Digital Command and Control technically, because there is no feedback from the system to acknowledge that a packet was successuly delivered to the destination. What DCC is, is more of a targeting system for Fire and Forget munitions. Lock on the target (similar to prepare the packet) and fire (the transmission of the packet). Once the munition is away, there is no more contact with it. DCC is slightly different because it continually re-broadcasts packets but it still never listens for an acknowledgement from the destination. For true Command and Control, there needs to be continous bidirectional communications with both sides sending acknowlegements of successful delivery and decoding of the packets. For a model train example, this means the controller sends out a packet to the decoder at a specified address. The decoder then receives the packet and decodes it. The first acknowledgement is sent. Once the decoder proceeses and executes the command in the packet, it would then need to send another packet back to the controller confirming that the packet was properly executed, or not. None of this currently happens with DCC. The NMRA stopped at implementing a packet signature and behavior and the beginning constructs of a protocol but never finished the job from the outset. This meant that the companys could do whatever they wanted as far as the actual connections, meaning the wires etc. So Digitrax developed Loconet, Lenz has thiers, NCE has thiers and ESU has theirs too. The problem with the intial incomplete spec is that it was not thorough enough to insue the compatibility of devices beyond the mobile decoders. Sure you can intermix brands to some extent, but in doing so you will lose functionality. There were no systems integration analyses or specifications to keep this from happening. A case in point, the Digitrax DS64 can be operated by track power, thus it will work with any other DCC system. What you lose the the Loconet capability and its messaging capability to other devices to remove this traffic from the track signals. Second - Now is the time to look at DCC and see if it can be fixed, or it needed to be started over again. In any event, the long and the short of it is that if a new specifications comes out, all of the devices from that point on will be different from what we have now and may not work well toghether. So now is the time to look at these issues, and other and start working with the NMRA to fix what is broken and enhance what is correct. I think I have already voiced my issues above. And I will say that even a half a specification is better than no specification at all. I really enjoy running my trains on DCC over DC, but the engineer in me sees ways of making it so much better. But if they are beginning to see the problem they talk of, it may just be time to fix a lot of things. What else within DCC should the NMRA address to fix problem or issues that affect you? Or What is within DCC that is just fine the way it is? Again, I am hoping for a good discussion here. Moderators, if you feel this is inappropriate, plese feel free to remove.
For 99.9% of us out there, the current DCC standard works just fine. I am running model trains, not targeting an incoming ICBM. Loconet is fine just the way it is.
Well, we talked about this a couple weeks ago buried in a couple different threads. I agree, the original DCC is horribly designed from a Telecommunications standard. I disagree in that I don't think the system needs to be fully bidirectional. I've been advocating an Ethernet/Wifi based standard that would use a version of UDP/IP. Sadly I don't the resources opr desire to go much beyond standing on my soap box.
If this all means that my ten year old Digitrax throttle would still work with a future offering, go for it. Personally, I think they stopped short because the technology wasn't economically feasible at the time and to allow proprietary control bus to protect profits. I'd rather see a company making money and able to continue in business so I can get new stuff.
It is not anything about missiles, it is just about the need to send the same information out over and over again. This creates the traffic bottleneck that can start to impair the operations of the layout.
Hi, If you want to know more about cbus, which isn't just for DCC here is the link to MERG's page on the matter MERG Resources - CBUS Stephen Freeman
too little, too late Unfortunately, I think this has been the stand of the NMRA since DCC was adopted, back in the days when a hardware company still hand soldered resistors, software was considered a dirty word and large layouts with early controls were built by electricians, engineers and electrical savants. Something, something old dog and new tricks. Standards were only adopted after someone handed over the original protocols to the NMRA, who didn't seem to understand the computer and wireless revolution in the 90's. DC and DCC have watched the new fangled pc fad and never blinked, they weren't interested in changing a wheel that worked, they didn't want to read email, run trains remotely, have prototypical layouts or operations if it meant change. Well, I want to target my trains, have them report for duty and have the layout and dispatch know exactly where it is 99% of the time and not have to spend an additional $3k to do it. Simulate prototypical trains and that means having a layout and traffic that I do not control and interacts. My DCC, loconet, Digitrax is a computer that thinks it's a light switch, and is still hand wired like two soup cans and a string. God forbid we all would use the device that 99% of current and new modelers have before building a DCC layout, as an essential component. DCC should be reduced, if fixed at all, to a single signal broadcasting and receiving unit that has expansion slots PCI or USB depending on the layout complexity, and a pc control unit, keep operations in software, human or pc. Your throttle would still work it would just have to give the command to a central dispatch that listens, and relay to the loconet. All decoders, train or stationary accessory should pull power and commands off the command bus, like trains do now. Also you would be able to run dc trains on dcc layout because the management program could easily switch between the two live, as a auto reverser does with polarity. Everything should be bi-directional (but it'll be a cold day in hell before the current system is obsoleted). This is where I think NMRA missed the target again by mandating that they will have no central control. There should be no difference between a light, train, signal, sound or animation they are all just an address with simple command lines and analog mechanics. How many out there not using Windows, Leopard or Linux? All of which have Windows emulators. At a minimum there are already open source control codes out like JMRI. To a centralized software control then there is no difference between a Lenz, Digitrax, NCE or whatever it's just additional code, you know like pc hardware. The good news is they are finally going to adopt USB, WiFi, etc not that they will be easily adopted. I would venture a guess that the biggest deterrent to the hobby is wiring, hardware configuration, and command programming all of which would be greatly reduced by the use of centralized user friendly control by windows/java apps. Most importantly our industry should be open to tech improvements and reduced mfg costs by pinning to an industry that already has reached agreements on standardization. Who needs a phone when I can just ring this bell.
Well, there's a lot of 20:20 hindsight up there. I'm sure if Microsoft had known 20 years ago what they know now Windows 7 would be something rather different ... like Windows 1 And on that matter why does every one seem to think that 99% of modellers have a computer AND that they will be happy to use it to run their trains. We have 4 PCs in the house, none of them for trains and none of them going to be for trains. I'm not waiting several minutes for a PC to boot so I can shuffle some cars! And since I can buy a complete plug and play DCC system for the cost of a PC or laptop (never mind loading software and interface cards) why on earth would I want to use a PC anyway. I've no problem with those that want every turnout, light and animated scene on the layout to report it's current status, but on a 2' x 10' like mine I can actually see them with the naked eye faster than that Sorry, I'll get down now :embarassed:
You're right, Mike. Not everyone wants to run a real fancy system with computers and signals and CTC but some do. For the ones who do, DCC can have some limitations. It would be nice to replicate prototypical operation and not be hindered by the lack of standards or by poor standards. Everyone looks at model railroading differently. What works for one might not work for another.
Things I would like to see in any change to the DCC specifications: Maintain compatibility with existing decoders. The new standard should be capable of recognizing a legacy decoder and treating it appropriately. This allows any new equipment to be phased in and prevents resistance by those who have a lot of existing equipment. Add bi-directional communications capability to both locomotive and accessory decoders. The decoder should acknowledge receipt of a command and be capable of reporting its current operating status (e.g.; speed, direction, active functions, switch position) if the command station sends a status inquiry. I believe Lenz already has this with their “RailCom” capable decoders but it currently requires their control station and their gold series decoders. The specification should not restrict how the specification is implemented. It should not require or prevent the use of a PC. It should allow manufacturers to enhance their equipment by adding new features.
True, but since we are talking about DCC instead, I don't see why the requirements laid out by markwr can't be implemented. For one thing, backward compatibility is going to be a must or we are going to end up with people implementing multiple standards. One way or another, bi-directional communications are coming. The required protocols just have to be agreed on. Using a PC is possible now but you don't have to if you don't want to.
Keep in mind that the proposed “NMRAnet” S-9-5 and S-9-5-1 standards are for the Local Control Bus ONLY. They do not supplant the existing DCC standards and RPs at the railhead. LocoNet and Expressnet are examples of existing (proprietary) LCBs that would compete with the proposed standards. Current DCC standards and RPs (S9.x and RP 9.x) serve their purpose well, defining the electrical interfaces and protocols necessary for interoperability between the various DCC systems and layout operational elements (i.e., decoder controlled devices, mobile or stationary). These specs (which were originally developed by Lenz) recognized that positive acknowledgement of all messages or actions at the track level was neither necessary or desirable, given the system and bandwidth tradeoffs required to provide for the return channel. The need for the command station to provide both power and data makes the implementation a return channel problematical, and the burden of all the ACKs and NAKs (including guard times) could easily exceed the bandwidth consumed by the minimal retransmissions used in sending commands to mobile decoders (commands to stationary decoders are sent only once). There are some two-way track level schemes in use or proposed (including Digitrax Transponding, Lenz RailCom and NMRA RP 9.3.1). All require for the booster to go silent for a short interval to allow the decoders to transmit. In the case of RailCom and RP9.3.1 at least, this impacts the command station and requires additional circuitry in the booster or as an external add-on. Returning to the command bus issue however, both LocoNet and ExpressNet command busses already have (and always have had) two way capability, and use response messages where warranted. I can’t comment on other manufacturer’s systems, but by providing feedback via LocoNet, Digitrax supports full two-way communications with most stationary devices (DS64, SE8C, BDL168, PM42, etc. ), i.e., all but mobile decoders. The proposed “NMRAnet” would adapt the already established CAN bus technology used in the automotive industry to implement a higher capacity, more flexible and standards based command bus. While those of us that are engineers may salivate over the possibilities (MORE BITS!!) , our accounting and marketing friends may not necessarily share the excitement.
But the thing is - all those things can be done .. I have seen layouts that use DCC only for the control of the train. Everything else is done like signals and switches is done with C/MRI or some other interface. Unless you are building a HUGE layout like some of the NTRAK meet ups, then I think the current DCC versions are more than adequate ..
What we really need is a bus translator - one that allows me to plug my DIGITRAX throttle into an NCE or LENZ bus, or allows me to attach a Digi/Lenz/NCE wireless receiver into the local bus and translate to whatever host system there is. It would be great if my friend who has an NCE handset could come over, and operate on my layout with his throttle ..
Absolutely, those things can be done. However, C/MRI, etc are proprietary. There was digital control of locomotives before the DCC standards but they were all proprietary. It wasn't till manufacturers started producing "NMRA DCC" compatible equipment that everything took off. Competition drove down costs and forced manufacturers to start including decoders in new locomotives. Once the networking specifications are published and we start seeing software and hardware built to those standards, I think we will see another jump in the implementation of that technology. However, like you said, current DCC implementations are adequate for most people. A lot of people can do everything they want with the current systems.
All Amish Railroads Hindsight, is that when you see a horse and buggy from the rear? Why buy a DCC system when you could add one usb connection and two wires to your pc, in another room, and run your train the same as ever? Guess what, MS Word worked with win1, win7 and every version in between all with legacy. I can still read a movie review of "1984" on this pc. You'll boot up a pc to write a forum response but not run trains?:eyeroll: Not a pc for trains but a pc that also runs trains. I remember in 1978 everyone said DC was just fine, and by plug and play DCC you mean a 24" oval, no switch machines, no lights, no signals, no power management, no auto reverse loops, no routes, no memory, in other words no prototype. The electronics of a DCC system date back to 1985, let's see that makes [FONT="]35[/FONT] 25 years of ignoring pc hardware standards, plug-n-play since 1992, WiFi, USB... there is almost no software from all those years that can't be run on a modern pc with a applet. Most importantly is where the NMRA should push the future of train control, your "fine" system will work as long as the electronics last, about 5 years if you're lucky. I'm just going to keep this soap box if you don't mind. thad
As I've said before, they need to move to a wireless spec. Preferably WiFi which would provide more bandwidth than any loco could need and use wired Ethernet on the layout for other devices. This would offer consumer grade equipment that is relatively simple to install and use and is computer friendly from the beginning without absolutely requiring one. wiFi nics are now about the size of a double length SD flash card. So they will fit in locos.
Sorry thad, but I disagree with almost everything you said. It's almost embarrassing Hmm. And where does the 5 Amps or more of 14V power come from? And the handheld controllers? And when the PC is being used for something else I can't run trains. I know there is a lot of talk about the interconnected digital world, but there used to be talk about the paperless office. A typical prototype for many people is a branch or shortline, maybe even narrow gauge - no switch machines, no lights, no signals, no routes ... and auto-reverse still needs short-circuit detection and polarity swapping hardware - a PC can't do that without additional cards. I wish I lived on your side of the pond. I've got loads of software on CD and floppies that won't even run on 32-bit XP, never mind 64-bit W7. (And I've got the grief from the rest of the family because of that ) My Powerhouse Pro is 7 or 8 y.o. already (I changed the memory battery a couple of years ago) and still going strong. It has no spinny bits (fans, HDD) like a PC and I expect it'll do another 5-10 years.
