From: greene@edisto.mro4.dec.com (Michael Greene)
Subject:  Re: Command Control Standard Status Update
Reply-To: greene@edisto.mro4.dec.com (Michael Greene)
Organization: Digital Equipment Corporation
Distribution: usa
Date: Mon, 17 Aug 1992 21:51:47 GMT


--
I'm posting the following at the request of Jeff Barry, who was
dashing off on vacation...

Michael
--------------------------



							Jeffrey Arno Barry
							NMRA # 86388
							21 Martin Street
							Acton, MA  01720
							(H) 508-263-8717
							qbarry@qb.enet.dec.com

							14-Aug-92

To whom it may concern:

Greetings,

The following are my comments on the proposed NMRA Standard "Electrical
Standard for Command Control, All Scales."  This standard is currently in
preliminary draft form.  I am commenting on Version 0.6R, dated 15-Jul-92.

[ Since starting this reply I have had a chance to converse with the author
  of 0.6R.  I have left the bulk of this reply unchanged, but in a few
  places I'll make comments in [] based on that conversation.]

I want to start by saying I appreciate the effort that has gone into this
so far and want to thank the people who have done the work.  I hope my
input to this process will prove useful as well.

My intent with this letter is to address the aspects of the proposal which
I consider inadequate, and I hope to persuade others with this letter so
that these shortcomings will not show up in the final, approved standard.
I wish in no way to criticize the effort or the people involved.

I have heard that the standard is being written to accommodate an existing
command and control chip, the "Lenz" chip, which is the basis (??) of the
Marklin Digital (tm) products.  Whatever the name and history of this chip,
I am concerned that the NMRA might accept this chip as the standard simply
because it was there "firstest with the mostest" regardless of any flaws in
the function of this device or other chips which may soon become available.

[ I have since been told that the maker of the aforementioned chip intends
  to be very flexible.  He is only concerned with maintaining backward
  compatibility to his chip, not with trying to shoehorn the standard to fit
  his chip. ]


Critical To Smaller Scales.
- ---------------------------

I particularly want point out the special importance of this standard to
those of us (including myself) who model in the smaller scales, TT, N, and
Z.  In the smaller scales the ONLY C&C system that which will work in all
locos is a single (?) chip device in a VERY small package.  N-scale tenders
and dummy B units have certainly been stuffed with C&C circuit boards
before, but what about that small diesel switcher we want to bring "on
line"?  Only a chip will fit; there is NO way to shoehorn in a circuit
board of discrete components as is possible with the larger scales.

									Page 2



Further, once an NMRA C&C standard is approved, it will have a chilling effect
on the design of alternative chips.  The design of new chips is fantastically
more expensive than new circuit board design, so it is unlikely a chip foundry
would build an alternative that goes against an existing standard.  One need
only look at the push towards "open systems" (ie standards) within the
computer industry to see the POWERFUL influence which standards have on the
people who build such things.

[ The Lenz "chip" is actually a pair of chips, one a microprocessor, the
  other a memory chip.  The system is highly programmable in some respects so
  we can use the existing chip if we don't change certain things. ]

The bottom line is that a chip built to this standard may well prove to be the
ONLY option for C&C that we who model in the smaller scales will have, so it
is especially critical to us that it serve our needs.  If the standard is
flawed, small scale modelers may well get no alternatives.


14 Speeds Is Not Enough.
- ------------------------

As proposed in Draft 0.6R, there are only 4 bits allocated to speed selection,
giving 16 possible speeds.  (A separate bit is used to indicate direction.)
Two of these codes are taken by STOP and EMERGENCY STOP, leaving just 14 speed
settings.  The standard attempts to ameliorate this situation by suggesting
"speed averaging":

B-2.2>> The Mobile Digital Controller shall provide a smoother speed transition
B-2.2>> by averaging the last two speed values sent in order to provide up to
B-2.2>> 28 possible forward and 28 backward speeds.

0.6R goes on to address the need for the need for greater speed control at
lower speeds:

B-2.2>> It is recommended that the Mobile Digital Controllers use non-linear
B-2.2>> speed steps, so there is a finer granularity between speed steps at
B-2.2>> slower speeds.

In my mind, the limited number of speeds available under Draft 0.6R is the
single most serious flaw in the whole proposal.  Here are some problems
which I see:


									Page 3




- - I believe that speed averaging is highly suspect.  First of all it feels
  like a band-aid solution to something which should not be a problem in the
  first place.  Secondly, and more to the point, it could prove to be a
  source of unreliable operation.  The draft states:

  Part 1, C>> Because the electrical conductivity between the Mobile Digital
  Part 1, C>> Controller and Signal Generating Unit is susceptible to noise,
  Part 1, C>> due to the properties of rotating wheels on rails, command
  Part 1, C>> control packets should be sent as frequently as possible to
  Part 1, C>> all currently operating Mobile Digital Controllers.

  I believe the contact problem is worse with the smaller scales.

  One problem with averaging is this: In order to get an averaging effect in
  the noisy environment, a continuous stream of alternating, adjacent speed
  settings (eg 5,6,5,6,5,6,5,6,...  for speed 5.5) would have to be sent since
  you do no know if either speed setting was received.  Thus to achieve one of
  these "averaged" speeds, you effectively double the bandwidth required to
  send a speed, and there is not a whole lot of bandwidth there to begin with.

  Another problem is jerkiness caused by averaging in a noisy environment.  If
  the loco has been receiving 5,6,5,6,...  and suddenly a packet is lost, eg
  5,6,5,???,5,..., the loco will average the last two packets received, 5 and
  5, and set itself to speed 5.  On a club layout where there may be a lot of
  bandwidth in use, the next 6 to the loco may be delayed long enough to cause
  a noticeable drop in speed followed by an increase after the next 6 is finally
  received.  Averaging can therefore result in jerky train motion, especially
  at higher speeds.  This is not a problem with direct speed settings.


- - Believing, as I do, that speed averaging is not reliable, the proposed
  standard leaves just 14 speeds.  I wondered what that would look like,
  say, for my N-scale Minitrix U Boat which runs at 300 scale MPH at full
  power.  (I admit the top speed here is rather unprototypical, but a good
  standard should handle all equipment and tastes.  :-)  As recommended by
  the draft I set up "non-linear speed steps" favoring the lower speeds,
  using a constant multiplier between steps (basically the 14th root of
  300, approximately 1.5).  The proposed standard would have my U Boat
  running at the following speeds:

	     Setting	Scale Speed	      Setting	Scale Speed
	     -------	--------------	      -------	--------------
		0	Stop			 8	17.3
		1	Emergency Stop		 9	26.0
		2	1.5			10	39.1
		3	2.3			11	58.8
		4	3.4			12	88.4
		5	5.1			13	132
		6	7.7			14	199
		7	11.5			15	300

									Page 4




  The low end is pretty good for crawling around yards and sidings, but by
  the time we start getting to road speeds, about around speed 9 and up,
  the scale speed differences increase faster from each setting to the next:
  13, 19, 30, 44...  To my mind these are noticeable and unacceptable jumps
  in speed as I am standing there SLOWLY turning the dial on my throttle.

[ The Lenz chip has 64 speeds internally even though the commands have 14.
  The 14 external speeds are equivalent to 14 of the 64 internal speeds.
  When told to go to a different one of the 14 speeds, the chip steps
  through the intervening of the 64 speeds at a rate determined by some
  momentum function.  If momentum is turned off, stepping is essentially
  instantaneous and the jump between the 14 speeds is indeed evident. ]

- - The single worst problem with the small number of speeds comes from trying
  to MU dissimilar locos.  Done correctly, this is one of the places C&C
  allows us to do something we cannot do with analog systems, but with a
  small number of speed settings things may not work so well.

  The worst scenario is with a rear helper: The "master controller" is told
  to move out the train at speed X.  It looks up the speed settings for the
  front loco and sends it, but, say, X turns out to be a little faster than
  the setting.  Similarly, the master controller sends the setting closest
  to X to the rear loco, but it turns out that that setting is a little, say,
  higher than speed X.  Now we have a train under compression; the front
  loco is not going to run significantly faster with the push from the rear
  because of the worm gearing so prevalent in our hobby.  This compression
  is a potential disaster given that so much of our equipment comes with
  truck mounted couplers (and Rapido couplers and insufficient weight in n
  scale).  Under analog control I have seen the rear loco slowly work its
  way through a train, derailing car after car.  This is not acceptable
  either with analog or C&C control.

  I'm not completely sure what number of speeds would make this scenario
  improbable, but it's bigger than 14.  I don't even want to think of the
  possibilities of MU'ing and missed speed packets under speed averaging!

[ To my knowledge the Lenz chip still does not address this problem. ]


Comments on packet encoding.
- ----------------------------

The following comments are relevant to Draft 0.6R, Part I.A, "Packet
Encoding".  First and foremost I noticed this:


I.A>> It is permissible to lengthen either the positive and or negative
I.A>> voltage pulse for "0" bits.

									Page 5




Why?  There is no reason for this in the spec that I can see.  And there
are some reasons why it is not desirable: (1) It expands the tolerance of
what the bit detector will accept, making the detector more vulnerable to
false detections.  (2) To generate and receive varying length pulses
requires more circuitry than do fixed length pulses.  More circuitry means
more cost and less reliability.  (3) Since the signal is, in fact, used to
send power as well, one must consider the signal's frequency when designing
track driven power converts.  Allowing the longer 0 pulses means, say, more
filtering is required for remote DC sources.  It is better to have the
pulse length confined to a narrow region.  [ I guess #2 & #3 are nits. ]

Unless there is a compelling reason for varying length pulses in the
proposed standard, this "feature" should be dropped.

[ I found out that the lengthening 0 is there so that zeros sent can have a
  substantial DC component which can be used to run non-C&C locos with open
  frame motors.  However, there is some possibility of other types of motors
  would burn out under these conditions, so I still think it a bad idea. ]


The second thing I noticed about packet encoding is that the length of the 0
bit is an integral multiple of the length of the 1 bit, namely twice as
long.  This seems contrary to what I know about frequency shift modulation,
namely that integral multiples of frequency increase the possibility of
aliasing, making misdetects more likely.  Electrical noise on the track
could very conceivably make a 0 look like two 1s.

If the bit detector had a 0 period of, say, 1.5 times that of the 1 period,
it would be much easier for the detector to reject noise, it would certainly
allow the 10% length tolerance the spec calls for, and it would increase
bandwidth.

[ I doubt this can change because it would not allow backward compatibility
  with the Lenz chip. ]


Which brings me to my final question on packet encoding: When you work out
the numbers, on average the proposed standard will handle about 171 packets
per second.  Is that enough?

It certainly is for small home layouts, but what about N-trak meets with 25
operators busily spinning their throttles (and all of said commands are
being sent multiple times for aforementioned reasons)?  I am not suggesting
that the bandwidth in the proposed standard is insufficient, but I'd like
to KNOW via simulation or experience that the bandwidth is sufficient for a
LARGE AND BUSY layout BEFORE we commit to a standard.

									Page 6



Comments on Controller Data Byte contents.
- -------------------------------------------------

The proposed standard uses 2 (of 8 total) bits to encode the following
overall functions:

B-2.2>>		00 = Reserved for possible future expansion
B-2.2>>		01 = Speed and direction data byte
B-2.2>>		10 = Auxiliary function data byte
B-2.2>>		11 = Reserved for use by the manufacturer
B-2.2>>			for internal testing

[ This format is indeed a backward compatibility issue. ]

Of the 256 possible values of this byte (which is used to control speed,
horns, lights, you name it), fully a quarter, 64 values, are used for
manufacturer test.  This is grossly excessive, especially considering the
existence of "Service Mode" (PART II, C) and the 7/8 UNused set of codes in
the "Service Mode Instruction Byte" (PART II, C-1).

There is simply no reason to take that much operational potential away from
the end users (us!) for manufacture's test.  (I was in the logic test
business for 15 years and I know what I am talking about.  I would be happy
to consult with any chip manufacturer who can't figure out how to test an NMRA
standard chip.  Free!)

Additional comments: 

- - The code sections could be combined (00,11) or renumbered (01,10) so that
  speed and direction get half of the available address space (eg 1dssssss)
  at least with no loss for functions and expansion.

- - What "primary function" is SO important that it has to take a bit away
  from the speed?  That bit should be moved elsewhere and more space be
  given to the speed.

- - Emergency stop could be a combination of "backwards" and "speed=0" so that
  another speed value is freed up.

The bottom line is that we could get more functions and speeds if the data
byte format is cleaned up, though I won't propose an alternative here.

[ I will later. ]

									Page 7

C-1 Service Mode Instruction Byte:
- ----------------------------------

C-1>> Note: The definition of other values of Bits 6-8 are left to the 
C-1>> manufacturer's discretion.  Possible examples include starting 
C-1>> voltage, acceleration rate, braking rate, and speed response curve.

- - Using service mode to set momentum is a problem.  Prototypical operation
  would require that an engine, say, once disconnected from or attached to
  its train, would have to be on an electrically isolated track so that
  service mode could get at it to change its momentum.  This electrical
  isolation would make layout wiring much more difficult and in part defeat
  one purpose of C&C, ie simplified wiring.


Error Checking:
- ---------------

It strikes me that using a whole 8 bits for an error check is excessive.  If
nothing else it eats up 20% or so of available bandwidth.  Aren't the bit
detector and packet detector enough that we don't need 8 error check bits?

[ Lenz proposes additional use of this byte to allow another 3-byte format. ]


Summary
- -------

I am VERY concerned that the 14 speeds allowed are not enough, especially
for MU or helper work.  I hope that the final standard will have at least
64 speeds.  There is certainly room for it if space is better utilized.

[ I seem to have landed myself on the C&C standard committee.  After my
  vacation I'll jump into it with my emphasis being placed on getting the
  standard to meet the needs of the smaller scales without sacrificing the
  larger scales!  :-)  ]


------- End of Forwarded Message


----------------------------------------------------------------------------
** The opinions expressed above are not necessarily those of my employer **

Michael Greene                  Phone:     +1 508.467.2149
Networking Consultant           FAX:       +1 508.467.3106
Public Sector Marketing         E'mail:    greene@edisto.mro4.dec.com
Digital Equipment Corp.         
Marlboro, MA USA                Member, 470 Railroad Club
----------------------------------------------------------------------------