From your later posts you seem to know: Too bad/lazy approaches in the controllers when it comes to registration, re-registration and parameter readouts.

Then of course it does not help the average user who does not build his/her own controller. The average user needs the whole system to work, not just the protocol.

When it comes to decoders, I have never observed any directly mfx protocol related errors in them. There is some odd behavior in the automatic recognition of operation mode (mfx, MM or AC) in some decoders but that is not directly related to the mfx protocol.



The second point here is a clue to most of the reported problems with mfx. When you delete a loco while the controller is on STOP, the controller can not invalidate the address in the deleted loco only, since it would require a ping with wrong decoder ID, and the ping command can not go through when on STOP. So, instead it increases the sequence number. Now all locos have their addresses invalidated. The stupid controller now starts re-registration of all the other locos, instead of just re-assigning the addresses to them. Completely unnecessary, I think. The controller knows all the decoder IDs already.

This is also a clue to another problem, where you no longer can reach a decoder. The controller thinks it must invalidate the address in the removed loco. Else, it would not have considered a change of the sequence number necessary after deletion of a loco when on STOP. But re-registration of all locos does not occur when the loco is deleted and the controller was not on STOP. This implies that the controller sends a ping to invalidate the address in the removed loco in that case. Now assume you have already removed the loco from the track. Then the loco will not see the ping, and its address is still valid. So it will not respond to a search. But the controller thinks the loco address is invalidated and will respond to search when it comes back on the track. Stupid controller. If it tries to invalidate the address in the decoder, it should check that it takes effect, by doing a search for the loco. If there is no response to that, the controller should suspect that the loco still has a valid address.

(See my previous post for an explanation of how mfx works.)

Many of my locos had to be sent to Göppingen. Many came back with a new decoder, leaving an orphaned entry for the old decoder.
This includes a few locos with Compact C Sine motor with the economized driver electronics.
Sometimes locos go back to the dealer because you're not satisfied.
Sometimes you upgrade a decoder and have to delete the old entry.

Knowing that deletion leads to mass re-registration I tried to avoid deleting loco. Still I had mass re-registrations.
Maybe the ESU documentation is not complete.

If you have older program,you cannot use mfx+ decoder with MS1 and MS2,by registration automatic.
It result error.
You must have at least version 1.83 to use mfx+ decoder.
With older system like CU6021,there is no problem to use locomotivs with mfx+ decoder.
The new mfx+ decoder do have some problems.

The whole concept of a "programming track" is only used in controllers I do not have. So I do not know exactly. I could see some benefits with a separate programming track with mfx, but it depends on how the controller makes use of it. Probably it is not so useful with the current controller implementations.

The programming track is necessary to change the CVs (internal memory settings) of the decoders. Examples where this may be used is to change the maximum speed of the locomotive, the volume of the speaker, the non-mfx address, or the acceleration and braking delay. When changing these values on my mfx locomotives I always put the locomotive on the programming track. This ensures that even if there are other locos on my layout, only the variables of the locomotive on the programming track are changed. To the best of my experience it is only possible to change these values when the mfx locomotive is on the programming track.

My programming track is part of my layout which is wired via a double pole switch that allows me to change the power source between 'programming' and 'normal running'. I am then able to program a loco by driving it to the programming section and throwing the switch.

I am one of the fortunate users who have not had any problems with my mfx locomotives. This might be because I only have a few locomotives to test the track laying on my layout as it is under construction. I am also using a CS2 and it appears that there are fewer mfx problems when a CS2 is being used.

Very interesting topic and good information about how mfx works or should work. I just wonder why I don't seem to have any re-registrations of my mfx locos even when they could have been in my display cases for very long time periods? I use CS2 60214 and I always have my locos on the loco list. I usually delete locos only when I sell them away or have some other peoples locos in my own CS2 loco list. There are anyway over 100 locos so I don't want that list to be any longer than what is really needed.

Offtopic: To help finding a loco from CS2 loco list I always modify every loco name like this: I start loco name with D (diesel), E (electric) or S (steam) to find them faster and this way the loco type is found in alphabetical order. Next the railway company like DB, DRG, SNCF etc. and then the series and road number combo like BR 39 048, BR 41 356... Followed by the Märklin model number in these cases 39390 and 37927 and after that the decoder address like 39 or 41. It makes my life easier.


Back to this mfx topic: I have not deleted a loco with track power off and without that loco on the track to be deleted. Now I will not ever do it that way in the future either when I read what can happen because of this.

Should these mfx things work then like computers getting their IP addresses from DHCP server and with a limited or unlimited IP address release time? Computers have MAC addresses to identify them. As mfx decoders are unique they can be thought to have each a unique MAC address. Is the "DHCP server" or the thing which remembers how long the controller remembers that unique mfx decoder "address release time" in our controllers or in the decoders themself?

Somehow this mfx protocol works also similar to multicast, broadcast and unicast in computer world. Maybe not as well it could in some cases though.

Just my thoughts...

Regards,
Janne

Thanks very much Tom. I have not been successful in reading the CV values to verify the update when on the main line. I will try again.

There is no timeout in the decoders at least. The decoder looks for changed controller ID and sequence number. and for ping commands with wrong decoder ID. Only these two events cause the decoder to invalidate its assigned address. And it is the controller who is responsible for causing these events.

Thanks for your fast reply. Why some people then have these re-registrations if their locos have been on unpowered sidings for long periods of time? Is this caused then by their controllers? They are not using CS2 controllers if I remember correctly. If mfx decoders don't have this kind of "memory" then the problems must be in the different controllers.

Regards,
Janne

Programming track is designed to be used for MM protocol (e.g. a fx decoder). If you try and change an fx decoder address with other loco on the same track you will mess up the other loco's as well. One of Marklin's sales argument for Mfx was that you are able to program on the main track (POM).

I so far had no issues with Mfx, but I also use a newer controller (CS2)

By the way if you have issues with registering when putting a new Mfx loco on the track, try and add manually a new loco and in the newer software version we now have a menu where you can trigger a new search.

As a last option try wiring some cables direct from track to the red/brown cable inside the loco. A faulty ground connection will never get the loco going...

Brgds Lasse

Please Goffy, stop these outbursts. It is possible to discus and debate without such.

Per.

I agree.. Behave Goofy!

I agree as well. I've said it before, Goofy, I'll say it again! Be nice! /BDNZ

Edited by moderator 05 October 2014 00:14:43(UTC)  | Reason: Not specified

And Perz has no right,by writing "Goofy" is guessing...
So i wonder who discus and debate with such.

The problem with mfx decoder is Märklins attitude.
They sucks!
I did learn my mistakes about locomotivs with mfx and mfx+ decoder and it´s never more shopping with Märklins decoder.
I wish Märklins analog locomotivs with 21 pole schnittstelle,so we customer can choise another sound decoder instead.
Mfx and mfx+ decoder=

You are truly staunchest Märklinist.
The real captain are Märklin,who teels to you,you are forcement to buy ours locomotivs WITH mfx decoder.
Possible to buy analog is zero.

You did start topic,by present "Why i dislike mfx..."
In this case,you must either accept by saying:Yes with mfx or No.
Mostley of Märklinist do like ESU decoder which are multiprotocol that i see better possible to decides what protocol customer want to use.
I don´t like registration automatic with mfx and mfx+.
I want to control byself to choise by start new locomotiv to reprogram adress and the name of locomotiv.
I want to change byself protocol of the mfx decoder,but it´s not possible because Märklin don´t like it when customer use other digital system with DCC protocol too.

Why should Märklin fix it,since they have same functionals year 2006...?
When you buy Märklin loco with mfx,you cannot change protocols.
If you buy Märklins competitors locomotivs 2 or and 3 rail,you have possible to choise protocols.
When you now write "functional",i suppose you don´t excuse by saying...it´s not that i meant!
Even 128 speed steps are totally unnecassary to use on the tracks.
But AUNT MÄRKLIN don´t care...

There should also be some warnings included in the instruction manuals of the controllers and mfx locomotives (or mfx decoders) how to avoid locomotive re-registrations. Like don't ever delete a mfx locomotive when it is not on the track and track power is off. This way many frustrating re-registrations could be avoided for other mfx locomotives that user has. With CS1, CS2 and MS2 at least some SW update to be able to delete a mfx loco without the need to have it on the track or on powered track section before this. Afterwards only this loco would automaticly re-register if needed when put back on track and not all mfx locos... Maybe it is totally impossible to bring up such an update if this is not "right way to do it with mfx protocol itself". Sorry my bad English ...

Perz has described very well how mfx protocol works and in my opinion there is nothing that Märklin could do to fix it to better except to have an update to fix that re-registration problem like described above if it is even possible.

Some mfx locos and decoders have bad running charasteristics, but I mean the mfx protocol otherwise than that. It just needs to be used "correctly" and these things should be really described better from Märklin. It seems like mfx protocols functionality depends strongly of the controller used. This mfx protocol should be possible to disable and have instead DCC enabled instead if needed because of this for example. Also individual sound file and sound level adjustments should be possible. It's unfair in my opinion if some controllers support mfx and a user then buys mfx locos and gets into trouble with them because the controller used is not "the right one" to work like it should with Märklin mfx decoders.

I think Märklin may just be too careful to avoid many messed up mfx decoders by users who don't know what they are doing to decoder CV settings etc. They have at least more open adjustment possibilities in their digitalising sets mfx decoders. That 60945 mSD steam locomotive sound decoder is like that.

Regards,
Janne

Perz also said "You may be right, but how could you know?"

His point is that you haven't used a scope or a protocol analyser to view all of the command structures to compare it against what should be happening, so your answer can only ever be conjecture.

There was no abuse directed at you by Perz, so you were not provoked in any way and should not have responded in the way you did.

For goodness sake, this is a Model Train forum, we are talking about Model Trains, not life and death issues. We should all act like adults and not get all upset when someone makes a comment we don't like!

ESU decoders cannot be used with many recent MäTrix locos because MäTrix locos do not have a NEM decoder socket. I won't buy an mSD to replace the factory-installed crippled mSD.

Exactly Tom!
Also an good point about to have analog locomotivs with NEM decoder socket,so customer decides byself to buy an sound decoder,in this case ESU.
But Märklin hates competitors and make sure to only produce digital locomotivs with pre install sound decoder.
I dislake mfx system,so long there is no possible to change protocols,speed step and map functions with MS2.
Also possible to use doubleheaded locomotivs with MS2 are missing too.

I'm not 100% sure, but it has been suggested that there are some incompatibilities.

That's what I thought.

These waters are muddy enough already, let's try to not add to the confusion....

So a mLD decoder worked, but a mSD didn't, both in the same MTC21 socket? Was this socket on a Marklin adapter board?

I wonder where ESU get the sound for a Br53? Synthesized from two 2-cylinder locos perhaps?

Yes, it was on the 21 pin mtc board that came with the mSD decoder. The mLD decoder worked fine when plugged into the same board. The mSD decoder, being faulty out of the box, only ran in a forwards direction. All sounds on the decoder worked fine, just reverse did not work.