Ian and others,
I am not going to quote your posting, not because I don't value it but because it will take me longer to respond if I do have to interleave everything, and I woul dlike to tackle some issues in different order.
1.. Why NMRA? You are not the only person to suggest that involving the NMRA is a non-productive exercise. After the experiences of the DCC process even many of the manufacturers might agree with you. But right now the NMRA is suggested as being the place to standardise things. However, the attitude of the NMRA and some of its officers and staff may change that.
I understand your concerns about the NMRA. Fortunately none of these efforts (except for the S9.5 Voss one) directly involve the NMRA. The development work is going on independently and then material is being offered to the NMRA to accept as standards or not as they see fit. The Voss effort is from Don Voss, Didriks brother. He was for a time, part of one or more of the various working groups. But it seems right now that he has totally withdrawn, and has convinced Di that his personal proposals should be included in teh drafts of standards being put to the NMRA board next month. At least Di has been transparent enough to allow the working group proposal to appear unmodified as well. If you wish to read the first part, try these docs.
Original draft physical layer
Descriptive note for the above
Voss modified standard proposal
Descriptive material with Voss modifications
Right now we, the OpenLCB group, are following the NMRA track, but lets see what happens.
2.. Why call it a LAYOUT control bus? Good question, I suppose the answer is that we are designing the LCB (and I am specifically involved with the OpenLCB or NMRANET proposal S9.6 group) for layout use. We are not conceited enough to believe we can design something that is all things to all users. That is for people with far less possibility of success! However the entire architecture lends itself to many other things. So let's crawl before we try and Olympic marathon.
3.. Why not base it all on a PC? The reality is that while for techno-nerds and geeks the idea of putting something like a PC in there is nice, for many people it is not! However the OpenLCB system and others are already supported by JMRI and so PC based configuration and management is already a possibility. Another reason is size and connect-ability. A PC like box is big, no matter how dense it is, and if I want to hide something inside an N scale station building, for example, its not going to be the sort of thing you mentioned. Its going to be something not much bigger than a DCC decoder, and I have seen a PC that small yet, neither have I seen anybody able to integrate Ethernet in something that size, at a price we can afford.
4.. Standards a-plenty? Yes, of course there are, gazillions of them. Many of them requiring high entry prices to play, others barely supported or used. Standards are great, but often they do nothing more than document the past. History is great, and we need to know it, but we also need to move forward.
Now on to more general issues.
Average Joe modeler: If we accept for a moment the work done by the OpenLCB team before the NMRA convention in Milwaukee last summer, then in fact you could go to the store (of course we had to make our own), buy a couple of little boards and get some sort of control working - WITH NO PC! Go and have a look at one or two of the movies at
the OpenLCB site to see what can happen with very simple hardware. Using a non-PC based system such as the blue-gold approach develop by Bob Jacobsen and David Harris it is possible to set up the interactions, even quite complex ones, in just a few moments. And look mum, no PC, just my bare hands!
Various people, including some Open Source groups (like OpenLCB and the MERG-CBUS group in the UK) are now designing or have kits already available to implement LCB's. Commercial manufacturers have design in the works and their is serious interest and some involvement from existing DCC manufacturers.
Initially the proposal is to use CAN bus on the layout. It is robust, noise tolerant, very inexpensive and extremely widely used. It can operate in very low power environments if needed. But it is limited to 1mbps maximum speed. So it is inevitable that manufacturers will use Ethernet and other systems to extend and expand something like OpenLCB. In fact that has already been demonstrated in Milwaukee by the OpenLCB team. And the extended PC based functionality you want, is already addressed in the OpenLCB work and the JMRI work.
Some manufacturers also plan super simple connections, which I call "last foot" options, for connecting things like individual signal masts to a control-point module.
The producer/consumer event model that is being used, at least in OpenLCB, scales very well from a simple two node (board) system to potentially something as big as a FREMO meetup with hundreds of model modules interconnected. Other systems, such as DCC will become potential peripherals on a system like OpenLCB, so a single controller attached to the LCB Will serve to do anything on the layout or on the track. Imagine a complex sequence of movements in a passenger station involving signals, an animated platform guard, points, level crossings, possibly multiple trains, route and timetable displays and your CTC, all happening automatically just because you clicked on a button, or because a loco appeared in a certain spot. Oh, and it had to be a certain loco, based on RFID in the vehicle! Or possibly on a geo-location function built into the LCB.
Once we have the model railroad features sorted out then I can only imagine where the system will go then. I already know doll-house modelers who are interested to use OpenLCB to automate their models!
I see that while I have been writing this that David Harris, another of the OpenLCB hard core has responded. If people here are interested, then both of us will be happy to continue posting. In the meantime, the
OpenLCB website may answer some more questions. And please bear in mind, we are looking for other volunteers to help if they wish to contribute.
Kindly,
John day (Toronto Canada)
nb: NMRANET aspirant protocol is a product of the OpenLCB working group, as is the unmodified S9.x.1 draft mentioned herein.
