Let me tackle the manufacturer problem from another direction. Let's assume the world I want came to be, ethernet for the network, boosters to do network-to-rail conversion. Command station becomes software on a PC. Turnout, signal, and other controllers become standardized down to A/D D/A boards that get flashed with software to do the right action (control a turnout, light a signal, etc). Today, folks like Digitrax and NCE employ people who build "embedded systems". That is, folks who know how to program PIC chips to do all of this stuff. In my future, they need Apple and Microsoft software programmers to write command station programs. That's a very tough transition. I think this is also why the CAN bus is favored. CAN bus is extraordinarily similar to LocoNet. I don't know XpressNet, but I think it is also similar. Serial bus, similar speeds (maybe a smidge faster), PIC sort of interface would likely still be used. Now, why would Digitrax, Lenz, and others go for this? Well, their existing staff understands it, and integrating it into their existing products should be relatively easy. Yes, they loose some sticky by being compatible, but they also gain cheaper parts since CAN bus is well used in for instance automotive applications. More off the shelf, less in house designing going forward.
That's a pretty good explanation of the problem. It would be a shift in expertise and I'm sure none of the people who were involved in DCC, people who are experts in that type of industrial electronic design, have any interest in changing anything. I will comment again on Ethernet and sizing. the phrase "There would be too many ports" doesn't really work as a negative for ethernet. Loconet and Expressnet are going to be unable to support as many ports as Ethernet ELECTRICALLY, because of their daisychain bus. Also, again, no wiring required. Just buy pre-made cables.
OpenLCB - S9.6 - NMRAnet Hi All-- I guess I should reply, since this all started with a quoted message of mine. NMRAnet is a project to develop a local control bus (LCB) that is parallel to the DCC system. It is not specifically directed at DCC, but can be used with any motive control (DCC, DC, PWM). It is not meant to replace DCC, but supplement it by controlling accessories that include everything from turnouts, signals, semaphores, street lighting, turntable control, layout lighting etc. I am one of the developers of OpenLCB / S9.6, which is one of the proposals for NMRAnet. More info at OpenLCB.org As mentioned in that first post, we did show our stuff at the 2010 NMRA convention, see: OpenLCB at NMRA OpenLCB is an opensource LCB that is multi-transport. At the moment we are focusing on Ethernet and CAN, but other transports, such as RS485 can be accommodated. We are designing OpenLCB to be a step forward from existing LCBs, with features for novices to experts, and from small to large layouts: - No board, node, or channel numbers - each board or node comes with a world-wide unique number. - Easy push-button programming for novices and others. See: PushButton1 and PushButton2 - No chance of conflicts between nodes. This means freedom to move your modules around as you like, and no need to reprogram nodes because of such conflicts. - Support for very large layouts, such as modular meets and museums, with fast backbone and multisegments, and with auto-topography and reduced set-up effort for modular meets. - Support for integration of legacy equipment. - Extensibility for new equipment and protocols. - Auto-filtering and routing of messages to reduce network traffic. - Support for higher level software through XML and self-description of nodes. - Uses Producer/Consumer Events, Datagrams and Streams. I can answer questions, if you have them. We also welcome ideas and help -- this is a community project! David
Well, your message certainly generated some interest ... 13 pages of it Welcome to Trainboard. And as you will have seen (if you read all 13 pages) people here will certainly tell you what they think, but usually politely.
Alright, who is playing Lazarus, resurrecting this thread? Personally, I see the NMRA standards as a guideline as opposed to an ideal. What I'm learning is no two locomotives are evenly matched, each runs a little different from a growling, snarling start to a squeeling, squeaky brake application. It's all but impossible to set a standard that is absolute. What it gives us is a starting point and we each need to work or feel our own way through it. Clear as mud....right? Now what the....is this LCB? I know what a CB is and use it to talk to truckers when traveling. LCB? You engineering types are going to have us flying our trains and that isn't prototypical. Grin!
The LocoBuff Blue module was successful for me, I'm now building a LocoNet Wifi Ethernet module which allows you to send LocoNet commands via IP Addressort number. The extension of this is a small project with an ethernet interface on one side and send and receive hex commands to throw switches or sense objects.... but I want to maintain compatibility to existing software. There is just a whole bunch of modular technology in the market place now and by adding this and that you can create any interface you like... Likewise, the PIC processors ($5) provide the brains to convert datastream between LocoNet and any hardware protocol. Assuming you have a LocoNet to UART electrical interface... A UART-Bluetooth interface is $50 A UART-Wifi Ethernet interface is $100 A UART-!0BaseT Ethernet interface is $25 Dwayne
Although I have read postings here before, I have never joined, too many other things to do. So here goes. I am another of the developers associated with the OpenLCB project (along with David Harris who posted earlier in this thread) A very healthy attitude I think! Some NMRA standards, such as track standards, have been the actions that have really made our hobby possible. In fact, it was the need for just such standards which created the NMRA in the first place. For most of us "engineering types" involved with L(ayout) C(ontrol) B(us) development the idea is in fact to be able to operate our trains MORE prototypically than is possible with what we have now. When you run an operating session do you have enough people to provide a driver for every train (each one with a CAB of his own) and controllers and signallers for the entire operation? But with an LCB you could have a train detector in the track section just before a mainline junction. Even if everybody forgets to set the points and signals, the signal would block the train and the detector would tell the DCC system to bring it to a halt. Maybe it could even say, wait until after a train in the previous section of the mainline has cleared, follow all the prototypical signaling rules and the operating schedule, and at the appropriate time allow the train to enter the mainline. Depending on your era and prototype, as many as three people, each with several decisions. With an LCB? Well, it could all be automatic. An LCB is generally intended to be something that will allow pretty much any variety of sensors that you want. Simple switches or push-buttons, BODs, RAILCOM detectors, RFID, IR train sensors, IR remote controls, Radio connected CABs, whatever. It is intended to handle anything that you have that can respond to an action, or in our terms, an EVENT. A producer node (sensor or whatever) produces EVENTS. A consumer node responds to them in some controlled way. A push on a button on a control panel may produce and EVENT which causes a small signal mast controller to CONSUME that event and change the state of a signal. A very simple application, but imagine if you have a fully signalled layout for passenger operation you could have HUNDREDS of signals, in the LCB based system they could all be connected over a single cable bus, easily configured, and potentially controlled or monitored on a PC. Although it is replete with much detail, the OpenLCB website will give you a lot deeper understanding of LCBs. One final comment, OpenLCB is not intended to take the place of any of the current proprietary standards, unless you want it to. In the background various people are working on how to interface to these systems such as LocoNET, XPRESSnet, and even DCC, to ensure that current systems are interoperable in a way not possible now, and to protect your investment in any of these, or any other systems that are out there. Welcome to the future! It is closer than you might think. John Day
The OpenLCB project is certainly interesting. My projects will be based on IP/Ethernet and all logic will be in computer(s). Ethernet is just sooo easy to connect. Dwayne.
Yes, I think that is becoming more and more viable. We have concentrated on CAN and Ethernet, and wireless is in the cards. CAN is very good for smaller layouts and local service, while the Ethernet is good for large layouts, which will likely have multiple area CAN segments. Many modelers do *not* want a computer (PC) attached to their layouts. We therefore are working to provide user-interfaces that extend from push-button programming at the low end for novices through standalone tools for serious modelers to PC based tools for very large museum layouts and modular meets. We interface with JMRI, since one of our group, Bob, is intimately involved in it, and other computer based tools, for configuration, but also tracing, debugging, and operations. Sounds like you have a good handle on these issues, and I would like to hear more as you proceed -- perhaps we can join forces? David www.OpenLCB.org
Well Ethernet is certainly a great way to connect a PC to a layout . Having Ethernet on every node is probably still too pricy. While we do connect via CAN-R232 adaptors and CAN-USB, Ethernet is more flexible, and every modern laptop does have one, and one is all you need to let multiple programs on your PC talk to MRR accessories. David www.OpenLCB.org
David, Well I did give a good look over your site and I see some merit and some things that either I am not understanding, or you are making it more difficult than it needs to be. If you are willing to communicate offline, I would share my take on some of things that I see as an improvement from an engineering standpoint as well as a consumer standpoint. The use of Ethernet is interesting but can easily get beyond an affordable level for a modest size layout. And if you are using Ethernet, why are you not implenting more of an IPv6 addressing scheme and using a TCP schema to isolate command groups instead of being restrained by the CAN protocol? I think the level of the technical discussion I am prepared to go into would not be appropriate here. Let me know what you would like to do.
OpenLCB Sure, love to chat off-line. The material on the website is a work in progress and includes many notes regarding possible directions and implementation choices, and so may be confusing. There is a Common Message Format document that is more directed at Ethernet messaging http://www.openlcb.org/trunk/documents/CommonMessageFormat.html. This has been adapted to CAN, and CAN has received more attention, since CAN is likely to be the transport of choice for smaller layouts and locales, and a better fit to todays technology. I suspect the Common Message Format is more in line with what you are thinking. At this point we are using TCP/IP, as UDP is not reliable enough. I am not sure what you mean by 'isolating the command groups' -- however we can take that off-line. David
No worries. My motivation is (1) simplify the controller interface for children with special needs - My son has major fine and gross motor control issues and even a simple dial with forward and reverse is too hard to use. Wifi Bluetooth and Wifi Ethernet connectivity provides a bridge to software controlled interfaces on an iPad and other special needs communications devices. To use a real world example, an adult or child who only has the ability to blink/control his eyes being able to control a train and all the DCC sound effects is what I am aiming for. (2) do away with the the pc and hardwired interfaces. Provide layout automation using a small/handheld computing device. A 1st generation iPhone has a bunch of smarts and I suggest could provide automation of a very complex layout - WiFI provides the connectivity. (3) Mash (1) and (2) together so that the routing/switching can be intelligent instead of the limitations of a simple loop. My UART-Wifi modules arrived today and I have a modified LocoBuffer Blue waiting for WiFi installation. I should be able to validate WiFi communication and start iPad programming in the next day or two. Dwayne Sinclair
Wow, good stuff! Yes, iPhone could do that. The Androids would probably be more ameniable to us programming them. We think wireless is going to be the transport of choice in the future, but we will still need a protocol. Keep us up to date! David
Smart Phones are pretty expensive add-ons after the DCC system if you are not a user of them Even after that, the monthly bills are not that attractive either. Special needs really do need to be addressed in this hobby, I think something a little larger and easier to see like a Tablet device makes more sense over the Smart Phones.
I think lots of different things will make sense depending on your situation. An iPad would make a very nice control panel for most of us, and for special needs should work very well. It is possible voice command is already available for them? I have an iPhone, so using it for a throttle is essentially free. Also, since it uses Wifi, it works even without a phone plan (so when I get an Android phone, I will have two throttels ;-) ). For a throttle, an iPhone's screen is close to perfect. BTW, iTouch and iPhone already work as throttles through JMRI and withrottle http://withrottle.com/WiThrottle/Home.html --- I have tried the free version. David
