So how does MFX work!
No idea, but hopefully the simplified explanation below will provide a brief insight about how mfx® works, due to copyright restraints, and End User Agreements it is not possible to include any direct references to the actual details of the mfx® protocol.
As an aid to understanding, first a very quick run through of the basics of the DCC protocol.
Firstly the clue is in the name (DCC) Digital Command Control!
The DCC protocol defines signal levels and timings on the track.
The DCC command station creates the digital packet. Many command stations have an integrated booster which, in combination with its power supply, modulates the voltage on the track to encode digital messages while providing electric power.
The voltage to the track is a pure digital signal. The DCC signal does not follow a sine wave. The command station quickly alternates between 0 Volts and +22 Volts*, on the ‘A’ and ‘B’ rails, through what is colloquially known as a misapplication of technology via the ‘H’ Bridge, resulting in a modulated pulse wave.
One rail is always the inverse of the other, with each data pulse repeated. The length of time the voltage is applied provides the method for encoding data.
To represent a binary one, the time is short (nominally 58 µ), while a zero is represented by a longer period (nominally at least 100 µ). As there is no polarity, direction of travel is independent of the rail's phase.
In 2006 Lenz, Tams to name a few, started development of an extension to the DCC protocol to allow a feedback channel from decoders to the command station. This feedback channel can typically be used to signal which train occupies a certain section, but as well to inform the command station of the actual speed of an engine, known as RailCom.
So how does mfx® work?, simply replace the word DCC, and re read with the word mfx® it its place!
In a little more detail.
The rail signal consists of a square-wave alternating voltage. The polarity changes are used to transfer information. The same principle as used in Digital Command Control, a standardized and particularly common two wire model railway systems format.
The rail signal only changes with the timing (the actual timing differs slightly from the DCC timing period) of the polarity (0 Volts and +22 Volts*), however the polarity can remain the same for a fixed period of time. These timing breaks are used for the separation periods within the mfx® communication protocol, and are used to generate the feedback between the decoder and the Central Station. Refer to the reference to RailCom.
Data padding is used to insert extra bits (usually 1111) into the data stream in order to avoid certain bit patterns in the normal data stream, that could cause confusion with the data stream packets generated by a DCC system.
From a physical perspective, the rail signal is therefore compatible with DCC.
Therefore on the same section of track, DCC and mfx® can happily exist without any confusion to the decoder.
*0 Volts and +22 Volts are used as a general reference guide for illustrative purposes only, refer to the actual Central Station documentation for the voltage levels applied.
DCC User, why turn mfx® off?
Firstly to prevent degradation of the DCC Signal and to keep the maximum available Bandwidth for the DCC Signal.
If mfx® is on, the decoder will continue to Broadcast a mfx® protocol request, bit pointless using resources to look for something that doesn’t exist on a DCC system!
Secondly, as from the notes above the DCC and mfx® data signals are fairly similar, and given that most Users of DCC systems are at best haphazard, lackadaisical, slapdash, and prone to using under specified cable and wire, and often have shoddy and totally unsuitable cable connections, it’s little wonder the decoder gets confused trying to decipher whether it should be operating under the DCC protocol or the mfx® protocol!
Programming a mfx® decoder:
Details are listed within existing posts on this Blog.
First version, LGB 55028 available from early 2014, now discontinued.
The Leuchtturm Garten Bahn is DCC only, programming is achieved by using PIKO or Massoth DCC equipment, using the Navigator Handset to enter individual CV’s to Write or Read, or via a decoder template designed using the Massoth Service Tool software program, use of the Massoth PC Module and/or using the Massoth Service Board.
Second Version LGB 55029 available from early 2019 to present date.
Equipment as above, plus the addition of Marklin Programmer and the Marklin mDecoderTool3 software program, used in the main for creating new or modified versions of existing Sound Files for uploading to the LGB 55029 decoder.
The Marklin mDecoderTool3, whilst useful, it unfortunately is not the most useful tool to have if the primary protocol in use is DCC.
Their are a number of omissions, particularly troublesome is the ‘missing’ binary bits for multiple options for a number of CV’s.
Whist these missing bits of information are fairly inconsequential for a mfx® user, they can and do cause some major head scratching for the DCC User.
A reliable and recognised DCC System with a robust programming ability, to Write and Read CV’s, is therefore more of must have, than a luxury.
A DIY alternative available from the Authors and Designers of the DCC++EX system, far more useful and beneficial to a DCC User, than that often touted but seriously flawed JMRI combination.
From the Marklin mDecoderTool3, generating the .mdtp file, it is possible to interrogate this file and re edit the contents for uploading back to the decoder.
At present there is only one DIY option available, which can be used to directly access the memory locations within the decoder.
No further further details will be published, especially NOT a ‘How to Do It’, on the two methods mentioned above, they both require a detailed knowledge and first hand experience of the inner workings of the LGB 55029 Decoder Firmware.