OpenDCC GBM16, Gleisbesetztmelder / BiDi-Belegtmelder

FAQ

    Hier häufig gestellte Fragen und Antworten rund um den BiDi-Belegtmelder.
  • Wie ist der Status des Projekts?
    Hardware?
      Der GBM hat Serienstand erreicht, Version 1.4. Platinen hierfür sind auf Anfrage als Teil einer Musterbestellung verfügbar (s.u.).
    Software?
      Der GBM erkennt Adressen und Belegtmeldung sowie CV-Rückmeldung auf allen Kanälen (parallel), die sind über Xpressnet und eine OpenDCC Zentrale abrufbar. Als direktes Hostinterface ist HSI88 oder BiDiB wählbar.
      Eine genauere Status-Übersicht findet sich in der Versionsübersicht und im Forum.
    BiDi?
    Mittlerweile ist die lizenzrechtliche Seite geklärt, OpenDCC hat eine offizielle Lizenz der Fa. Lenz GmBH, Giessen, die unter dem Namen Railcom vermarktete Rückmeldetechnik zu verwenden. Bitte die Lizenzbedingungen beachten. Der GBM unterstützt railcom für Adressmeldungen und Geschwindigkeitsmeldungen. Des weiteren hat OpenDCC eine Lizenz für railcom+ (Fa. ESU, Ulm), hier werden weitere Funktionen folgen.
  • Gibt es fertige Platinen?
    Es gibt noch keine Serienleiterplatten, jedoch werden gelegentlich Sammelbestellungen von Musterplatinen durchgeführt. Hier sind fallweise PCBs verfügbar. Eine Leerplatine für trackproc (GBM16T) und controlproc (GBM16TC) kostet 27,90. Es gibt aber mittlerweile den GBMBoost!
  • Was kostet in etwas ein fertiger Belegtmelder?
    Hier kommt es natürlich auf den Einkauf der Bauteile an, der blaue C ist oft nicht der absolute Billigheimer. Folgende grobe Kalkulation (bei Einzelkauf via reichelt) kann man annehmen:
    Prozessoren:14,00
    USB, XP, LM317:7,00
    Anschlußklemmen:7,00
    Dioden:7,00
    LEDs:4,00
    Cs:2,00
    Rs:2,00
    Platine:27,90
    Es ergeben sich ca. 70€, was je Rückmelderabschnitt in der Größenordnung zwischen 4€ und 5€ bedeutet.
  • Wo kann ich den Belegtmelder anschließen?
    Gleisseitig eignet der Belegtmelder sich besonders für DCC, die Stromverbrauchsmessung ist mit dem DCC-Signal synchronisiert. Auf der Zentralenseite bzw. PC-Seite ist ein gleichzeitiger(!) Anschluß an Xpressnet, USB und S88 möglich. Anstatt S88 ist auch BiDiB möglich. Allerdings muß man hier auf die Masseführung achten: alle angeschlossenen Bussysteme müssen gleichen Massebezug haben!
  • Was passiert bei verschiedenen Rückmeldesystem bzw. Abschnitten ohne Rückmelder an den Übergängen?
    Wenn Rückmelde-Systeme mit unterschiedlichen Spannungsabfall an der Quelle und am Gleis (eben bei der Überfahrt) verbunden werden, bleibt nur das System mit dem geringeren Spannungsabfall im Eingriff. Der Strom sucht sich den Weg mit dem geringsten Widerstand. Kombiniert man also Meldeabschnitte mit Spannungsabfall (im Fall des GBM16T von 0,3V bis 0,4V) mit Abschnitten ohne Spannungsabfall, so wird bei Überfahrt der Strom so lange wie möglich über den Pfad mit geringerem Abfall fließen, d.h. einen Lok wird erst erkannt, wenn sie vollständig im überwachten Abschnitt eingefahren ist. Das führt zu Unsicherheiten im Bremspunkt.

    Ein weiteres Problem bei zu unterschiedlichen Spannungsfall ist die railcom-Meldung: Bei railcom schickt die Lok ja rückwärts einen Strom zum Booster. Wenn jetzt nun z.B. die Lok in einem Abschnitt mit hohem Spannungsabfall steht (z.B. konventioneller S88-Melder mit 1,4V) und sich ein günstigerer Weg als über den Booster z.B. über einen beleuchteten Waggon in einem Abschnitt des GBM16T ergibt, wird der dortige Detektor diese railcom-Meldung lesen. Plötzlich hat dann der Waggon einen Dekoder drin ...

    Man sollte also darauf achten, dass das Spannungsniveau überall gleich ist.
  • Habe ich es richtig verstanden, ein Controlprozessor kann 4x 16Port GBM managen?
    Ja, das ist richtig. Auf dem Controlproc sind neben dem direkt angekoppelten Trackproc noch 3 weitere Steckplätze zum Anschluß weiterer Trackproc. Diese werden mit Flachbandkabel, 6-polig, 2mm-Stecksystem verbunden.
  • In der NMRA wird für einen Bidi-Detektor ein maximaler Spannungsabfall von 55mV bei 34mA angegeben, hier ist es mehr. Stört das?
    Die Spec in der NMRA richtet sich insbesondere an die Reihenschaltung von Belegtmelder, Detector und ev. noch ABC Bremsstrecke. Der Dekoder soll hier in Summe nicht mehr als 2,2V sehen. Der OpenDCC GBM macht bei den normal vorgesehenen Meßwiderständen von 22 Ohm einen Spannungsabfall von ca. 250mV, weitere Spannungsreserven z.B. für Belegtmelder entfallen. Der Gesamt-Fußabdruck des GBM ist also extrem klein. Eigentlich ist das ein Belegtmelder mir sehr geringem Spannungsabfall, der auch BiDi kann (mit Spannungsabfall 0V).
    Wenn man die Meßwiderstände kleiner wählen würde, dann sinkt die Empfindlichkeit für Belegtmeldung durch Widerstandsachsen und eine Messung mittels schwachem Ersatzstrom bei Ausfall des Gleissignales (wenn die Booster abgeschaltet sind) wird technisch zunehmend schwieriger. Unter Verzicht auf diese Empfindlichkeit kann man auch mit dem GBM16T den Spannungsabfall der NMRA einhalten, für die Analysesoftware ist das kein Problem.

    In der Railcom-Spec V0.1 vom Juli 2011 wird ein maximaler Spannungsabfall des Detektors von 200mV definiert. Dafür müssten die Sensewiderstände auf 5,6 Ohm geändert werden. Bedingt durch diese Änderung ist eine andere Bitschwelle in der Software erforderlich (BIDI_THRESHOLD). Bei geänderten Sensewiderständen ist daher eine andere Firmware erforderlich.
  • Wie funktioniert die Polaritätserkennung?
    Wenn eine Lok eine BiDi Nachricht absendet, so sendet sie auf ihrer (in Fahrtrichtung gesehen) rechten Gleisseite (rotes Dekoderkabel). Der GBM erkennt die Stromflußrichtung (hierbei wird nur der CH1-Kanal ausgewertet) und generiert daraus die gemeldete Richtung. Ein gesetztes Richtungsbit bedeutet, dass die Lok mit Ihrer linken Seite (bei Blickrichtung in Fahrtrichtung 1) mit der Gleisseite verbunden ist, in welcher der Detektor installiert ist. An der linken Seite ist bei Verdrahtung mit NEM-Farbe der Radschleiferanschluß in schwarz. Das Richtungsbit ist also davon abhängig, in welcher Gleisseite der Detektor installiert ist.
    Das gesetzte Richtungsbit wird in den Debugausgaben als '-' oder '^' angezeigt, ein nicht gesetztes Richtungsbit als '+' oder 'v'.
    Diese Polarität wird als Richtungsbit auch an die Zentrale bzw. den PC gemeldet. Des Richtungsbit bezeichnet also die Aufgleisrichtung, nicht die Fahrrichtung.
  • Wie schnell ist die Adresserkennung und von was hängt das ab?
    Adresserkennung erfolgt gleichzeitig in Channel 1 und Channel 2. Diese können im Dekoder separat aktiviert werden (CV28).
    • Channel 1 ist der 'Broadcastkanal', hier kann eine Lok unabhängig von der DCC-Ausgabe erkannt werden. Um Fehlerkennungen zu vermeiden, filtert der GBM16T mehrere Nachrichten und erst nach einer einstellbaren Anzahl fehlerfreier Adresserkennungen wird diese Adresse auch an dem PC gemeldet. Die Erkennung dauert üblicherweise ca. 100ms - 130ms.
    • Channel 2 ist der Kanal, in dem nur der angesprochene Dekoder antworten darf. Damit ist eine Adresserkennung nur möglich, wenn die Lok auch angesprochen wird und sie hängt auch vom Lokstack der steuernden Zentrale ab. Die Erkennung dauert vom 50ms (be wenigen aufgerufenen Loks) bis zu 600ms (bei sehr vielen Loks).
      Channel 2 ermöglicht Erkennung und Unterscheidung mehrerer Dekoder auf einem Abschnitt. (bis zu 4)
  • Was bedeutet 'gleichzeitige' Auswertung? Der GBM16T hat keine fest zugeordneten Railcomerfasser, sondern alle 16 Eingänge werden dynnaisch auf die Erfasser geschaltet. Dabei werden neu belegte Eingänge sowie Eingänge, auf denen der aktuell in der DCC-Nachricht angesprochene Dekoder zugeordnet ist, bevorzugt. Es sind immer mind. 4 Erfassungsschaltungen gleichzeitig aktiv.
    Durch diese dynamische Zuordnung und die Parallelverarbeitung ergibt sich im realen Betrieb eine quasi gleichzeitige und schnelle Erkennung auf allen 16 Kanälen.
  • Wie viele Dekoder können pro Abschnitt erkannt werden? Bis zu vier unterschiedliche Dekoders werden zugleich in einem Abschnitt erkannt.
  • Ist das schwer zu löten?
    Das ist immer relativ zu betrachten: Es ist kein Reflow-Löten erforderlich und es kann mit normalen SMD-Lötkolben gelötet werden, daher leicht. Es sind da einige recht kleine SMD-Teile, daher schwer.
    Der ATXmega hat 0,5mm Pitch (=Beinchenabstand), das neigt gerne zu Kurzschlüssen. Ohne optische Hilfsmittel und Entlötsauglitze: fast unmöglich!
  • Warum wurden keine größeren, leichter lötbare Bausteinen verwendet?
    Der GBM basiert auf einem vollkommen neuen Ansatz, BiDi zu detektieren - dazu braucht es einen leistungsfähigen, hochintegrierten Prozessor wie den ATXmega. Und den gibt es leider nur in TQFP100 oder noch kleinerem Gehäuse.
    (Zudem ist SMD Löten einfacher als man zunächst vermutet.)
  • Wie unterscheiden sich verschiedene BiDi-Melder voneinander? Hierzu ein paar Fragen, die man beim Vergleich abklären sollte:
    • Kann der Detektor die normale Belegtmeldung auch?
    • Welche Empfindlichkeit hat die Belegtmeldung - werden Widerstandsachsen sicher erkannt?
    • Wie ist das Verhalten des Belegtmelders bei Nothalt der Anlage - bleibt die Meldung erhalten?
    • Kann der Detektor die Aufgleisrichtung der Lok erkennen?
    • Kann der Detektor Loks auch nur anhand von Bestätigungsnachrichten erkennen oder braucht er unbedingt Channel 1 Broadcast?
    • Kann der Detektor Nachrichten von zwei oder mehr Loks in einem Abschnitt unterscheiden?
    • Wieviele echte Empfänger sind je Gleis vorhanden? Und wenn gemultiplext wird, nach welchem Verfahren erfolgt das? Werden Quittungen einer Lok sicher erkannt?
    • Wie schnell kann eine neue Lok erkannt werden?
    • Werden weitere BiDi-Nachrichten wie z.B. Neuanmeldung, Istgeschwindigkeit oder CV-Quittungen erkannt?
    • Ist das Busprotokoll offen und zukunftssicher?
    • Kann die Empfangsquittung eines Lokbefehls an die Zentrale übermittelt werden (Gleisausgabe-Optimierung)?
  • Bei mir geht der S88-Bus nicht?
    Das kann seine Ursache in einer gesetzten JTAG Fuse am ATXmega haben. Wenn diese gesetzt ist, funktionieren die S88-Ansteuerleitungen nicht.
  • Wenn ich am ControlProc G<cr> eingebe, dann antwortet dieser mit S88:on XP:off TrackProc: 0:n.c. 1:n.c. 2:n.c. 3:n.c.
    Wenn sich ein TrackProc mit n.c. (=not connected) meldet, dann 'sieht' der ControlProc denn Trackproc gar nicht, d.h. TP_DETECT ist high. Ursache kann ein fehlerhaftes Kabel sein oder die Lötbrücke am Trackproc ist nicht geschlossen.
  • Bei mir kommen die Meldungen immer mit DID = 0
    Hier kann der Fehler in der Verbindung von ControlProc zum Trackproc liegen. Die DID wird dann nicht korrekt angefordert und bleibt auf 0.
  • Wie weit dürfen GBM16T und GBM16C voneinander entfernt sein?
    Empfohlen ist max. 1m. Ein Betrieb mit 3m ist möglich, dabei ist dann allerdings auf eine Leitungsführung getrennt von störenden Leitungen wie Gleiszuführungen zu achten. Die interne Übertragung zwischen GBM16C und GBM16T erfolgt mit 250kBaud und 3.3V Pegel und ist mit CRC und fortlaufender Nachrichtennummer abgesichert.
  • Welchen Optokoppler kann ich verwenden?
    Die interne Daten-Übertragung läuft mit 250kBaud. Ich habe wegen des geringen Stromverbrauch und der direkten Ansteuerung aus dem Prozessor vollintegrierte 'Digital Isolator' verbaut, z.B. ADuM1100AR oder ADuM1100BR. ISO721 von TI ist eine weitere mögliche Alternative.
    Für die CMD-ACK-Leitung reicht ein einfacher Standard-Optokoppler.
  • Wozu dient CMD-ACK, brauche ich das überhaupt?
    CMD-ACK teilt der Zentrale über einen einfachen Open-Collectorring mit, dass der Dekoder das letzte DCC-Kommando erfolgreich empfangen hat. Die Zentrale kann darauf die Befehle für die Lok aus dem Wiederholungs-Puffer nehmen und so mehr bzw. schnelleren Befehlsdurchsatz auf DCC erreichen. Wenn das ACK nicht ankommt, geht es so wie bisher. In diesem Fall einfach die Bauteile weglassen.
    CMD-ACK wird nur von BiDiB unterstützt.
  • Was ist Secure-ACK?
    Secure-ACK ist eine zuschaltbare Eigenschaft im Rückmelderprotokoll, welche für eine perfekte Absicherung der Rückmelderübertragungen sorgt. Bisher war es so, dass eine Rückmeldung an den PC gesandt wurde - ging diese (z.B. auf Grund einer Störung) verloren, nun, dann war sie halt weg. Wenn es z.B. gerade der Haltmelder für eine Zugfahrt war, dann wird diese Zugfahrt nicht anhalten und das kann ziemlich üble Folgen haben. Auch ein Ausfall eines Rückmelders hatte ähnlich Konsequenzen.
    Secure-ACK löst das Problem: die Belegt-Meldungen werden vom PC wieder in den Rückmelder zurückschreiben. Dieser führt einen Vergleich durch und wiederholt fallweise die Nachricht. Ebenso wird die Nachricht wiederholt, wenn die Bestätigung innerhalb einer bestimmten Zeit ausbleibt.
  • Der GBM16T spinnt, macht sporadische Belegungen, die ich mir nicht erklären kann
    Hier wurde der Ferrit in der Zuleitung von VCC zur Analogversorgung vergessen. Der Prozessor mißt zwar Werte, diese driften aber stark (weil ja keine gültige Versorgung anliegt).
  • Kann ich den GBM16T für 3L-Gleis (Wechselstrom, Märklin) einsetzen?
    Der GBM16T kann bei 3L-Gleis sowohl für die Belegtmeldung und Railcom-Auswertung der Lok verwendet werden, als auch für das Erkennen von Achsen.

    Lok: DCC1 kommt an die Außenschiene, DCC2 (bzw. die Meldeeingänge des GBM16T) kommt an die getrennten Mittelleiter. Damit kann der Dekoder erkannt werden und Railcom ausgewertet werden.
    Achsen: Zur Achs-Erkennung wird eine Außenschiene isoliert. Dieser isolierte Abschnitt wird mittels eines Widerstandes 10kOhm mit dem Stromfühlereingang des GBM16T verbunden. Eine leitende Achse verbindet nun bei Überfahrt die bisher isolierte Schiene mit DCC1 und es fließt Strom von DCC1 über die Achse, den Widerstand 10k zum GBM16T. Dort über Sensor zu DCC2 und dadurch wird eine Belegung erkannt.
  • Kann man auch Railcom bei Accessorydekodern benutzen?
    Ab Version 2.06.03 sind die entsprechenden Dekodierroutinen enthalten. Da Accessory-Dekoder nicht permanent senden und daher der GBM16T nicht 'weiß', an welchen Ausgang die Accessorydekoder angesachlossen sind, muß man in der CV40 den für Accessory benutzten Eingang einstellen. (Voreinstellung: Eingang 0)

Versionsübersicht GBM16T:

  • V2.07.01
    17.11.2018: POM count reset bei CV Wechsel
  • V2.07.00
    23.07.2018: added distance message (DYN_DISTANCE_ENABLED)
  • V2.06.13
    26.04.2018: clear_idmode_occupancy; Bugfix bei MO 0
  • V2.06.11
    07.10.2017: bugfix bei der Bremse auf Confidence, Added g_current_maxhold (detect track with short); SECACK_ON kann Werte zw. 20 .. 100; added shift of seed when DISCONNECTED
  • V2.06.04
    19.04.2017: Bugfix im Reverser (dieser hatte sich in der 2.06.00 eingegeschlichen), bugfix im Decoding von consist-Adressen
  • V2.06.03
    24.03.2017: Zusätzliche Kanalwahl bei POM für Accessory
  • V2.06.02
    23.03.2017: Neu: POM für Accessory
  • V2.06.01
    22.02.2017: Neu: Backup des Offsetabgleichs (kein erneuter Abgleich für folgende Updates erforderlich)
    13.01.2017: Neu: hochgenaues Timestamping für Geschwindigkeitsmessung und nahtloses Einmessen.
  • V2.05.01
    13.01.2017: Zurücksetzen des Channel Entprellers, wenn eine Kollision erkannt wird.
  • V2.1.1
    17.04.2014 ID01 und ID02 (Channel 1 Nachrichten) werden im Channel 2 als Geistermeldungen interpretiert und verworfen. Damit lösen inkompatible Dekoder wie LDG30 und LD-G-32 keine falsche Adressmeldung mehr aus.
  • V2.1.0
    11.04.2014 Unterdrückung Programmiermodus, wenn der GBMBoost in Programmiermode ist - damit kann man nicht versehentlich beim Lokprogrammieren den GBM16T mit verstellen.
  • V2.0.7
    04.01.2014 Neue Auswertefunktion für DCC Quality
  • V2.0.5
    04.05.2013 weitere Ergänzung bei dem Kehrschleifenfunktionen, bugfix bei der Geschwindigkeitsmessung
  • V2.0.3
    26.05.2013 Zusatzfunktionen für Kehrschleifen
  • V2.0.2
    20.03.2013 Modifikationen an der Auswerteroutine (insb. hilfreich für ESU Lopi3 und Lopi4, ältere Firmwarestände)
  • V2.0.0
    16.02.2013 Neues Interface zum Controlproc (erfordert eine Controlprocversion > 2.x)
            Zusätzliches Filter gegen Falschmeldung bei mehreren Loks auf dem Gleis
            Filter und Glättungsalgorithmus für Geschwindigkeitsmeldungen
            Erkennung von bis zu 4 verschiedenen Dekodern auf dem Abschnitt.
            Verbesserte Erkennung durch Offsetabgleich (nach Firmware-Update einmalig durchzuführen)
            Unterstützung atxmega128a1u
            Integrierte Meßstrecke für Geschwindigkeitskontrolle
  • V1.2.3
    26.11.2012 Der Soft-UART ist modifiziert und mit größeren Fangebereich ausgestattet. Damit sollten Decoder mit ungenauem Takt besser erkannt werden.
    26.11.2012 Die railcom-Dekodierung ist neu und umgestellt auf aktuelle Spec plus legacy Nachrichten.
    26.11.2012 Es gibt jetzt einen sog. Lokmanager, welcher
            a) CV-Meldungen filtert und         b) Speed filtern mitteln und filtern könnte (noch nicht aktiviert)         c) vorbereitet ist, um Anmeldevorgänge (railcom+) und Block-CV zu beherrschen.
  • V1.1.0
    30.03.2012: Bugfix in der Kehrschleifenansteuerung bei aktiviertem railcom.
  • V1.0.1
    26.12.2011: Weitere Befehle zur Konfiguration der Kehrschleife.
    19.12.2011: Zusatzmodul Kehrschleife integriert. Ansteuerung der Ersatzstromquelle.
  • V0.06
    16.02.2011: Verbesserung des Fangbereiches des BiDi-Receivers: dieser kann jetzt Taktabweichungen des Senders von 2,5% tolerieren.
    16.02.2011: Erweiterte Triggermöglichkeiten zum Dump eines fehlerhaft empfangenen BiDi-Paket. Damit steht ein Mittel zur Analyse von Fehlern bereit.
  • V0.01
    04.12.2010: neu dazu: check auf fehlerhaft programmiertes EEPROM

Versionsübersicht GBM16C:

  • V2.01.00
    25.01.2014: Anpassung für BiDiB 2014, Username, Confidence
  • V1.01
    17.03.2011: Xpressnet: Fifo-Überlauf bei zu vielen Adress- und Belegtmeldungen im Power-Up verhindert.
    17.03.2011: Durch Stecken von Jumper0 kann die aktuell gewählte Hostemulation deaktiviert werden und es wird das Debug-Interface geladen.
    12.03.2011: BiDiB-Hostprotokoll neu dazu (Aufruf mit 'eb')
  • V1.00
    04.12.2010: first release