Can someone please explain to me what the major difference between mfx an d DCC is?

Probably nothing.
It´s functions inside byself how you want to control locomotivs with difference motor too.
Märklin could have choise DCC protocol as standard too when they did start an new digital system.
But they didn´t and did choised what they expected.
I don´t believe mfx anymore time,so i have and did learn my lessons.

Hello Kimball,

PM sent.

Hi Svein,

Perhaps I can help with a very simplified explanation, as I understand it. I am not a digital expert and don't really know or want to know the fine detail of the protocols.

The original digital standards for control of model railways was developed by Lenz in conjunction with Marklin. Both the original Marklin digital format and DCC are developments of Lenz's protocol. Marklin's circuits were produced by Motorola, hence the use of the term Marklin Motorola, or MM for this system. Electronically, both digital signals are similar.

Marklin's original system was developed after about 10 years into the MM2 format, which allowed more functions. These were labelled by Marklin as being "FX" decoders.

In contrast, DCC was continuously developed over the years to the standard we see today. This is because the protocols are open for anyone to use, so many small companies produced improvements. It overtook the capabilities of Marklin's system to provide a greater number of addresses, functions, etc.

In the Early 2000's Marklin needed a way to improve the digital product and, if possible, leapfrog the capabilities offered by the cometitior DCC system. Together with ESU they developed the MFX system, which offered greater numbers of functions, virtually unlimited addresses, and for the first time the ability of locomotives to register themselves on the controller, which meant that the operator did not need to remember the locomotives address, or what functions were available, as these were displayed on the screen after automatic registration.

ESU and Marklin fell out over the development of the system. I won't go into detail why, but I believe no one party was at fault. There were shortcomings on both sides of the partnership. Marklin retained the rights to MFX and used other companies to produce the hardware needed to continue the system. ESU retained the right to use the MFX protocol in their decoders and controllers.

Developers of DCC then saw that the auto-registration features of MFX were a serious advance from their competitors, so they also developed a similar system, which was named Railcom. The way the similar functionality is derived is, I believe, completely different to how ESU developed the MFX system for Marklin.

The position as it stands today is that we have Marklins (and ESUs) MFX system, with auto-registration, about 16 or so functions, and unlimited addresses which are invisible to the user.

On the other side we have the DCC standard, which now also has Railcom's auto-registration, though this is not available in all controllers. DCC has a greater number of functions (about 25?), and virtually unlimited addresses, though these have to be specified to the controller.

My feeling is, and I don't have any numbers to prove it, that traditional Marklin users have adopted the MFX system in good numbers and welcome the increasing numbers of locomotives available to use with either their Central or mobile stations. DCC users, the majority of whom are from a 2-rail DC background, continue to use DCC as implimented in various brands of controller, but are probably slower on the uptake of Railcom compared to MFX users.

This post represents how I view the digital control story, and I may or may not be perfectly correct in any or all of my statements. It's just an attempt to answer Svein's question about the differences between MFX and DCC.

I think there are two reasons for this. The main reason is that it really does not matter. On most DCC systems I can just punch in the address and off I go. The other reason: To fully take advantage of RailCom I need a RailCom detector. These are truly expensive (the ECoS Detector with only four RailCom ports cost around 180 € (245 USD). At these prices I can live fine with "old school" detection.

And just to clarify: It is my experience that some people (not necessarily in this forum) think missing software update features and bad motor control is a disadvantage of Mfx. It is not. These issues are caused by limitations in the decoder and firmware. They have nothing to do with the protocol. You can buy DCC-decoders that perform equally bad, and are equally difficult to adjust as well.

On my layout I have both Mfx (for testing purposes) and DCC (most locos are DCC). I have not had any problems with my Mfx test machine.

My main issue with the built-in decoders is that they seem to be inferior to the ones I can go out and buy (Mld, Msd, LokPilot etc.). I think this is much more important than Mfx vs. DCC which to me is like a discussion on English vs. German. IMO: If the decoder gets the job done, it does not matter what language it speaks.

That being said: I do think that Märklin should be more open to the fact that DCC exists. I think they are slowly getting there. I think the original intend is not to lock people in, but to deliver a system that "just works". I think the easiest way to do this, is to control every single aspect of the hardware and software. This will work for the majority of the customers, but of course it will cause problems for those who want to do more. Märklin could perhaps deliver the locos with DCC disabled, and Mfx enabled. Every guy with a DCC system, would be able to change this in a heartbeat and everybody would be happy.

As David stated, ECoS 50200 has Railcom+ hardware embedded into the controller. Older controllers like the CS1R will support Railcom+ with a software upgrade and then the external hardware (booster) you must purchase. It isn't an "extra" you must buy so much as an upgrade you must make if your controller predates Railcom+.

No problem for me, as I have no plan to add further manufacturers to my collection. I have four non-Märklin models only (2x Roco, 1 Brawa and 1 NMJ, all fitted with Märklin decoders.
I have a very simple philosophy: When I play with Märklin, I stick with Märklin. I have to admit that I have installed five ESU M4 (both v3 and v4) sound decoders, due to their programmability and available project files.

Thanks Tom, I might try that next time I need to program a Piko loco. I originally tried to disable the DCC, but I couldn't find how to do that in the instructions that came with the loco. Are the CVs that select the protocols the same as on a ESU decoder?

Excuse me, but you have no idea why I modified the poll, and I'm certainly not impressed by your comments, both towards myself, and Ray for starting this poll. Just because you are in a grump with life, please don't take it out on everyone else!

Hi Mulldog,

In fairness, polls can be useful.
I think that "polls" by their very nature, will elicit divergent views, and this sometimes leads to extremes on either side.

regards
Kimball

I'm not sure why a simple poll seems to be generating so much angst among members, but I think the time has come to lock this topic.