The address that shows on a CS2/CS3 in the locomotive edit pages is just a "marker" so to say. The CS assigns this marker for indexing purposes so it can sort in a search like sorting the locomotives by address.

To see or edit the actual MM (default) address you need to get into the configuration screen and look in the "Formats". There it will give you the "MM2" address, which is what a 6021 uses.

Rick

Thank you both 😊

Hi Mark,

I took upon me the challenge to make a MFX controller by myself. So no Gleisbox and/or Central Station, really build it yourself. I'm using an ESP32 and a DFRobot motor driver board (https://www.dfrobot.com/product-1512.html) to drive the decoders. Since I don't have any digital trains, only old analog trains, I bought a DHG700 MFX lokomotive and a LokPilot 5 decoder board. Based on the document of Stefan Krauss I managed to create the power/driving signal, sending commands including the CRC and detecting a 1 bit feedback. When doing a Decoder Search on broadcast address 0 only the LokPilot 5 decoder board responds with a 1-bit feedback as descripted on the article of Stefan Krauss. The DHG700 does not respond. It simple is standing on the track with a blinking roof LED. I'm clueless why the DHG700 doesn't respond. Since I don't own a Centrale Station could you send me some oscilloscope images of the first communication with a MFX decoder? I'm specially interested in the broadcast communication.
Sorry to 'dive bomb' in a few lines what I'm doing but I've to start somewhere... And it's like you said, it's almost impossible to find people with this 'low level' interest.

Greetings, Roland

Hi again Roland,

Thinking a bit more about your problem - if you don't have ready access to another Marklin user to get information from, I could try to capture the serial output from my sampler to a file using puTTY or something similar and make that accessible on my Mega account.

I have an ML 00610 loco from a discarded Aldi set that is probably of similar complexity to your loco. I could try to capture both a regular start up and drive as well as a new registration.

Let me know if you want me to attempt that - but be aware that, due to some serious health issues, it could take me a while ...

Cheers, Mark

Hi Mark
Based on the logging picture you placed some posts ago and a reply from Stefan Krauss it could be I have an answer (fingers crossed). Will try tomorrow and keep you posted.
Greetings,
Roland

Yes, this might be the reason, no HQ id. Already changed the code. Need to compile and test. But bed is calling on this side of the globe....

Oh boy, oh boy, oh boy.... Am I enjoying myself? Very much so!
These three files are very insightful. Thanks a million.
I've spend already some hours in studying your files and I've learned a lot. I added to my code a HeadQuarters function that sends out continuously, with a certain interval, on broadcast address 0 a control center UID with a registration counter number. I used your control center UID so we could exchange loks with each other....
I'm now writing code to be able to extract the lok decoder UID.

You enjoy your engineering fluid and the Gravy song.

Keep you posted.

Greetings,
Roland

PS Stefan Krauss also responded pointing me in the correct direction.

Hi Mark,
Finally success! With the help of your log files and some pointers of Stefan I managed the DHG700 lok to respond. Studying your log files I noticed your station constantly repeated the Headquarter UID and registration number. Being a novice with the MFX prorocol I didn't include this headuarter broadcast in my code. This left the DHG700 in its last state being roof LED and forward lights switch on and with a stored unknown Headquarters UID.
When including the Headquarters command the DHG700 responded by switching off the roof LED and forward lights. And, most importantly, the DHG700 responded on a decoder search command on broadcast address 0.
I extended my code to be able to find the decoder UID. I managed to find the first bit of the 32 bits of the decoder UID with the help of an oscilloscope. I need an oscilloscope since I don't have as of yet build the electronics to detect the decoder response. This wil be my next mission. This also answers your question about the feedback path, at this moment there is hardly none.
When the electronics and code is more or less showable I will share with you and the community. But give me some slack. Sitting hour on hours in my man cave comes with a cost. I must not forget my family....

Keep you posted.

Greetings,

Roland

Hi Mark,

About the bits and pieces, I hear what you say and I'm planning to report this adventure on my website. But understanding MFX took some time, making the electronics, writing code and setting up a website will take some time too and I'm not retired yet.... So I've to divide my time.
I studied your coding work and alternative RDS decoding circuit. Kudo's! Your way of coding resembles my way of coding which made life much easier...
But I want to think out of the box and make decoding simple by trying to lose the RDS chip(s) and solve the decoding in software. Decoding from a controller standpoint is easier because you know whenever a decoder start talking. This means that (all) available resources in your processor can be used to decode. BTW I use a Wrover ESP32 but I'm thinking of switching to a ATOM Lite M5 to make everything nice and compact.
Coming back to the signal decoding. To be able to measure the signals which I generate with the software and the ESP32 I placed a resistor in between the driver and the track. The resistor value is too high to drive multiple loks but good enough to drive one lok and to measure signals going back and forth with an oscilloscope. Now the decoder uses a current source to talk back. The current from my DHG700 lok is 100mA. If I would change the resistor value to 0.2 ohm the voltage over the resistor, containing the feedback data, would be 20mV. Yesterday evening I was playing around with LTSpice, a free electronics simulator, and came up with the following circuit:



This circuit I created detects edges of digital pulses and outputs them to a 3.3V level suited for the ESP32. The simulation result looks like this:



The green signal is one side of the +/-18V signal on the track. After 250us I start to simulate a 1 bit feedback signal (should be 20mV and not visible in the simulation plot). The blue signal is the output signal on the collector of Q2 that should be used as a signal to the ESP32 for decoding. Simulation shows it should work but I'm not happy yet. First of all the feedback signal, when using a 0.2 ohm resistor, is very low and therefor sensitive for interference. Secondly the power in the series resistor, when pushing 10A, is 20W, which is a lot. Thirdly there would be a voltage drop of 2V.
So my thinking cap is still on how to improve on this.


U2 a Merry Christmas and keep you posted.

Greetings,
Roland

IIRC on the ms1 they use a transformer to pick up the return message. This should give you significantly less than 0.2 ohm for the primary, and you can then get a significant voltage step up on the secondary. I haven't tried to deduce the schematic on any other controllers as yet.

Hi Mark et al.
Progress... I've been busy in between Christmas festivities and the project starts to show some lift off. Ready? Here we go:

1. I call the electronics and software I'm working on "The ATC", short for "The Alternative Train Controller" (you need to call it something).
2. Exchanged the ESP32 Lolin32 dev.controller board for an Atom Lite ESP32. This makes the footprint of the ATC 100x 70 mm.
All pins of the Atom Lite are used but spared two pins for an I2C interface (for future expansion).
3. Finished, build and tested the Feedback electronics.
4. Included Bitstuffing


In a previous post I showed a Feedback circuit that worked but was component critical and potentially could absorb a lot of power. Like kiwiAlan mentioned I also thought of a solution with a transformer. After some designing and simulating I came up with the following solution:



According to the simulator it should give the following result:



The green trace is one side of the +/- 18V track signal. The blue trace is the signal on the collector of Q1. Please note that for visualisation purposes I decreased the 18V to 5V and pause time for a 1-bit feedback from 6.4ms to approx.0.5ms.
Mind you the 28uH coil still gives an high inductive resistance for the frequencies used in a MFX signal (period times 50us, 100us and 19us). But that's something to solve/improve upon later.
After building the circuit I included an interrupt function in the ATC software capable of capturing the 52.63kHz signal from a decoder when respoding on a 1-bit feedback. On an oscilloscope (In Real Life) it looks like this:




In the top window you see a 'Decoder Search command with 1-bit feedback' frame. The signals are the trigger signals (Purple) showing the start of certain events within a 'Decoder Search command with 1-bit feedback' on broadcast address 0. Yellow, signal on the track. Blue the output of my circuit. Bottom window, a zoomed in view of the beginning of the pause period.

When giving a Decoder Search command my software responds with:

Write frame in array bitArray to track: 10 0000000 111010 000000 00000000.00000000.00000000.00000000 01110010
1-bit response confirmed. Number of pulses counted: 337

10 0000000: 7 bit format address 0
111010: Decoder Search command
000000: counter
00000000.00000000.00000000.00000000: 32-bit decoder address 0
01110010: CRC

The number of 19us pulses I expect within the 6.4ms response windows is 336. The software counts 337. Good enough for me to deside for a positive 1-bit response.


The Bitstuffing, include a zero after transmitting eight ones, looks like this:




Next stop finding out the decoder address (UID).

Greetings,

Roland

Hi Mark,

the ferrite core looks like this:



The actual dimensions can be found in the schematic in the previous post. It was a core that I had laying around. I didn't any specs on it. I determined the induction by adding a parallel capacitor and applying a sine wave. Based on the resonance frequency I could calculate the inductance of the coil. Then plugging in core dimensions and inductance in a 'ferrite core calculation program' I found on the internet I could make an assumption of the ferrite core specifics.

BTW I managed to retrieve the ID of the DHG700 lok, being 7df8dd24 and from the LokPilot5 module f9ee151c.
I can also successfully ping to the lok.

I'm getting close now.....

Greetings,

Roland

Hi Mark,

bummer that you threw away a these life necessities... I know the feeling when you throw something away that you haven't used for years and the next day you need it.

About your question, the transformer has a ratio of 1:1. In the primairy side a current of 100mA will flow generated by the decoder. So you can expect this current also in the secundairy side. Together with the 10 ohm resistor this will give 1V. You can see this also in the simulation (green trace). The signal on the secundairy side is high enough to saturate the transistor.
For the number of windings on the ferrite core I used my gut feeling, since I didn't knew the specifics of the ferrite core. I would like to see less windings hence reducing the inductance but I don't know how many windings I can reduce.
Also the 1-bit feedback signal has a higher frequency than the regular data feedback from the decoder. I don't know this for sure yet because data feedback is another challenge to figure out.

Hope this helps.

Greetings,

Roland

Thanks for chipping in. You said I could reduce the number of windings of the primairy side to a quarter of the current number. Why not one winding? What would be the penalty?
And you did not mention the secundairy side. Do you think I should also reduce the secundairy side to the same number and keep the 1:1 ratio?

About the 10 ohms, I agree this value reflects back to the primairy side but keep in mind that during normal driving operation (=read when power is needed to drive the trains) the lowest frequency is 10kHz (100us). With a given current inductance of 28uH this means an inductive resistance of 1.8 ohms. The 10 ohm will be not dominant. And bear in mind that when reading out the decoder the track driver electronics is placed into a special state. The highest current is comming from the decoders giving feedback.
However I would like to see this the inductance value lower resulting in less losses, less windings and a smaller ferrit core. But, again, how many winding would still be feasible?

At this moment it's working (but could be improved) and made big steps in understanding the MFX protocol. Perhaps even more then I show... .

I'm looking forward to your answer.

ChrisKenna is your controller a CS3?

Roland,

If you're still looking, this program (on ESP32) does the job : https://github.com/BOBILLEChristophe/MFX_discovery

Christophe

Thank you Roland for this very encouraging message.

I'm very interested in this question of MFX feedback. I know how much time and effort it takes to look for DIY solutions, especially when there is little or no documentation on the subject, which is the case with the Marklin RDS. And even on forums like this one, which is global in scope, we often feel quite alone.

And also when you don't have all the skills at your disposal, as I do. I think I can classify myself as a programmer (which is what I do for a living), but unfortunately I'm not much of an electronics expert!

Don't hesitate to share your code, even if it's very incomplete, as I may still be able to help you.

I hope this project has a happy ending.

Christophe

Hi Roland,

Would you be willing to share the electronic schematic and the list of components for the RDS feedback?

That's what I'm currently stuck on.

Thanks in advance.

Best regards

Christophe