windigipet.de
Win-Digipet - deutsche Foren => Win-Digipet allgemein => Thema gestartet von: Rupert van Swol am 03. Februar 2025, 14:35:28
-
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
-
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
-
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
-
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
-
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 .
-
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
-
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
-
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
-
. 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
-
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
-
Hallo Zusammen
Ich hole diesen Thread wieder raus, denn heute ist mir auch passiert, was Rupert hier gemeldet. Also auch BidiB kann davon betroffen werden.
Die Automatik lief ohne Probleme. Ein Zug hielt auch richtigerweise im Bahnhof an. Nach 40s sollte er wieder losfahren. Während alle anderen Züge richtig fuhren, fuhr dieser nicht mehr los. Ein Blick auf das GBS zeigte, dass im iFAZ plötzlich eine andere Lok drin stand als physisch drauf, und wegen der Matrix konnte diese nicht mehr weiter fahren. Das kuriose, die falsche Lok war nicht mal physisch auf der Anlage, konnte daher nicht mal woanders rückmelden. In der Lokdatenbank war die Lok aber noch auf Anlage. Die Anlage ist schon stundenlang gelaufen. Das war aber noch nie passiert.
Ich habe mittlerweile auch die Zugüberwachung eingeschaltet. Diese hat schon 2 Mal angesprochen und gesagt, dass Lok xy nicht in der Position war, wie erwartet. Eine Überprüfung zeigte aber, dass alles i.O. war. Die Lok wurde ein Block weiter angezeigt. Ich dachte aber, dass das eine Fehlschaltung wegen der Folgefahrstrasse war. Ich vermute aber, dass das selbe Phänomen dahinter stecken kann.
Wenn Railcom so unzuverlässig funktioniert, dann kann man sich das Geld sparen.
Gruss
Stephan
-
Hallo Stephan,
hast du in letzter Zeit mal Decoder in Loks geupdatet? Ich habe u.a. in einem der letzten Austausche mit BiDiB-Entwicklern mitbekommen, dass es seitdem ein Hersteller in seinen Dekodern einfach ausgedrückt die Railcom-Sendeleistung hochgedreht habe es Probleme gäbe. Sie mir aber bitte nach, dass ich den Herstellernamen nicht nennen werde, da ich als WDP-Mitentwickler hier neutral bleiben möchte.
Grüße
Markus
-
Hallo Markus
Nein, ich habe keine Loks geupdated in letzter Zeit. Das liegt schon länger zurück. Ich habe zwei neuere Dekoder eingebaut bzw. einer war vom Werk aus drin. Aber beide Loks standen heute nicht auf dem Gleis, als das passierte. Eine davon ist aber die falsche Lok.
Die einzige Änderung die ich vor den Automatiklauf heute Abend gemacht habe, war die Einstellung des Boostermanagements in WDP, der jetzt auch richtig funktioniert und angezeigt wird.
Ich werde sas Phänomen weiter beobachten.
Gruss
Stephan
-
Hallo zusammen,
da ich auch schon seit über fünf Jahren BiDiB fahre konnte ich dieses so noch nicht feststellen.
Was ich aber als letztes geändert habe war ein Update auf einen Zimo Decoder MS440 D auf 5.5.
Danach wird bei einen Neustart der Anlage die Lok nicht mehr wie vorher die Fahrtrichtung angezeigt.
Sie bleibt auf Neutral die Anzeige, heißt es werden nur der obere und der unter Strich in Rot angezeigt.
Aber kein seitlicher Strich (West / Ost / Oben / Unten) wie bei den anderen Loks für die Anzeige der Fahrtrichtung angezeigt.
Vermutlich ist bei Railcom eh Luft nach oben und noch nicht alles ausgeschöpft.
Aber es grundsätzlich zu verteufeln finde ich nicht so gut.
Wo wären wir heute wenn die Vordenker nicht die Schritte wagen würden?
- wir hätten Ultraschall, keine Röntgenbilder, kein Strom, kein MRT usw.
- kein Airbag, keine Gurtstraffer, kein Navi, keine Rückfahrkamera usw.
Gibt noch viele weiter Beispiele in der Medizin, im Beruf usw…
Aber eins dürfen wie nie vergessen, wenn sich Hersteller nicht so ganz an die Norm halten oder an die Vereinbarungen, die einst mal getroffen wurden um die nötigen Schritte in die Zukunft zu realisieren zu können.
Möchte aber kein Shitstorm auslösen, es ist meine Meinung zum Thema Railcom, die jeder haben darf.
Gruß Kurt
-
Hallo Kurt
da will keiner einen Shitstorm auslösen. Wir besprechen das hier. Ich hatte auch bis jetzt monatelang kein Problem.
Das wäre Schade, wenn eine Unzuverlässigkeit des Systems die ganzen tollen Features einer Software zunichte macht.
Gruss
Stephan
-
Hallo zusammen,
Bin froh zu lesen, dass das Phänomen kein Einzelfall mehr ist .
Es handelt sich also um zwei völlig unterschiedliche Hardware-Systeme .
Gott sei Dank funktioniert WDP2021 auch ohne railcom einwandfrei.
Na dann liegt es ja an den Hardwareherstellern, die uns railcom verkaufen wollen, das Problem zu lösen.
Ob das Produkt Railcom noch eine Zukunft hat, wird die Zeit zeigen.
Aber ich warte nicht mehr darauf.
Gruss
Rupert
-
Hallo Rupert, hatte so ein ähnliches Problem. Bei mir war es so, das plötzlich gleich mehrere Fahrzeuge auf einem FAZ standen, die wo anders waren bzw. standen ;D Nachdem ich meinen Booster getauscht habe trat dieses Problem nie wieder auf! Grüße Ingo
-
Hallo,
das ist mir auch schon mehrmals passiert.
Alles sehr nachvollziehbar.
Ich dachte auch, es läge an den Boostern, die haben sich auch schon geändert.
Die deutsche Modellbahnindustrie zeigt mit dem Finger auf die anderen und beschwert sich über Protokolle.
Solange nur ein Decoder an einem Decoder angeschlossen ist, ist alles in Ordnung.
Und das gilt für 99 % der durchschnittlichen Benutzer. (Diese 99 % wurden beiläufig erwähnt).
Die meisten Demogleise und auch Testgleise haben jedoch ein gemeinsames Merkmal, das die englischen Modellbahner den Typ "pure watching-the-trains-go-by design" nennen.
Solange nur 1 dcc-Decoder an 1 Detektor angeschlossen ist, ist gegen den locale railcom melder nichts einzuwenden.
Und das ist bei einer Eisenbahnmesse oder einem Testkreis eines Betatesters immer der Fall.
Auffallend ist, dass es kaum Demostrecken mit Rangierbetrieb gibt, wo zwei DCC-Decoder oder gar mehrere DCC-Decoder auf 1 Marker platziert sind.
Movi- 1
https://youtube.com/shorts/FVqqeegwd1g?feature=share
In diesem 2. Film befinden sich wieder Decoderpaare auf einer Markierung.
Auf Markierung 2 befindet sich ein Decoder und auf den benachbarten Markierungen 3-4-5 befinden sich zwei Lokomotiven auf 1 Markierung, mit einer vorgegebenen CV28-Zusammensetzung. Einem guten Beobachter wird aufgefallen sein, dass auf Markierung 5 zwar eine Belegung, aber keine Railcom-Meldung vorhanden ist. Es gibt hier zwei Decoder, die Kan 1 aktiv haben.
Die Situation ist stabil, Melder 2, Melder 3, Melder 4 zeigt die Decoderadresse an.
Solange sich diese Einstellung nicht ändert, ist alles in Ordnung.
Beachten Sie, was passiert, wenn der Decoder auf Melder 2 entfernt wird.
Dann wird die Meldung auf Melder 3 und 4 instabil.
In dem Moment, in dem der Decoder an seinen Platz zurückkehrt, wird die Situation stabil.
Movi- 2
https://youtu.be/lmm7PrEpusc
-
Hallo Zusammen,
ich nutze nun seit ca. 11 Jahren RailCom in Verbindung mit BiDiB und muss sagen, ja, es ist mit unter nicht ganz einfach und günstig alles so zu gestalten, dass genau diese Erscheinungen, wie hier beschrieben, eben nicht eintreten. Ich bin mir hier auch bewusst, dass so mancher von euch da sagen wird, nee, dann will ich das aber nicht. Nur bitte dabei auch bedenken, eine Anlage unter Einbeziehung mit RailCom, setzt auch voraus, dass man auch die Norm dafür komplett einhält und nicht nur teilweise…😊
Ich darf z.B. mal daran erinnern, dass man beim Einsatz von Beleuchtungen, innerhalb der Lok oder Waggons, bitte nur LED zum Einsatz bringen sollte.
Auch bei der Auswahl der Decoder sollte man echt vorsichtig sein. Beispiel, ich rate dringend davon ab, Decoder von MIniTrix zum Einsatz zu bringen. Im Übrigen macht ja Märklin auch ganz klar deutlich, dass sie RailCom eben nicht unterstützen…😊Klar, es gibt auch so manche Artikel darüber, wo man denkt, Quatsch, kann man doch einfach anders einstellen, nur zu, dies ist z.B. so ein Decoder welcher hier eben nicht Normgerecht arbeitet und warum sollte er es auch, der Hersteller behauptet es ja auch gar nicht…😊 Nur der Anwender ist der Meinung, ach, bekommt man alles eingestellt.
Auch bei Viessmann oder Piko wäre ich hier sehr vorsichtig! Klappt nämlich nicht…😊
Ein weiterer Punkt ist hier die Thematik die Kanal1 und Kanal2…, Ich meine also CV28…
Auch hier gibt es die tollsten Empfehlungen. Eines ist dabei richtig, es liegt an der verwendeten Hardware, welche auf der Anlage verbaut ist. Ich selbst hatte mal eine reine BiDiB-Hardware von Fichtelbahn/OpenDCC im Einsatz. Hatte mich zum Schliss nicht mehr total überzeugt. Gerade in Verbindung mit Soundloks gab es hier immer wieder Probleme. Ich spreche hier natürlich von einer größeren Anlage, wo z.B. so ca. 15-20 Züge zur gleichen Zeit unterwegs sind. Dann habe ich da so vor ca. 5 Jahren umgestellt und der GBM-Master durch eine mc² ersetzt, und seit dem läuft bei mir alles komplett reibungslos…😊
Welche Einstellungen nutze ich denn nun, bei Kanal 1 und Kanal 2? Nun, bei den Lok-Decodern immer beide! Bei den Funktionsdecodern dagegen immer nur Kanal 2.
Sollte jemand hier tiefere Einblicke wünschen, nun dann einfach mal bei mir melden.
Wie gesagt, ich habe damit sehr gute Erfahrungen gemacht und nutze hier nur Decoder von D&H, Zimo und ESU (bitte die 5-Version).
Ach und noch ein wichtiger Hinweis, bitte dabei immer die neuste Firmware der Decoder nutzen und natürlich auch die von WDP…😊
Gruß
Wolfgang
-
Hallo Wolfgang,
Na ja, lasst uns weiterhin Spaß an unserem Modellbahnhobby haben.
Ich bin auch sehr froh, dass das Railcom-Problem nicht an WDP liegt! Wenn ich WDP ohne Railcom in Betrieb nehme, läuft WDP 100% reibungslos.
Außerdem habe ich Lokomotiven mit D&H, Zimo und ESU und eine FM7000 Hornby vom Englischen Anbieter. Sie erwähnen, dass eine neue Firmware-Version aktualisiert werden muss.
Und das hat mir keinen Spaß gemacht.
Dies bedeutet, dass Sie im Prinzip 4 Lokprogrammierer kaufen müssen, um die Firmware aktualisieren zu können.
Das ergibt eine schöne Summe von über €600. ;D
Und dann ist da noch die Frage, ob Railcom richtig auf die zentrale Hardware abgestimmt ist.
Kann man dann noch sagen, dass es in die Kategorie Spielzeug fällt?.
Herzliche Grüße,
Jan Stienstra
-
Hallo Jan,
ja, dass hast Du richtig erkannt. Es ist nicht ganz günstig...:-)
Ich habe da für meine Anlage die Programmer von D&H, Zimo und auch ESU gekauft.
Habe es aber auch bisher nicht bereut. Bei mir läuft alles bisher so, wie ich es mir vorgestellt habe... ;)
Na und ob ich nun 400€ für eine neue Lok ausgebe oder deutlich weniger für einen Programmer, muss halt jeder selbst für sich einschätzen...
Gruß
Wolfgang
-
Hallo Wolfgang, du sagst
dann habe ich da so vor ca. 5 Jahren umgestellt und der GBM-Master durch eine mc² ersetzt, und seit dem läuft bei mir alles komplett reibungslos…😊
frage mich, warum KM 1 die System Control 9 durch eine IB 3 ersetzt , bestimmt nicht, weil die so gut sind !
Grüße Ingo
-
Hallo Wolfgang,
Ja so kann man es formulieren, jeder kann selbst entscheiden was er anschaffen möchte. Zu Recht.
Allerdings stehen die Modellbahnhersteller im Wettbewerb mit Decoderherstellern, die ihre Decoder mit speziellen Sounds etc. auf den Markt bringen. Und genau wie ich sehe ich eine schöne Lokomotive/einen schönen Zug, von dem wir sagen, dass Zimo, D&H, ESU einen zuverlässigen Decoder eingebaut haben werden.
Das Thema Railcom wird in den letzten Jahren immer stärker als Lösungsinstrument propagiert. Ich habe festgestellt, dass Railcom und WDP beim Thema Falsche Fahrt perfekt zusammenpassen. Dies geschieht, wenn die Lok „erkannt“ wird.
Dies ist derzeit nur möglich, wenn 1 Lok auf 1 Besetztmelder steht. Wenn wir mit MIFAZ mit mehreren Loks fahren wollen, beispielsweise zum Kuppeln etc., verschwindet der Lokname aus dem FAZ-Fenster.
Dann weiß WDP nicht mehr, wohin der fehlende Lokomotivname verschwunden ist. Ich denke jedoch, dass Railcom ein wunderbares Werkzeug ist, um WDP-gesteuerte Sicherheitsziele zu erreichen.
Anschließend werde ich noch einmal auf den NMRA-Standard zurückkommen, in dem Railcom spezifiziert ist. Und dennoch scheint es so, als hätten die verschiedenen Decoderhersteller unterschiedliche Varianten bei Railcom eingeführt, die nicht einheitlich geregelt sind. Und dann sprechen wir über den CV28. Diese Werte werden in unterschiedlichen Interpretationen formuliert. Für einen Modelleisenbahner ist das ein frustrierender Albtraum, mit dem man nichts anzufangen weiß.
Du würdest sagen: Wolfgang, tu mir einen Gefallen
und mach es für Modellbahner bitte etwas aufschlussreicher und verständlicher.
Und sind wir mal ehrlich: Müssen wir eine akademische Ausbildung absolvieren, um die Decodiertechnik zu beherrschen? Ich freue mich bereits darüber, dass das Decoder-Registerlistenblatt im WDP übersichtlicher geworden ist. Ich kann klar erkennen, was los ist.
Das ist etwas ganz anderes als 4 Lokprogrammierer mit unterschiedlichen Interpretationen der Einstellungen.
Betrachten Sie das immer noch als Spielzeug?
Ich weiß auch, dass mein Lodi-System einwandfrei funktioniert. Es steckt im Lokdecoder. Und genau danach sucht Lokstore. Die Technologie steht nie still. :D ;)
Herzlichen Gruß,
Jan Stienstra
-
Wenn ich all dies lese, bin ich Markus Herzog sehr dankbar, dass alles im windigipet 2021 auch ohne railcom funktioniert.
Es kann doch nicht sein, dass wenn von einem Modellbahnhersteller behauptet wird, dass ein Produkt mit einem Protokoll übereinstimmt, dass so ein peinliches Ergebnis erzielt wird, wie in diesen beiden Filmen gezeigt.
Die Lokomotiven in diesem Film hatten den gleichen Decoder Markenbezeichnung, den gleichen Typ an Bord und hatten auch alle die neueste Firmware erhalten.
Die großen Dieselloks mit einem Gewicht von 4,5 kg und zwei Motoren an Bord habe ich nicht in den Film aufgenommen, da diese Decoder mehr Möglichkeiten bieten, wie z.B. die Einstellung der Signalstärke der übertragenen Railcom-Meldung. Dann ist es auf jeden Fall eine Railcom-Party auf der MOBA.
Meiner Meinung nach gibt es eine völlige Nichtübereinstimmung der Modellbahnindustrie.
Wenn ein Hersteller seinem Produkt bestimmte Eigenschaften zuschreibt, dann sollten nach europäischem Recht diese Eigenschaften auch im „normalen Geschäftsbetrieb“ geliefert werden.
Ich habe den point of no return finanziell schon überschritten .
Ich weiß jetzt, dass es nicht funktioniert und trotz aller Versprechungen nicht funktionieren wird.
Dass es nicht funktionieren wird, wusste Brend Lenz schon lange . 8)
Da es noch NIE einen Lenz GBM8 mit lokalen Railcom-Empfängern auf dem Markt gegeben hat .
Grusse
Rupert
-
Hallo Zusammen,
es ist immer wieder das gleiche Spiel. Jemand hat eine Frage zu einem Thema und es werden dazu verschiedene Antworten gegeben. Soweit, so gut…
Ok, ich konnte euch leider nicht mit meinem Wissen und mit meiner Erfahrung überzeugen.
Daher hier mal meine letzte Antwort zu diesem Thema, wenn ihr doch alles besser wisst, warum fragt ihr dann danach? Auch ein Grund für mich, warum ich nicht mehr als Beta-Tester tätig bin. So etwas brauche ich einfach nicht mehr…😊
Ich kann nur für mich sagen, wie es bei mir geht und mein Wissen dazu versuchen weiter zu geben. Bei vielen Anwendern hat dies auch zum Erfolg geführt, jedoch halt nicht bei jedem. Ob ihr dieses Wissen nun annehmen wollt oder nicht, kann ich ja nicht beeinflussen und werde es auch nicht mehr versuchen.
Wenn ihr der Meinung seid, es ist alles Quatsch, dann ist es halt so…😊
Bei mir geht alles richtig und bei euch… 8)
Na und damit betrachte ich für mich, dieses Thema, als erledigt. Weitere Antworten von mir oder Hinweise dazu, werden natürlich nicht mehr erfolgen.
Gruß
Wolfgang
-
Hallo zusammen,
ich würde sagen wir schließen das Thema hier jetzt mal so langsam.
Jeder hier etwas postuliert hat aus meiner Sicht ein bisschen Recht, aber auch ein bisschen Unrecht. Ich könnte jetzt noch ganz viel dazu schreiben. Aber ich lass das jetzt um nicht die Diskussion noch weiter anzufachen.
Was ich aber versprechen kann:
WDP wird weiter voll Railcom unterstützen und auch neue Features von Railcom bzw. Features noch besser nutzbar zu machen - hoffentlich zur Freude aller die Railcom nutzen
Und: wer warum auch immer kein Railcom nutzen will auch der wird weiterhin von uns weiter voll bedient werden ohne Wenn und Aber
Bitte die Diskussion hier jetzt als beendet betrachten ehe das ganze noch emotionaler wird.
Grüße und Danke
Markus