Tapiola Parish Model Railway Club

Why to build an Accessory Encoder

Just two weeks before the layout was to sail to Intermodellbau '03 in Dortmund, the system developed a fault (another of the LW120 boards became dead). There was not enough time to get spare units as none of the Finnish retailers stock this component, so the equipment was sent over to Lenz for repair. Lenz has been a very good supplier and promised to act promptly. As time was getting short, I was asked for a workaround in case the spares would not reach Finland on time. (The repaired unit came week after the Intermodellbau '03, but there was no charge!)

Of course the Helsinki club could have used the TV remote like LH100 manual interface or the LW100 tower cab, but the remote is too complicated to use and manage in exhibition, and tower cab was not a very handy interface either.

The first remedy was the Tapiola club's TMWDCC system. We programmed one portable computer with all possible routes so that with considerably quick commands one could set routes to all 13 through tracks and 5 spurs.

The desire was still to have the old control panel as user interface.

Enter the Mike Bolton's Model Electronics Railway Club (MERG) Accessory Encoder. The schematics and processor source code and hex files are found on MERG web site. This single unit replaces all the above units. The problem was that the MERG Accessory Encoder is designed for on-off switches, but Helsinki club used centre-off momentary switches.

NMRA-DCC accessory decoder packet format

The accessory packet format is described in RP 9.2.1 D: Accessory Digital Decoder Packet Formats and is somewhat like this:

Accessory decoder packet format: ================================ PP..PP 0 10AA-AAAA 0 1aaa-CDDX 0 EEEE-EEEE 1 P = Preamble (at least eleven ones) A = Address LSB part a = Address MSB part in complement form (0=>1, 1=>0) C = individual outputs: 1=0n, 0=0ff, DD= Turnout number within decoder: 00=>1 .. 11=>4 X = coil select: 0=> straight, 1=> diverging E = error detection byte

(Note: I use dash between byte nibbles, so as to make it easier to figure out the bit positions). So, to make things crystal clear, I asked the NMRA-DCC-SIG (Special Interest Group) that have I understood the above thing correctly. The result (after mixup with the meaning of what I have here called as C) was, that the following should be true:

1111..11 0 1000-0001 0 1111-1011 0 EEEE-EEEE 1 Preamble | 10AA-AAAA | 1aaa-CDDX | Err.Det.B aaaAAAAAA -> 111000001 -> Acc. decoder number 1 C on/off: 1 => on DD turnout: 01 => 2 X str/div: 1 => set to diverging => COMMAND: SET TURNOUT NUMBER 2 DIVERGING

Initial test at the Helsinki club

After I had assembled the system on a piece of Vero board I went to the club and was a bit surprised...

Something fishy

C1 C2 C3 C4 ... C16 R1 1 9 17 25 ... 121 R2 2 10 18 26 ... 122 R3 3 11 19 27 ... 123 R4 4 12 20 28 ... 124 R5 5 13 21 29 ... 125 R6 6 14 22 30 ... 126 R7 7 15 23 31 ... 127 R8 8 16 24 31 ... 128

I started the testing! At, what I considered to be the first turnout, I got no action. The same happened to turnout 2, 3 and 4. When I tried turnout number five the turnout number one operated. I was puzzled. I then concluded that possibly the rows are not in correct order, but that too was a wrong assumption.

The problem realised

I had some e-mail exhange with the designer Mike Bolton, and he assured that the schematic was indeed correct, but Lenz idea of turnout numbering is not quite the same as others. Mike also suggested I'd get the free ShowDCC software from Tannersoft so as to double check what was in fact sent over to rails! I installed the software, and made the neccesary hardware to connect it to PC's microphone connector. Hmmm....

The turnout numbers I found at the Helsinki club were the same as those displayed by the software, but the ones that didn't work at the club (original design's turnouts 1, 2, 3 and 4) dispalyed negative turnout numbers (-3, -2, -1 and 0) Hmmm...

The result was that turnouts were found as follows:

C1 C2 C3 C4 ... C16 R1 (-3) 5 13 21 ... 117 R2 (-2) 6 14 22 ... 118 R3 (-1) 7 15 23 ... 119 R4 ( 0) 8 16 24 ... 120 R5 1 9 17 25 ... 121 R6 2 10 18 26 ... 122 R7 3 11 19 27 ... 123 R8 4 12 20 28 ... 124

Following Mikes guidance I realized where the problem lies:

The NMRA Recommended practise 9.2.1 begins with a section A: Address Partitions:

"The first data byte of a Extended Packet Format packet contains the primary address. In order to allow for different types of decoders this primary address is subdivided into fixed partitions as follows."

The partition for acceesory decoders is stated as:

Addresses 10000000-10111111 (128-191)(inclusive):
Accessory Decoders with 9 bit addresses

In this light the decoder numbering should start from address that has the first byte value of 128 (80h, '1000-0000'b). hence (if decoder addressing starts with 0):

1111..11 0 1000-0001 0 1111-0011 0 EEEE-EEEE 1 Preamble | 10AA-AAAA | 1aaa-CDDX | Err.Det.B aaaAAAAAA -> 111000001 -> Acc. decoder number 1 C on/off: 0 => 1 DD turnout: 01 => 2 X str/div: 1 => set to diverging => COMMAND: SET TURNOUT NUMBER 6 DIVERGING

BUT: I've been told that the NMRA DCC Working Group has agreed, that the relation between packet bit patterns and the expressed "address" need not have anything to do with each other, thus the above sample packet can equally right be expressed as TURNOUT 2 or TURNOUT 6.

What I consider as open to discussion is the fact that should all command stations be capable of accessing the whole address space, if they implement accessory decoder control.

Also, I'd like have some clarifiction about the contents of CV's controlling the addressing of the decoder. How can anyone describe the accessory decoders properties, if the only way is to say to which bit pattern it will response.

Apparently the major NMRA-DCC compatible command system's manufacturers have choosen one or the other, and aren't so keen on explaining about their way of choosing or reasons behind their soluton, with two exceptions (NCE and ZTC).

The realization

dccace_1.asm

C1 C2 C3 C4 ... C16 R1 1+ 2+ 3+ 4+ ... 16+ R2 1- 2- 3- 4- ... 16- R3 17+ 18+ 19+ 20+ ... 32+ R4 17- 18- 19- 20- ... 32- R5 33+ 34+ 35+ 36+ ... 48+ R6 33- 34- 35- 36- ... 48- R7 49+ 50- 51+ 52- ... 64+ R8 49- 50- 51- 52- ... 64-

New development after Bankalas 2003 in Skövde, Sweden

We encountered problems as for some reason the Lenz system didn't end sending the turnout activating DCC-commands although we had ended sending packets from this sub-system. We concluded that this could be due to only having one idle packet between turnout activating commands and that probably the LC100 requires a deactivating packet from our subsystem as we only send turnout activating packets, no loco commands at all.

All in all, I modified the code and had some extensive e-mail correspondence with Lenz. The Lenz staff assured that our system should work if the sub-system is indeed sending the packets I described. It took some time until I had a chance to test the system with the updated version of the software at Helsinki club layout. Eventually it seems to work as intended.

Big thank to Lenz for support, and also to Mike Bolton for exellent advice and Helsinki club for using their Lenz equipment for testing!

dccace_2.asm

At Bankalas it was also agreed that the code should be modified so that the decoder addresses could be shifted without re-programming. We choose to use the last decoder's (decoder number 16 or turnouts 61..64) control terminals (turnout 61+/-, ... turnout 64 +/-) to select the starting decoder number (hence the original decoder 1 is now decoder 1 / 8 / 16 / 24 / 32 /40 / 48 / 56 or 64 depending on jumper position. If there is no jumper, only idle packets will be sent (this allows for making the control panel un-manned without disconnecting all the buttons. If the encoder would be disconnected from LC100 this would have caused a reset at LZ100!). We are still uncertain about the maximum number of turnouts LC100 can forward to master system -- the manual says "64 turnouts", but it should be 64 decoders ;).

C1 C2 C3 C4 ... C16 R1 1+ 2+ 3+ 4+ ... 16+ R2 1- 2- 3- 4- ... 16- R3 17+ 18+ 19+ 20+ ... 32+ R4 17- 18- 19- 20- ... 32- R5 33+ 34+ 35+ 36+ ... 48+ R6 33- 34- 35- 36- ... 48- R7 49+ 50- 51+ 52- ... JUMP R8 49- 50- 51- 52- ... JUMP

JUMPERS: one of eight must be in place, will shift above tables turnout numbers so that e.g jumper at R7:C16 -> turnout 1 becomes 97 turnout 2 becomes 98 etc. C13 C14 C15 C16 ----- ----- ----- ----- R7: SW 1 SW 33 SW 65 SW 97 R8: SW129 SW161 SW193 SW225

We have made number of tests with LC100 module and still got the LZV100 to start continuously sending accessory encoder activating packets. (I even bought a Lenz SET90 of my owm to make sure I understand things correctly!)

What we concluded is:

• LC100 will need activating and de-activating DCC-packets from sub-system in order to send respective activating and deactivating X-bus instructions to LZV.
• The LZV will start sending accessory decoder activating DCC-packets when the X-bus command says so, and will end sending accessory encoder activating DCC-packets when de-activating X-bus command is received.
• LZV will not send de-activating DCC-packets!

Hence the Accessory encoder designed to be used with LC100 was altered so that it will send two activating DCC-packets and two de-activating packets to make sure LC100 will notice the de-activating DCC-packets. If LC100 misses the de-activating DCC-packet from subsystem, it will not send the de-activating X-bus command to LZV, hence the Lenz system will start to send turnout activating DCC-commands forever thus burning the turnout motor and in worst case also the decoder!

ace_1b.asm (w. address shift, sends two activating and two deactivating X-bus commands)

Encoder with address shift (this unit is fitted with 4514 chip instead of 2 x '138).

The modified schematic