Hello RCH,

Bravo, I looked at the site on the link you give. You have indeed succeeded in mastering the locomotive controls and also the feedback from the decoders to the control centre, which is probably not the easiest thing to do.

I'm currently on holidays and don't have everything I need to test. I'll try it out when I get back in early August.

I have a few questions to get me going in the meantime.

1° - Which software, which control unit to drive the ESP32 ? What is the protocol between the control interface and ATC? TCP? CAN to be compatible with Marklin's graphical interfaces (MS2...)? But on your diagrams, I see that it's more likely to be USB?

2° - You don't list the components for this feedback circuit as you do for the control unit. It's probably not very difficult to do from the schematic, but could you add it to the site to avoid confusion?

I look forward to hearing from you.

Best regards

Christophe

Dear RCH -

Parabens - a few brief comments/questions to check my understanding.

Sorry, I (lazily) haven't yet read the code which would no doubt answer some questions directly. But based on the schematics, ...

• The DFRobot motor controller provides track power and modulates it to send the digital signals to the locos and track accessories. Correct?
  
• The ferrite inductor and associated circuitry detects the feedback from the loco decoders and any track accessory feedback. Correct?
  

The motor controller is a neat shortcut to a device that could probably drive DCC and as well.

Osoraku

Hello,

You speak of “reading the code”. But I haven't seen anywhere that the code is published?

Christophe

Congratulations RCH on getting the ATC going.

Sorry I took so long to reply - some of us retired people have very busy schedules getting around to all those vineyards, resorts and attractions ...

I know how much effort you put into this project - and to do it all with just one loco, a couple of pieces of track and not even an MS2 is an achievement you can be proud of. At the beginning I said you would probably need some serious therapy if you ventured down the mfx rabbit hole - but you have had a win and still seem reasonably sane.

I think many have been able to get something going via the CAN bus and track box but this is real "first principles" stuff and mfx is quite complex when you get down to the nuts and bolts level.

I look forward to seeing where it goes from here and will be very happy to provide further help if you need it.

Once again, well done.

Mark (revmox).

Hi all,

I do agree with Christophe that making this work for DCC shouldn't be much of a problem. It works for MFX so no reason that it shouldn't work for DCC. I started with MFX because this protocol was best descripted by Stefan Krauss. I had to start somewhere...

About the RMT Christophe descipted, for the none ESP32 users, RMT is a seperate 'device' inside the ESP32 used for generating digital patterns. I think intially intented for generating Remote Control signals like your TV remote. Using the RMT would relieve you from timing issues. You can generate patterns (read MFX commands) that can be send to the track without interference of other unknown, hidden internal ESP32 processes like WiFi. Not using RMT I have seen these unwanted timing interruptions when generating the MFX signals. First of all the MFX decoders are quite forgiving in handling these timing issues. However I circumvented the timing issue to a minimum by using the following:
- seperate the critical timing and lets say the 'human interfacing' on seperate cores. Note that it is imperative to realise that Wifi (which I'm using in the ATC) takes place on core 0. So critical timing is shifted to core 1.
- elevated core 1 priority to it's max
- initiate timing crital timers and/or interrupts on core 1
- use a good oscilloscope to be able to see if you are doing the right thing....

While developing the code I had a look at the RMT option. I abandoned this option because I think RMT is ment for burst patterns like your remote. MFX or DCC for that matter is a continuous signal flow where communication is 'embedded' within the flow while maintaning the OLC-rule (see chapter Driving signal). RMT can generate MFX command patterns OR the '0' steady state signal but intertwining the both AND maintaining the OLC rule I'm not sure.
But please be my guest and try. It's like Revmox mentioned the ATC is "first principle stuff". I do not want to stop progress.

About the code, it's not released yet. It's more over than a 1000 lines (excluding 500 lines or so of comment...). I want to put in a effort to make it as readable as possible. So please be patient.

RCH