Hi Kiko
I only have a medium size layout with 27 locos, 60 turnouts all simultanously connected, all are Märklin MFX except one Loksound 5 mini decoder.
All is controlled by a CS3 with a 100 Watt power supply (no booster).

When I have a derailment causing occasional shorts then, sometimes one or two decoders (always the same ones as if they were "weak") do funny things (start sounds, start moving) but I never observed a change of MFX registration except - rarely - when I install a new loco while all the layout is not connected with power on: the new loco may take an existing MFX number and the old MFX has to re-register but this is very rare (once a year or so).

Because I use Rocrail, I would notice immediately when there is a change in MFX registration # (because it won't work until I correct the loco registration# on Rocrail).

I understand that you are clearly an ESU person (ECOS, LokSound, etc) while I am clearly a Märklin person so it may explain the difference in MFX different behaviour.
Note: M4 ESU decoders are only very simplified MFX decoders with a very unfriendly editing of variables with a CS3 or CS2 (a nightmare really, so much so that I am shelving the only loco with an ESU decoder I have). The difference is with a CS2 or CS3 you can program 100% of decoders while with an ESU decoder you MUST use a lokprogrammer (I don't have).

So I may be wrong in my observations and I am not saying that Märklin is better / worse than ESU.
Cheers
Jean

Hello marklinist5999,

Thanks for your reply. Yes, you are correct in stating that interference plays a role in our digital systems. However, in my case I don't think that it's a case of interference because the problem affects only a few MFX locos and none of the LokSound locos. Hence my original question of whether this is a prevalant Marklin MFX problem.

Cheers,

I prefer DCC because i too did have problem by use mfx protocol. It doesn’t matter if i use Märklin trains or Trix. Both works better with DCC protocols. Did also tested with difference digital system.

Hello Alan,

Even though I purchase the multi-format variants of LokSound decoders, I only use them in DCC mode. When I talk about MFX I refer to Marklin decoders because currently all these locos run in MFX mode. So, in short: LokSound decoders run DCC and Marklin decoders run MFX. My original question relates to running the Marklin decoders in DCC mode.

Cheers,
Andry

Hello Jean,

That's exactly why I have both programming environments -- each decoder is programmed with its own programmer and software. Problem solved.

But, we're getting sidetracked. My original question is not about what is better or worse, it's about people with experience running Marklin decoders (MFX) in DCC format. I'd like to know their experience -- pros and cons -- so that I can make an educated decision before jumping head first.

Cheers,
Andry

Hello,

In my case, my digital central is an Intellibox IR, which does not handle the mfx protocol, I have many locomotives that have from 6080 decoders to the current mfx-dcc, and many multiprotocol lokpilot, and I use the Train controller to manage my layout, I use with priority the DCC protocol if possible, if not, the Marklin Motorola, the decoders that I like the least are the marklin mfx that don't have DCC, for me they are the worst, and occasionally they give me problems with the change of direction, sometimes they don't obey the command, and some friends have the same problem.
Regards

Translated with DeepL.com (free version)

Maybe a little off topic about the merits of MFX vs DCC but the comment in a previous post about mfx locos losing their registration caught my eye as a central part of the problem. I'm part way through developing a device to record the mfx signal coming from the controller, decode and display it. It can currently record about 2 minutes of traffic from the controller but enough is working for me to see that occasionally, at start up, a decoder will "get confused" for some reason and try to re-register - sometimes incorrectly. It does seem as if there could be a "bug" in the mfx protocol that some users encounter too often for their comfort.

My understanding from the MS2s I have (which could be completely wrong) is that each controller has a unique 32-bit address, as does each mfx decoder - these are burned in at manufacture and unchangeable (similar to a computer's MAC address). The controller also has a 16-bit reset counter that is incremented every time there is a factory reset. Thus, the controller on a layout is fully identified by those 48 bits - and each decoder knows it is on that layout by looking at those 48 bits. If you factory reset the controller, the reset counter will go up by one and every decoder will think it is on a new layout and try to re-register.

Anyway, at start up some decoders seem to misread the 48-bit controller identification and botch the attempted unnecessary re-registration. Here's a sample print out of the decoded mfx signal from early testing. The controller always lives at address 0 and its identification is shown as HQ-UID and HQ-CNT.



I'm also developing a carriage based on a 4411 chassis that can just be plonked on the rails to show the basic speed and direction information being sent to the locos.

I have also experienced this, and when also some ”Mfx address conflicts” also appeared, I finally decided to disable Mfx on my CS2. On ALL decoders where DCC is available (Märklin Mfx, ESU and everything else), only DCC is enabled now, leaving Mfx and MM disabled. I only have one older Märklin Mfx engine (from 2017) but DCC is enabled also on this engine, undocumented. I have a handful old ”MM only” Märklin engines, which requires both DCC and MM to be enabled on the CS2.

Now, I never experience any engine decoder issues!

My only drawback is that I have to be careful buying older Märklin Mfx engines, as they could have only the Mfx and MM protocols available.


On Märklin Mfx engines run under DCC, you may ”only” access the first 29 functions. I had to change the mapping of some functions on the SBB Giruno in another thread.

I use mfx where I can - ok, on the main layout it's M3 only so my locos will not discuss their mfx address with the central. But this seems to be a minor problem, and may appear more with non-Märklin centrals than with a CSx - just a supposition.
Clearly, DCC does not permit the address discussion between decoder and central, the highest possibility is to transmit automatically some information to the central via RailCom which is not actually implemented by Märklin, afaik.

In my opinion the opposition mfx vs DCC is lore or mess the same as between DOS and Windows, you remember?, or Windows vs Linux. DCC is a protocol that has grown since the late 80s, been blown up with number of new functionalities, but always with a regard to the beginnings : a 1990 DCC decoder has to understand modern DCC, and a modern decoder has to understand a 1990 central ! In the 90s, bit programmation was the best you could do, while Märklin rested on analogical hardware programmation... but now it's clearly vintage, so as no normal user will stay on his 1990 computer with black-green monochrome monitor and hundreds of commands to know for running little programs. Linux uses GUI, too !
Märklin Decoders are designed for mfx, so I use them in mfx. Others are designed for DCC, so I use them in DCC. Others have been designed for MM only, so... no choice no problem.

Just when onrailing a new loco, do it nearby the connection to the central, or even better make it connect to the central by onrailing it on the programmation rail, and then transpose it to the main rails - and do not forget that you must never onrail a loco when the rail is under current ! That's the cause for many issues, that we forget to unplug the rails before onrailing or derailing a loco.

There are pro and cons by use mfx or DCC protocol.
If you have and use MS2 you do have some problems by use mfx protocol with the locomotive while DCC protocol are more easer way by change value in every CV adress.
If you have CS3 you have complete control by use mfx protocol in every locomotive by Märklin because Märklin prioritize mfx.
Of course you can do with the DCC protocol too but i did find out that it is more easer by use MS2 if you shall use DCC by change value in every CV adress.
I did tested Märklins turnout decoder m83 by use DCC protocol and use mfx in the CS3 by search new article which are more easer way by set it.
Lenz digital plus are hopeless by program Märklins digital accessories!

I’m running DCC (or MM2) because Rocrail was pain with MFX. DCC is very somid and in my opinion trouble free. The only thing you have to do that is a bit of work is to assign function icons by hand.

-Eino

Simple...if you use Märklin system CS3 or and MS2 you have to add manual input if you use DCC protocol.
It´s the way of the system made of manufacture.

All my locos are mfx and with the CS3 have no bother. All register and off they go. My Piko MFX was also fine but the rest are Marklin. No other software etc which although might be boring for some I have no problems and just enjoy driving and using routes and CS3 facilities. I did use DCC in the past but now find it not necessary but it will depend on the locos you buy and their decoders.

Going back to the original question - are there any really good reasons NOT to run Marklin locos in DCC?

Marklin has been a leader in developing digital train control and deserves full credit for what they have achieved and how well it does work. However, it seems clear from this topic and other digging on the forum that some users do have issues with mfx misbehaving. Having created an mfx sampler that can record and decode over two minutes of mfx signal from the track I can see that an existing successful mfx registration is sometimes "lost" and various problems follow.

In my case, maybe once or twice a week, I have some locos that ignore all commands for up to a minute after starting the layout but then decide to charge off at some random speed. I notice that some locos seem completely unaffected while others feature more often with one 74 class that seems to be most affected. I only have a small layout, 10 locos and two MS2's - the problem is noticeably worse when dual MS2's are used. My GUESS is that it is a decoder firmware issue as the signals on the track always decode properly (look correct and pass the CRC test) with my sampler and look good on an oscilloscope.

Absolutely no problems when only DCC used.

---

For those with a morbid technical interest -

My commented Arduino sampler code and the interface diagram (plus some other rubbish) can be found on the cloud at - https://mega.nz/folder/U...A#xyaaqkKX0ypSpaHtTKZENw

This does not decode all the functions in mfx - just the main ones regarding registration and loco speed and direction - it was started out of technical curiosity about the problem, if I decide to go the DCC path then there's not really much point in extending it.

For those wanting to dig deep into the workings of mfx I recommend Stefan Krauss's site where you will find a great pdf. Site is in German but I've supplied him an English translation that can be downloaded from there.

https://www.skrauss.de/

My UNSUPPORTED WILD GUESS, as a retired electronic/electrical/communications/embedded computing engineer, is that the error correction protocol used in the decoders isn't robust enough in some situations. It uses an 8 bit cyclic redundancy count (CRC-8 CCITT, polynomial x^8+x^2+x^1+1 with a start value of 127) which would be good for burst noise and small errors but could possibly produce quite a few false positives across a noisy 50 or 60 bit data frame.

There was a decoder firmware release that would do exactly this as it did an mfx identification. It would be somewhere in the 2017-19 time frame IIRC. The T3 loco I have in my avatar picture had this problem.

You can find the history of decoder updates in clapcotts thread on cs2/3 updates and the decoder revisions that come with each one.

For your current locos I would suggest you find someone with a cs2 or cs3 and ask them to update your locos, and your ms2 while you are at it. You only need to update one ms2, any others you have will update off that one along with the track box.