The wide world of LCB's.

Layout Control Buses that is.

As with any efforts to produce standards, particularly open ones, their has been an attrition of projects in recent years. Layout Control Buses for model railroads are not new, but those that exist now are often based on simplistic and not greatly flexible schemes. Possibly the classic is Dr Bruce Chubbs C/MRI which first appeared in Model Railroader magazine in February of 1985. Based on a simple microprocessor module with an RS-485 or RS-422 interface, connected to a PC, the C/MRI system then uses a series of IO expansion cards to connect to pretty much anything. Updated fairly regularly the Chubb designs are now starting to show their age but are still a viable control system. Information and parts can be found at the JLC Enterprises website.

From the ever industrious MERG group in the UK comes Gordon Hopkins RPC system. Of similar vintage and technology to the Chubb system RPC relies on a series of interconnected interface boards. Having the pleasure of meeting Gordon I can only attest to his keen modelling interest and his designs reflect that. However like the Chubb system it is now getting dated, much of the work on it having been done in the late 90's.

In 2007 or so their again emerged from MERG the CBUS system conceived and developed by Mike Bolton in the UK and Gil Fuchs in California. Based on CAN bus this comparatively new system marks the beginning of the new LCB era. General purpose modules, well connected, using something akin to the producer/consumer model of operation. CBUS has a Yahoo Group as well. The boards are based on PIC controllers with CAN bus. The early boards had some issues with ground bounce and offset, but the later 12V board versions are reported to be somewhat more stable. However the practicve of sharing ground and power for the communications and operation power does detract form the stability of larger layouts. CBUS is a credit to its developers and certainly deserves a look.

OpenLCB arrived on the scene also in 2007 but began life in 2005 when I designed a DCC and accessory system that never saw the light of production. Discussions surrounding this approach stimulated Dr. David Harris and myself to explore further and through our acquaintance with Alex Shepherd in New Zealand we started devising what was at first an object oriented network which transitioned to a producer consumer network as we developed. The principal developers for OpenLCB are myself, David Harris, Bob Jacobsen (of J/MRI) and Alex Shepherd. Their is also an active Yahoo Group. Some hardware has been designed and is in use but much OpenLCB development was done on the Silicon Railway LEDuino (which includes CAN bus, DCC decoder input and rudimentary response signalling, LocoNet interface and the usual serial and USB interfaces) and other Arduino type boards. John Plocher has an Arduino model railway shield.

Don Voss proposed an RS-485 based system (as I recall) which he later moved to CAN bus in 2008 or so. Very little data has been published, but what has can be found linked on the largely outdated NMRAnet website as the S9.5 system.

There have been others, but quite honestly the details are rather vague in my mind right now and I would have to dig back into history. I should also say that I am directly involved with OpenLCB, and I have been a part of the NMRAnet community since essentially before it existed!

Tune in again for some technical discussion very soon.

Why? He asked...

Would Don want to change the heavily discussed and argued OpenLCB physical layer standard (already voted and accepted within the OpenLCB community) and modify it?

Several of my colleagues at work and elsewhere have been heavily involved with CAN bus for some little time now. So over the last few days a couple of us have used our break time to kick around some ideas in an attempt to figure out why Don was so insistent that these changes be included. All of the comments that I recall related to increasing the number of nodes allowable on a given length network.

Three factors influence the length of the network.

• The round trip propagation delay between the two most remote nodes.
• Voltage changes due to the intrinsic resistance of the cable and the Rdiff of the individual receivers
• Waveform distortion or signal level attenuation due to the effective distributed capacitance of the transmission line.

Cable: The specification as we established it calls for the use of CAT 5e cable, which according to the ISO11801 standard should have nominally 5.7ns/m delay. But this is purely for the cable, it does not include connectors, PCB's with their own intrinsic capacitance and the effects of any common mode chokes or ESD protection devices. Prudent manufacturers may choose to include common mode chokes, ESD clamping diodes or varistors for protection. All of these add capacitance which will increase Vp and reduce the maximum cable length as well as add waveform distortion as alluded to above.

Resistance: We are assuming, that despite their being no explanation of the derivation of the constant in the numerator of the equation, that the VossBros equation assumes a 90 ohm/kilometre resistance. And thats fine, but our concern here is that not only does the VossBros change actually not specify what Ri is, nor does it spell out how that constant was derived. That equation does not appear to take into account any parasitic or stray capacitance introduced by PCBs, connectors, ESD protection or whatever.

Waveforms: Anybody who knows anything about transmission lines knows that rise and fall times are a function of bandwidth. Compromising bandwidth with capacitance means that to get the performance we have to reduce capacitance, which means reducing cable length. If you are to allow users to calculate the maximum network length, or max number of nodes for a given length, then capacitive effects must be taken into account, but in the VossBros documents they are not.

The OpenLCB standard offered to the NMRA (but butchered by VossBros) specified the important maxima, length and number of nodes. Why was that so hard to understand? I have one possible hypothesis. At one point the concept of gateways and bridges was discussed with the S9.5/Voss group. It seems that in their own opinion bridges don't play well with their protocol. Of course we can't offer much more of an opinion because no details of their protocol have ever been published. But that could explain the obsession with maximising the number of nodes. So an S9.5/Voss based LCB could be limited to the 111 or 112 or whatever number of nodes. OpenLCB/S9.6 on the other hand can use bridges and gateways to create much larger LCB's.

Life has been busy

Life tends to deal all sorts of interesting cards to us. In the last six months I suppose the economic crisis has consumed most of us, especially those trying to hold onto our jobs! So it has been some time since I wrote anything here, but now I can remedy that neglect.

Altera/NIOS-II

Seems to have been a major focus of my work for much of the past two years. I now have four successful designs under my belt, one is in production, one is going into production now with a third to be in production in the next month or two. The fourth may never see the light of day - that will depend on the speed of another major development project I am working on.

LEDuino

My baby! This is our take on the extremely successful Arduino project. Several volume orders for special applications have consumed a huge amount of time and effort. About Octoboer 2008 we built a large batch of the revision B board which has been very successful. Finally we have had time to implement some CAN bus code for the thing and code for DCC is under way. If you want to know more, keep a watch on this page for more details.

Arduino/Leduino mechanical drawing

The Arduino concept, and our own LEDuino, have been a great success. But one persistent difficulty I see is the lack of an accurate board outline drawing. At least supposedly "authorative" template I have seen had errors. So based on the Eagle files of the official Arduino Diecimila I created a layer in my EDA package that has the dimensions that as far as I can tell are accurate. This PDF file is a copy of that layer. Unfortunately I do not use Eagle but if you do, feel free to translate my drawing and I can happily post it on my site if you want.

LEDuino in the wild.

Well, the first LEDuinos are making their way into the wild. The very first shipment went to Australia. I hope the unit enjoys going back to my home country! Response so far has been very gratifying. We are working on some application examples using the LEDuino specific capabilities, more news soon.

Arduino field to get a new entry

For some time now my colleagues and I have been using Arduino ( http://arduino.cc ) style hardware based on the Atmel ATmega168 processor and a very easy to use development environment. The Arduino IDE environment is flexible enough for much rapid prototyping work, but simple enough for non-technical people to use, in fact it was originally designed for teaching design students how to build interactive projects.

The more we used the system, the more we liked it. But the more we used it the more we found we were missing some things we take for granted on our more sophisticated development platforms.So why not add some interfaces to the Arduino to make it more usable in a variety of applications?

So we sat down and figured out what we use most commonly. Thus is born the LEDuino.

• Buffered I2C bus for longer cable runs and higher bus current operation. So we added an IES5501 bidirectional driver.


• We play a lot with designs for model railway layouts. Already we use a lot of DCC, so we figured that a standard DCC decoder input, complete with basic acknowledge facility. So we added that with full galvanic isolation both ways for convenience.


• In a number of situations we use CAN Bus. Several developing or proposed model railway layout control busses use CAN, so we figured we could be compatible and give ourselves a simple development platform for that too. CAN is also used in a variety of other fields where we have some professional involvement.

So why the name LEDuino?

Well, one of our engineers develops a lot of LED based technology for architectural, visual effects and signage, he often wants to talk to serial interface devices like the TLC5940 from TI. So we added an entirely custom connector on the bottom edge of the photo, it has a serial interface that is designed to mate with some of our other products. As time goes on some of these products will be added to this range of products.

So this is it, the beginnings of a new range of Arduino inspired technology which is in fact already well proven, well used, and well liked.