Zitat von Vincent Hamp im Beitrag Kennst Du schon Traintastic?hab nur mal "ein bisschen" Fahren probiert, das ist ja nicht was die meisten Leute machen wollen die Traintastic installieren.
was genauer erwarten die meisten Leute?
Eine Belegtmeldung.
natürlich wäre Rückmeldung an der OpenRemise wünschenswert. Aber dann würde ich mir wünschen, dass es so in der Z21APP aussehen würde:
(hier ein Screenshotausschnitt aus der Z21APP, ein einfaches Oval, gesteuert per schwarzer Z21 mit Roco 10808 RM-Modul.)
Zitat von Vincent Hamp im Beitrag #106Bugfix RailCom Kanal 2 Rückmeldungen wurden ignoriert wenn sich in Kanal 1 mehrere Meldungen überlagerten
bin derzeit im St. Vinzenz zugange . Test werden sich noch etwas verzögern... Obigen Satz verstehe ich allerdings nicht, zumindest nicht komplett. Ist naturlich alles auch eine Frage des Timings. Kanal 2 Meldungen der Lokadresse (mit durch den lokalen Detektor ergänztem Ort einschließlich Aufgleisrichtung) setzt voraus, dass dieentsprechende Adresse von der Zentrale adressiert wurde und der Decoder unmittelbar einen ACK gesendet hat, die von auswertenden Firmware/Software zueinander zugeordnet und direkt auf einem Display angezeigt wird oder irgendwohin weitergeleitet wird, wo sie dem Modellbahner angezeigt oder von einem Steuerprogramm verarbeitet werden kann.
Wenn also eine Adressen per Kanal 2 gemeldet werden kann, bleibt nur die Frage wie aktuell ist die Info wirklich, da - je nach Anzahl der Loks im Refreshspeicher und der Priorisierungs-Strategie der jeweiligen Zentrale - eine immense Verzögerung auftreten kann bis die Information komplett ist und wirklich verlässlich zur Verfügung steht.
Hallo Vincent, auch wenn OT: ich möchte Dir hier mal ein ganz großes Kompliment machen, was Du neben Deinem Job und Deinem privaten Leben hier für ein professionelles Produkt auf die Beine gestellt hast und es nicht nur am Leben erhältst, sondern ständig verbesserst und weiter entwickelst. Leider kann ich Dir bei diesem Projekt hier wenig helfen, weil Programmierung nicht mein Metier ist. Aber ich sage - sicher in vieler Namen hier - einfach mal: DANKE!!!!!!! Viele Grüße - Frank
Zitat von vikr im Beitrag #107Test werden sich noch etwas verzögern... Obigen Satz verstehe ich allerdings nicht, zumindest nicht komplett.
Ganz simpel. RailCom hat bis zu 8 Datenbyte, waren die ersten beiden kaputt wurden die restl. 6 nicht beachtet.
Zitat von frank_II im Beitrag #108Hallo Vincent, auch wenn OT: ich möchte Dir hier mal ein ganz großes Kompliment machen, was Du neben Deinem Job und Deinem privaten Leben hier für ein professionelles Produkt auf die Beine gestellt hast und es nicht nur am Leben erhältst, sondern ständig verbesserst und weiter entwickelst. Leider kann ich Dir bei diesem Projekt hier wenig helfen, weil Programmierung nicht mein Metier ist. Aber ich sage - sicher in vieler Namen hier - einfach mal: DANKE!!!!!!! Viele Grüße - Frank
Danke für die netten Worte, ganz uneigennützig ist es aber nicht da ich das Gerät auch bei der Arbeit verwende um "mal schnell" was zu testen.
Zitat von Vincent Hamp im Beitrag #109Ganz simpel. RailCom hat bis zu 8 Datenbyte, waren die ersten beiden kaputt wurden die restl. 6 nicht beachtet.
das ist korrekt aber nicht ganz so einfach. Meines Wissens sollte die Prüfung für beide Kanäle völlig unabhängig erfolgen. Werden also im Kanal 1 Bytes als formal ungültig erkannt und verworfen, können - im Kanal 2 derselben Lücke - dennoch gültige Bytes und Nachrichten gelesen und anerkannt werden. Gültige Kanal 2 Werte sollten eigentlich auch frühere Kanal 1 Werte (insbesondere auch erkannte Adressen) toppen. Es kann auch da zu ganz unterschiedlichen Timing-Überraschungen kommen.
Ergänzung: Leider sind "gultig" erkannte Nachrichten in Kanal 1 keine Garantie dafür, dass Loks mit diesen Adresse auf dieser Anlage überhaupt existieren und deshalb wird gefordert auf irgendeine Weise organisatorische Weise sicherzustellen, dass sich nur ein Railcom-Decoder auf einem Abschnitt befindet, wenn man die Adressen zuverlässig erkennen will. Aber wenigstens eine Fehlermeldung des Detektors "Achtung ich erhalte Kanal-1-Meldungen von mehr als einer Railcom-Adresse" wäre hilfreich, um die erhalteten mit Vorsicht zu behandeln und nicht sofort Geisteradressen daraus zu machen, die zwingend den Eingriff des Benutzers erfordern. Befinden sich mehrere Adressen auf einem Abschnitt bekommt man mit Glück vier Adressen als gültig angezeigt und nur mit viel Glück die der beiden tatsächlich sendenden Decoder. Es ist darüber hinaus unklar wann bei mehreren langen Adressen die bieden Teile der Railcom-Kanal-1-Nachrichten zusammengesetzt sind und welche zueinander passen und wie lange diese Info als aktuell angesehen werden soll. Es ist leider auch Adressen die Antworten nirgens definiert, wie ein Modellbahn-Steuerprogramm damit tunlichst umgehen sollte.
Der Vorteil von Kanal 2 ist die Zuverlässigkeit der Antwort nur auf eine gezielte Anfrage der Zentrale an diese DCC-Adresse. Das Problem bei vielen Loks (es reichen schon zwei Dutzend im Refresh der Zentrale, die nichtmal selber fahren müssen) auf der Anlage ist, dass nicht klar ist wann der Decoder, der gerade einen lokalen Detektorabschnitt betreten hat, von der Zentrale angesprochen wird damit er seine Qittung loswerden kann (und ob die dann auch wirklich vom Detektor korrekt empfangen werden kann.
Thema drucken
Antworten
. Test werden sich noch etwas verzögern... 
H0-Modellbahnforum.de - das Forum mit der Forumbahn!
»
Technik und Steuerung von Fahrzeugen und Anlage
»
Software
»
OpenRemise - Neue Open Source Zentrale / Programmer
15.05.2026 13:08 (zuletzt bearbeitet: 15.05.2026 21:17)
