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.

de Javu all over again.

When I wrote a day or so back about the NMRA process for standardising the very first part of their desired NMRAnet little did I know that a decision had already been made. Of course, the usual dictums of common courtesy seemed to have escaped the NMRA Board of Directors and the Standards and Compliance Manager. The working group was not informed. The authors of the document were not informed. The standard merely appeared at some point. The next line on the index page points to the as yet non-existent technical note.

At least in the version finally published some of the material so offended the Standards department manager was restored. But the sad part is that the changes which remain are just as offensive to the technical community. Even more amusing is that what we have asked for over so many months, something that supports the assertions of Don Voss, still hasn't been supplied, nor is it included either in the standard as published, or in the draft TN (the real one we dont know).

The standard suggests that we can adopt CAN bus yet vary it. I wonder if somebody, like Robert Bosch the inventors of CAN bus, has copyright control! The bastardised CAN bus we are presented with sinmply is not CAN bus. The Voss brothers ask that we accept that CAN bus certification of a component is required, but that an essential CAN bus specification, Rdiff(min), must be >20kohm. But Rdiff(min) is only tested to be >10kohm for CAN bus certification. A transceiver manufacturer may, but is not compelled to, state what Rdiff actually is, or the range that may be encountered.

All of this when they went to such lengths to try and justify this variation using data and application notes designed to sell specific products. By including a formula in the standard for determining the maximum theoretical under ideal conditions network length WHICH INCLUDES Rdiff AS A PARAMETER! Well, they sneakily dont say that, they include 20,000 as a constant. When in reality the maximum langth of the network, under those same conditions (or the maximum number of nodes) could be longer or larger if the original equation from NXP were used and the effective Rdiff left in place. Of course, after FOUR years of discussion it is hard to expect such rigour to be part of the standard isn't it?

Like I said, what did we really expect? Procedural fairness? Honesty and technical integrity? Openess of process and procedure? Well, this is the NMRA after all.

Seems some things never change! The NMRAnet saga 3 years on

When I wrote my post yesterday referring to the debacle surrounding the NMRA and the NMRAnet process I had in the back of my mind that this had been going on for a long time, what I had forgotten was that I posted on  the same broken process back in April of 2008, close to three whole years ago. In that post I referred to the process that had been going off the rails routinely for the previous 12 months. Which means this debacle must have been going on for about 4 years now!

Insane.....

And we still can't get a sensible word out of the NMRA process.

During that time an amazing group of people have developed the bulk of a standard series and protocol family known as OpenLCB. Their work and their efforts in the NMRAnet working group have formed the basis of the S9.x.1 standard proposal which has been butchered by the amateurs I referred to yesterday. As a part of that effort I find the last minute unsupported modifications outside of the working group process to be an abomination.

How much longer does it have to go on?

Or maybe it needs to come to a stop now, and like the DCC working group before it, fade into oblivion. Since June of 2009 the DCC community has been split in two. A US based manufacturers group which only admits established large scale commercial DCC manufacturers to its discussions, and a European group which insists that all its meetings will be in Europe and business conducted in German. If the NMRAnet working group persists, then I wonder how long it will be before we come to the same impasse?

In the meantime maybe the "OpenLCB" group on Yahoo groups is a good place for anybody wnating to know what an LCB (Layout Control Bus) really looks like.

When amateurs dabble

When amateurs dabble in technology we see all sorts of things happen. Some are amazingly good, the Arduino would be an example of that. From small beginnings a group of hackers and hobbyists have changed the face of microprocessor learning and development. A true paradigm shift.

But for the last few months I have spent many hours working to try and bring some sanity to the NMRA (National Model Railroad Association) standards discussion over a model railway layout control mechanism they want to sponsor called NMRAnet.

The development of the scheme was to be co-operative, but never open. However in the end the brother of the Standards Manager for the organisation left the co-operative discussion and took no further part in the working group established by volunteers to develop the scheme. This same former member of the working group then had his brother modify the documents submitted by the working group to include his own favoured changes. Sadly they were generally ill-considered and had the backing of nobody in the working group.

So now we stand at an impasse, two versions of the documents will be put to the board of directors. We wonder which will survive, the original which is sound, rigorous and based on ISO and other standards, or the modified, crippled version, which removes several of the most basic safeguards to the reliability of the network.

Who knows, buyt in teh past it seems tat no matter how ill advised the changes unilaterally proposed by the Standards Manager they have been accepted. Lets hope the NMRA Board of Directors changes their minds this time.

Whatever happened to.....

In this case, MIPS Technologies.

Based on original academic research done at Stanford from 1981, MIPS was formed in 1984 and until the 1990's was influential as a supplier of CPU chips for a variety of manufacturers, including such names as SGI, Siemens/Nixdorf, Olivetti and many others. Since then MIPS has also been licensing architectures and core designs which became prominent in the set top box, cable modem and router arena. They never made it into the Smartphone/PDA market, long dominated by Intel and ARM.

And now we see yet more advances from ARM, newer cores such as the Cortex-A15 and promised improvements this year and next seem to set the field for an even greater market penetration by ARM.

So I really do wonder, where will MIPS go now?

Its not easy keeping a blog!

And I am sure a lot of you know that. Between work and family how should I find the time to say things here. Well, I keep finding notes of all sorts of ideas around my desk, so maybe I should just post some of those!

The goalposts keep moving!

The microprocessor has been with us for some time now, on my radar since 1974 with the release in April 1974 of the Intel 8080 which I first applied only a few months later. So I grew up and was 'educated' before the microprocessor. In those early days the choices were minimal, Motorola introduced the 6800 a little later in 1974. Despite protestations to the contrary that one or the other had some great technical or architectural merit it was really a matter of religion which path you followed. You could make a choice then being comfortable that it would hold good for a few years.

More recently the same religious fervour is evidenced by the proponents for the Freescale (formerly Motorola) 6800/6802/6809 ancestored chips versus Microchips PIC and Atmels much newer 'C' code optimised AVR and megaAVR. Each has its benefits, but logic defies any choice other than the one that I like!

But now the game has a completely new set of rules. ARM, of Cambridge UK, has turned the world upside recently with the introduction of the Cortex-M3 IP core. In a very carefully staged collaboration with Luminary (now part of TI) we saw the introduction of the Luminary Stellaris parts - the first M3's. Now everybody is on the band-wagon! Atmel (ATSAM3 is Cortex M3 based), TI through the acquisition of Luminary, NXP with the LPC17xx series, ST Microelectronics STM32, Toshiba and a new Norwegian startup - Energy Micro. All good viable companies, and don't count Energy Micro out, although only 2 years old they have some well experienced talent from Chipcon (now part of TI) and Atmel.

So now we don't get each manufacturer offering us a new architecture - we get them offering us different customisations and peripheral mixes all based on the same CPU core and interconnection fabric.

Oy vay!