Dear Adrian -

Sorry it wasn't clear - both marklin.py and threadsafe.py are at the github site where the rest of the code is.

Osoraku

Dear Adrian -



Yes.

I reworked the code to auto-configure the CAN board.

Osoraku

Edited by user 27 April 2025 14:17:05(UTC)  | Reason: Updated code to auto-configure

Find the circuit for a 60113 gleisbox in my cloud storage using the link below-

Also in there you will find data sheets for the chips it uses.

C5081F502 MCU processor
MAX3058 CAN transceiver
CD4555 dual 1 of 4 decoder
SAA6579 and PT2579 RDS decoder, my 60116 track box has the PT2579 equivalent
ZXCT1009 high-side current monitor - a nifty device that I haven't seen before that produces an isolated output current proportional to the voltage on its input terminals, I think it picks up the mfx feedback from decoders and also provides the over current protection sensing?

https://mega.nz/folder/g...I#59XJTLCZ9wx1t5pihgbrww

Thanks for sharing but what you present here uses an RDS component (SAA6579 or PT2579). These components are difficult to find today and expensive.

I tested the MFX feedback with these RDS components and another schematic but I couldn't isolate the useful information. So I gave up on the piss.

I was very interested when you published this schematic that didn't use RDS components. Is this the wrong way to go?



If not, I'd be very interested if you could provide some clarification, particularly on the choice of coil.

I'll then try to implement it and share my results.

MFX feedback is the only thing missing from my otherwise perfectly functioning power plant.

https://www.marklin-user...es-without-CS-2-3-or-MS2

Christophe

Dear Adrian -

Sorry, not yet. I am away from my hardware for a few weeks and can't test anything attached to the real world.

I'm sure that Christophe's design works. Of interest to me is whether enough of the spare pins on the Joy-IT or Waveshare CAN boards can be used the same way and integrated into a single device (with, say, 8 or so S88-equivalent feedback inputs). That would be a simple, cheap, integrated device to go with a starter set.

(Edited later): This has now been tested and the code is updated

Osoraku

Edited by user 27 April 2025 14:18:33(UTC)  | Reason: Tested and updated

revmox

Thanks for the feedback. Can you give me more details on the electronic schematic that would be suitable.

Is the schematic obsolete???



I have the skills and equipment to decode binary signals. But not enough electronics.

I know that the MFX return signal can be analyzed either by an Arduino, an ESP32, an RP Pi Pico or even an ATTiny.

If I could have the schematic of this feedback part alone, I could make a great contribution, and the control unit I've proposed is open source and works very well. It would be a great plus for the community.

Thanks in advance.

Christophe

PS: It would probably be better to continue on another thread or by private message!

Hi Christophe,

I’ve posted the gleisbox information here as it might in some way be useful to people working through it. I’m not trying to produce a train controller – RDS is just an interesting technical puzzle for me to solve that seems to be an obstacle for those that are.

The circuit using the 567 tone decoder works but is NOT recommended – it uses a current transformer and these are always difficult for others to replicate. It has a high component count and either needs 1% components or some decent electronic equipment to set up the PLL centre frequency. The tone decoder output momentarily drops lock when an RDS phase reversal occurs and this is what must be detected. If you want to push ahead (and obviously you have seen my previous posts) then the only information you are missing is the transformer. Unfortunately, it has gone out with the trash, as I’m cleaning up in preparation for moving house but it used the same unknown core from my glory box as shown on the right in the picture of the bread boarded circuit, 17 OD, 10 ID, 5H, 2T primary, 8T secondary loaded with 10 ohms as best I can recall.



It would seem the far better approach would be to lean on Marklin’s mass produced method that is working satisfactorily in so many gleisboxes. Tracing the gleisbox path from the current monitor chip to the RDS chip MUX input should provide what is needed – and also give the possibility of overload protection to those that don’t already have it. Here’s a copy of some private chatter that may help you if you go down that path, it works on the bench detecting 1s and 0s from an RDS generator.

---

I’ve used an Arduino Nano, with the more advanced platforms you gain many, many things but lose that level of visibility and control. (My staff used to call it the “Rule of 4” – 4 cores, 4GHz, 4GB and 4 obscure, deprecated libraries to turn one LED on in 4 seconds. Defence contractors, who charge by the line, just love it).

First, I’ve written a program to lock into the initial RDS waveform edges – then shift by a quarter of the RDS period 4.75uS to place sampling at mid-pulse – then sample every 9.5uS to capture the phase of the RDS signal. I then take 30 samples pre the phase change point and 30 samples post the phase change point. This gives a tolerance of tens of microseconds in response time for the loco decoder. If >27 of the samples in Sample 1 are in phase with the start then I consider it a valid RDS start (allows for some noise), if >27 of the 30 samples in Sample 2 are also in phase then I consider it a valid RDS logic 1, if <3 of the 30 samples in Sample 2 are in phase then I consider it a valid RDS logic 0. If those overall conditions aren’t met then I consider the reading invalid. Easier than focusing on the exact point of phase reversal. I’ll christen this the Mox Method and work on seeing if it comes together in the real world.



Good luck with your project.

Revmox

I can add in a MFX loco by hand. I don’t know what address to put in. Is there a way to make Rocrail auto detect the MFX loco?

Gopal

Dear Adrian -



No. With Rocrail, there's no need to use UDP unless you want multiple controllers/throttles to run locos. Anything coming over the CAN bus will get forwarded. Your other hardware will have its own comm path (over RS232?) to Rocrail and won't be using WiFi.

Osoraku

Dear Adrian -



If you're concerned that the pico-can controller will use up the USB ports on your computer, you can hook it up to USB power from a wall plug. Then the RS232↔︎USB adapter is available for your feedback device, making it look like an RS232 connection to Rocrail. Or do I misunderstand?

Osoraku

Dear Adrian -

No worries. Rocrail will do the feedback integration and control via its separate comm paths. It makes no odds to the pico-can controller.

From the links that you posted, Rocrail apparently handles the HSI-88 as a feedback route to it via a serial port (RS232). You must have one of the USB dongles to connect RS232 to your Macbook Air test bed. Rocrail will probably see the HSI-88 as a serial device at /dev/cu.usbmodemxxxxx and show it as a choice on its setup page.

I may have a combined CAN-WiFi and feedback hub tested in a week or so. A Waveshare board is on its way to me as I type but I'll need some way to simulate feedback for testing. Pushbuttons, maybe. Fingers crossed.

Osoraku

Dear Adrian -

After reading the CS2 protocol definition (version 1.0 and 2.0) and how they implement feedback, it is pretty clear that there is an "old" way and a "new" way to implement feedback. The "old" way broadcast the whole 16 state bits of an S88 module 10 times a second. This wastes bandwidth and clogs comms paths. In version 2.0 this use is deprecated. The "new" way only reports state changes, which lowers bandwidth demands enormously. I plan to use that approach, which shouldn't burden the pico at all.

As before:- fingers crossed; testing required.

Osoraku

Dear Adrian -



You're enlisted then! I got the code running and tested (TCP & UDP versions) as well as I can with what hardware I have at the moment. You can download it from the github repository. The pins to use for the feedback connections are documented in the README for it.

The main problem is how to hook up feedback devices: neither board offers easy connections. (I tested the hardware with breadboard jumpers and Rocrail reporting the feedback.) Male breadboard jumpers work best with the Joy-IT board and female with the Waveshare board.

I worked out a way to get sensor feedback into the Raspberry Pi using the header pins on the Joy-IT board. The Waveshare board could be attached similarly. Tests OK with Rocrail and JMRI.



Another way to get sensor feedback into the Raspberry Pi pico (RPP) without a breadboard+jumpers is through this board. It provides breakouts of all the RPP pins with screw terminals and plugs into the headers on the Waveshare board.



Osoraku

Edited by user 06 May 2025 15:14:33(UTC)  | Reason: Added image of connected feedback devices & JMRI testing; also add breakout board image

Dear Mark - The connector provides power & CAN signals. Because you can daisy-chain CAN devices with the bus wiring (a sniffer with a comms/output path), methinks the main benefit for this cable would be to power > 2 MS2s.

Osoraku