Hi, Jens,

AFAIK mfx was designed to be compatible with DCC. Difficult to say who's to blame: the mfx design, the mfx implementation of the ECoS, or the DCC implementation of the unnamed turnout decoder.

mfx locos receive their addresses automatically, so I presume you do not know if it really is address 3.
With 2048 addresses for accessories, it should be easy to avoid address 9 (but other addresses may also be affected).

Some turnout decoders can be set to MM protocol. This would be an easy workaround.
mfx locos can be run using MM protocol (but normally limited to 9 functions per loco and 27 or 28 speed steps respectively).

I haven't heard of similar problems so far.

Tom makes a valid point. The "mfx" address is not 3. The "3" is the Marklin / Motorola address. This would be used by a 6021, Intellibox or other controller that is not capable of detecting "mfx" decoders.

Assuming the controller in question (ECoS) is capable of identifying "mfx" decoders (and the ECos is indeed capable of this), then the address being used is the unique "mfx" address. As such, the address of "3" would not be used (or transmitted) in this scenario.

Of course, it would be easy enough to test if this "3" is causing a problem -- just assign the decoder a different Marklin / Motorola address. My money says it won't make any difference.

Okay - thanks. That goes to show how little I know about mfx.
We'll have a go at it and see what changes.

Thanks, both. I'll be back.

Edit: Oops, we posted at the same time - Thanks all
Actually it's a BR80.

DCC and mfx signalling looks rather similar. DCC uses pulses of 58 and 100 microseconds, mfx uses pulses of 50 and 100 microseconds. A 50 microsecond pulse could be interpreted as a 58 microsecond pulse and vice versa, even if it is outside of the specifications for the respective protocols.

What should stop the protocols from getting confused with eachother is:

- The DCC message starts with a 14 bit preamble consisting of only "1"s. No decoder is allowed to accept a message with less than 10 preamble "1" bits.

- The mfx protocol has a rule that forbids more than 8 "1"s in a row, so that it can not look like the start of a DCC package.

- Th mfx protocol has a "code violation" pattern that indicates the start of a message. This kind of pattern is never sent with DCC.

- A DCC message has an 8-bit checksum at the end. Messages with wrong checksum should be discarded by the decoder.

- An mfx message has an 8-bit CRC at the end. Messages with wrong CRC should be discarded by the decoder.

If the decoder does its job properly there should be no risk for mixing it up. But if you make a sloppy decoder implementation you can certainly get interference.

I would expect the protocols had some means to avoid confusion, and sure enough - like you explain - they do.
I'm sure that in the end it will turn out to be a user error ...

If the DCC accessory decoder is programmable, it may have been programmed by accident. Maybe?

I believe the version is correct, yes.
It's a Märklin loco and a ESU SwitchPilot accessory decoder. No Viessmann stuff nearby. With the SwitchPilot address changed, the problem is gone.

Here, however, is an explanation (in German) of why this may happen if the DCC accessory decoder is not prepared to handle and ignore an mfx signal:
http://s1gf.de/thread.php?threadid=10384

The essence, as I understand it, is that an mfx "one" bit has both positive and negative edges in a period. If a DCC decoder only sees the positive edge (which is only necessary in DCC), then it may interpret the mfx preamble as a sequence of zeros and act accordingly.
Now, I still haven't analyzed this properly, but given the very good explanation and the fact that the problem is gone at my friends', I'll let it rest here.

Happy new year everyone

I have asked.
RailCom is not enabled