GBM-A: Gleisbesetzmelder mit BiDi-Zugerkennung

    (von J.Kühn)
    Der hier beschrieben Gleisbesetztmelder ist, wie alle Projekte dieser Website, nur für den nichtkommerziellen, privaten Gebrauch bestimmt. Die Bestandteile der bidirektionalem Kommunikation nutzen u.a. Technik von Lenz (RailCom). Die beschriebene Hard- und Software ist im beta-Stadium und noch nicht für die Inverkehrbringung vorgesehen. Jeder ist gern eingeladen an der weiteren Entwicklung mitzuarbeiten. Dazu werden die folgenden Unterlagen bereitgestellt. Dieses Projekt erfordert zum gegenwärtigen Zeitpunkt grundlegende Programmierkenntnisse und Kenntnisse in der Verwendung der Atmel-Programmierumgebung.

Was kann der Bidi-GBM allgemein in DCC-Systemen?

  • traditionelle Besetztmeldung über Stromfühler (bis 10kOhm) über S88. Hinweis: wird die Varianten mit voller RailCom-Konformität gewählt, so geht die Erkennung bis 5kOhm)
  • zusätzliche virtuelle Momentmelder für Ein- oder Ausfahrt eines Bidi-Fahrzeuges in den Abschnitt
  • Übermittlung aller Melder aller GBM's über ein S88-Kabel zur Zentrale oder zum PC-Interface
  • Zugerkennung und Meldung an Hand der DCC-Adressen der Bidi-fähigen Fahrzeuge (derzeit per Inter-10 Emulation, RC-Talk vorbereitet, weitere nach Verfügbarkeit der Protokolle)
  • Meldung der Geschwindigkeit der Fahrzeuge insofern Decoder es unterstützt und enstprechende Softwareunterstützung kommt

Was kann der Bidi-GBM zusätzlich an der OpenDCC-Zentrale?

  • S88 over XpressNet (kein S88-Kabel mehr notwendig)
  • PoM Read, CV's am Hauptgleis auslesen
    • Der Bidi-GBM ersetzt also den klassischen GBM und erweitert diesen um neue Funktionalität die durch Bidirektionale Kommunikation möglich wird.

    Für die klassische Belegtmeldungen werden alle Fahrzeuge mit Stromverbrauch > 1,5mA erkannt. Je nach Anwendungssoftware erhöht sich durch Zugerkennung die Sicherheit beträchtlich (Falschfahrterkennung), aber vor allem wird der Komfort (fahren mit Handregler in Kombination mit PC) und die Steuerungsmöglichkeiten verbessert.

Funktion

    Der GBM verfügt über 16 Ports. Für die Rückmeldung der normalen Belegtmeldung und der Momentmelder wird der S88n-Bus benutzt. Dabei kann jedes Modul einen S88-Anschluss verwenden, der Verkabelungsaufwand verringert sich aber, wenn der S88 nur am Gateway angeschlossen wird. Bei Verwendung der OpenDCC-Zentrale ist keine S88-Verkabelung mehr notwendig.

    Die BiDi-Meldungen werden von den Gleisbesetztmeldern über XpressNet an das Gateway gesendet und von dort gesammelt an den PC übermittelt. Für die Verwendung des XPressnet muss derzeit ein Master vorhanden sein (Zentrale, Multimaus etc.), die Aufgabe aber auch von dem Gateway übernommen werden.

Bidi-Gateway

    Als Gateway dient eine abgerüstete Platine des GBM (der DCC-Teil entfällt). Das Gateway kommunziert mit den GBM's und der Zentrale per XpressNet, mit dem PC per USB und mit Zentrale oder S88-PC-Interface per S88.

    Für das Gateway kann ggf. auch die Hardware Hardware des OpenDCC Gateway verwendet werden. Als Schnittstellen bestückt werden muss nur USB und XpressNet.

Bidi-GBM

  • Schaltungsbeschreibung:
    (Schaltung als PDF)
    Die 16 Port's sind jeweils mit einem 10 Ohm (5 Ohm) Stromfühler versehen und werden über Komparatoren mit einer Vergleichsspannung von 12mV ausgewertet. Die Empfindlichkeit für die klassische Belegtmeldung liegt so bei ca. 10kOhm (5 kOhm). Der Spannungsabfall über den GBM-Port wird durch die Schottky-Dioden auf ca. 0,3V begrenzt und liegt damit für einen klassichen GBM recht niedrig. Trotzdem sind diese 0,3V noch 100mV größer als die Konformitätsgrenze von Railcom. Um hier volle Konformität zu erreichen, müssten 5 Ohm bestückt werden. Technisch gibt es keinen Grund, nicht die höhere Empfindlichkeit der 10 Ohm Messwiderstände zu nutzen.
    Die Belastbarkeit des Ports wird durch die Grenzwerte dieser Dioden, der Leiterbahnbreite und den Anschlussklemmen bestimmt.
    Im DCC-Logikteil werden die 16 Ports über zwei 16-bit Multiplexer auf einen schnellen Optokoppler zusammengefasst und ermöglicht die Erkennung der Aufgleisrichtung (die aber derzeit von den Hostprotokollen i.A. nicht übertragen wird). Der Multiplexer erhält seine Schaltinformation über 4 Optokoppler vom Logikteil. Die Stromversorgung des DCC-Logikteils wird aus dem DCC-Signal generiert (Vcc_DCC und Vss). Zu beachten ist die Trennung der GND-Signale in DCC_GND und GND.
    Im Logikteil findet sich die CPU ATmega1284p für Ansteuerung und Auswertung, sowie die diversen Schnittstellen XpressNet, S88 (nur falls nicht von Gateway oder der Zentrale übernommen) und USB (letzteres hier nur für Diagnosezwecke notwendig). Die Stomversorgung erfolgt über den XPressNet-Anschluss und wird über den IC 7805 stabilisiert. Eine Stromversorgung über S88 oder USB ist optional möglich (Diode und/oder Drossel bestücken).
  • Schalter, Jumper, LED's:
    S1 legt die Adresse des GBM (DID) fest. Derzeit bestimmt das Gateway mit Inter-10-Protokoll die maximale Anzahl von Lesestellen mit 99. &xnbsp; Damit sind größere ID's als 6 nicht sinnvoll. Die Adresse der Lesestelle errechnet sich aus (ID * 16) + Port. Der erste Anschluss am GBM&xnbsp;mit ID 0 ist also Lesestelle 1, Port 16 am GBM mit ID 5 ist Lesestelle 96.
    Die ID wird ebenfalls als voreingestellte XpressNet-ID verwendet (geht 0 ???). Falls diese ID aber besetzt ist wird automatisch auf eine andere ID ausgewichen.

    Wenn J1-1 gesteckt ist, wird die Monitoringausgabe am USB zugeschaltet (250000Bd).
    J1-2 dergleichen für die Debug-Ausgabe (debug-level und port in init_bidi_gbm definiert)
    K5 Anschluss für ein USB-TTL-Kabel falls USB nicht bestückt wird (fallweise für Debug oder Firmwareupdate)

    LED1 leuchtet solange sich ein BiDi-Fahrzeug an einem der Ports befindet, und geht kurz aus bei Freimeldung für ein Fahrzeug.
    LED2 blinkt im 1s Rhytmus als 'Lebenszeichen'.
  • Leiterplatte:
    (Bestückungsplan als PDF, Leiterplatte PDF)
    Die Bauelemente sind auf einer 100*105 Platine (2-lagig) untergebracht. Es wurden noch einige DIL-Bauteile verwendet, aber größtenteils auf SMD zurückgegriffen. Dabei wurden jedoch die größeren Bauformen 1206 bevorzugt, die sich durchaus auch noch ganz gut händisch löten lassen.
    Momentan habe ich noch 3 Testplatinen aus einer Nachlieferung die ich gegen Unkostenbeteiligung abgeben kann, bei Bedarf sind die Platinendaten aber auch im target-Format verfügbar um weitere Platinen fertigen zu lassen.

    einige Bauteile (USB und die Messpunkte) sind optional (auf dem Bestückungsplan rot)
  • wie geh ich beim Aufbau vor?
    • alle SMD-R's und C's bestücken, auch gleich die BAV's und den Transistor (nicht mit den Dioden verwechseln!)
    • DCC-Schottky-Dioden und R's 10 Ohm von oben innen nach unten außen bestücken (für die Dioden besser einen stärkeren Lötkolben verwenden)
    • Stromversorgung sowohl für Logik- als auch für DCC-Teil bestücken. Evtl. auch schon die Klemmen für DCC
    • mit strombegrenzten Netzteil 12V anlegen (nur Notfalls bei eingesteckten XpressNet), +5V Vcc kontrollieren
    • +15V an DCC anlegen, Vcc-DCC kontrollieren, ebenfalls +12mV kontrollieren
    • -15V an DCC anlegen, Vss 0,7 bis 0,9V kontrollieren, auch -12mV kontrollieren
    • jetzt noch die 16 Port's an den Klemmen-Lötaugen nachmessen, noch korrigiert es sich ohne Klemmen einfacher. Widerstand muss 10 (5) Ohm sein, über Widerstand angelegte +/- Spannung (oder ~) darf nicht >0,3V werden
    • CPU auflöten, Stecker für Programmieradapter bestücken (falls CPU nicht schon programmiert), CPU versuchen anzusprechen und erstmalig zu programmieren, Fuses setzen
    • restliche SMD-IC's bestücken, wieder alle Spannungen (Vcc, Vcc-DCC, Vss kontrollieren)
    • Fassungen für IC's, Buchsen, LED's, Schalter, restliche Jumper etc.
    • Klemmen für die Ports - entweder alle zusammen oder von unten nach oben (wegen der Steck-Reihung!)
  • dann ein Funktionstest:
    • ID am Schalter einstellen, XpressNet dran, Stromversorgung da?
    • blinkern die LED's? Funktionieren die anderen XpressNet Geräte noch?
    • wenn USB bestückt: Terminalprogramm mit Baudrate 250000Bd prüfen ob Debugausgabe ankommt
    • DCC anklemmen (und Signal/Spannung wirklich auch anlegen )
    • S88 OUT (falls bestückt) als letztes Modul in die Kette, Testmelder in der Software für die Moduladresse einrichten
    • jedes Portklemmenpaar nacheinander mit einem 10kOhm-Widerstand (oder weniger) überbrücken, S88-Melder muss anschlagen
    • BiDi-Fahrzeug auf einen Port, mit USB-Monitor nach den Meldungen schauen (oder am Gateway Meldungen prüfen).
    • Zeitverhalten prüfen wenn alle Loks am DCC aktiv sind
  • Software:
    Ein vorhandener Softwarestand ist für Testzwecke nutzbar. Der GBM-A wurde getestet mit TC7G. RocRail & WDP sollte auch funktionieren. Andere Programme sollten funktionieren sobald eine kompatible Inter-10 Unterstützung angeboten wird.
  • Hinweise zum Übersetzen der Software:
    Im AVR-Studio sind unter Project->Configuration Options verschiedene Konfigurationen für Atmega644/1284P und GW/GBM angelegt um CPU-Paremeter umzuschalten und die Binarys nicht immer wieder zu überschreiben (jeweils extra Verzeichnis).
    In bidi_gbm.h und bidi_gw.h entscheiden die beiden Definitionen BIDI_GBM und BIDI_GW mit 0/1 jeweils ob ein Gateway oder ein GBM kompiliert wird.
    In bidi_gbm.c kann in der Routine init_bidi_gbm der Debug-Level für die Ausgabe am USB angepasst werden.
    GBM_MAPPING_DEFAULT definiert einen Versatz der GBM-ID zur Einordnung der Melderadressen in den Adressbereich der Zentrale (für DID und SID). GW_GBM_MAPPING_DEFAULT erledigt gleiches für den Versatz am Zugerkennungssystem. Damit kann man die jeweiligen Adressbereiche flexibel ausnutzen.

  • Änderungen
    • Dezember 2011: kleinere Ergänzungen, Hinweis auf Änderung 10 Ohm->5 Ohm
    • Februar 2011: Korrektur Beschreibung
    • Januar 2011: CPU Atmega1284P statt 644P, Schottky MBRS 140 ersetzt durch MBRS 240 (2A)