Christophe,

Great work as always! Any chance you can add in other protocols like DCC and MM2? Essentially duplicating the functionality a Gleisbox.

Gopal

Hello @patnaik & @rhfil,

patnaik : Yes, it is of course possible to extend to the DCC and MM2, these are “just” extra lines of code that require you to spend a little time on them.

rhfil : The process of recognizing and assigning an MFX address is a little complex and needs to be understood.

In DCC, the locomotive address is “hard-written” into the decoder. This address can be modified by CV programming.

For MFX, the “short” address comparable to the DCC address is called Loc-ID by Marklin, not locomotive address but local address. MFX decoders also have an ID which, by definition, is unique for each locomotive. Two apparently identical locomotives, produced at the same time, can be distinguished from each other by their UID.

The UID - LocID pair is specific to each control unit and stored in the control unit. At regular intervals, the control unit sends requests to the rails using this UID - LocID pair.

If the locomotive responds, all is well and nothing more happens. If no locomotive responds, the control unit will send a UNBIND, forcing the locomotive with the UID to delete its Loc-ID, triggering a new identification by the control unit based on this UID-LocID pair.

So, when you go from one CS3 to another, it's a coincidence that the LocID assigned by the first CS3 is also the one registered in the second CS3. And if we go back to the first CS3, it will then create a new Loc-ID which may well be different from the one it had already assigned, because in the meantime it may have assigned it to another locomotive.

In reality, no two addresses (Loc-ID) are ever the same, because 16-bit DCC addresses are in the range 0xC000 to 0xFFFF, while MFX addresses are in the range 0x4000 to 0x7FFF.

So, for example, for address 3, 0xC003 for DCC and 0x4003 for MFX.

As I said, it's a bit complex, but not complicated.

Christophe

Dear Christophe -

I read the code for this project and have a few questions about it. Thank you for generously sharing it. Following our PM exchange, I hope that you can answer a few technical questions about it in particular, and differences between DCC and MFX in general.

1) If I read the code of the directMFX_ESP32 project correctly, you only use RMT for MFX output. There is no way to receive MFX input, and so to use the MFX protocol for loco discovery. Is this a correct reading of the code? If there is no way to read digital signal input from the rails, that also means that it is not possible to read CV values in programming mode.

2) I have been reading the DCC protocol standard. It is based on voltage level changes for specific durations. In it, there is no capability to read DCC signal input from decoders. Rather, DCC uses a completely different, current-based protocol in short intervals when track voltage is switched off to pass data back from decoders. I am sure that there are good engineering reasons for this choice (though it seems to me strange). Is that also true for the MFX protocol, or is that one of the mysteries of MFX that is still not fully understood?

Osoraku

Hello osoraku,

You have to distinguish between two things, programming and the main channel.

For me, reading and writing CV's must be done on a programming channel. kiwiAlan explained the principle well in DCC by current consumption.

With MFX too, CV's are programmed by modulating the channel signal. Only confirmation is by return of an RDS signal. This is the same feedback procedure as for MFX locomotive recognition.

As for the DCC, I think you're mixing up two things. When you talk about the track voltage being cut, you're referring to the CUTOUT, which is the window created by the central unit for RAILCOM feedback, and this is the main track.

Railcom, although it allows you (among other things) to read the locomotive address, is not comparable to MFX recognition. In the case of MFX recognition, once it has been achieved, it cannot be reproduced in general. Railcom, on the other hand, is based on the principle of identifying a locomotive in a given area every 100 milliseconds or so.

In MFX, there is no equivalent to Railcom for identifying a locomotive in a given zone.

For Railcom and the necessary equipment, please refer to an article I wrote here: https://www.locoduino.org/spip.php?article334

Christophe

Actually there is every reason that mfx could emulate Railcom, but I believe Marklin have not implemented this as they would fall foul of the Railcom patent.