LGB/Marklin new stock with Marklin decoder - ?problems?

AustrianNG said:
I left my 22930 well alone - I have a Navigator MTSIII combo so all loks are on short addresses. It's no use Märklin expecting customers not to change the addresses of their locos at least.
Click to expand...
I have several new Marklin locos with the mfx chip and sound. I also run them on the CS2 Central Station which recognises them instantly, I think that each chip has a unique identifier code which the Central Station identifies. There is therefore no need to set the address of the loco. This may well be the reason that Marklin is not expecting customers to change the address.
 
I finally took everything out of my Rhatia and installed a Zimo MX699KV. It now sounds and works great. Lights and smoke all work the way they are suppose to. All in all I am very happy with the loco. Next engine I get with the socket I will try the Zimo MX699LS. By the way I have a massoth XLS M1 minus the speaker available very cheap.
 
Mike -
So if you have 3 or 4 locos on the track without changing their address and they are all addressed "3" what happens ?
(Have i missed something?)
 
tell no.3 to move backwards they all move backwards..
 
AustrianNG said:
See post number 41 above Mike (The one that Mike the Strong made).
Click to expand...
The mfx system from Märklin is a two way protocol which allows the central station (CS) and the mfx-decoders to negotiate an individual loco address for each loco/decoder. This is not the loco address stored in the traditional CV, so effectively each loco (which all very well may have CV1 set to 3) will have a different mfx loco address. In addition to the negoatiation of the loco address the mfx-system allows the loco decoder to report all functions to the central station (CS), which will be displayed and can be selected on the CS.
 
If the decoder is NMRA compliant then you will be able to change the address using CV1 directly. The Navigator option to change the address via a shortcut may not work tho.
Most digital systems these days have some form of decoder identification built in either a proprietary one like Marklin or Railcom etc.
 
Loco said:
The mfx system from Märklin is a two way protocol which allows the central station (CS) and the mfx-decoders to negotiate an individual loco address for each loco/decoder. This is not the loco address stored in the traditional CV, so effectively each loco (which all very well may have CV1 set to 3) will have a different mfx loco address. In addition to the negoatiation of the loco address the mfx-system allows the loco decoder to report all functions to the central station (CS), which will be displayed and can be selected on the CS.
Click to expand...
This is one of the reasons that I changed from MTS2 to Marklin CS2 to ensure compatability. I have no problems in loading Massoth Chipped Locos into the CS2. I rather like the way in which you put an mfx chipped loco on the track and it is instantly recognised by the CS2 - no need to change addresses.

Regards

Martin
 
MTheStrong said:
This is one of the reasons that I changed from MTS2 to Marklin CS2 to ensure compatability. I have no problems in loading Massoth Chipped Locos into the CS2. I rather like the way in which you put an mfx chipped loco on the track and it is instantly recognised by the CS2 - no need to change addresses.

Regards

Martin
Click to expand...


Possibly a silly question, Martin - but just to be clear - I'm assuming this ONLY works with the new MFX decoders? If you have anything with an older MTS or any other DCC decoder, you presumably still have to load everything about it (including the loco address) manually into the CS2 in the same way as we have to do now with Massoth or any other system?

Jon.
 
Zerogee said:
Possibly a silly question, Martin - but just to be clear - I'm assuming this ONLY works with the new MFX decoders? If you have anything with an older MTS or any other DCC decoder, you presumably still have to load everything about it (including the loco address) manually into the CS2 in the same way as we have to do now with Massoth or any other system?

Jon.
Click to expand...

Not a silly question..
You will need to input information to the CS2 for DCC only loco's..
The CS2 will try to talk to a loco using MFX first, then MZS (Marklin-speak for MTS/DCC).
An MFX decoder will look for MFX protocols and respond to them before DCC. - You can turn off support for either protocol on an MFX decoder.
 
Zerogee said:
Possibly a silly question, Martin - but just to be clear - I'm assuming this ONLY works with the new MFX decoders? If you have anything with an older MTS or any other DCC decoder, you presumably still have to load everything about it (including the loco address) manually into the CS2 in the same way as we have to do now with Massoth or any other system?

Jon.
Click to expand...
Hi Jon,
The CS2 recognizes the MFX decoder instantly. For other decoders, eg Massoth, as you write, , you upload the decoder information to the CS2. When the decoder is read you have options on the CS2 to identify as DCC, MM etc.

Regards

Martin
 
AustrianNG said:
I left my 22930 well alone - I have a Navigator MTSIII combo so all loks are on short addresses. It's no use Märklin expecting customers not to change the addresses of their locos at least.
Click to expand...
Sadly for me the LGB MTS offer of 1-21 (or was it 22) does not work for me. With a regular changing diet of different Timetable Operators, the last two digits have to be used to ID the Loco. That has meant on occasion making up dodgy Loco Numbers to ensure that the Check Digit can be used as part of the ID. So long as they fit a Germanic Scheme I am happy. Needless to say all my Genuine Harz Locomotives have the correct numbes. Sometimes renumbereing and modifying to a different Animal to get what I want.
JonD
 
The NMRA CV concept in it's present format has some disadvantages, dealing with a collection CV's such as CV 29 with its binary format is complicated, whilst only being able to enter one value is cumbersome.

Due to an oversight the NMRA had simply forgotten to define a mechanism for providing feedback from the decoder to the command station regarding the supported CV's, thus it is not possible for the command station to find out, which CV's a decoder supports.

With the introduction of the mfx® system the user does not have to deal with CV's, values and the binary system. The command station should rather request the decoder to provide this kind of information and then enable the user to enter any values in an easy way on the graphic interface.

For instance, you do not have to enter the value 15 in CV 3 on an mfx® capable command station but rather set the acceleration time to 10 seconds. Thanks to mfx® you do not have to remember that CV 3 contains the value for the acceleration time and that the value 15 is equivalent to about 10 seconds. This kind of complex technology is hidden in the mfx® command station.

Therefore the mfx® system does not cater for a direct method of influencing the memory spaces, the so-called mfx® configuration area of the decoder. Generally, mfx® only permits access via the command station.

This method has only one drawback. How can the owners of other command stations that are not mfx® capable access the configuration area? This is facilitated by means of a register concept that is somewhat similar to the NMRA DCC CV's.

Unfortunately this does not provide access to all characteristics of the mfx® decoder and you will find that not all the decoder parameters can be accessed with a non-mfx® command station.

Therefore mfx® decoders cannot be programmed with a pure DCC command station since the parameters can only be accessed with either the mfx® or the Motorola® protocol.

The User is recommended to read thoroughly any accompanying documentation supplied with regards to which CV's can be altered, paying particular attention to any “Formula” that may be required to allow a value to be entered into a CV on a mfx® decoder, for example, all values have to be multiplied by 4, as a values of 0-255 are not recognised.

Depending on which revision of the decoder is fitted, and as to whether the provided documentation is correct for that particular decoder, CV 50 could in some revisions be altered, but generally the answer is now no, the accepted standard is fixed as mfx® first and foremost, and then NMRA DCC.

By default the decoder expects a data signal in an mfx® protocol, if such a data signal is not present will then revert to accepting an NMRA specified DCC data packet, and as such will behave as DCC, but without the mfx® protocol that is required to fully access the inner workings of the decoder.
 
Very useful info there.
My control kit 'talks' Motorola as well as DCC, you pick which protocol to use with each decoder when you set the loco up. It would be interesting to see how it works with an MFX decoder if anyone wants to bring one over when the weather eventually picks up!
 
Arthur Aardvark said:
The NMRA CV concept in it's present format has some disadvantages, dealing with a collection CV's such as CV 29 with its binary format is complicated, whilst only being able to enter one value is cumbersome.

Due to an oversight the NMRA had simply forgotten to define a mechanism for providing feedback from the decoder to the command station regarding the supported CV's, thus it is not possible for the command station to find out, which CV's a decoder supports.

With the introduction of the mfx® system the user does not have to deal with CV's, values and the binary system. The command station should rather request the decoder to provide this kind of information and then enable the user to enter any values in an easy way on the graphic interface.

For instance, you do not have to enter the value 15 in CV 3 on an mfx® capable command station but rather set the acceleration time to 10 seconds. Thanks to mfx® you do not have to remember that CV 3 contains the value for the acceleration time and that the value 15 is equivalent to about 10 seconds. This kind of complex technology is hidden in the mfx® command station.

Therefore the mfx® system does not cater for a direct method of influencing the memory spaces, the so-called mfx® configuration area of the decoder. Generally, mfx® only permits access via the command station.

This method has only one drawback. How can the owners of other command stations that are not mfx® capable access the configuration area? This is facilitated by means of a register concept that is somewhat similar to the NMRA DCC CV's.

Unfortunately this does not provide access to all characteristics of the mfx® decoder and you will find that not all the decoder parameters can be accessed with a non-mfx® command station.

Therefore mfx® decoders cannot be programmed with a pure DCC command station since the parameters can only be accessed with either the mfx® or the Motorola® protocol.

The User is recommended to read thoroughly any accompanying documentation supplied with regards to which CV's can be altered, paying particular attention to any “Formula” that may be required to allow a value to be entered into a CV on a mfx® decoder, for example, all values have to be multiplied by 4, as a values of 0-255 are not recognised.

Depending on which revision of the decoder is fitted, and as to whether the provided documentation is correct for that particular decoder, CV 50 could in some revisions be altered, but generally the answer is now no, the accepted standard is fixed as mfx® first and foremost, and then NMRA DCC.

By default the decoder expects a data signal in an mfx® protocol, if such a data signal is not present will then revert to accepting an NMRA specified DCC data packet, and as such will behave as DCC, but without the mfx® protocol that is required to fully access the inner workings of the decoder.
Click to expand...
Hi AA,

Many thanks for your very detailed explanation. This is most useful.

Regards

Martin
 
... which is all very well and definitely an improvement over the NMRA DCC protocol, but Maerklin needs to be very careful not to alienate a significant portion of the market by not fully supporting NMRA DCC which is out there as a widely used standard. Granted Maerklin have always liked to go their own way, but for me this is not a good sign. They need to market versions of models without the MFX chip.

By the way, probably best to credit that Arthur Aardvark's explanation above is lifted from the LokPilot V3 manual.
 
Last edited:
Completely agree Nick, Maerklin do seem to be disregarding the investment a lot of people have made by offering a product that can only be fully used by purchasing new control kit.
Whilst decoder ID is a fairly standard part of DCC systems now to use a system that is non compatible seems short sighted to say the least.
 
shropshire lad said:
Completely agree Nick, Maerklin do seem to be disregarding the investment a lot of people have made by offering a product that can only be fully used by purchasing new control kit.
Whilst decoder ID is a fairly standard part of DCC systems now to use a system that is non compatible seems short sighted to say the least.
Click to expand...
I think that it is important to consider that the MTS system was reaching its sell by date. Technology has moved on apace and,certainly from a german perspective, there has been a significant desire to enhance the model railway experience. From a business point of view too there would be little to be gained from prolonging out of date technology. You can of course continue to run your existing stock using propriety equipment. However it is fully understandable that many users will want to use the latest technologies - hence Marklin's position.
 
You must log in or register to reply here.
Back
Top Bottom