THEMA: Kennt ihr schon DCC++/DCC-EX #11

Hast du mir eine Empfehlung für eine preiswerte Hardware mit Schaltplan? STM32 bevorzugt. Meistens haben die alledings nur eine H-Brücke drauf.

Es geht auch andersrum. Es gibt Loks die haben ein DCC-EX System als Decoder drin, auch etwas größere zum mitfahren.

Empfehlungen für bessere Endstufen oder Konstruktionen nehmen wir gern entgegen


Der Innenwiderstand muss auch klein genug sein, deswegen z.B. nicht mit dem ollen Standard Shield. Das kann zwar Brake aber das reicht nicht.

Für die Freunde von RailCom muss ich leider immer wieder um Gedult bitten oder uns mit Tat zu unterstützen.

Grüße,
Harald.

Nabend.

Also das EX8874 Motorshield sollte man mindestens zum Arduino Mega2560 haben. Das Arduino Motorshield kann man getrost für DCC-EX vergessen.
Und on Top noch das hauseigene WiFi Shield vom DCC-EX Projekt. Bitte NUR das wegen der speziellen Firmware kaufen!
Als Werkstattzentrale und Testgerät ist die jetztige Ausbaustufe klasse. MEHR ALS DAS BRAUCHT MAN ALS ANFAENGER NICHT! Das war damals als alles ins Rollen kam der große Unterschied zum Kommerz.
Jetzt hebt die Sache wohl aber Richtung Highend Zentrale in der Zukunft ab. Klar dafür braucht man bessere Rechenleistung. Lockt aber damit weniger Anfänger an.
Es war einmal eine Idee für IT Neugierige und DCC Modellbahner Anfänger und vor allem kleines Geld. Das ist jetzt leider in Zukunft Geschichte.
Hoffen wir mal die Version 5,6.x bekommt wenigstens ab und zu noch mal einen bugfix spendiert, falls einer bekannt wird.
Die hauseigene DCC-CSB1 werdet ihr DCC-EX IT Nerds ja dann erneut um- und aufrüsten müssen, sodass die Reise eine Ebene höher weiter gehen kann. Viel Spaß noch.

Und ich bin jetzt endgültig raus aus dem Projekt.

P.S.: für RailCom gibt es genug Ausrüstung am Markt! Muss DCC-EX das wirklich haben?!?!?! Die Zentrale braucht für Einsteiger auch keinen Rückmeldebus!!! Alles Preis- und Ressourcentreiberei. Ihr verlauft Euch im Wald mittlerweile. Back to the roots Leute.

Wer nach ersten Schritten voll einsteigen möchte hat dann genug Auswahl am Markt.

Grüße.

Frank

@vik (#89 im vorherigen Thread),

Du hattest vermutlich überlesen, daß ich weiter oben (#53) geschrieben hatte, daß ich ein eigenes Projekt verfolge und DCC-EX gar nicht nutze. Daher ist es überflüssig, die Verdrahtung zu veröffentlichen, auch wenn ich das könnte, weil ich mir natürlich selber ein entsprechendes Dokument erzeugt habe. Ich will mich eigentlich auch gar nicht in die DCC-EX-Diskussion einmischen, aber weil hier von MEGA-Preisen (Wortspiel beabsichtigt) die Rede war, wollte ich doch mal darauf hinweisen, daß es auch günstiger geht.

Vielleicht wäre der Ansatz auch etwas für Haba und das DCC-EX-Team: Ich habe das auch schon mal bei anderen Projekten gesehen (vornehmlich 3D-Filament-Drucker, aber auch andere), daß dort nur ein Motherboard entwickelt wurde, auf dem verschiedene Standard-Maker-Komponenten, wie eben Microcontroller, Motortreiber und ähnliches gesteckt werden. Außer Anschlußklemmen und vielleicht ein paar Kondensatoren oder andere leicht zu lötende THT-Kompnenten ist dort nichts drauf. Gerade bei den Microcontrollern versuchen manche Maker-Hersteller auch, unter ihren Varianten pinkompatibel zu sein. Andere Hersteller übernehmen diese Pinbelegungen terilweise dann auch.

Klaus

Wir haben Anwender, die sowas gemacht haben. Große Boards mit aufgelöteten Headers sind über dem was die Leute bereit sind zu zahlen. Interesse eher lau.



Das verschwindet jetzt alles *Puff* in einem Nebel  des Vergessens sobald wir Version 6 präsentieren.



Dann kann man auch gleich das Shield auf 3.3V anpassen, auf ESP32 umsteigen (Keyestudio ESP32 Plus) und braucht kein externes WiFi Shield. Außer der Einsteiger braucht die fuffzich IO des Mega.



Macht Sinn.

Grüße,
Harald

PS: wer Spuren von Ironie findet liegt gar nicht so daneben.

Hallo,

Was viele vergessen: Der Mega 2580 ist trotzdem nur ein 8-Bit AVR mit 16 MHz und die CPU da drin kann auch nicht mehr als der ATmega328 vom Uno. Es ist ein riesiger Chip, der mit den vielen Pins ganz mächtig aussieht.  Das ist er nicht.  Er hat so viele I/O dass er die gar nicht in alle in Echtzeit bedienen kann.
Er wird hauptsächlich wegen des relativ großen Programmspeichers von Anfängern benutzt, die 5 I/O brauchen aber Angst haben, ihr Programm würde zu groß. Verbreitung hat er durch die China Klone gefunden,  die mit CH340 USB Wandler kosten ganz wenig. Das Original ist ziemlich teuer.

Grüße,  Peter W

Hallo Harald, das ist genau die Form der Nachhaltigkeit, die ich eher kritisch sehe....

MfG

vik

Darum habe ich mich für einfache HW entschieden und die gesamte Logik auf den PC verlagert. Feature updates sind SW updates auf dem PC, die HW bleibt.

VG,
Frank

Hallo Frankna ja, so ganz einfach ist Deine Hardware
https://rtb4dcc.de/
ja auch nicht und man muss mit dem PC und entsprechenden Entwicklungstools schon mehr vertraut sein, als es die Breite der Modellbahner in der Zielgruppe (mit etwa sechzig Jahren und mehr) ist.

MfG

vik

Daran arbeite ich, dass dieses auch fuer einen Laien bedienbar wird. Es ist halt viel Arbeit und dauert seine Zeit ...



Die von fschum zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login

Hallo Frank, Danke für die Vorschau! Sieht wirklich imponierend aus!
Ist das in der Spalte mit dem "<-||->" im Kopf die aktuelle Aufgleisrichtung des Fahrzeuges auf dem entsprechenden Detektor-Abschnitt? Falls nicht, wie kann man sich die anzeigen lassen?

MfG

vik

VIKTOR & FRANK,

Ihr kapert gerade den DCC EX Thread. RTB4DCC ist ‘ne ganz andere Baustelle.

LG
threedots

Danke ... (Roland).


Das ist eine Ansage, teilt ihr die Meinung?

1. Sollte eine DCC-EX Zentrale RailCom Cutout können?

2. Wenn es genug Ausrüstung (ich denke jetzt vor allem an Detektoren) am Markt gibt, welche sollte DCC-EX unterstützen? Oder würdet ihr eine DIY Lösung für RailCom Detektoren einsetzen?

Grüße.
Harald.

Hallo Harald,

unabhängig von der hier laufenden hitzigen Diskussion bzgl. des wegfallenden Mega2560 Supports in neuen Versionen ist mir aufgefallen, dass ich für mein Testoval noch eine Steuerungselektronik brauche, die analog und DCC beherrscht. Klein und kompakt soll sie sein und meinen WLAN Handregler kann ich auch koppeln. So fiel meine Wahl kurz und schmerzlos auf die CSB1! Bin schon gespannt, was Eure neue Software v6 so bringen wird.

Ich verfolge das DCC Ex Projekt sporadisch seit Anfang 2024 und ein nahender Klinikaufenthalt bietet mir dann genug Zeit, mich mal gründlich durch den Sourcecode des Projekts auf Github zu wühlen.

Deine Frage nach RailCom Enthusiasten laß ich mal offen im Raum stehen. Das, was aus der Feder von Lenz in den entsprechenden Normungsdokumenten veröffentlicht wurde, gefällt mir persönlich  überhaupt nicht. Außerdem gibts ja überm Teich noch DCC-A als Parallelentwicklung. Und das proprietäre RailCom Plus in DACH wird sich imho mittelfristig nicht durchsetzen können.

Soll DCC-EX also das RailCom Cutout unterstützen. —> ja!

Und für die Detektoren böte sich doch so ein kleines Netz aus ESP32 an, die drahtlos mit einem Master ESP32 kommunizieren könnten. Der Master ESP könnte dann ein Interface zur DCC Zentrale implementieren, ob das nun LocoNet, CAN, I2C oder auch einfach über IP erfolgen soll, müsste dann noch festgelegt werden. Ein kleines Platinchen mit Optokoppler zu, Abgriff des DCC Signals vom Gleis und ein Spannungsregler zur Versorgung des ESP32, ggf. Noch ein USB Interface und ein Reset Taster für den ESP. Schlägt für die Hardwareseite eines „local detecors“ mit nicht mal 10€ zu Buche.

LG
threedots

DCC-A ist keine Parallelentwicklung sondern eine (komplizierte) Erweiterung von RailCom die eine Anmeldung mitbringt.

Kleine Korrektur: DCC-A ist eine deutsche Entwicklung (opendcc)! Der Begriff „überm Teich“ ist falsch.

Zu 1: Den RailCom-Cutout in die Präambel zu „stanzen“, ist technisch kein Hexenwerk. Das konnte Wolfgang Kufers Z1 schon vor knapp 20 Jahren. Das sollte (muss nicht) DCC-EX beherrschen.

Zu 2: Ich befürchte, dass dieser Punkt aktuell massiv unterschätzt wird. Hier muss man sich im Vorfeld sehr genau überlegen, wo die Reise mit dem Gesamtsystem später hingehen soll. Meines Erachtens scheitern an dieser Hürde – von wenigen Ausnahmen abgesehen – fast alle Ansätze. Die wahre Mächtigkeit des Upstreams (RailCom) entfaltet sich nämlich erst dann, wenn er nahtlos mit dem Downstream (DCC) koordiniert und orchestriert wird. Das wirft direkt die nächsten Architekturfragen auf und man gerät ganz schnell vom Hundertsten ins Tausendste.

Hallo Vincent und Frank,

Danke für die Richtigstellung bzgl. Open DCC und DCC-A. Ich hab das falsch aufm Schirm gehabt und dann nach Übersee verortet.

LG
threedots

Also meine Frage war nicht technisch gemeint. Wie man den Cutout hinbekommt ist dann je nach CPU und was der CPU sonst noch macht eine anderes Problem. Die ESP32 sind ja "intressant" was die Realzeiteigenschaften anbelangt.



Kann dir versichern, haben wir bemerkt
Das ist auch einer der Gründe warum es nicht schneller geht.

Grüße,
Harald

Hallo Harald,

gibt es Infos darüber, was in Eurem Team bzgl. RailCom gerade läuft bzw. geplant ist?

LG
threedots

Hallo threedots,

was wäre Dir denn wichtig bzw. würdest Du Dir an Funktionen wünschen?

Entwickler wollen es meistens „gut“ machen und somit *alles* implementieren - und das macht Projekte ggf umfangreich.

Mit freundlichen Grüßen,
Frank

RailCom:

Jetzt:
Cutout on Mega track A (MAIN)

Bald:
Cutout on ESP32 (all MAIN tracks)

Noch nicht (aber will man wohl haben früher oder später):
Cutout wenn der ESP32 als Booster arbeitet
Verwertung der RailCom Information (das muss man noch in einem externen Program z.B. JMRI machen)
RailCom Hardware

Grüße,
Harald

Hallo Frank,

da jetzt softwaremässig erstmal die Voraussetzung für RailCom in Form des DCC Cutouts  geschaffen wurde, fragte ich halt einfach mal nach dem aktuellen Planungsstand.

Mir gehts hauptsächlich um die folgenden Punkte:
- RC Detektion am Gleis
- Definition eines RC Rückmeldekanals
- Ob und wie RC Daten gegebenenfalls in DCC-EX künftig verarbeitet werden sollen/können.
- automatische RC Lokerkennung inkl. Aufgleisrichtung und verfügbarer Funktionen (z.B. für die Handregler)

LG
threedots

P.S. Harald hat während des Editierens meines Posts geantwortet. Danke für die Infos.

Hallo, Ja, allerdings nicht als teures Zusatz-Feature sondern nach mehr als zwanzig Jahren ist das für eine DCC-Zentrale meines Erachtens selbstverständlich. Tatsächlich konnte man schon in die DCC-Pakete der DCCpp von Gregg Bermann immer per Booster den Cut nachträglich spezikationskonform in die DCC-Präambeln schneiden. Abgesehen von Wolfgang Kufers Booster-2 konnte das die zweite Serie des Tams B-3, auch einige Uhlenbrockbooster der Power-Reihe und naturlich von Littfinski und etlichen anderen gewrblichen Herstellern.
So ein Booster erhöhte aber den Beschaffungspreis eines DCC-EX (oder DCCpp) immer um etwa mind 45 Euro oder mehr und damit um das vier bis fünffache.
Wenn man jetzt also zwingend das DCC-Ex Motorshield mit den zwei DRV8874 für gut fünfzig Euro benötigt, um allein den Railcom-Cut in der DCC-EX-Zentrale integriert zu haben, ist das m. E. völlig unverhältnismäßig. Mit einem L298 lässt sich der zeitlich korrekte Cut auch generieren, man muss dann halt ggf. auf andere Optionen verzichten oder als Booster mit einem zusätzlichen Arduino oder auch kleinerem Mikroprozessor.
Wenn DCC-EX dann allerdings einen globalen Detector an Board hätte, der das Auslesen von CVs und sogar die Anmeldung der Fahrzeug-Decoder ermöglicht, wäre das wieder verhältnismäßig. Bis dahin kommt man als Modellbahneinsteiger mit einer gebrauchten aber fix und fertigen (freigeschalteten) weißen z21 einschließlich der umfangreichen Dokumentation deutlich besser weg, zumal man ja ohne Risiko sofort die Z21APP als eingeführte Benutzeroberfläche nutzen kann. Und wenn einem diese Art der Bedienung nicht zusagt kann man auf fast alle Fahrgeräte und Modellbahn-Steuerungsprogramme zurückgreifen.

MfG

vik

Hi Viktor,

Du vergleichst hier wieder mal Äpfel mit Birnen. Wer, wann, was und zu welchem Preis konnte, spielt heute keine Rolle. Deine letzten Postings lassen bei mir den Eindruck aufkommen, dass Du das DCC-EX Projekt um jeden Preis schlecht aussehen lassen willst.

Was bezweckst Du eigentlich?

Wenn Dir soviel an RailCom liegt, dann bring Dich doch konstruktiv in die entsprechenden Gremien ein, z.B. bei den Fragen, wie sich mehrere Decoder im gleichen Gleisabschnitt kollisionsfrei erkennen lassen und in welcher Reihenfolge sie sich, bezogen auf einen zu definierende Referenz-Punkt an einem der beiden Gleisenden befinden.

Wo steht eigentlich in den DCC Normen geschrieben, dass es für POM einen globalen RC Detektor braucht?

LG
threedots

Die meisten Zentralen in der Welt können kein RailCom oder es wurde nachträglich abgestellt oder nie angestellt weil mit den eingesetzten Decodern nicht kompatibel. Fleischman har 2020 noch solche Decoder verkauft. Digitrax noch heute. Trotz 20 Jahren also nicht selbstverständlich. Ich würde sogar behaupten dass die meisten DCC Anwender in der Welt noch nie von RailCom gehört haben noch damit in Berührung gekommen sind.


Nur bringt es nix, weil nicht genug Strom durch den L298 bringt (der Spannungsfall durch den ollen Transistor ist zu hoch). Hab ich das nicht schon geschrieben?


Bringt ein globaler Detektor was oder wird das System erst intressant wenn ich lokale Detektoren habe? Und brauch ich einen globalen Detektor wenn das Gleis da wo ich aufgleise einen lokalen Detektor hat?

Die automatische Anmeldung mit RailCom wird immer als der heilige Gral beschrieben. Aber: Bringt das so viel mehr als die Lok auf ein abgetrenntes Gleis zu stellen, das kurz als PROG-Gleis anzuwenden und dann mit der davon erhaltenen Adresse loszufahren? Das ist die bei DCC-EX vorgeschlagene Methode.



Ich weiss jetzt nicht warum du in "Kennt ihr schon DCC++/DCC-EX " Reklame für alternative Lösugen machst. Der Kurs für eine gebrauchte Z21start auf Ebah liegt bei so EUR 270, man muss aber aufpassen was für den Preis dabei ist (Netzteil 2A oder 3A, Freischaltcode, Router, Maus oder eben nicht).

Wenn Roco eine klare Ansage machen würde, dass nach Zahlung von EUR 20 um die App an Fremdzentralen anwenden zu können das auch garantiert ist (also dass die EUR 20 nicht futsch sind falls es nicht geht) dann würde wahrscheinlich DCC-EX die RocoApp unterstützen.

Grüße,
Harald

Hallo,



Dazwischen liegen Welten! ... ich habe auch sowas wie DCC_EX entwickelt, von Grund auf *mit* Railcom. Der sich ergebende Komfort ist m.E. ein ganz anderes Moba Erlebnis. Ich stelle das in absehbarer Zeit hier im Forum mal vor. Nicht als Konkurrenz sondern als Erfahrungsbericht.

Zurueck zu DCC_EX: Ich wuerde im Schritt 1 zu einem globalen Railcom Detector raten, weil das einiges an Komplexitaet (kein Bus System notwendig) vom Tisch nimmt. Lokale Detektoren kann man spaeter immer noch nachziehen.

- Aufgleisrichtung und Addressmeldungen im Kanal-2 sind recht einfach zu implementieren, weil man dazu nichtmal das Railcom-Paket inhaltlich auswerten muss.

- POM ist der erste groessere Implementierungsaufwand seitens RC. Das (optionale) xPOM dann noch ein Tacken aufwendiger.

- Railcom DYN Werte (z.B. QoS, Gleisspannung, Decoder Temp, usw) spielen in der gleichen Komplexitaets-Liga wie POM.

- DCC-A ist ne echte Hausnummer. Das Protokoll hat es in sich; soll heissen - hier wird es komplex.

- Schlussendlich dann die Decoder Update Protokolle, soweit von den Herstellern offengelegt. Ist vermutlich die Koenigsklasse.


Meiner Einschaetzung nach sind die ersten beiden Punkte realistisch mit der Option auf den dritten.

VG,
Frank

Darauf freue ich mich schon. Ich sehe das wirklich nicht als Konkurrenz. Kommentare hier im Forum die darauf chließen lassen dass man weiss von was man redet schätze ich sehr.

Grüße,
Harald

Hallo Harald und Frank,

der lokale Railcom Detektor ist doch ebenso in der Lage, POM auszuführen. Zur Not wird ein solcher direkt am DCC Gleissignal-Ausgang eines Boosters angeklemmt.

Der GFP ist in einem solchen Szenario außen vor, bei Bedarf kann er relevante Informationen über eine geeignete Schnittstelle abgreifen.

DCC-Ex ist also zunächst fein raus, es sei denn, es sollen RC Detektoren in der eigenen Firmware (wofür auch immer, tbd….) eingebunden werden. Dann stünde auch die Entwicklung eigener Detektoren und eines geeigneten Rückmeldebusses an.

Also, quo vadis? Es bleibt spannend ….

LG
threedots

Hallo Harald, Das ist eine schwierig zu verifizierende Feststellung.
Meinst Du damit die meisten aller je auf der Welt gebauten Zentralen oder die meisten Zentralen, die man heut hier in Deutschland, Östereich und der Schweiz neu erwerben kann? Zählst Du die aktuellen Zentralen von Märklin mit?
Das klingt schon ein wenig nach dem Motto "Kenn ich nicht, haben wir nie gebraucht, brauchen wir auch in Zukunft nicht!"
Vielleicht können wir erstmal eine kleine Liste machen, von welche Zentralen wir sprechen, unter welchen man also aktuell wählen kann, wenn man z.B. dieses Weihnachten (2026), seinen Enkelkindern einen Einstieg in die digitale Modellbahnwelt schenken will, mit der sie noch am Weihnachtsabend die ersten Züge fahren lassen können. Im nächsten Schritt können wir dann prüfen, welche davon (ggf. optional) die Railcom-Lücke beherrschen.

MfG

vik

Alle Zentralen von Digitrax, alle von NCS um die beiden großen außerhalb von D-A-CH zu nennen und dann auch noch alle die MFX anwenden, alle kein RailCom, das sind schon mal ganz viele, oder? Dagegen stellen wir die Zentralen von Lenz und die z/Z von Roco. Alles andere ist vom Market share wahrscheinlich Kleingemüse.



Gern in einem andren Thread.

Grüße,
Harald

Hallo Harald,ich denke, da übersiehst Du einiges. Die ECoS und alle anderen aktuellen Zentralen von ESU. Dann die Uhlenbrock-Zentralen! Selbst fur die erste IB und für das Twincenter wird eine RC-Nachrüstung angeboten. Alle Zentralen von Digikeijs und Yamorc, sowie die aktuelleren Zentralen von Piko haben Railcom an Bord. Naturlich auch die alten Zentralen von Tams (in Kombination mit dem richtigen Booster), sowie die aktuelle MC2. Selbst der olle Viessmann Commander konnte die Railcom-Lücke optional zur Verfügung stellen (konnte bloß nie selbst etwas mit den Railcom-Nachrichten anfangen). Dann wären da noch die eher seltneren Zimo-Zentren und natürlich die Zentralen von Fichtelbahn. Und was man so hört, soll es selbst bei der CS3 zeitnah möglich sein die Railcom-Lücke (auf Wunsch) einzusachalten, nachdem seit 2023 alle Trix-Triebfahrzeuge ab Werk mit Railcom fähigen Decoder ausgeliefert wurden und das inzwischen auch bei minitrix so zu sein scheint. Bleibt zu hoffen, dass der Hersteller, dies über ein Firmwareupdate auch bei der Gleisbox nachrüstet!
Alles in allem scheint DCC-EX eben doch ein Produkt zu sein, dass sich in erster Linie am amerikanischen Modellbaher - bzw. den dortigen Marktteilnehmern - orientiert, was ja auch nicht wirklich überrascht...

MfG

vik

Ich denke, dass die Amis etwas neidisch nach Europa blicken, in das Land des RailCom und wünschen es sich sehnlichst. Aber Digitrax kocht ja gerne eigene Suppen. Ich kenne einige Freunde, die gerne deswegen auf DCC mit RailCom umsteigen wollen. Darunter viele Lionel Spur 0 Kunden (auch so eine Insellösung).
Gruß Holger

Dass man in Amerika auf RailCom "neidisch" wär glaub ich nicht. Der amerikanische Markt ist einfach nicht so Technik verliebt. Bloß keine CVs anfassen, hauptsache die Lok bewegt sich irgendwie.

Siehe dazu auch den LCC Bus an dem die Amis seit 10 Jahren werkeln... Bis heut gibt's quasi keine Produkte dafür.

1. RailCom ist schon eine feine Sache und die MFX Anmeldung ebenso. Gut wenn DCC da nachzieht. Wenn man in die Zukunft schaut, sollte man dies mit im Blick haben.
Alternativen, wie Steuerung über Bluetooth, haben sich noch nicht wirklich durchgesetzt, vermutlich auch wegen fehlenden Standards.

2. Das Erscheinen der neuen verbesserten WLAN Maus von Roco wäre ein guter Anlass mal wieder über die Unterstützung des Z21 Protokolls durch DCC-Ex nachzudenken.

Uli

Hallo Vincent,

das mit LCC ist ein interessanter Hinweis. Im wesentlichen handelt es sich dabei doch nur um einen CAN-Bus mit einem draufgesetzten Protokoll.

Haben wir hier in DACH doch auch schon in ähnlicher Form. Märklin, ESU und CDB setzen auch auf den CAN-Bus, um nur einige zu nennen. Und immer schön inkompatibel zueinander!

Solange sich größere Hersteller nicht zusammenschließen, um eine Produktidee gemeinsam voranzubringen, wird es mit der Etablierung neuer Standards auch weiterhin klemmen.

Das hat mit Amerika oder Europa zunächst nix zu tun, das ist eine reine Frage des Geldes.

@Uli,
das ROCO Protokoll ist doch so gut dokumentiert, dass Du Dich in das DCC-EX Projekt einbringen könntest um an der Implementierung teilzunehmen!

LG
threedots

Ist eigentlich fertig. Nur braucht es jemand der bereit ist die Probleme die auftauchen an eigener Hardware zu untersuchen und zu lösen. Und der auch den Anwendern erklärt warum sie entweder zahlen oder eine alte Z1 App installieren sollen.

Grüße,
Harald

Hallo Harald, wäre das nicht eigentlich Aufgabe der DCC-EX-Entwickler zu klären. unter welchen Bedingungen man eine von Roco - für die eigenen Produkte entwickelte und über den Verkauf dieser Produkte auch refinanzierte - Software nutzen darf?

MfG

vik

Hallo Roland, nirgens, man benötigt zu PoM - "Programmieren auf dem Hauptgleis", weder einen globalen, noch einen lokalen Railcom-Detektor. Man muss halt die DCC-Adresse kennen.

MfG

vik

Das sehe ich anders. Wir reden hier grad von Railcom und in diesem Kontext benoetigt POM sehr wohl einen Detektor. Dabei ist es egal, ob es ein globaler oder lokaler Detektor ist.

VG,
Frank

Hallo,

Zum CV Schreiben nicht,  zum Auslesen der Werte schon!

Grüße,  Peter W

Hallo Frank,

wir sprechen von DCC-EX. DCC-EX beherrscht das Programmieren, d. h. das Schreiben der CVs von DCC Loks auf dem Hauptgleis gemäß DCC-Spezifikation uneingeschränkt. Über das Lesen  von CVs auf dem Hauptgleis findet sich nichts in der DCC-Spezifikation. Dazu ist das Programmiergleis mit dem direct-modus da.

Wenn man hier nicht sehr genau ist, läuft man große Gefahr, daß man Leser, die sich mit diesen technischen Sachverhalten noch nicht so vertraut gemacht haben, verwirrt

Will man CVs auf dem Hauptgleis auslesen, muss man zusätzlich gemäß der Railcom-Spezifikation vorgehen und neben dem Railcom-Detektoren einsetzen. Dabei gibt es beide Möglichkeiten, sowohl über globale, als auch über lokale Detektoren. Ich halte den Weg über einen Detektor in der Zentrale selbst, d.h. einen globalen Detektor, wie er z.B, in jeder z21, also auch in allen weißen vorhanden ist, für einfacher zu implementieren. Aber natürlich funktioniert es auch über einen (oder mehrere) lokale Detektoren. Geht man über lokale Detektoren, kann die Adresse (einschließlich Aufgleisrichtung) dort lokal angezeigt werden, wie es z. B. der Lenz LRC120 oder die Tams RCDs (in Kombination mit den RCAs) beherrschen. Jetzt benötigt man allerdings noch einen Weg, um diese Information irgendwie an die Steuereinheit (Zentrale oder Rechner mit Modellbahn-Steuerungssoftware) weiterzuleiten. Jeder lokale Detektor benötigt also z.B. ein Interface. Die Steuereinheit muss diese Infos entgegen nehmen und verarbeiten können. Das ist zum Einstieg m. E. ein deutlich höherer Aufwand, als der Weg über einen globalen Detektor. Nur dieser Weg - über lokale Detektoren - ermöglicht aber den Ort mitzuteilen, wo sich eine sendende Lok gerade aufhält.
Mir ist schon klar, dass Dir, Frank, das alles vertraut ist.

MfG

vik

Wäre es nicht die Aufgabe aller Betreiber von Webseiten zu klären welche Browser die Anwender dieser Webseiten nutzen dürfen?


In dem Fall ist es eher fraglich dass Roco die Benutzer der App in dem Fall zur Bezahlung auffordert ohne einen Gegenwert für diese Bezahlung anzubieten ("es kann dann funktionieren, keine Garantien" ist meiner Meinung nach kein Gegenwert).

Nehmen wir einmal an, es funktioniert plötzlich nicht mehr weil Roco wieder etwas ändert (hatten wir schon damals als die Bezahlung eingeführt wurde) ohne es zu dokumentieren, dann hat DCC-EX den schwarzen Peter. Dazu habe ich wirklich keine Lust.


So wer die Kompetenz dazu hat kann sich alle Teile selber zusammensuchen und sich ein eigenes DCC-EX bauen das vielleicht mit Rocos Produkten zu steuern ist.

Grüße,
Harald

Als einfacher Anwender einer z21 Start halter ich RailCom für unverzichtbar. Habe sogar alle Lokdekoder ersetzt die RailCom stören. Es ist der Komfort und die Sicherheit des PoM, die ich mag. Kein versehentliches CV Ändern bei mehreren Loks. Und für eine Aufgabe brauche ich es unbedingt. Da ich fast nur Dampfloks in Doppeltraktion fahre, brauche ich PoM zur Einstellung der gleichen Geschwindigkeit der Loks. Ohne, wäre das eine Quälerei.

Gruß von Aron

Hallo Aron,

Du bist doch kein Anwender von DCC-EX. Es geht hier um die Unterstützung der z21 App, nicht der Roco Zentralen, durch DCC-EX.

Was allerdings die Nutzung von RailCom anbetrifft, sind einige Leute hier voll auf Deiner Seite.

LG
threedots

Das hat Märklin doch vor einiger Zeit mit der MS2 schon mal vorgemacht. Rob hat dann die Notbremse gezogen und die Weiterentwicklung des MS2 Supports in Rocrail eingestellt.

Insofern eine völlig nachvollziehbare Haltung deinerseits.

LG
threedots

Da muss ich erneut widersprechen.

Richtig ist: Ohne RailCom lassen sich CVs auf dem Hauptgleis ausschließlich blind schreiben. Man erhält weder eine Bestätigung über den Erfolg, noch kann man den geschriebenen Wert zur Überprüfung auslesen. Ein echtes „Programming on Main“ (POM) ist das in meinen Augen nicht, sondern eher Etikettenschwindel – eine ziemliche Krücke für den Anwender.

Mit solchen Aussagen tun wir den Anwendern keinen Gefallen. Wie soll ein Laie verstehen, warum RailCom eine wichtige und sinnvolle Erweiterung ist, wenn der Ist-Zustand so schöngeredet wird? Du erweist dem Thema Railcom damit einen Bärendienst.



Das ist nicht richtig. Siehe dazu RCN-214, Kapitel 6.


MfG,
Frank

Hallo Harald, ja klar, das gilt aber auch, wenn die Railcom-Spezifikation oder gar die DCC-Spezifikation geändert würden. Auch hier könnten z.B. für bestimmte CVs eine konkrete Nutzung empfohlen werden ind damit mit einer bisherigen - Hersteller spezifischen Nutung kollidieren. Auch Hersteller, die sich treu an die bisherige Spec gehalten haben, haben das Nachsehen. Nur ganz wenige werden ihre bisher verkauften Produkte so umbauen dass sie zur neuen Spec passen. Ihre aktuellen Produkte werden sie natürlich versuchen konform zur geltenden Spec upzudaten. Aber selbst das funktioniert leider nicht immer, wenn der Normgeber nicht mit genügend Sorgfalt vorgegangen ist und entsprechend Rücksicht genommen hat bzw. wollte.

MfG

vik

Aber dann kann ich nachlesen was zu ändern wäre. Kann ich bei Roco aber nicht da ein nach der Spezifikation implementierte Zentrale nicht mit der Z21App in der jetzigen Version funktioniert.

So dein Argument ist ein gutes dafür Normen nicht einfach über den Haufen zu werfen und sich um den Bestand zu bemühen, hat aber mit der Situation um das Z21 Protokoll nix zu tun. Eine neue Version der Protokollspezifikation ist nicht aufgetaucht.

Grüße
Harald

Hallo Frank, ich finde es auch schöner, wenn man bei der Programmierung auf dem Hauptgleis, kontrollieren könnte, ob das Programmieren erfolgrejch war und die CV so geändert wurde wie gewünscht.
Aber tatsächlich funktioniert das *blinde" PoM bei den meisten Anwendern seit mehr als 30 Jahren eben meistens zur vollen Zufriedenheit. Jedenfalls scheint es für amerikanische Modellbahner kein überzeugender Grund zu sein, mehr Geld in Zentralen zu investieren.

Für mich selber ist es durchaus ein Grund mehr Geld auszugeben, aber ich finde es ist kein Grund den Begriff PoM umzudeuten zu behaupten PoM funktioniert ohne Railcom gar nicht. Das scheint mir Geschichtsklitterei zu sein.
Railcom ist dagegen (zusätzlich zu DCC) eine eine hinreichend funktionierende Methode, wenn man unter Verwendung des DCC-Protokolls den Aufenthaltort eines Triebfahrzeuges (DCC-Adresse einschl. Aufgleisrichtung) - zum Zeitpunkt "t" - mit ausreichender Genauigkeit, routinemäßig gemeldet bekommen will.

MfG

vik

Ich werde mir das noch einmal überlegen. Wenn hier seit über 30 Jahren nahezu vollste Zufriedenheit mit dem Status quo herrscht, möchte ich weder meine noch eure Lebenszeit mit Debatten vergeuden, die sich ohnehin nur im Kreis drehen.

Hallo Harald,Ja die letzte Version der z21-Lan-Spezifikation ist vom 6.11.2023. Die Roco-GF fühlt sich aber offensichtlich nicht mehr uneingeschränkt an die öffentlichen Aussagen
https://dimo.vgbahn.de/2020Heft3/Roco-Fleischmann-Interview.pdf
früherer Geschäftsführer gebunden.
https://www.drehscheibe-online.de/foren/read.php?010,10782954,10785826

Traurig aber wahr, aber andererseits, vor den Kadi haben sie eigentlich auch niemanden gezogen, der da seitdem irgendwas umgeht.

MfG

vik

Ops Mode (wie PoM damals hieß) ist älter als RailCom und damit wäre PoM plötzlich Schwindel geworden als RailCom aufgetaucht ist. Siehe NMRA RP9.2.1 so Mitte der 1990er und RailCom so ab 2003.

Wenn man eine z21 hat braucht man RailCom eher als mit DCC-EX weil da hat man kein separates Programmiergleis.

Grüße
Harald

PS: ich habe nirgendwo geschrieben dass ich damit _zufrieden_ bin. Sonst hätte ich wohl kaum so viele Stunden in RailCom investiert.

Hi Harald, ja, da gebe ich Dir Recht, der fehlende seperate Programmiergleisanschluss ist eine Designschwäche der weißen z21, die Roco wahrscheinlich ein Mehrfaches an Support-Aufwand gekostet hat, als duch die Verstümmellung eingespart wurde. Gerade Einsteigern passiert es regelmäßig, dass sie sämtliche auf der Anlage stehenden Loks und angeschlossenen Decoder gleichzeitig ungewollt umprogrammieren...

MfG

vik

Hallo Viktor,

wenn Dir die z21/Z21 so wichtig ist, dann bring Dich konstruktiv ins DCC-EX Projekt ein und kläre die Fragen mit Roco, die Du aufgeworfen hast. Deine restliche Zeit könntest Du sinnvoll darauf verwenden, den Z21 Protokollstack nebst Gateway in DCC-EX zu integrieren.

Was bei DCC wohin und wozu gehört, kannst Du getrost mit Arnold Hübsch klären. Der arbeitet schließlich bei den RCN mit und ist dafür ein geeigneterer Ansprechpartner.

LG
threedots

Hallo Roland, vielen Dank für Deine vielen Arbeitsaufträge, aber mein Wunsch, den Railcom-Cut zu implementieren, ist in DCC-EX ja - nach zehn Jabren - erfüllt worden, wenn auch erstaunlich hochpreisig. Es wird halt ausschließlich ein exklusiver Anbieter - der dazu notwendigen Hardware - unterstützt . Die weitergehenden Vorschläge (z.B. zur Nutzung der Z21APP) kamen von anderen Foristen - hier im Forum.
Du scheinst doch mit Deiner ECoS recht glücklich zu sein, obwohl Du Railcom bisher selber noch gar nicht groß nutzt.?
Es gibt aber auch noch viele andere hoffnungsvolle Hersteller die bei Railcom mitspielen wollen, z.B. Railbox.
Alle müssen sich für irgendeinen Bus entscheiden, wenn sie lokale Detektoren unterstützen wollen. Es scheint schon sinnvoll, dass hier nicht jedesmal das Rad neu erfunden wird. Railbox
https://www.railbox.pl/de/groups/sterowanie
hat sich z,B, wie Uhlenbrock, Roco (bei der schwarzen Z21) und Digikeijs und Yamorc für LocoNet entschieden. Aber ist das immer dasselbe? Gibt es da soetwas wie eine Norm?
Warum Railbox ihr vielleicht spannendes Produkt, den z21-Emulator zurückgezogen hat bleibt unklar, ist aber schade.

MfG

vik

Die von vikr zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login

Es gibt aktuell Bestrebungen Loconet, XPressNet, S88 und was weiß ich was zu Normen, aber bei dem bestehenden Wildwuchs kann man sich vorstellen wie lustig dieses Unterfangen ist...

Hallo,

Was Loconet betrifft,  gibt es Firmenstandards. Es gibt eine freie Lizen mit Dokumentation für Privatnutzer. Darauf aufbauend, gibt es Erweiterung von Digitrax selbst und von Uhlenbrock. Beide kriegt man meines Wissens nur als Digitalhersteller und gegen Abschluss eines Vertrages. Ob und wieviel man da für eine Lizenz zahlen muss,  entzieht sich meiner Kenntnis. Wie man z.B. einen alten Fleischmann Lokboss als Handregler nutzen kann,  ist nicht dokumentiert. Der kann nämlich nicht die Adresse dispatchen, sondern steuert fix die Adressen 1-4 an Das scheint eine proprietäre Erweiterung von Uhlenbrock zu sein. Leider scheint Uhlenbrock nicht interessiert zu sein, seine Erweiterungen zu nutzen.  Deshalb pfeife ich auf Loconet.

Man könnte es natürlich durch Reverse Engineering heraus finden,  was zum Teil durch Lesen des Programmcodes von JMRI oder Abhören des Loconet möglich ist. All diese Informationen sind dann für Eigennutzung beschränkt,  aber können nicht in einem Open Source Projekt benutzt werden.

Grüße,  Peter W

Da JMRI (also in Gänze) als GPL Software vertrieben wird ist es gestattet daraus Teile zu nehmen und in andere GPL Software einzubauen. Sonst würde JMRI gegen die GPL verstoßen, und das können wir uns nicht vorstellen da das sogar zu einem Entscheid beim höchsten Gericht geführt hat, oder?

Grüße,
Harald

V
Hallo Frank (fschum),


Zitat - Antwort-Nr.: 41 | Name: vikr

Habe in der RCN-214,
https://normen.railcommunity.de/RCN-214.pdf
Kapitel 6 noch mal nachgelesen. In dieser vergleichsweise recht jungen Spezifikation wird explizit auf die RCN-217 (also die aktuelle Version der zentralen Railcom-Spezifikation) verwiesen, gerade, um Doppel-Definitionen zu vermeiden.


MfG

vik

Die Nucleoanwender (STM32) die sich mit GIT auskennen können schon mal die neuesten master und devel ausprobieren, das sollte jetzt wieder duch den Compiler gehen. Versionsnummern gibts später.

Grüße und guts Nächtle,
Harald

Gibt es eigentlich Neuigkeiten von der ESP32 Front? Konnte die Timerproblematik schon gelöst werden?
Im RCN-212 werden 68 Funktionen für Lokdecoder beschrieben. DCC-Ex unterstützt bis dato nur 31 Funktionen. Hat das historische oder design-bedingte Gründe? Da die 8bit CPUs bei der weiteren Entwicklung ja nunmehr ausgeschlossen sind, sollte die knappe Ressource RAM hier keine große Rolle mehr spielen.
Die fertig implementierte Unterstützung des Z21 Protokolls könnte nun doch auch in den Master übernommen werden. Alleine 100000 Downloads der Z21-App für Android sind doch schon mal eine Hausnummer. Da kommen die unzähligen physischen Mäuse und Apple-User noch dazu.

LG
threedots

Moin,

Danke, es funktioniert
Devel ist die Version 5.9.4

für das Erfolgreiche Compilieren müssen zuvor alle Caches gelöscht werden.

wenn es nicht will auch den Inhalt von %USERPROFILE%/.platformio (Windows) löschen
das ist leider das Manko von PlatformIO, dass die Caches irgendwann beginnen den Build zu behindern ..


Viele Grüße, Franzi

Positiv:
DCC-EX schlägt unter Einbezug der Fortentwicklung auch Hardwareseitig Rocos neue weiße z21newGen Start um Längen!
Gut gemacht.

Hallo,
"um Längen" hört sich so nach Vergleichsgemessung an.
Welche DCC-EX-Zentrale hast Du - in welchem Kontext (Fahrregler, Layout, Stellwerk, Rückmelder etc. ) - mit welcher z21newGen Start verglichen?

MfG

vik

Ab 29 sollten die erweiterten Funktionspakete gesendet werden. Funktioniert das nicht? Wenn nicht dann bitte Fehlerrapport mit Versionsnummer und so.

Zu PlatformIO:

Ab dem nächsten DCC-EX Update werden dann die von PlatformIO heruntergeladenen Pakete nicht mehr in .platformio  (unter dem Anwender) sondern in .pio (per Projekt) gelagert. Das macht das Arbeiten leichter wenn man verschiedene Versionen für verschiedene Projekte verwendet. Bei der Gelegenheit hab ich auch noch einen Bug in Scons 4.11.1 (das Paket auf dem PlatformIO aufbaut)  gefunden und auch Arduino_Core_STM32 3.0.0 ist noch sehr "null punkt null" (deswegen lieber 2.12.0)

Grüße,
Harald

DCC-EX Version 5.6.4 minor update
BugFix: Corrected decoding for F13 to F20 & Minor fixes for PlatformIO compile

Hallo Harald, hallo allerseits,

hat jemand in DCC-EX 5.6.4 schon mal den Diagnostik-Befehl:
"<D RAILCOM ON>"
eingesetzt?
Was wird dann bei welchen Gelegenheiten im seriellen Monitor ausgegeben?

MfG

vik

Hi,

da wird ein boolesches Flag auf true gesetzt, damit künftig Railcom-bezogene Diagnose Nachrichten ausgegeben werden können.

LG threedots

Hallo Roand, schon klar, aber erstens wird das Setzen dieses Flags im Monitor nicht bestätigt, was ja bei anderen (auch diagnostischen) Kommandos der Fall ist.
Und zweitens, ich finde nirgendwo eine Dokumentation welche Nachrichten dann - nach dem Einschalten dieser Option - zu erwarten sind.
Vielleicht hat Du ja einen zielführenden Link für mich?

MfG

vik

Harald

Hallo Harald, OK, was bedeutet es jetzt für Release 5.6.4?

So ganz spezifikationskonform scheint mir der Cut von DCC-EX 5.6 auch beim Mega noch nicht reingeschnitten zu werden, deshalb erhoffe ich mir aufschlussreiche Hinweise bei eingeschaltem Flag!

MfG

vik

Vik,

zum einen erläutere doch bitte, warum Du meinst, die Cutout sei nicht ordnungsgemäß.

Zum anderen, was genau wären für Dich „aufschlussreiche Hinweise“?

VG,
Frank

Hallo Vik,

du schreibst immer nur so schwammiges Zeugs, ohne konkret zu werden. Was ist denn nicht spezifikationskonform an der Austastlücke, die DCC-EX beim Mega2560 erzeugt?

Was Du offensichtlich noch nicht verstanden hast oder verstehen willst, ist die Tatsache, dass die Generierung der Austastlücke und RailCom zwei verschiedene Dinge sind, wenn auch das Letztgenannte das erste als Voraussetzung bedingt.

Da DCC-EX über keinen physischen RailCom Detector verfügt, gibts auch noch keine Verarbeitung der RailCom Daten, also auch keine Diag Infos.

Ich kann Dein Rumgetrolle hier nicht mehr ertragen! Werde konstruktiv und schildere konkret, was möglicherweise fehlerhaft ist bzw. bringe Dich konkret in den Entwicklungsprozeß ein. Falls Dir das nicht möglich sein sollte, halt einfach Ruhe!

Greetz
threedots

Hallo Frank,leider weiß ich nicht was das Kommando <D RAILCOM ON> bewirken soll. Bei mir wird das Einschalten ja nicht mal quittiert.

Ich verwende jetzt einen Mega mit LAN und diesem sündhaft teuren DCC-EX-Motorshield aus Großbritannien. Ein in das Ausgangssignal des Main-Anschlusses eingeschleifter RCD mit angeschlossenem RCA-1 sollte (wie bei allen anderen Railcom fähigen Zentralen) die Lok-Adresse in Kanal 1 anzeigen, sobald irgendeine DCC-Adresse (z.B. die 1) angesprochen wurde. Leider zeigt das RCA-1 nur "belegt".
Ein tieferer Blick mit einem Logic-Analyzer läßt mich vermuten, das die Lücke nicht spezikationskonform (zu spät?) geschnitten wird, so dass die ersten UART-Bits verschluckt werden, die Nachricht vom RCD verworfen werden muss und nur belegt angezeigt werden kann.

Natürlich kann DCC-EX selber davon nix mit bekommen, aber für den Modellbahner sind die Anzeigen ja nützlich, z.B. um sich ganz schnell mal anzeigen zu lassen, welche DCC-Adresse bei einer Lok eingestellt ist.

MfG

vik

Hi Vik,

konstruktiv geht also doch. Aber wenn Du das Shield auch außerhalb der EU kaufst, bist Du selbst Schuld, dass die Kosten dafür so hoch sind. Da Du ja für Deine Stammtische (10x) auch pro Person 50€ per VHS aufrufen lässt, solltest Du das doch längst locker verschmerzt haben, oder kommt bei dem Preis etwa keiner?

Hallo Roland, ich denke sie beginnt vielleicht zu spät?
eben, die Austastlücke muss zum richtigen Zeitpunkt nach dem PacketEndBit begonnen haben.
Man muss ja die Daten eben nicht mit demselben Programm verarbeiten, welches die Lücke erzeugt. Aber wenn die Lücke nicht zum richtigen Zeitpunkt da ist, schaffen es die schwachen Stromimpulse des Railcom-Decoders nicht, sich gegen das DCC. Signal Gehör zu verschaffen.
Bloß, weil Dir vielleicht bestimmte Kenntnisse und Erfahrungen fehlen und Du einen Beitrag nicht gleich einordnen kannst, ist es schon bemerkenswert, sowas als "schwammig" zu diffamieren. Man muss nicht gleich so persönlich werden. Das scheint mir schon etwas sehr leichtfertig an Mobbing zu grenzen....

Gruß

vik

Ich hatte Dir doch vor langer Zeit einen meiner DCC/Railcom Logger geschenkt. Ist der kaputt? Schliesse den doch mal an und dann siehst wo das (moegliche) Problem liegt.

https://rtb4dcc.de/blog/dcc_logger/

VG,
Frank

Hallo Roland, doch, mit kleinen Unterbrechungen seit 2011  und die Teilnehmer müssen sich sogar selbst Getränke und ggf. auch etwas zu essen mitbringen. Aber wir sind immer eine ganz nette Runde. Es handelt sich um einen VHS-Kurs. Das sind die Kosten für den Raum, die Nutzung der medialen Infrastruktur und die Kursverwaltung.
Glaubst Du wirklich damit kann man seine eigene Modellbahn finanzieren?
Wieviel kostet Dich das denn, wenn Du an einem Stammtisch in einer Gaststätte teilnimmst?

MfG

vik

Hallo Frank, Nein, er ist nicht kaputt, ich nutze ihn, wenn ich mir eine Statistik über viele Ereignisse erstellen will.
Als vorwiegend visueller Mensch fällt es mir zunächst leichter grafisch aufgearbeitete Bilder aus meinem neuesten Analyzer (Vincent Hamp) zu durchsuchen und zu vergleichen.

Links die DCC-EX mit eingeschaltetem Railcom. Die Lücke wird geschnitten der Railcom Decoder sendet seine Nachricht, der Analyzer zeigt die UART-Bits an, kann sie aber nicht decodieren. Das passiert natürlich auch in einem Detector, wie dem RCD.

Rechts das Signal derselben Lok hinter einer MS2 mit nachgeschaltetem Railcom fähigen Booster. Hier sieht man die Nachricht in Kanal 1 und ACK in Kanal 2.

MfG

vik




Die von vikr zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login

Vik,

warum nicht gleich so? Warum laesst Du uns im vagen, wenn Du eigentlich bessere Informationen hast.

Nach dem Bild zu urteilen sehe ich das auch so. Hinter dem Paket-Ende Bit ist ein weiteres 1'er Halb-Bit zu erkennen (hinter der roten Linie). Das darf nicht sein. Somit ja, der Startzeitpunkt der Cutout (=TCS) kommt zu spaet.

VG,
Frank

Die von fschum zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login

Hallo Frank, schön, dass Du meine Anahme bestätigst, ich war mir nicht hundert prozentig sicher und hatte versucht meine Vermutung daher eher in einer Frage zu formulieren.
Ich konnte mir einfach nicht vorstellen, dass es ein derartiger Fehler ist. Die Programmierer werden doch selbst entsprechende Werkzeuge oder zumindest seit 20 Jahren  handelsübliche Detektoren, wie einen Lenz LRC120 haben.
Da es die Railcom-Variante von DCC-EX seit Mai gibt, hatte ich gehofft, dass es auch positive Erfahrungen mit Detektoren von anderen Anwendern gibt.

Vielleicht ist ja der Startzeitpunkt in den Sourcedateien irgendwo parametrisierbar? In die Registerprogrammierung einzutauchen, würde ich mir jedenfalls weiterhin nicht zutrauen...

Da muss man wohl hoffen, dass die DCC-EX-Programmierer sich des Problems erneut annehmen?

Ich bin ja eh ein Optimist und hoffe sogar Märklin baut den Railcom-Cut in CS3 und evt. sogar in die MS2 ein....

MfG

vik

Also wenn was nicht funktioniert dann sag es doch, bitte mit so viel Information wie möglich, am Besten eigentlich Startuplog weil da ist schon einiges drin.

Natürlich haben wir den cutout getestet und auch Loks damit gelesen. Aber da wir ein paar Timertricks anwenden um das DCC Signal so genau hinzubekommen wie möglich kann es passieren dass bei einer anderen Änderung das ein halbes Bit verrutscht ist.

Und nein, RailCom cutout  auf dem Mega ist jetzt nicht so der must-have Hit dass uns die Leute dafür die Bude einrennen.

So erstmal, Mega, unser Motor shield, Ausgang A (MAIN) und exakt welche Version?

Grüße
Harald

Das kostet ungefähr wie alle (*) anderen 5A MOSFET Motor Shields mit 2 Kanälen und individuellen Stromfühlern auf mA Niveau.

Grüße,
Harald

(*) Mir ist eins bekannt das leider nur fast das kann was wir brauchen.

Hallo Harald, ja, wenn es allzu oft gar nicht, oder nicht mit allen Decodern oder nur mit ausgesuchten Detektoren funktioniert, verlieren die Modellbahner selbstverständlich das Vertrauen in Technik mit diesem Namen.
Dabei liegt es meistens daran, dass die Komponenten nicht so präzise implementiert sind, wie es die Spezifikation fordert.

Eine Platinenrevisionsnummer kann ich auf meinem DCC-EX-Motorshield nicht erkennen.
Die Version der CommandStation_EX ist 5.6.4.

MfG

vik

Ich hab auch schon gehört dass wir doch bitteschön RailCom mit dem Arduino Standard Motor Shield implementieren sollen, weil das nicht so überteuert ist.


Dann werd ich das zusammenbauen und mal sehen wo der Cutout sitzt. Heute habe ich aber wahrscheinlich keine Zeit, so bitte noch etwas Geduld.

Grüße,
Harald

@Alle, außer HaBa.



Das vom DCC-EX Team entwickelte EX8874_Motorshield ist doch nicht teuer und weit besser als das Arduino_Shield. Es spart ja auch ein Netzteil ein, wenn Du den Mega2560 nicht am USB Anschluß dauerhaft betreibst. Zum Beispiel wenn das WiFi shield on top dazu kommt und man mit Handregler ohne PC steuert.

Die Motorshieldversion des EX8874 steht m. W. n. auf der Unterseite der Platine. Ich habe Rev. A. Es gibt auch Rev. B.

Gruß.

Hallo Frank, Danke!
Du hast recht. Mein (grünes) DCC-EX-Motorshield ist mit "Rev A" gekennzeichnet.
hallo Harald, klar, freue mich sehr, dass Du der Sache auf den Grund gehen möchtest.

Setzt Du zum prüfen einfach einen Lenz LRC120 ein? Oder nutzt Du einen DCC-EX Logic-Analyzer
https://dcc-ex.com/reference/tools/diagnostic-tools.html#logic-analyzer-decoder
zur Prüfung des DCC-Protokolls oder versuchst Du es einfach mit einem Oszilloskop?

MfG

vik

Ich seh mir das mit dem Oszi an. Mit einem modernen Gerät das Samples nimmt kann ich ja einfach auf den Cutout triggern und dann nach links Bits zählen. Wer es eilig hat und nicht auf mich warten will kann in DCCTimerAVR.cpp die Zeile

finden und da einfach so viel rausnehmen (also z.B. +58) bis es passt. Das wäre mein erster Test. Der Cutin sollte sich um die gleiche Länge verschieben, also der Cutout selber gleich lang bleibt.

Grüße,
Harald

wenn ich hier und in anderen threads  lese verliere ich langsam den Glauben an die Menschheit.
Nein ich brauche kein railcom,
nein ich steuere meine Loks nicht mit einem Rechner und bin dankbar für die Enthusiasten die DCC++ und DCC-EX unendgeldlich entwickeln und zur Verfügung stellen auch wenn ich es nicht nutze.
Vielen Dank
Arne

Hallo Arne, Ist das wirklich so schlimm?muss man auch nicht, man braucht dazu nichtmal digital.
Aber auch wenn man digital - per DCC - fährt und zusätzlich Railcom einsetzt, hat man ein paar nette Vorteile - auch ganz ohne einen Rechner nutzen zu müssen.

By the way: Nutzt Du auch kein Handy mit Deiner Moba?

Und selbst falls Du drohst wegen Railcom den Glauben an die Menschheit zu verlieren, was könnten wir dagegen tun? Warum verzichtest Du nicht einfach selber weiter auf Railcom und lässt andere Modellbahner Railcom einfach nutzen.

MfG

vik

Ja es is so schlimm diese Anspruchshaltung bei Projekten die Enthusiastenn betreiben.
Bei es ist ja so teuer und dann werden Rollmaterial für ein vielfaches angeschaft.
Nein ich programiere die Decoder mit einem Sprog und fahre mit einer Uraltzentrale mit Physikalischen Tasten und Regler.

''[qoute]Und selbst falls Du drohst wegen Railcom den Glauben an die Menschheit zu verlieren, was könnten wir dagegen tun? Warum verzichtest Du nicht einfach selber weiter auf Railcom und lässt andere Modellbahner Railcom einfach nutzen.''[/quote]

Nein mir is Railcom schnuppe , ich habe halt hier das alte Männersyndrom das mich eine Anspruchshaltung bei Opensource nervtund das hier nur der Auslöser war.



für manche Modellbahner !

Aber jetzt is auch gut und ich bin raus.
Gruss
Arne

Hallo Arne, egal, ob Opensource oder kommerzielles Produkt, wenn ein Feature als implementiert gelistet ist, sollte es auch regelhaft funktionieren. Und natürlich kann im Einzelfall auch mal was schief laufen.
Modellbahner, die ein Produkt fertig erwerben und ganz besonders solche, die Bauteile für eine bei Selbstbaulösung erwerben, sollten m. E. sicher sein dürfen dass alles wie beschrieben funktioniert, sofern sie die Anleitungen bei Bau Installation und Inbetriebnahme akkurat beachtet haben. Bei kommerziellen Produkten greift im Zweifelsfall die Garantie. Opensource-Lösungen sollten doch keine Wetten sein, wieviele von den genannten Eigenschaften vielleicht genutzt werden können.
Bei DCC-EX ist seit Mai 2026 - mit Version 5.6.0, basierend auf Mega, dem DCC-EX-Motorshield - der Railcom-Cut als funktionierend gelistet. Mit anderen Boards wird das erst für zukünftige Softwareversionen in Aussicht gestellt.

MfG

vik

Ich finde inzwischen den Tonfall hier sehr unangenehm.

Es geht nur um DEINE Befindlichkeiten!

Wie wäre es wenn du auch akzeptierst, dass andere Menschen andere Prioritäten haben

Dazu gehört, dass ICH Handys / Touch Bildschirme, ob im Auto oder der MoBa oder anderen Stellen einfach ätzend finde

Damit spreche ich anderen Usern nicht ab das zu Nutzen! Ich rechtfertige mich aber nicht, für meine Art der Nutzung!

Davon ab, habe ich mir Handregler mit Touch gebaut, die ich mit physischem Drehregler nutze.
Trotzdem nutze ich das Handy für solche Zwecke nur notgedrungen und nicht für den Hauptzweck.

Franzi

Hallo Franzi, OK!
sorry, da hast Du mich mißverstanden, mir ging es darum, dass man nicht porstulieren sollte, dass man mit seiner Modellbahn keinen Rechner benutzt, wenn man mit Handy oder Tablet (oder einem Arduino) steuert oder eine Linuxzentrale wie ECoS, CS etc. einsetzt.
Und natürlich es gibt keine RICHTIGE Art und Weise das Modellbahnhobby zu betreiben, also auch keine FALSCHE. Art und Weise.
Railcom zu nutzen ist - wie so vieles - Geschmackssache.

Eine Aussage wie "ich brauch kein Railcom" sagt also für andere genauso wenig, wie "Ich brauch kein digital", um mit meiner Modellbahn glücklich zu sein. Warum sollte man das jemandem absprechen?

MfG

vik

wer RailCom nicht braucht oder nutzen möchte, kann das gerne tun und sich am besten aus den Diskussionen dazu heraushalten... Ich finde RailCom eine feine Sache, wenn es funktioniert. Und wenn etwas nicht ganz perfekt ist, Entwickler wissen eine konstruktive Kritik immer zu schätzen.
Also dranbleiben und DCC-EX weiter verbessern.

VG Uli

Dieser Thread ist fast voll, und wir können (bald) neu weitermachen.



Vik, ich finde diese Anspruchshaltung gegenüber Open-Source-Projekten maßlos. Man darf nicht vergessen: Diese Projekte entstehen in der Freizeit und sind nicht kommerziell.



„... sollten sich ... darauf verlassen können ...“ – Wow, das ist wirklich ein starkes Stück, im Kontext von OpenSource.

Ganz ehrlich: Genau solche Erwartungen halten mich davon ab, hier irgendetwas über meine eigenen Selbstbauprojekte zu veröffentlichen. Nur mal ein paar Zahlen: Ich investiere seit etwa acht Jahren enorm viel Zeit in die Entwicklung meines digitalen Steuerungssystems und habe weit über 5.000 Euro (also fünftausend) für Prototypen und Testaufbauten ausgegeben. Es funktioniert zu meiner Zufriedenheit, ist aber keineswegs fehlerfrei. Kommentare wie die oben genannten wären für mich nur schwer zu ertragen.

Beste Grüße
Frank

Hallo Frank, Ich schätze Deine Engagement sehr, glaube Dir aber natürlich, dass Du auch getestet hast, was bereits mit Deinen Komponenten in einem konkreten Kontext funktioniert. Natürlich kannst Du einen ausführlichen Disclaimer anfügen und Dein Projekt dabei genau erläutern.
Und natürlich darf auch beschrieben werden, was vielleicht irgendwann funktionieren soll, aber es muss beschrieben werden, was derzeit noch nicht zuverlässig funktioniert.

Ich fände aber keineswegs seriös Leute zu animieren in ein Projekt - egal ob gewerblich oder nicht - Geld und Lebenszeit zu investieren, wenn man ihnen nicht eine   Mindestfunktionalität zusichert. Erhoffte Möglichkeiten können, Risiken müssen beschrieben werden. Es gibt viele Modellbahner bei denen das Geld nicht so locker sitzt, dass sie sich da Fehlinvestionen leisten könnten.

MfG

vik

Das ist das schöne an einem Projekt ohne Installer wo man config.h von Hand editieren muss (also wie das originale DCC++): es hällt einem die Anwender mit unrealistischen Ansprüchen vom Hals.

Und, meinen Vorschlag von #89 ausprobiert?

Grüße,
Harald.

Sorry, aber Du hast echt einen Vogel !!