Erläuterungen zur Software von OpenDecoder

Implementierung von RailCom®

    RailCom eine bidirektionale Erweiterung zu DCC. Dekoder können mit RailCom Ereignisse an die Zentrale zurückmelden. Für Weichendecoder sind dies insbesondere Befehlsquittierungen und Lagerückmeldungen der Antriebe.
    Opendecoder3 ist einer der ersten Zubehördekoder, welcher RailCom unterstützt. Für RailCom sind (verglichen mit einem normalen Decoder) sowohl Erweiterungen in der Hardware erforderlich, als auch zusätzliche Funktionen in der Software des Dekoders zu implementieren.
    (Anmerkung: Die Lagerückmeldung war bereits mit OpenDecoder2 über eine extra Ringleitung möglich.)

Der Ablauf bei RailCom

  • Aktionen in der DCC-Empfangsroutine:
    • Bei jedem Beginn eines DCC-Bits wird ein Zähler gestartet.
    • Wenn ein Endebit einer DCC-Nachricht erkannt wird, dann wird ein Flag (railcom_window) gesetzt.
    • Bei ersten Präambelbit werden dieses Flag und die beiden Flags der Kanäle wieder gelöscht. Zudem wird eine ev. erzeugte und CH2-Meldung gelöscht.
  • Aktionen in der DCC-Dekodierroutine:
    • Wenn die Dekodierroutine einen Accessory-Befehl (allgemein) erkennt, wird ein Flag (railcom_window_ch1) gesetzt.
    • Wenn die Dekodierroutine bzw. Aktionsroutine einen Accessory-Befehl für diesen Dekoder erkennt, wird ein Flag (railcom_window_ch2) gesetzt und die entsprechende Railcom-Meldung erzeugt und zum Absenden bereitgestellt.
  • Aktionen im Hauptprogramm:
    Es wird kontrolliert, ob:
    • railcom generell aktiviert ist,
    • das allgemeine Flag (railcom_window) gesetzt ist (Erkennung Austastlücke),
    • die jeweiligen Flags des Kanals eingeschaltet sind,
    • das zugehörige Zeitfenster für den jeweiligen Kanal erreicht ist.
    • Zusätzlich wird im Kanal 1 noch überprüft, ob überhaupt eine Meldung abzusenden ist.
  • CH1-Meldungen werden unabhängig von DCC Befehlen aktiv gesetzt. Dies kann z.B. durch eine Weichenrückmeldung oder durch Handverstellung verursacht werden.
    Die Task 'CH1_drop' versucht nun, diese aktiven Nachrichten an die Zentrale zu senden und zwar so lange, bis durch einen entsprechenden Befehl oder Abfrage angenommen werden kann, dass die Zentrale die Nachricht erhalten hat. 'CH1_drop' implementiert auch das back-off, also das zufallsgesteuerte Auslassen möglicher Sendezeitpunkte zur Kollisionsvermeidung.
  • CH2 Meldungen entstehen aus DCC-Befehlen und sind sofort nach dem Befehl zu senden. Diese Datagramme werden aus 'dcc_decode' bzw. 'action' erzeugt. Diese werden automatisch beim ersten Präambelbit auf wieder ungültig gesetzt.
  • Wenn das definierte Zeitfenster für einen RailCom-Kanal verstrichen ist, dann werden die jeweiligen Kanalflags wieder gelöscht.

Herstellen des zeitlichen Bezuges

    Da die Polarität des DCC-Signals bei der bisher verwendeten Empfangsroutine unerheblich war d.h. sich durch die Analysemethode von selbst korrigierte), ist auch die Phasenlage des Empfängers zum DCC Signal nicht bestimmbar. Dies ist aber für RailCom wichtig, weil sonst die Zeitfenster für das Senden von Meldungen nicht getroffen werden.

    Um die bisherige Empfangsroutine railcomfähig zu machen, ist also eine zusätzliche Polaritäterkennung erforderlich. Hierzu wird die zeitliche Lücke nach der Präambel ausgewertet:
  • Ist die Lücke zwischen letzter Eins und erster Null 116µs (also so lang wie eine Eins), dann wird das Signal phasenrichtig erkannt.
  • Ist die Lücke zwischen letzter Eins und erster Null jedoch 1,5*116µs, dann wird das Signal mit falscher Phase erkannt. Durch invertieren der aktiven Flanke des Interrupts wird die Phase umgedreht und somit der zeitliche Bezug sichergestellt.