Problem mit der Modellbahnanlage namens Railcom.

[Rupert van Swol]

Hallo Forum,
wir haben ein Problem mit der Modellbahnanlage namens Railcom.
Ich benutze oft mehrere Züge in einer MIFAZ.
Dann ist es schön, die Railcom-Funktionen eines 2-Schienensystems zu nutzen.

Allerdings wird das automatische Fahren zu oft durch falsche Meldungen von Railcom komplett lahm gelegt.

Dies äußert sich darin, dass Decoderadressen über Railcom auf anderen MIFAZ erscheinen, ohne dass der physikalische Detektor dieses Mifaz aufgrund eines physikalischen Stromverbrauchers tatsächlich aktiv geworden ist.
In der Gerüchteküche wurde bereits ein Decodername genannt, da etwas nicht 100%ig protokolliert werden konnte, aber das Phänomen auch bei einer anderen Marke auftritt.
Dies wurde unabhängig voneinander von zwei anderen WDP-Benutzern festgestellt. Die genau das gleiche Problem hatten. 
Wir scherzen schon, dass dieses “lokale“ railcom-Problem durch die niederländischen Windmühlen verursacht wird.

Es ist nicht Windigipet, die berichtet und handelt nach dem, was sie erhält.

Ich habe jedoch einen Zweifelsfall, nämlich die Meldung einer unbekannten Decoderadresse, die nicht in der Zugdatenbank von Windigipet erscheint.
Die Frage ist, woher das Ausrufezeichen „!“ kommt, das nach der vierstelligen DCC-Decoderadresse erscheint.
Wenn es nicht von Windigipet kommt, was ich hoffe, dann kann der Zeigefinger deutlicher auf das verwendete System oder den Decoderhersteller hinweisen.
Wenn das Ausrufezeichen „! „tatsächlich von Windigipet gesetzt wird, dann stellt sich die Frage, warum eine DCC-Decoderadresse gemeldet wird, wenn sie bereits in der Zugdatenbank von Windigipet vorhanden ist.
Was ist der Grund dafür, dass dieser Status im Bruchteil einer Sekunde von unbekannt auf bekannt wechselt?

Ich habe das WDP-Daten logbuchvom 26. Januar beigefügt.

Mit freundlichen Grüßen

Rupert van Swol

[Markus Herzog]

Hallo Rupert

Stell bitte eine Datensicherung zur Verfügung, dann schau ich mir mal an wieso die Meldung erscheint, dass die Adresse nicht zu gewiesen ist.

Ich habe zwar einen Verdacht, aber ehe ich jetzt hier Aufsätze schreibe. Ist es für mich viel einfacher, das gegebenenfalls an eurer Datensicherung zu erklären.

Und das Ausrufezeichen ist übrigens nur ein Satzzeichen

Grüße
Markus

[Rupert van Swol]

Hallo Markus,
ich habe das Backup vom 24. Januar wiederhergestellt und es ist als Forumsdatei angehängt.
Bin sehr gespannt auf den krummen Nagel, den Du unbedingt finden willst.

Mit freundlichen Grüßen,
Rupert

[Markus Herzog]

Hallo Rupert,

ich will nicht unbedingt was finden, aber ich habe was gefunden ;-)

Also die Meldung war ja z.B. das am 4. Lodi-System ein Fahrzeug mit der Adresse 7754 gefunden wurde und diese Adresse keinem Datensatz zugewiesen werden kann/zugeordnet werden kann.
Dann schauen wir uns doch mal das Fahrzeug mit Adresse 7754 in der Fahrzeug-Datenbank an....und gehen auf die Registerkarte "Wartung/Zugerkennung" und was sehen wir da?
Dort ist nicht angehakt, dass das Fahrzeug auch über das 4. Lodi-System erkannt werden darf. Dort musst du bei den Fahrzeugen welche auch über das 4. Lodi-System erkannt werden sollen den Haken setzen. Ist bei anderen Fahrzeuge teilwseise auch gemacht, bei vielen fehlt aber auch das andere System.

Hättest du jetzt nicht in den System-Einstellungen das automatische Öffnen des Railcom-/Fahrzeug-Assistenten deaktiviert (oder mal in dem Dialog) hätte WDP dir auch vorgeschlagen diese Verknüpfung noch zu setzen. Steht ja auch in der zweiten Zeile der gelb markierten Meldung, dass dieser Assistenten helfen würde.

Man muss die Zugerkennung schon je Fahrzeug und Erkennungssystem aktiviert haben. Wieso macht WDP das nicht automatisch?
Weil es durchaus User gibt die gleiche Adressen auf unterschiedlichen Systemen parallel nutzen und daher muss der User schon die Erkennungszuordnung je System aktiviert haben oder nicht.

Grüße
Markus

[Rupert van Swol]

Hallo Markus ,
vielen Dank für diese nächtliche Schnüffelei.
Bin froh, dass Du etwas gefunden hast, was dieses unerwünschte Phänomen verursacht.
Auch ich bin etwas überrascht über deine Entdeckung.

Wenn man bedenkt, dass es sich bei dieser 4. Schnittstelle um den alten Lodi S88 Commander mit zwei angeschlossenen Lodi RM16+ handelt, die nur die Weichenstellung des verwendeten DCC-Kobaltantriebs überwachen.

Kurz gesagt handelt es sich bei dieser 4. Schnittstelle um den alten Lodi S88 Commander mit den beiden daran angeschlossenen Lodi RM16+, die keine Railcom-Fähigkeit haben, um Railcom-Nachrichten zu empfangen,
auch der zugewiesene DCC-Stromkreis, der von einem alten LS-Booster stammt, ist nicht mit einer Railcom-Abschaltung ausgestattet.

Kurzum, alles, was an diesem separaten DCC-Stromkreis railcom-bezogen sein könnte, wäre technisch und auch physikalisch nicht in der Lage, railcom-Meldungen zu erzeugen oder zu empfangen.

Das ist auch der Grund, warum ich diese 4. Schnittstelle in der Lok-Datenbank nicht angekreuzt hatte ( Registerkarte "Wartung/Zugerkennung" .  Das war also mein bisheriger Gedanke.

Werde ich eine Rückmeldung an den Hersteller geben   , wie es möglich ist , das dies noch passieren kann .

[Markus Herzog]

Hallo Rupert,

Kann es sein, dass ihr mal die Railcom Melder von dem einen auf das andere System verschoben habt?
Irgendwie passt für mich die Datensicherung nicht zu den Protokollen.

Grüße
Markus

[Rupert van Swol]

Hallo Markus, das mag stimmen, ich habe ein wenig herumprobiert, um zu sehen, ob die Railcom-Jumper auf dem alten Lodi S88 mehr oder weniger unscharf waren.
Aber ich werde trotzdem die Rückmeldung zu deiner Anleitung von gestern geben.

Ich habe keine Berichte mehr über unbekannte Decoderadressen gesehen. Also ist dieses Problem verschwunden.
Was bleibt, ist das ständige Springen der railcom-Adressen zu den Mifaz oder anderen Orten.
Oder noch schlimmer, alle Lokomotiven auf der Anlage stehen gemütlich auf 1 Detektoradresse und melden sich an oder ab.

https://youtube.com/shorts/yWMozA1jOe8

Macht es Sinn, ein neues Datenprotokoll und den geänderten Gleisplan zu senden.

Dieser Ausschnitt zeigt einen Wagen mit einem railcom Decoder auf einer Weiche , ohne die physikalische Stromerkennung aktiv . Alle Weichen haben eine Erkennung . Und die Lok 1900 ist mit ihrer railcom Adresse an einem anderen Ort . Aber ohne railcom ist das Leben mit windigipet gut.

Grusse
Rupert

[Markus Herzog]

Hallo Rupert,

Macht es Sinn, ein neues Datenprotokoll und den geänderten Gleisplan zu senden.

Nein macht es nicht, denn du zeigst ja schon, dass die meldungen ständig schon im Lodi FX kommen.
Ganz ehrlich ist aber auch die Frage, ob wenn viele Züge im miFAZ es dort überhaupt Sinn macht Railcom aktiviert zu haben auf dem miFAZ, denn WDP kann ja mit den Infos eh nur bedingt was anfangen, denn maximal kommt ja für WDP die INfo "Lok ist da", aber es ist ja z.B. gar nicht die Reihenfolge aus den Railcom-Meldungen zu ermitteln, denn die Meldereihenfolge via Railcom hat ja nix mit der physikalischen Reihenfolge auf dem Gleis zu tun.


Grüße
Markus

[supermoee]

. Aber ohne railcom ist das Leben mit windigipet gut.

Hallo Rupert

Kann ich so im Allgemeinen nicht bestätigen. Ich fahre mit Railcom mit BiDiB und habe absolut Null Probleme mit der Rückmeldung über Railcom. Die Loks werden alle da angezeigt, wo sie auch physisch stehen.

Das muss am Lodi System liegen, welches vielleicht gestört wird durch irgendwelche Ausseneinflüsse bzw. Interferenzen.

Gruss

Stephan

[Rupert van Swol]

Hallo Stephan,
Bin ein Ex BidiB Fahrer, bin aber aufgrund des Umfangs groß auf Lodi umgestiegen, die GBM Booster (ich hatte vier) konnten nicht mithalten.

Natürlich kann das Lodi-System auch fehlerhaft sein und die Lokomotive falsch melden oder die vom Decoder empfangenen Daten können auf dem Weg vom lokalen Detektor zum Lodi S88 LX falsch sein.
Derzeit ;
Eine Lok sendet ihr Railcom-Feedback in einem Austastintervall einer anderen Lok. Diese interne Fehlfunktion des Lodi GBM8v2 führt dazu, dass „irgendwie“ alle anderen Railcom-Decoderadressen, die sich auf den Gleisen der Modelleisenbahn befinden, unter einer einzigen Feedback-Adresse angezeigt werden.

https://youtube.com/shorts/yWMozA1jOe8

Diese beiden Punkte schließen sich nicht völlig aus, aber ich halte es für ziemlich unwahrscheinlich: Bei der Datenübertragung verwenden wir Prüfsummen und Sequenznummern und andere Softwareabschwächungen. Bei Problemen würden Fehlermeldungen erscheinen.

Wenn diese Falschmeldungen nur sporadisch auftreten, können sie herausgefiltert werden, aber meiner Meinung nach ist dies im Lodi-System nicht oder nur unzureichend der Fall, und bei der Filterung stößt man immer irgendwo an eine Schwelle, wo man dem Decoder einfach glauben muss ;-)

Ich bin nach wie vor der Meinung, dass man sich sehr ernsthaft mit dem sogenannten „Channel2 Debounce“-Algorithmus befassen sollte.

Rupert