Hallo,

was ich hier versuche, hätte ich gern fertig benutzt, aber scheinbar gibt es das so nicht.

Ich würde gern einen "dummen" Gleissignal-Monitor für H0, ca 14-20V bauen. Dumm, denn er soll nur den Hi/Lo-Daten-Strom vom Gleissignal im PC verfügbar machen, aber selbst nicht interpretieren.

Er soll nicht DCC oder mm2 decodieren, ein Teil, eine Aufgabe.

Als Plattform habe ich ins Auge gefasst: Ein USB-IO-Board an einem handelsüblichen Linux- oder Windows-PC. Das Board frisst natürlich keine 18 Volt Gleissignal. Also einen Widerstand brauchen wir, Diode gegen Fehlpolung, wahrscheinlich wäre ein Kondensator zur Potentialtrennung vernünftig. Ich bin elektrotechnisch noch nicht so erfahren wie ich gern wäre. Geschwindigkeit sollte kein Problem sein - wir wollen die Decodierung in Software erledigen und schrittweise verbessern von "welche Protokolle laufen hier? Mfx? DCC mit/ohne A und Railcom? MM2?" zu "welche Befehle welches Protokolls"? und was daraus folgt, kann dann gern ein anderes Stück Software entscheiden. Eine verlässliche Bearbeitungszeit, konstante Latenz, ist vernachlässigbar. Wahrscheinlich ziemlich schrecklich für die Automatisierungs-Gemeinde alter Schule.

Warum kein Raspberry mit GPIO? Es ist wahrscheinlich leichter, das fertige Programm auf die spezielle Umgebung Raspi zu portieren als ein Raspi-Programm zu verallgemeinern. Ich möchte auch nicht auf einen konkreten mittelstarken Computer festgenagelt sein. Die Zweck-Hardware soll so doof und übertragbar wie möglich sein. Signalstrom vom Gleis oder Boosterzugang abziehen, verkleinern, entkoppeln, verfügbar machen.

Daher auch die Überlegung, lieber kein Programm für einen Microcontroller zu bauen. (Mir ist bewusst, dass die meisten USB-GPIO-Boards zweckentfremdete vollwertige Microcontroller-Boards sind, auf denen ein Standardprogramm läuft)

Wenn noch nichts da ist, warum dieser Thread? Gebotene Gründlichkeit, vorhandene Erfahrung nutzen, Denkfehler aufdecken, übersehene bereits existierende Lösungen, was sich eben ergibt.

Bereits vorbetrachtet:
Hardware-Entwürfe und Programme für opensource Lokdekoder und stationäre decoder, dcc sniffer. Wie gesagt, ich war etwas überrascht.

Hallo mbw,
suchst Du sowas?
https://tams-online.de/Gleisbesetztmelder-GBM-8
Österliche Grüße
Ernst

Hallo,

warum denn keinen µC in Betracht ziehen? Gerade ohne µC sehe ich die Herausforderung, mit einem PC das Gleissignal mit konstanter Frequenz abzutasten.

Ggf, kannst du das direkt verwenden:
http://centredcc.fr/en/presentation/dcc-monitor/
Du benutzt dann halt nur den Arduino und schreibst deine Applikation auf dem Rechner selbst nach deinen Wünschen.

Ansonsten gibt es auch hier im Forum verschiedene DCC-Monitor Projekte, die meisten auf Arduino-Basis. Da kannst du natürlich auch was Eigenes von ableiten, was dann Rohdaten uninterpretiert an den Rechner schickt.

Zitat von Häisbischer im Beitrag #2

---

Hallo mbw,
suchst Du sowas?
Link entfernt wegen Zitatlimit Gleisbesetztmelder-GBM-8
Österliche Grüße
Ernst

---

Zitat von ICEVfan im Beitrag #3

---

Hallo,

warum denn keinen µC in Betracht ziehen? Gerade ohne µC sehe ich die Herausforderung, mit einem PC das Gleissignal mit konstanter Frequenz abzutasten.

Ggf, kannst du das direkt verwenden:
Link im Zitat entfernt, darf ich aktuell nicht.
Du benutzt dann halt nur den Arduino und schreibst deine Applikation auf dem Rechner selbst nach deinen Wünschen.

Ansonsten gibt es auch hier im Forum verschiedene DCC-Monitor Projekte, die meisten auf Arduino-Basis. Da kannst du natürlich auch was Eigenes von ableiten, was dann Rohdaten uninterpretiert an den Rechner schickt.

---

Du wirst in jedem Fall einen Mikrocontroller brauchen, der mit Interruptroutinen und Timern das digitale Signal einer Zentrale in Nullen und Einsen zerlegt. Unterschiedliche Protokolle nutzen auch unterschiedliches Timing, Präambeln etc.

Meinen DCC-Monitor könnte man dazu bringen, den nackten DCC-Datenstrom auszugeben, ohne die Interpretation der einzelnen Bitfolgen und Befehle. Da müsste man nur etliche Routinen weglassen und nur die von der NRMA-Library gesammelten Bits ausgeben.

🧮 DCC-Monitor auf Arduino-Basis: N E U Version 1.5

Was willst du mit dem nackten Bitstrom anfangen?

Hallo mbw,

Zitat von mbw im Beitrag #5

---

Die IO-USB-Module, die ich mir angesehen habe, sind Microcontroller-Boards mit einem Programm, das genau nur dies schon tut. Ich möchte in der Software auch mit fehlerhaften Codierungen oder undokumentierten Protokollen am Gleis umgehen - da nützt es mir nichts, wenn sich jemand die Mühe macht, die Pakete im Microcontroller-Code schon zu interpretieren.

---

Zitat

---

Was willst du mit dem nackten Bitstrom anfangen?

---

Verschiedenes. Zunächst mal protokollieren, statistisch erfassen, Häufungen in Grafana visualisieren. Dann speziell nach roten Paketen schauen, also solchen, die nach Normensammlung nicht definiert oder illegal sind. Später mal Realismus in die Modellbahn bringen - etwa, dass die Programmlogik zwar ihre Regeln befolgt, aber einen unscharfen Blick auf die Gesamtsituation hat und unterschiedlich schnell, auch mal fehlerhaft, auf erkannte Situationen reagiert. Ganz hinten auf dem Waschzettel steht, man soll mal ein LLM auf die Sensordaten ansetzen und gucken, wie es abstrakte Fahrbefehle umsetzt und aus Sensorereignissen, dem Gleissignal und dem Befehlsbus (in dem Fall MCAN) die Züge identifizieren kann. Aber ob ich da überhaupt hinkomme? Muss man sehen. Die Rückmeldungen im Forum sind schon mal wichtig. DCC hatte ich mit 8kbit/s im Hinterkopf, mm2 hatte ich in der gleichen Geschwindigkeit vermutet ohne nachzuprüfen. Guter Hinweis.