Massoth- CS2/3 issue

Neil Robinson

Neil Robinson

Registered
Country flag
If you have a loco that runs O.K. on CS2/3 but not Massoth try running on analogue DC for a short time.
At the last East Midlands' GSS meeting I was approached by a member with a problem that was new to me.
He claimed his recent LGB/Marklin loco with factory fitted DCC and sound would run on his Marklin CS system but not his Massoth. He needed it to run on Massoth as he much preferred using the navigator outdoors to his tablet.
At the meeting, unsurprisingly It didn't respond to the group's elderly LGB MTS system even though the unit had been updated to parallel.
Having brought the loco home the "fix" was both surprisingly simple and discovered accidentally.
I tried it on analogue DC. Initially it didn't move but it started to respond when I reversed the power. It then ran as it should on analogue. What's more it then ran properly with my Piko DCC system.
 
Useful to know, Neil..... I wonder if this is related to the recommendation that you run a new MFX-chipped loco on the default address (3) under DCC control before attempting to change the loco address, which appears to "tell" the decoder to expect DCC commands - if the person you mentioned above ran the loco on his CS2/3 first, that may have put the decoder into its MFX mode which could be why it then wouldn't respond to the DCC commands from the Massoth system. Maybe running it on analogue somehow "reset" this.....?
All speculative of course, it seems there are more quirks to this MFX malarkey than Marklin tell us about.....

Jon.
 
New one on me - as Jon says, the running on Massoth address 3 seems to now be well known and accepted - but god only know why! But not running on Massoth after CS3 is a serious limitation for garden visits. Up until now, at least decoders seemed cross compatible between manufacturers.
 
This isn't so much about decoder cross-compatibility between manufacturers, it's more a problem of running your locos under different digital protocols ie. NMRA DCC and Marklin MFX. The decoder can handle both but as has been mentioned, the Marklin decoders seem to like to settle on one protocol or the other when first addressed, and remember that setting. It probably avoids the firmware having to keep re-checking which protocol is in use, which would likely affect responsiveness to commands.

Handy to know that plonking on analogue triggers the decoder to revert to hunting for the protocol.

There are plenty of other multi-protocol decoders out there in the small scales (eg. run on DCC or Motorola formats), but I don't know if they behave in the same way with regard to determining and remembering which protocol.
 
Up to a point Nick, A DCC compatible decoder should be just that. I would return mine if i found the problem described above. Not fit for purpose.
 
Zerogee said:
I wonder if this is related to the recommendation that you run a new MFX-chipped loco on the default address (3) under DCC control before attempting to change the loco address, which appears to "tell" the decoder to expect DCC commands - if the person you mentioned above ran the loco on his CS2/3 first, that may have put the decoder into its MFX mode which could be why it then wouldn't respond to the DCC commands from the Massoth system. Maybe running it on analogue somehow "reset" this.....?
Jon.
Click to expand...

That matches my thoughts Jon.
Apparently the loco ran fine on MFX with its address changed to five.
The fun started when the owner decided he preferred to use his Massoth system as he found the Navigator easier to use, especially outdoors.
 
stockers said:
Up to a point Nick, A DCC compatible decoder should be just that. I would return mine if i found the problem described above. Not fit for purpose.
Click to expand...

A very fair point.
However in this case the decoder was inclusive with a brand new loco.
I'm unsure if all variants of LGB/Marklin's current locos are available without decoders. Even if they are I suspect some prospective purchasers wouldn't fancy any perceived hassle of aftermarket decoders.
 
I am aware of returns of locos to two different UK vendors. All power to the customers - only one way to kick the manufacturers. I feel sorry for the vendors though.
 
You don't need an aftermarket decoder Neil. You require the manufacturer to provide what they advertised - MFX, DCC compatible.
 
Would be curious to know, if the same problem occurs in reverse, Massoth to MFX, suspect the default is use "our" equipment.
 
stockers said:
... You require the manufacturer to provide what they advertised - MFX, DCC compatible.
Click to expand...

Yeah but the decoder is DCC compatible, it's only a problem where the owner wishes to run with different protocols. If indeed it requires some form of reset when you change from one to the other, then I'd agree it's not at all user-friendly. Of course it's typical for a manufacturer to neglect this sort of thing in the documentation - not considering users may want to change protocol repeatedly.

If you google around you'll find evidence of the same sort of problems encountered by users of Marklin multi-protocol decoders in other scales, yet I've yet to find anywhere else mentioning this "discovery" about resetting on analogue or the decoder learning/fixing which protocol on first use.

No Gold Star for Marklin on this one - could do better!
 
Does make you wonder if any 'features' will come to light with the Piko central station and controller..
The CS being manufactured by one company, and the (hand) Controller by Massoth. :wondering:
 
From what I understand, the "corporate push" to LGB is to support MFX first, since this is Marklin's game plan.

I'm not at all surprised that the decoder sort of "locks on" to the MFX protocol, and then becomes "deaf" to DCC. I'm not an expert on MFX, but I understand the method of data transmission is similar enough that once the decoder is in a "digital mode", it would be hard to switch between MFX and DCC. Makes sense from a hardware and software standpoint.

Greg
 
The following is provided for information, further reading of the subjects covered are provided in the links……………………..


upload_2017-5-8_12-19-32.png​

There are two pulses of different lengths, 100 and 50 microseconds. the long pulse, the logic 0 and the short pulse, the logic 1 (as with DCC).
Where as DCC the pulse train is always in pairs, in the mfx format it is as a single pulse regardless of whether a pulse is positive or negative, it is only the duration of the pulse that determines what is a 1 or what is 0.

Märklin/ESU mfx command structure.

The command consists of 4 to 10 bytes, and sends one mfx packet. Byte 0 is the command code. Byte 1 contains the length of the packet(in number of bits, excluding flags, CRC and bit stuffing).

The following two to eight bytes contain the train command data. The data is sent msb first within bytes. Any remaining bits in the last byte of the command are ignored. The start and end flags as well as the CRC and bit stuffing are added by the additional driver command, and should not be included in the mfx command structure.

The mfx packet is transmitted repeatedly until a new command is given.

Command mfx once.

Similar to above but the command is not repeated. Instead, a Märklin idle packet is sent repeatedly after the command is completed until a new command is given.

This command also allows several concatenated mfx packets, up to a maximum total command size of 32 bytes. Each mfx packet starts with one byte containing the packet length, and the following bytes in each packet contain the packet data.



upload_2017-5-8_12-19-32.png​

These consist of long pulses of 100 microseconds, and short pulses of 58 microseconds.
A long positive and a long negative pulse equals logic "0".
A short positive and a short negative pulse equals logic "1".
The problem of voltage reversal is simplified, as the decoder only checks the positive pulses. If the signal is reversed the same checking of the sequence of short and long pulses continues, so the sequence of ones and zeros, remains the same.

DCC command.
The command consists of 3 to 6 bytes. Byte 0 is the command code, and the following two to five bytes contain the train command data. The train command is sent msb first and byte 1 first. The preamble, start bits, error detection byte and packet end bits are added by the driver command and should not be included in the DCC command structure.

The DCC packet is transmitted repeatedly until a new command is given.


Bus Communication..............mfx....................DCC

mfx is a two-way communications system that ties devices related to the layout together or to a central management station. DCC as per the original NMRA standard is as such not a communications bus, because it’s essentially a one-way system despite some minor feedback capabilities.

The revised NMRA standard now includes and makes provision for a communications bus, recently renamed Layout Command Control (LCC).

S-9.7.x Layout Command Control (LCC) (02/20/2016), http://www.nmra.org/index-nmra-standards-and-recommended-practices

Further reading on the structure of mfx communication, (and revised NMRA) with reference to the CAN Bus, https://en.wikipedia.org/wiki/CAN_bus, and the the User Datagram Protocol (UDP), as used by mfx, http://www.erg.abdn.ac.uk/users/Gorry/course/inet-pages/udp.html
 
Last edited by a moderator:
railwayman198 said:
So if I buy a new MFX fitted loco and run it from the outset on my Massoth system without changing the address will everything work as it should including sound functions? I ask because P&S hobbies site states that 'please note it will require CV knowledge to work on non MFX central stations'. https://www.pshobbiesandmodelshop.c...-p-5879.html?sesid=msu64f3vji421v39v4rhbbh3n1
Click to expand...

I'm sure others will reply soon who have more direct experience - but as I understand it, yes - run it first on your Massoth-controlled track as address 3 (default as supplied) for a few minutes, and then (if you need to, of course) change the loco address by rewriting CV1, NOT by using the normal "change address" procedure on the Navigator (because doing that changes some other things as well as the actual address).
I'm assuming that it is probably the bit about changing the address that P&S are referring to.....

Jon.
 
Zerogee said:
I'm sure others will reply soon who have more direct experience - but as I understand it, yes - run it first on your Massoth-controlled track as address 3 (default as supplied) for a few minutes, and then (if you need to, of course) change the loco address by rewriting CV1, NOT by using the normal "change address" procedure on the Navigator (because doing that changes some other things as well as the actual address).
I'm assuming that it is probably the bit about changing the address that P&S are referring to.....

Jon.
Click to expand...

Jon is basically correct..
The Massoth Navigator / CS combination changes a number of things if you use the 'change address' function. - Which fails if writing to an Marklin/MFX decoder..
This means you have to change CV1 (for short addresses).
For long addresses, you need to 'long-hand' work values for the CV's..
 
I have 3 LGB locos that came with factory-fitted MFX decoders. I ran them "out of the box" on my layout (using Massoth 1200Z) to check they worked ok before I changed their addresses and adjusted the "protocol" CV that sets the decoders to use DCC rather than MFX.

To date they've all worked as expected - responded to the new addresses and all function keys did what the handbook said they should. Whether this is down to me accidentally following the advice above or maybe just being lucky I can't say, but hopefully my experience provides some reassurance.
 
You must log in or register to reply here.
Back
Top Bottom