Warning: DCC details hacking follows, and might be incorrect if I've misunderstood something. If you don't mind being confused, see
NMRA DCC extended packet format standard.
When a DCC packet is sent to an accessory decoder, it contains the following:
- A two bit preamble 0x10 which indicates an accessory decoder address
- 6 base address bits
- Addresses 1-63. Address 0 is reserved for broadcasts.
- 3 high address bits
- Add 64 times this value to the address to get the actual decoder address. Standard addressing is thus in the range 1-511.
- 3 bits that control which function outputs are being modified
- The language in the standard is confusing, but it seems that 2 bits are commonly used which results in 4 different outputs that can be controlled.
You can observe that the
LGB 55525 CV registers (page 10) actually follow this basically as-is:
- CV1 takes values 1-63
- CV9 takes values 0-7
However, there's a convention that each "function" has its own address, rather than being a sub-function of the actual address. Under this convention, packet address 1 outputs A-D are "addressed" as 1-4, packet address 2 outputs A-D are 5-8, etc. To obtain a packet address from a function address, apply the following:
packet address = (function address - 1) / 4 [drop fractions] + 1
which simplifies to
packet address = (function address + 3) / 4 [drop fractions]
The dropped fraction (0-3) is the decoder function being activated, with 0 being the first and 3 being the fourth.
Unhelpfully, the other table on pg 10 of the LGB 55525 manual maps function addresses ranges to CV9 without telling you how to derive the corresponding CV1 values. You might also note that sets of four addresses are missing - correspond to packet addresses 64, 128, etc. Normally you would access these with CV1 = 0 and CV9 = 1..7, but CV1 = 0 is not an available value on the 55525.
In contrast, the MX820 appears to allow any in-range combination of CV1 and CV9 except 0,0. The documentation on page 6 says that the split between CV1 and CV9 will be applied automatically by the ZIMO cab. If you're manually writing the CVs, you will need to be aware of how the address is split.
Note that accessory decoders do not have "extended addressing" like multi-function decoders, but they do have a bigger base range.
If I understand the process the decoder is actually using the conventional dcc addressing system of a whole number, its the MX32 which is actually using the sub address system for its own internal purposes.
No. The decoder is looking for the DCC decoder address in the packet, which is the one the MX32 is reporting to you. The MX32 "sub address" refers to which function gets triggered. The MX32 way of doing things is actually more accurate to the underlying system.
"Function addressing" (my term) is a fudge that pretends that the decoder address and the function indicator occupy a single address space which is 4x as large as the actual decoder address space.
I start by programming decoder / turnout motor unit on the programming track with the MX32, for this I will use the "conventional" CV#1 = 50.
Loco screen -> E + MN -> SERV PROG. -> A -> Address entry screen -> #50 -> F -> should say ACK. It should then read back address as #50.
With the caveat that I have never programmed an MX32, I suspect this will
not do what you want. Assuming you are using an MX32 to program an MX820, I believe this will write 50 to CV1. 50 in CV1 corresponds to
packet address 50 but
function addresses 197-200.
If you want function address 50, you will need to write CV1=[(50+3)/4]=13. Note that 53/4 has a remainder of 1, so you will be addressing decoder 13, function B. If you're using an MX820D or E this will be a problem, as they only have an output for function A.
I then Enter the new decoder into its "slot" on the MX32
Loco screen -> shift + W -> basis panel -> slot number in top left corner e.g. #50 -> dcc pair = 13 , 1 -> W or A to save in to MX 32
Function button associated with no 50 on MX32 will now operate switch #50.
I do not understand how the MX32 command station gets involved here, so I'll leave that to someone else.
I believe that when I use the z21 app with a standard z21 that the command station just accepts and retransmits commands from the app (and syncs those commands to other apps). In the z21 case, the command station doesn't get involved in trying to reinterpret commands or remap their addresses.
Greg - does the MX32 have the facility to push layout configuration to the z21 app? Or could I actually just connect up the z21 app and then enter and run everything via the app without adding loco & turnout entries in the MX32, assuming that the various decoder CVs were already programmed correctly (via some unspecified tool that is not the MX32)?
I know that instances of the z21 app can be told to share layout configuration between themselves, but there is no current facility to push or load layout configuration to the z21 itself. To me, the only obvious way the MX32 could do that is if it masqueraded as a z21 app that other apps could copy from.
Now with turnout graphic #50 on Z21 driving screen set to 50 in the control station the iPad should operate the turnout.
If you set the z21 app to drive turnout 50, you are actually asking it to drive turnout 13.B. I'm pretty sure that the MX32 will just pass this along to the layout, rather than inferring that you actually mean a turnout with CV1=50.
Now, if you were using an LGB 55524 or LGB 55025 (output B), setting CV1=50 would do what you expect. If you were using a Massoth 8156101, then setting CV1 would do nothing useful, since Massoth allows the decoder to respond to locomotive addresses and uses CV1 (and optionally CV17-18) for their multi-function decoder roles. Instead, you would program CV34=50.
I don't think you've actually told us the exact model of decoder you are using, and that really,
really matters.
