It is a mfx decoder so if it has been on the track of your CS3 it is already registered. Please check your list of locomotives, and see if there is a name which is matching.

mfx locos register automatically and negotiate a unique address with the controller. Make sure mfx is enabled in the CS3 - it is on by default.
Just find the loco in the loco list on your CS3.

Yes, at times tempermental. You don't need to register MFX locos on a programming track. Doing so (am I correct Jean)?- can possibly change the address or settings on already configured items like signals or turnout decoders. I read this in the new updated CS3 handbook yesterday.
If your loco list is large, one or more can possibly not show on the list. You can search for lost MFX items then.

as an idea you could unplug the main track, from the CS3, for this loco to load ?
What I mean is:
1) remove power to main track
2) attach a section of track to main track output of CS3
3) place loco on this fake main track and see what happens ?

I do not have many MFX locos, fortunately, but when it becomes an issue I delete all MFX locos from my EcoS and reload them one by one.

Just some ancillary comments

A curious observation that I will take on board.
The TFP(GFP) is meant to be a separate processor that I would have expected to be insulated from the async activity of the ethernet. And while the ethernet is reflecting the registration traffic, it is just UDP and not waiting for a reply.

? Are you perhaps referring to ethernet traffic from a layout control program?


In operational mode the programming track is similar to the main (all be it reduced power) - it is only when you actually "do programing" that the port switches to drive differently (in the CS1 you could actually hear a relay switch in)
In this sense mfx registration and even mfx/CV changes is not programming as such - programming refers to the MM/Reg , non-POM DCC/CV and firmware updates of a decoder.

That said, (poor) wiring (connections) is probably more of an issue than number of other mfX decoders. But NON mFx decoders would have an influence.
During the registration any mfx decoder should be quite silent during the feedback window, it is nonmfx decoders that will continue to present a load.


And just to be clear the feedback signal of a mfx decoder is not the decoder "driving/sending" a reply, but modulating (selectively loading/sinking) the feed from the controller which, at the time of a registration process window is not "fully driving like a fire hydrant" but "driving and listening"

the ability of decoders over the generations of technology to crisply sink and modulate may mean that the programming output (reduced current) is better for some , but not enough for others

It may be counter intuitive but one of the first things to pay attention to when putting a new loco (mfx decoder) onto a new controller is to observe that it immediately stops (if it was left with a speed setting on its prior controller). This happens because ever decoder knows/remembers its latest controllers signature ID (serial number) and, because a new controller is constantly sending its own ID with every packet, the decoder quickly (within secondss) says to itself "Whoa - new boss - better stop and wait for further instructions".

This generally is seen only with the motor stopping, it would be nice if the lights and certainly the sound also turn off until after registration to remove their power drain. If you loco does not turn its lights and sound off (because you left them on on the last controller) you may ant to return to the prior controller and specifically turn them off.

But again, as a debug tool, you might deliberately leave a loco/decoder "wound up" (from its old controller) just to ensure it does stop on the new controller -thus indicating that it is at least sensing a mfx command in the data stream.


It is then a separate process for the controller to - once every 30 seconds (so wait and count slowly) - put the call out "is there anybody new out there".
i.e. the new loco does not just hop on the line and shout "I am new here", it must wait to be asked.
Only new decoders will respond as existing ones will know who there controller is.

At this point it is definitely a hinderance if you have put more than one new decoder on the layout, as this will invoke another level of tie-breaking logic and slow the whole process down.

As a side comment , I would highly recommend an un-smoothed LED connected (with current limiting resistor) to the track power feed, as a human visual aide/guide for observing the flickering patterns of the track pulsations. It does not take long before you can discern the difference between the patterns of ongoing idle chatter, the busts/pause of the 30 second poll and the intense feedback traffic when getting data returned.
If nothing else it helps communicate to people that the registration can take "a while" to even start.

As a closing comment on decoders behaving badly. Experience from other life - not specifically trains/mfx
A single decoder/device on any bus can sometime "not shut up". While it may quite happily be doing what it is actually told and seeming to work ok, when you are attempting to send to a different decoder/device it will not get "off the line".
Unfortunately technology changes - especially timing tolerances - come in to play.



If anyone has experience with very early decoders/locos registering on a CS1/ECos but not a CS2/CS3 I would like to hear if you think it is speed related
(The CS1 was a lot more measured in its discovery and I wonder if the older/original mfx decoders cannot cope with the CS2 rate of command requests)

Edited by user 03 July 2021 13:14:03(UTC)  | Reason: Not specified

That's true.
But with CS2/3 the programming track output has its own transistors and the feedback from the loco to the controller should be cleaner on the programming track if there is a lot of rolling stock on the main track.

In my experience it is very convenient to have a transition between main track and programming track, with insulation of both centre and outer rails. The CS3 book says you may not have such a transition. Take care when you have such a transition.