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.
  • 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.
  • 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!
  • 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üssen die Sensewiderstände auf 5,6 Ohm geändert werden. Bedingt durch diese Änderung ist eine andere Bitschwelle in der Software erforderlich (BIDI_THRESHOLD).
  • 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 Stomflußrichtung (hierbei wird nur der CH1-Kanal ausgewertet) und generiert daraus die 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.
  • 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 Richtungserkennung?
    • Kann der Detektor Loks auch nur anhand von Bestätigungsnachrichten erkennen oder braucht er unbedingt Channel 1 Broadcast?
    • Kann der Detektor Nachrichten von 2 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. Istgeschwindigkeit oder CV-Quittungen erkannt?
  • 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?
    Das habe ich leider noch nicht ausprobiert. 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 GBM 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).

Versionsübersicht GBM16T:

  • 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:

  • 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