THEMA: Kennt ihr schon DCC++ / DCC-EX 12?

Was meist du Frank, sieht das jetzt besser aus?

Wir haben 8x 1 (Checksum) und dann Packet-end 1 und dann den Cutout.

Grüße,
Harald

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

Hallo zusammen,

bei Open Source muß man sich ein dickes Fell zulegen und darf sich von einzelnen nicht den "Spaß an der Freud" verderben lassen. Schade ist, wenn das Kooperative auf der Strecke bleibt. Ich habe das auch schon in beiden Richtungen erlebt. Einerseits, als ich für Trainz Content erstellt hatte, andererseits als Nutzer einer Open Source-Datenbank-Middleware, wo der Hauptentwickler nur Bugreports gegen die allerneueste Version und nur mit Testcases entgegen nahm, was bei den sporadisch auftretenden Problemen oft nicht möglich war, und er auch sonst ziemlich hochnäsig war. Irgendwann haben meine Kollegen und ich diese Middleware komplett herausgeschmissen und durch traditionelles SQL ersetzt, was vielleicht nicht so ganz elegant ist, aber unsere Probleme beseitigt und die Performance erheblich gesteigert hatte.

Insofern möchte ich appellieren, doch ein bißchen herunterzufahren. Auch wenn ich mein eigenes Projekt verfolge, das vielleicht mal in ferner Zukunft auch ein Open Source-Projekt werden könnte und dann auch in gewisser Konkurrenz zu diesem, Franks hochprofessionellem Projekt RTB oder Vincents OpenRemise stünde, finde ich die Diskussionen höchst interessant und würde es bedauern, wenn das aufgrund von Streitereien das hier nicht mehr stattfinden würde.

Klaus

@Harald,

Meine Interpretation des Osszi Bildes,

- links ein Null-Trennbit
- dann folgenden 8-bits (= XOR)
- dann folgt das Paket-Ende Bit

Die Cutout muss nun innerhalb der naechsten 26-32us starten (=TCS). Dem scheint so zu sein. Somit wuerde ich sagen - Ja, sieht gut aus.

VG,
Frank

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

Hallo Frank,

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


Musste das denn wirklich sein? Wie alt bist Du?

Gregg Bermann wendete sich mit DCC++ explizit an Bastel-Enthusiasten, die sich auch mit Mikroprozessoren vertraut machen wolle und zwar an Hand der damals didaktisch erfolgreichen Arduino IDE und den industriell verbreiteten Atmels. Dass DCC-EX-Projekt wendet sich in erster, Linie an informationstechnische Laien die eine Modelbahn digital betreiben wollen und das möglicht preisgünstig. .
Nach DCC-EX Nomenklatur sind das  "Conductors" und die etwas technikaffineren "Tinkerer" und nur ganz ausnahmsweise an Fachleute "Ingeniers". Die ersten beiden Gruppen müssen abholt werden, d. h. informmiert werden, damit sie überhaupt sinnvoll einschätzen können, ob sie selber mit hinreichender Aussicht auf Erfolg in dieses Projekt Geld und Zeit investieren oder ihren aktuellen Wunsch-Modellbahnstart (z. B. mit Railcom) besser mit einer kommmerziellen Lösung zu realisieren versuchen.

Genau mit dem Schritt den Modellbahner mit dem Installer von der config. h und damit eigentlich nicht nur von der Bedienung der Entwicklungsumgebung sondern auch  damit vom Programmieren so weit wie möglich abzuschirmen wird die eigentlich gemeinsame Augenhöhe der Entwickler bei Opensource verlassen. Die Entwickler erwarten keine angemessen Kenntnisse und dürfen solche Kenntnisse auch nicht mehr voraussetzen, wenn sie den Gebrauch der Anwendung beschreiben...
meinst Du, dass die "Conductors" und "Tinkerer", die ihre DCC-EX-Zentrale mit dem Installer aufgesetzt haben, Harald und Dir hier einfach mal so folgen, um - eventuell - DCC-Adressen auf ihrem Detektor sehen zu können?
Ich halte das für sehr unrealistisch.

MfG

vik

Hallo,

da möchte ich gehässig fragen, ob sich Linus Torvalds höchstpersönlich darum kümmert, wenn ein DAU nicht über den Login-Prompt von Linux hinauskommt. Daß sich das DCC-EX-Team stark bemüht, halte ich für offensichtlich. Daß es nicht jeden "abholen" kann (ich hasse diese Terminologie in der Politik), sollte doch auch verständlich sein, gerade weil es kein Projekt ist, daß sich durch Verkäufe finanziert, sondern hier Leute Freizeit und teilweise eigenes Geld investieren und die Ressourcen deutlich stärker beschränkt sind als bei einem gewinnorientierten Unternehmen. Da spielt es auch keine Rolle, ob das Team versucht, das Projekt für eine erweiterte Benutzergruppe verfügbar zu machen. Du machst aus einer Tugend einen Vorwurf.

Just my two cents,
Klaus

Hallo Klaus,

da leg ich doch glatt meine zwei Cents dazu 🙂

lg
threedots

Eine der Zielsetzungen ist, das man nicht unbedingt ein IT-Experte oder Elektronikexperte sein muss um DCC-EX anzuwenden. Die Community, die wir in Discord gesammelt haben zeigt uns auch dass das möglich ist. Die Teilnehmer dort versuchen uns nach bestem Können zu helfen. Manche können es besser, manche nicht so. Vor allem in der Ausführung einfacher Anweisungen hapert es, z.B. "Dialog öffnen und Log schicken". Leider gibt es auch unter denen einige wenige Abwender, die den Unterschied zwischen einem Communityprojekt und einem gewinntreibendem Unternehmen nicht verstanden haben.

Doch ist mir bis jetzt noch keiner untergekommen der aus einer Art Kundenanspruch heraus sich wie ein DAU verhält nur um zu demonstrieren dass wir nicht gut genug sind einen DAU zu hantieren. Genau so kommst du rüber.

Fehler/Bugs (wie jetzt wahrscheinlich beim Cutout) passieren, besonders anfällig sind Features die sehr wenige Anwender wirklich nutzen. Eine wirkliche Kontrolle (außer mit Oszi oder Logikanalysator) für das DCC Signal gibt es ja nicht. Kann ich bei der NMRA oder der RC einen Sketch runterladen der mir sagt ob mein DCC-Signal korrekt nach Norm (inklusive Cutout) ist? Nee, kann ich nicht, gibt es nicht. Es gibt ja nicht einmal eine publizierte Checkliste.  Weil dass mir irgendeine Decoder in irgendeiner Lok zusammen mit einem Detector RailCom Daten zurücksendet sagt ja eigentlich gar nix, weil die Produkte sind wahrscheinlich aus gutem Grund auf "sehr tolerant" eingestellt.

Grüße,
Harald

Hallo Klaus. habe 1993 erlebt, wie Leute reiheweise ihre Commodores und Ataris stilllegten und sich auf vorher verschmähten PCs einen ersten Linuxrechner aufgesetzt haben. Das waren nicht alles Informatiker, aber schon eher ambitionierte Leute. Vielleicht jeder achte davon war längerfristig erfolgreich. Vom Rest sind etliche ziemlich schnell zum Mac gewechselt, die meisten haben - binnen einem Jahr Windows auf ihrem PC installiert.
wohl eher nicht, für die soziale Lebens-Kompetenz hat er glücklicherweise seine Frau gewonnen. Im Arbeitsalltag ist er eher nicht für soziale Kompetenz bekannt.
https://www.spiegel.de/netzwelt/netzpolitik/lin...ueche-a-1228556.html
Auf den von mir besuchten Stammtischen tauchen immer mal Leute auf, nicht immer nur die Jüngsten, die den Anspruch hatten eine digitale Modellbahnsteuerung ("so wie im Modellbahnwunderland" ausschließlich aus selbst aufgebauten und programmierten Komponenten zusammenzustellen. Sie sind vielleicht nichtmal so fachfremd, etwa Mechatroniker oder Netzwerktechniker, bringen ein paar DCC-EX-Komponenten mit und klagen, dass sie wohl ein Brett vor dem Kopf haben, weil sie selbst das Ding nicht ans laufen bringen, dabei sind sie einfach nur auf Werbung und sozial Media-Mechanismen - meistens den Bestätigungsfehler reingefallen ohne es nur ansatzweise zu bemerken...

Was nicht heißen soll, dass ich Linus Thorvalds nicht für ein Genie, Git für eine wundervolle Iniative und DCC++ für ein tolles Projekt halte. Aber was daraus mit so manchem Slogan:
https://www.stummiforum.de/t222155f7-Analog-DCC...EXRAIL-Beispiel.html
beworben und geworden ist, sehe ich eben kritisch.
Nachdem ich vor zwei Wochen erfahren habe, das DCC-EX jetzt - nach zehn Jahren - mit Version 5.6 auch nativ den Railcom-Cut beherrschen können soll, habe ich mir das dafür - seitens DCC-EX - als erforderlich beschriebene DCC-EX-Motorshield besorgt und einfach mal ausprobiert.
Fazit: "erstmal dumm gelaufen!"
Wer sich ein wenig mit der Programmierung von solchen Mikroprozessoren auskennt, wird vielleicht meine Sorge teilen, dass ein solcher Hack in einer Hochsprache - wie ihn Harald hier vorstellt - das Timing nicht unbedingt für jede Betriebssituation des Prozessors im Anlagenbetrieb zuverlässig löst.

MfG

vik

Hallo,

die NMRA schaffen es offensichtlich,  ein moderne Testumgebung zu definieren. Es gab angeblich einmal eine PC Karte dafür aber weshalb man da nicht einfach ein Shield für einen Arduino oder Raspi mit der entsprechenden Anwendung gebastelt hat, verstehe ich auch nicht.  Die RCN scheint da nur hinterher,m zu japseln,  weil es auch in Europa niemand zu geben scheint, der das machen möchte  bzw.  Zeit und Kapazitäten dafür freigegeben möchte. Unter den Modellbahnherstellern gilt traditionell eine "mir san mir" Einstellung, da haben sich einige sehr ungünstig positioniert.

Grüße,  Peter W

Ok, ich denke die Argumente sind ausgetauscht. Lasst uns wieder zu DCC_EX zurückkehren.

Das Cutout Problem im derzeitigen Code scheint identifiziert, und wir warten jetzt mal auf den Fix. Ich bin mir sicher, Harald wird uns an dieser Stelle informieren.

Danke!

Naja, so richtig "rund" dürfte es personell bei der NMRA auch nicht rennen...
Und das man es nicht geschafft hat sich da zusammenzutun versteh ich auch nicht.

Hallo Harald,bislang kann es mit DCC-EX fur geneigte Modellbahner ausschließlich um Kanal 1 Adressmeldungen gehen, schließlich stellt DCC-EX nur die Lücke zu Verfügung und kann selbst keine Railcom-Nachrichten verarbeiten.

Hier ist seit zwanzig Jahren der Lenz LRC120 genau der tolerante Standard (auch wenn die Firmware des LRC120 in Zusammenhang mit bestimmten dynamischen Kanal-2-Meldungen einen von Lenz bestätigten Fehler hat),
Der LRC120 zeigt praktisch immer die korrekte aktuell im Decoder eingestellte Adresse an, wenn das Timing aller anderen Komponenten einigermaßen spezikationskonform ist und man im Decoder ggf. Kanal-2 ausschaltet.

Wenn man will kann man den LRC120 bei traditionell gut sortierten Händlern auch noch kaufen:
https://www.google.com/search?client=firefox-b-m&q=LRC120

MfG

vik

Hallo Viktor,

ich treibe mich nur gelegentlich auf dem Stummiforum herum, bislang meist Anfang des Jahres, wenn die Neuheiten präsentiert werden. Da war zumindest früher das Forum am schnellsten. Soll aber nicht heißen, daß es schlecht ist, nur bislang halt kein "Draht" dazu gefunden. Ich gebe Dir insofern recht, daß die Präsentation des DCC-EX-Projekts des Users md95129 alias Henner tatsächlich falsche Erwartungen wecken kann, wenn ich das so überfliege. Ist denn dieser User in irgendeiner Form ein Teil des Teams oder ist er bloß ein "Fanboy"? Im letzteren Fall kann man dem Team keinen Vorwurf machen. Auf der anderen Seite ist doch dort eine lebhafte Diskussion entstanden und dieser Henner scheint ja auch da anderen zu helfen. Jedes OSS-Team kann sich doch glücklich schätzen, wenn es solche Leute gibt.

Klaus

Ernsthaft? … Du empfiehlst einen 20 Jahre alten Kanal-1 only Detector, der ca. 60€ kostet und ggf. die kanal-2 Abschaltung notwendig macht. Das ist genau die Art von Promotion die Du doch so vehement kritisierst. Dieses Produkt gehört auf den Wertstoffhof aber nicht in den Einkaufswagen.

Wenn man mit RailCom in einem Projekt anfängt, was ist nützlicher zuerst: Die Lücke oder der Detector?

Außerdem kann man die Daten zu einem Computerprogram schicken, z B JMRI.

Grüße,
Harald

Hallo Harald,natürlich muss ein Zentralenprojekt mit der Lücke starten, wie Ihr das auch gemacht habt.
Schließlich sollen ja existierende Loks mit Railcom fähigen Decodern ihre Nachrichten irgendwo hinschreiben können. Existierende lokale Detektoren anderer Hersteller können diese Nachrichten dann aus dem Gleis auslesen und anzeigen oder dorthin senden, wo sie angezeigt und ausgewertet werden. Das funktioniert aber alles auch nur, wenn alle spezikationskonform arbeiten.

Ein globaler Detektor in der Zentrale ist natürlich in gewisserweise die Kür, weil damit Daten, z. B. CV-Werte - aus dem Decoder an die Zentrale übermittelt werden können. Die Zentrale muss aber mit diesen Nachrichten auch sinnvoll umgehen können.. Globale Railcom-Detektoren ermoglichen aber - wie übrigens auch mfx - keinerlei Ortszuweisung von DCC-Lok-Adressen auf Abschnitte der Anlage.

MfG

vik

Hallo Frank, nicht wirklich. Lenz sollte ihn endlich updaten.
Aber er kann eben ganz einfach und zuverlässig anzeigen ob DCC-EX es schafft die Lücke korrekt zu schneiden, wie es die Lenz LZV200 die z21 und Z21, die Digkeijs und Yamorc-Zentralen, neuere Uhlenbrock-, Piko- oder Tams-Zentralen und natürlich auch die ECoS machen, egal ob da noch andere Detektoren werkeln oder nicht.
Mit einer sorgfältig  geschnittenen Lücke (vielen Dank an Harald für den Änderungshinweis der constante nach "Kennt ihr schon DCC++ / DCC-EX 11" Beitrag 89), klappt jetzt nicht nur die Lok-Adress-Anzeige im LRC120, sondern
kann man natürlich sehr viel mehr machen... fragt sich nur was das dann mit welcher Bus-Infrastruktur (CAN, BIDIB etc.) kosten soll. .

Du hast vielleicht schon einen preisgünstigeren - fertig aufgebauten - Detektor aus Deinen eigenen Projektportfolio der sich genauso einfach einsetzen lässt, und den man jetzt als Modellbahner kaufen kann und der u. a. auch einfach die Adresse der Lok auf dem Gleis anzeigt, ohne dass man sie explizit vorher unter ihrer Adresse angesprochen hat?

MfG

vik


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

Ich habe hier mal einen universellen RailCom Detector entwickelt, welcher einfach nur die Lokadresse (Kanal1) anzeigt. Zentrale ist hier allerdings eine Z21PG (Mega mit LM298) nach Philip Gahtow, sollte aber an jeder anderen DCC Zentrale mit Cutout nach RCN217 funktionieren:
https://www.digimoba.de/RC-Detect.mp4
Ist erst ein Prototyp, wird noch weiter entwickelt. Wenn es meine Zeit erlaubt, werde ich mir auch mal die DCC-EX zusammen setzen. Bis dahin bleibe ich stiller Mitleser.
Gruß Holger

Hallo Holger, Danke fürs Video. Ja, seit zwanzig Jahren, die einfachste Art herauszubekommen, welche DCC-Adresse im Decoder einer Lok eingestellt ist. Hat man ein physisches Gleisbildstellwerk, kann man neben jedem Abschnitt in dem Fahrzreuge/Züge halten einen solchen Detektor aufstellen und bekommt angezeigt, welche DCC-Adresse dort gerade steht. Das funktioniert jetzt natürlich auch genauso mit der aktuellen (gefixten) DCC-EX 5.6.x.

Gibt es eine Möglichkeit sich anzeigen zu lassen, mit welcher AUFGLEISRICHTUNG das Fahrzeug auf dem Gleis steht?
Hast Du einen Bus (z.B. LocoNet) implementiert, so dass man die detektierten Infos ggf. auch weiterleiten kann, um sie z. B. auf einem Bildschirm oder in einer APP anzuzeigen?
Ist der L298, der die Lücke bei Deiner z21pg schneidet, als interner Booster oder als externer?

MfG

vik

Hallo Holger - sehr schön, was Du da gebaut hast!

VG,
Frank

Hallo!

Nimm einen Local Detector, klemm den zwischen Booster und Anlage und fertig ist der Global Detector.

Mit diesem Verfahren muss (1) keine Zentralen-/Booster Herdware geändert werden und (2) jeder kann selbst entscheiden, ob er er RailCom nutzen will.
Wenn die Zentrale selbst nichts mit den RailCom Daten anfängt, braucht sie (3) kein wie auch immer geartetes PHY-Interface, Daten-Pass-By ist das Stichwort.

Der Datenmüll der kollidierenden Kanal 1 Broadcasts nach dem Einschalten einer Anlage steigt mit der Anzahl der aktiven Lok- und Zubehör-Decoder. Je mehr Decoder sich gleichzeitig auf einer Anlage befinden, um so länger dauert es, bis sie identifiziert werden können. Das ist eigentlich das KO Kriterium für den globalen Detektor. Sorry!

RailCom POM/XPOM funktioniert prima mit lokalen Detektoren. Also auch hier brauchts keinen globalen Detektor! Nochmals sorry!

Und wenn jetzt wieder über die immensen Kosten für die Detektoren rumgemeckert werden sollte, bedenkt bitte, dass es nur Einmalkosten sind. In die ollen Verbrenner-Autos wird ohne Not  vollsynthetisches Motorenöl gekippt, der Liter zu 25€ und mehr, weil der Hersteller meint, das gehört so.

Mit Platine kommt so ein einkanaliger RailCom Detektor auf Materialkosten deutlich unter 20€, mehrkanalige Ausführungen werden geringfügig teurer.

Mit WLAN bzw. BLE brauchts auch kein kabelgestütztes Bussystem mehr.

Und solange ein frisch aufgegleistes Fahrzeug den spontanen RailCom-Kanal-1-Datendurchfall bekommt, um sich kundzutun, ist eine Diskussion über das zeitlich Verhalten von RailCom müssig. RailCom ist nicht echtzeitfähig und wird es auch nicht werden.

Und dann gibt es noch die diversen allgegenwärtigen elektrischen Störgrößen, die das schwache RailCom Antwortsignal nachhaltig bis zur Unbrauchbarkeit stören können.

LG
threedots

@threedots: Zwei Anmerkungen

1. Railcom ist sehr wohl ein Echtzeit System. Ich habe eine ganze Modellbahn Architektur darum gebaut.

2. Das (schwache) Railcom Signal ist sehr robust, weil es ein vom Decoder eingeprägter Strom ist. Die Betonung liegt auf Strom (nicht Spannung).

@Holger: Hast Du mal daran gedacht, Deine Platine in China fertigen zu lassen? Als Ersatz für das alte Lenz Teil.


VG,
Frank

Hallo Frank,

danke für Deine Anmerkungen. Echtzeit lasse ich für Kanal 2 uneingeschränkt gelten. Kanal 1 braucht hingegen echt mal etwas mehr Zeit 😉.

Dass diese RailCom-Antwort-Strömchen ziemlich robust sind, ist schon richtig. Wenn ich aber sehe, wie grottig manche Gleisverbindungen ausgeführt sind, welche Kabel verwendet werden und wie diese verlegt sind, vom Rollmaterial mal ganz zu schweigen, ist mein Kommentar durchaus angebracht. Auch Störfestigkeit kommt mal an ihre Grenzen. Und das trifft im Besonderen auf die globalen Detektoren zu, die mit allen Störgrößen einer Anlage klar kommen müssen!

LG
threedots

#Vik: Der 298 ist intern in meiner Zentrale (habe ich im Stummi auch gezeigt). Aufgleisrichtung sieht man nicht, muss mal sehen, ob ich das noch implementiert bekomme. Entwicklung geht demnächst weiter, derzeit bin ich etwas gehindert....
# Frank: ich lasse seit einigen Jahren schon meine Platinen in CN fertigen, da habe ich schon einiges an Erfahrung. Mit dieser muss ich erst mal sehen, ob sich das lohnt (Bedarf?), erst mal sollte der Prototyp sauber arbeiten, was er soweit schon tut. Die Entwicklung soll dann auch weiter in Richtung Busanbindung laufen, das war der eigentliche Beweggrund. Mehr möchte ich noch nicht verraten. Aber es sollen möglichst alle Moba- Busse bedient werden.

PS: Wer kein RailCom mag, muss es ja nicht einsetzen. Einige Kommentare hier sind schon etwas befremdlich..........

Hallo,

bezüglich Aufgleisrichtung: ich lese mich ja gerade in die RCNs ein. Ist denn eine Differenzierung nach der Stromrichtung notwendig, da die doch auch auf dem Kanal 1 mit der ID 3 übertragen wird (Bit 0)? Oder ist der Support bei den Dekodern mangelhaft? Die meisten Schaltungen, die ich sehe, auch die Musterschaltung in RCN-217, tun das ja nicht, sondern verknüpfen die mit "Oder" zu einem gemeinsamen Signal.

Klaus

Mangelhaft? Es gibt keinen kommerziellen Decoder der diese Info sendet.
Die Aufgleisrichtung an Hand der Stromrichtung ist leider auch kein eindeutiger Indikator weil früher nicht genormt war auf welcher Seite RailCom einzuspeisen ist.

Du musst die Stromrichtung des RC Signals auswerten. ID3 Unterstützung ist nahezu Null. Ich kenne nur meine eigenen Decoder die ID3 senden. Evtl. auch die neuen Zimos … Vincent?

Ich stimme Vincent zu, die Stromrichtung des RC Signals ist zwar in der RCN-217 genormt - aber die Decoder halten sich nicht dran. Das hat Layout Gründe bei den winzigen Decodern. Ist aber meines Erachtens nicht schlimm. Das Entscheidende ist, dass die „Aufgleisrichtung“ durch die Physik fest vorgegeben ist. Die Zentrale muss das dann in Führerstand 1/2 wandeln.

Hallo Roland, für eine sinnvolle Nutzung von Railcom auf einer Anlage ist eine Identifizierung beim Start der Anlage nicht erforderlich.
Die weißen z21 haben alle einen globalen Railcom Detektor. Er wird allerdings von der überwiegenden Anzahl der Modellbahner nicht genutzt. Die meisten haben den Railcom-Cut sogar eingeschaltet, merken aber nichts davon, bzw. ignorieren ihn einfach. Nur die wenigsten nutzen das Auslesen der CV-Werte auf dem Hauptgleis oder interessieren sich, bzw, nutzen, was etliche Decoder an dynamischen Daten in den Lücken (im Kanal 2) so aufs Gleis schreiben.

In welchen Situationen stört Dich ein irgendwo vielleicht vorhandener globaler Detektor so immens?

MfG

vik

Der LM298 ist für RailCom  nicht gut genug auch wenn es vielleicht funktioniert.

Die PG Software kann jeder anwenden wie er will, würde ich allerdings aus Lizenzgründen nicht wagen als Paket ins Internet zum Download zu stellen noch davon irgend etwas anzuwenden in meiner Software. Aber Klau von Software unter GPL und anderen Lizenzen ist ja heute Gang und Gäbe. Auch die AI hat es irgendwo "aufgeschnappt'.

Grüße,
Harald

Hallo Harald, ja, dass kann jeder für sich auf seiner Anlage machen, wie er möchte. Beim DRV8874 fällt erheblich weniger Verlustwärme an, als beim LM298, deshalb ist er in dieser Hinsicht deutlich besser, aber was genau heißt nicht gut genug? Gibt es da einen causalen Zusammenhang, warum im DCC-EX-Projekt der LM298 in nur Verbindung mit dem Cut nicht eingesetzt wird, aber sonst schon?
Der vergleichsweise hohe Preis ist für etliche Modellbahner schon eine Hürde, wenn sie es einfach nur mal ausprobieren möchten (war es auch für mich).

MfG

vik

In der Railcom Spezifikation steht drin wieviel Spannung an jedem Teil Abfallen darf damit die Stromschleife zuverlässig funktioniert und der LM298 ist drüber.

Siehe auch #11 #86

Grüße
Harald

Hallo Harald, Danke, da muss ich wohl nochmal Einiges nachlesen.

Du meinst exakt die Situation - während der Lücke -   wenn beide Schienen auf das selbe Potential geschaltet sein müssen, so dass der Strom (30 mA), den der Decoder liefern muss, optimalerweise ausschließlich durch den Messwiderstand begrenzt werden sollte? Geht der Weg  nicht nur über die "internen Freilaufdioden" (Bodydioden)?

MfG

vik

Vik,

der LM298 ist klassische bipolar Technik. Es gibt keine Bodydioden. Das Arduino Motorshield verbaut darum externe Schottky Dioden.

Der Railcom Strom muss somit durch den ‚unteren‘ Darlington und dann zurück über eine dieser Schottky Dioden. Das ist eines der Probleme: Über die durchgeschaltete Darlington Stufe fällt Pi mal Daumen 1V Spannung ab, über die Schottky dann nochmal ca. 0.5V macht zusammen 1.5V Spannungsabfall. Das ist ERHEBLICH und jenseits der Specs.

Frank

Hallo Frank,Danke! Das heißt, Lösungen mit dem LM298 sind auf keinen Fall so kaskadierfähig, wie es von der Railcom-Spezifikation gefordert wird.

MfG

vik

Hallo Vincent, stimmt, man muss(te) mit sich eine selbst Konvention ausmachen und aufschreiben und dann immer strikt daran halten (ggf. nachsehen, was man aufgeschrieben hatte ) dann alle die Fahrzeuge austesten und notfalls die Verdrahtung von Decoder, Radschleifern, Motoranschlüssen und Licht entsprechend anpassen.
Mit dem angesprochene Mangel bei der Festlegung/ Implementierung der Aufgleisrichtung, kann man bei Einzel-Detektoren  - genau wie bei den Fahrzeugen noch pragmatisch umgehen.
Aber bei mehrkanäligen (kommerziellen) Railcom-Detektoren, kann es (alles natürlich nur bei Gleisen ohne Mittelleiter) zu nicht auflösbaren Konflikten bei der Bestimmung der Aufgleisrichtung führen. Alleinige Folge eines nicht zuende auspezifizierten Standards und hat zu Folge, dass man beim Kauf - insbesondere von Mehrfach-Detektoren - leider sorgfältigst prüfen muss, was mit dem vorhandenen Bestand an Detektoren logisch bezüglich der Aufgleisrichtung harmoniert.
Tatsächlich können einem - für ein anlagenweit funktionierendes Railcom - eine ganze Menge Details das Projekt verhageln, aber man bekommt es hin, darf bloß leider nicht Komponenten aller Hersteller beliebig mixen.

Ich finde es jedenfalls toll, dass ich mit meiner (nach Haralds Vorschlag gehackten DCC-EX 5.6.(4) jetzt eine DCC-EX-Zentrale mit korrektem Cut habe. Getestet habe ich DCC-EX aber bisher nur mit einem lokalen Detektor und einer, bzw. zwei Railcom fähigen DCC-Decodern.

@Harald: Würde mich freuen, wenn Du hier melden könntest, sonald es von DCC-EX ein offizielles Release gibt, bei dem die Railcom-Lücke (mit Mega und DCC-EX-Motorshield) korrekt generiert wird.

MfG

vik

Moin,



Wieso das?

Ich betreibe seit vielen Jahren mehrkanal Detektoren und es ist noch nie zu einem Konflikt gekommen..

Hallo Frank, mehrkanalige (lokale) kommerzielle Railcom-Detektoren welcher Hersteller hast Du zusammen eingesetzt?
Den Grund, warum es da Probleme geben kann, hatte Vincent genannt:auf Grund fehlender Normvorgaben muss der Hersteller (bei mehrkanäligen Detektoren) willkürlich entscheiden, welches bei seinem Modell der gemeinsame Anschluss ist, der an die "nicht unterbrochene Schienenseite" angeschlossen werden soll.

MfG

vik

Vik,

das ist Deine Misinterpretation des Sachverhalts. Das hat Vincent auch so nicht geschrieben.

Warum redest Du in einer Tour die Dinge schlecht, vor allem schlechter als sie wirklich sind. Ich finde das unerträglich.

Zur Steigerung der Komplexität darf Viktor gerne auch noch über die Fragestellung Aufgleisrichtung und Fahrtrichtung im Zusammenhang mit Kehrschleifen sinnieren.

Ich fahre vorwärts in die Kehrschleife ein, vorwärts wieder raus und die Aufgleisrichtung hat sich geändert! Wie korreliert denn nun die Aufgleisrichtung mit der Fahrtrichtung?

Und dann darf er auch mal ausführlich erklären, was die schaltungstechnische Detektion der Aufgleisrichtung in einem RailCom Detektor mit RailCom zu tun hat!

Und als letzte Aufgabe darf er noch die Frage beantworten, was das ganze eigentlich mit DCC-EX zu tun hat.

LG
threedots

!!!

Hallo Frank, im Gegenteil! Mit DCC-EX, modifiziert, wie von Harald beschrieben, funktioniert mit dem Railcom-Cut alles, was überhaupt damit möglich ist, sofern man nicht vor lauter Begeisterung, die falschen Hardware-Komponenten nimmt.
Also eine DCC-EX 5.6.x aufsetzen und einfach selber ausprobieren!

MfG

vik

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

Wenn wir davon ausgehen dass wir als DCC-EX Anwender doch daran intressiert sind in welche Richtung der Decoder auf dem Gleis steht dann ist es intressant ob der Standard das in Wirklichkeit hergibt und welche Schaltungen im Detector benötigt werden um das zu erreichen. Es sieht aus als würde es bei Frank Sch. funktionieren das macht ja Mut, allerdings lebt DCC-EX mit ganz vielen Decodern zusammen  - wir macht man es am besten in dem Fall?

Es bringt aber nix hier auf die bösen Buben von DCC-EX zu schimpfen die die ganze Community an der Nase herumgefuhrt hat. Und wenn, dann bitte mit Vorschlägen die erläutern wo denn die Probleme liegen. Wenn allerdings _andere_ die Selbstbauzentrale als die EUR 10 Lösung für Jederman vorstellen - was sollen wir dagegen tun? Ich kann ein Lied davon singen wie Erwartungen und Fähigkeiten (und sei es nur bei der Kommunikation, z.B. _lesen_ von Anleitungen) unserer Anwender auseinanderklaffen.

Grüße,
Harald

Die Polarität des RC Signals als Aufgleisrichtung funktioniert mit jedem RC fähigen Decoder!

- drehe ich die Lok auf dem Gleis um, ändert sich die Polarität.
- durchfährt eine Lok eine Kehrschleife, ist danach die Polarität ebenfalls invertiert - klar, die Lok steht ja nun andersherum im Gleis.

Diese Eigenschaft ändert sich nie - egal was man macht.

—————

Nennen wir die Aufgleisrichtung: (+) bzw. (-)

Wir wissen nun für jede Lok, ob diese soherum (+) oder andersrum (-) steht.

Was wir leider nicht wissen, ob (+) dem Führerstand 1 oder 2 entspricht. Das müssen wir in der Zentrale hinterlegen. So wie wir der Zentrale sagen, die V60 hat DCC Adresse 60, müssen wir der Zentrale beispielsweise noch sagen: ‚Bei dieser Lok ist (+) identisch mit Führerstand-2 voraus‘

Frank

Hallo Harald, das hatte Holger eigentlich schon beschrieben. Man darf die Ausgänge der Operationsverstärker im Detektor nicht verodern, sondern muss sie getrennt nach Adresse verarbeiten. Im Gegensatz zu DCC sind die Railcom-Nachrichten "UARTs" d,h. jeweils komplett entweder positiv oder negativ.
Ich seh mal nach, ob ich Dir ein Osci-Bild schicken kann.

Hast Du einen Link auf die COMMAND-EX-Version, mit der die Railcom-Lücke korrekt geschnitten wird?

MfG

vik

Ist das so schwer zu finden?

https://github.com/DCC-EX/CommandStation-EX/releases/

Grüße,
Harald

Das UI von GitHub ist leider tatsächlich wenig intuitiv. Ich hab schon E-Mails von anderen ENTWICKLERN bekommen die die Releases nicht gefunden haben.

Hallo Frank,

Du hast voll ins Schwarze getroffen. Die ganze Intelligenz gehört in den Fahrzeugdecoder, nicht in den RailCom Detektor. Ob das Kind nun +/-, rechts/links, ost/west, vorne/hinten oder sonstwie genannt wird, ist eigentlich egal. Das jeweilige Fahrzeug muß die Referenz für die Aufgleisrichtung sein.

Meine V60 ist aber noch analog! Die ist als Referenz also ungeeignet😎

LG
threedots

Hallo Harald, Danke, dass Du die CommandStation-EX 5.6.5 heute Mittag eingestellt hast.
Ich hatte zuletzt heute morgen leider noch vergeblich gesucht.

MfG

vik

Hallo Harald,hier die angekündigten Osci-Bilder.
Im ersten Bild sind die Strom-Verläufe auf dem Gleis in der Lücke alle positiv, im zweiten Bild alle negativ.
Wenn alles korrekt verdrahtet ist und von den nachfolgenden Software-Ebenen fehlerlos weitergeleitet und interpretiert wird, kann die Aufgleisrichtung auch korrekt angezeigt werden.

Detektoren, die das Gleissignal verodern, machen das Vorzeichen weg und erkennen die korrekte Adresse, aber verlieren die Aufgleisrichtung.
Bei den TAMS RCDs mit per RS482 angeschlossenem vierstelligen Display (RCA-1) gibt es fünf Möglichkeiten.
Der Abschnitt ist leer: es wird ein Strich "-" angezeigt.
Im Abschnitt wird Strom verbraucht, aber keine Adresse detektiert: es wird ein doppeltes Klammernpaar (()) angezeigt.
Eine Adresse wird erkannt: Die Adresse wird angezeigt.
Eine Adresse und die Aufgleisrichtung wird erkannt: Die Adresse wird dargestellt und der Dezimalpunkt wandert in Aufgleisrichtung durch die Ziffernanzeige, also entweder von der höchstwertigen Ziffer zur niederwertigsten oder umgekehrt.
Die Codierung der Werte im Transportprotokoll vom Detektor zur Anzeige kann durchaus problematisch sein. Oft wird die Aufgleisrichtung einfach binär codiert (vorwärts = 0, rückwärts =1), weil DCC-Adresse, Detektor-Nummer und Aufleisrichtung alles in zwei Byte passen soll, wird der Zustand "Aufgleisrichtung nicht vorhanden oder nicht erkannt" gar nicht codiert. Der Wert unterscheidet sich dann nicht von vorwärts.
Wird die Aufgleisrichtung also nicht zuverlässig erkannt und die Lok steht "rückwärts" auf dem Abschnitt wechselt die Codierung zwischen "1" (rückwärts) und "0" (nicht erkannt) ohne dass sich Aufgleisrichtung auf dem Gleis wirklich ändert. Für ein Steuerprogramm sind die Railcom-Nachrichten dann außerordentlich verstörend, die Schuld wird Railcom gegeben, dabei liegt es an der unglücklichen Implementierung der Weiterleitung vom Detektor zur weiter verarbeitenden Instanz.
Dies ist m.E. der wichtigste Grund warum viele Modellbahnsteuerprogramme dazu tendieren die Railcom-Daten zwar zur Anzeige bringen, aber bei Entscheidungen während des Betriebes recht konsequent ignorieren.

MfG

vik

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

Hallo, hier noch Fotos mit einem RCD-1.:
1. Gleis frei.
2. Gleis besetzt. (tatsächlich hat mein über 15 Jahre alter RDC-1 mit manchen Decodern Probleme, vielleicht sollte ich die Elkos ersetzen.)
3. Adresse 1037. (Dezimalpunkt läuft von links nach rechts)
Kann man hier im Forum anstatt Bildern auch kurze Videos hinterlegen?

MfG

vik


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

Na dann werden wir mal Vers. 5.6.5 in den Mega2560 einspielen.

Edit: Korrektur Versionsnummer.

Hallo Frank,
mit der V5.6.3 wird es wohl noch nicht klappen. Du benötigst die 5.6.5 vom Freitag.

MfG

vik

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

Danke, ein Tippfehler. Tschuldigung.

@Beitrag 50

Videos geht, wenn Du selbst einen Account auf YT z.B. hättest, dne Du dann verlinkst.

TAMS Hardware cooperiert also schon mal ein wenig mit dem DCC-EX Projekt; RC Austastlücke. Es genügte mir schon, wenn ich einen Maintrack RC Input via Sniffer und Anzeige hätte wie im Beispiel.

Jedenfalls sieht so deine Schaltung auf den ersten Blick aus.

Hallo Frank, ja, die ersten RCD-1 gab es 2008 kaufen. Sie funktionierten seither mit jedem Booster/ Zentrale, die die Railcom-Lücken zum richtigen Zeitpunkt in den DCC-Paketen auf das Gleis sendet, wie z.B. auch der Booster2 (2007/2008) von Wolfgang Kufer hinter jeder (NMRA kompatiblen) DCC-Zentrale.

Man kann das RS485-Kabel auch statt (oder zusätzlich) an ein Display, an das RC-Link führen und das RC-Link per USB an einen PC. Mit dem Programm RC-Link-Tester kann man sich die auf allen (maximal 24 an einem RC-Link) angeschlossenen Detektoren gerade erkannten DCC-Lok-Adressen dann - einschließlich Aufgleisrichtung - auch permanent listen lassen.
Die Aufgleisrichtung wird dann durch einen Richtungspfeil vor der Adresse angezeigt. Natürlich funktioniert das mit allen Programmen, die den RC-Link einbinden können!

MfG

vik

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

Was haben eigentlich TAMS und seine nicht mehr lieferbaren Produkte mit DCC-EX zu tun?

Anstelle Reklame für Zeug zu machen, das es nicht mehr beim Händler zu kaufen gibt, sollte lieber mal drüber sinniert werden, wie sowas für DCC-EX Teilprojekt im Open Source Kontext aussehen kann. Es gibt da ja einige Ansätze, z.B. die von Frank oder Paco, aber deren Quellcode ist Closed Source.

LG
threedots  

Hallo,


So einen Ansatz verstehe ich überhaupt nicht, außer die Autoren verwenden Programmteile oder Libs, die ihnen rechtlich nicht gehören.

Grüße, Peter W.

Hallo Roland, seit letzter Woche funktioniert der Railcom-Cut mit DCC-EX-5.6.5. Ich bin begeistert und finde es toll, dass man das jetzt mit Komponenten testen kann, die schon mit anderen Zentralen funktioniert haben, zum Beispiel auch der Selbsbau-Detector mit Anzeige von Holger, die ja hinter der z21pg funktioniert.

Auch die Nachbauten der Komponenten von Paco und Abkömmlinge davon, eigentlich alles wo die Aussicht besteht, dass es heute funktioniert, fände ich interessant auszuprobieren, das muss auch nicht zwangsläufig Openource sein. Ich habe durchaus Verständnis dafür dass, Wenn jemand wie Paco oder Frank (Fschum) soviel Arbeit in ein Projekt gesteckt hat, er die Sourcen nicht veröffentlicht oder es gleich als Produkt einordnet.
Du selber hast berichtet, dass Du Dir - aus bestimmten persönlichenGründen eine ECoS mit passendem Detektor beschafft hast.

Ich teste jetzt aus, was ich so habe, halt mit der DCC-EX-5.6.5 aus.. Modellbahnhobby bedeutet für mich
"Ausprobieren, was so mit dem Vorhandenen mõglich"

So wird das RC-Link schon seit etwa 2012 und DCC-EX-5.4.x seit letztem Jahr auch von Windigipet unterstützt.

Die Kombination DCC-EX-5.6.5, RCD  mit RC-Link und Windigipet-2025c-Demo  funktioniert bei mir. Das Einrichten ist allerdings recht knifflich und vielleicht nicht jedermanns Sache aber so finde ich die Railcom-Lücke schon mal gut genutzt. Vermutlich klappt es in ähnlicher Weise auch mit Traintastic oder Rocrail etc.
Ich würde mich freuen, auch über andere Testergebnisse mit DCC-EX und Mut zur Lücke zu lesen. Wen das nicht interessiert, der kann es ja einfach überlesen.

Auf dem ersten Bild wird die vom RCD erkannte Adresse im Gleisbild (im Fahrzeuganzeiger) angezeigt und der Name ergänzt. Geht man mit der Maus auf diesen Eintrag wird das in der Fahrzeufdatenbank hinterlegte Bild in der gemeldeten Aufgleisrichtung (zweites und drittes Bild) eingeblendet!
Sollte ich Windigipet deshalb nicht nutzen, weil es nicht OpenSource ist?

MfG

vik



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

Hallo Peter,

ich verstehe das auch nicht. Aber so spielt das Leben.

LG
threedots

Es gibt noch andere Gründe:

* Die Autoren meinen irgendwann mal ein Produkt darauf zu basieren (schwieriger das Produkt dann zu kopieren) von dem sie was verdienen könnten

* Die Autoren wollen verhindern dass jemand anderes ein Produkt darauf basiert und es dann (je nach Lizenz) unrechtmäßig verkauft

Nur som am Rande:  Es gibt eine DCC-EX Zentrale in Indien die als "DCC-EX" verkauft wird ohne dass wir gesagt haben dass der Name verwendet werden darf und ohne dass die GPL berücksichtigt wurde. Eine Schar von Anwälten wie LEGO haben wir allerdigs nicht.

Grüße,
Harald

Ich bin bereits mit Harald in Kontakt wegen der RailCom Detektor Frage.

Demnächst mehr in diesem Theater .....

Das ist eine steile These und zugleich eine Unterstellung. Ich frage mich oft, warum soll man sich das antun.

Der Code ist von der ersten bis zur letzten Zeile selbstgeschrieben, zu 100% hardwarenahe in Assembler programmiert und verwoben mit den Echtzeit Bus-System. Es läuft auf AVRxxYYzz Prozessoren.

Peter W und threedots: Was genau wollt ihr jetzt für DCC_EX übernehmen?

VG,
Frank

Glaub ich dir gern, bei DCC-EX haben wir uns entschieden das zu vermeiden.

Warum?

* Sehr wenige die Assembler schreiben/lesen können
* Noch weniger die Assembler für moderne 32bit uCPUs kennen (ARM oder Xtensa, z.B)
* Der Gewinn doch sehr begrenzt ist (Timing durch Anzahl der Instruktionen)
* Die Portabilitär auf einen anderen Prozessor total flöten geht

Doch haben wir nix daegen wenn auch andere unsere Protokolle anwenden, wir versuchen das so gut wie möglich zu dokumentieren.

Bei uns ist alles GPL und nicht irgend ein Mix aus GPL, MIT und undefiniert wie man so oft findet. Das war auch eine für uns wichtige Entscheidung.

Grüße,
Harald

Hallo Frank,

ich könnte mir vorstellen, Deine Diodenschaltung zur Polaritätserkennung (aka Detektion der Aufgleisrichtung) zu übernehmen. Der Code zur RailCom Decodierung der Kanäle 1 und 2 muß ja auch noch implementiert werden. Das ist Fleißarbeit und entspricht so ungefähr der Neuerfindung des Rades zum x-ten Mal.

Ich habe gerade mein eigenes kleines Projekt namens „RCD W-EX“ gestartet, um mittels eines ESP32-C3 das Gleisformat abzugreifen und daraus RailCom Antwort Pakete zu extrahieren/decodieren. Im ersten Step soll mal die Lokadresse aus Kanal 1 nebst Aufgleisrichtung auf einem OLED Display dargestellt werden - mit Kollisionserkennung auf Kanal 1!

Folgen soll dann die vollständige Decodierung beider RailCom Kanäle gemäß RCN 217 und 218 und die Implementierung eines Interfaces zur drahtlosen (!) Datenübermittlung an DCC-EX.

Fühle Dich eingeladen, an der Entwicklung mitzuwirken. Da ist fast alles noch offen!

LG
threedots

Hallo,

bitte keine Grundsatzdiskussionen über Assembler vs. Hochsprache.

LG
threedots

Also die Schaltungen liegen alle auf github.

Beispielsweise der Detektor im Booster auf Seite 4,

https://github.com/git4dcc/RTB_C12/tree/main/doc/C12_schematic.pdf

———-

PS: kurz zum Funktionsprinzip

- „RCM.rx“ geht auf einem USART Eingang
- „RCM.pol“ geht auf einen Pin der auf fallende Flanke triggert

Ist ein RCM Byte vom USART empfangen worden, schaut der Code ob es einen Flanker Trigger gab. Wenn Ja (+), wenn Nein (-) Polarität. Das ganze getrennt für Kanal-1 und 2.

Das ist alles.

Hallo Harald,

in "Kennt ihr schon DCC++ / DCC-EX" 10 Beitrag #71
hatte ich vermutet

Das hatte sich bestätigt und konnte von Euch mit Version 5.6.5 erfolgreich gefixed werden! Vielen Dank!
Im Kontext der Nutzung der DCC-EX-Zentrale (MEGA 2650 und DCC-EX-Motorshield) mit anderen Programmen und meinem Testaufbau ist mir aufgefallen, dass der Railcom-Cut manchmal plötzlich weg ist, z.B. nach einem kurzen Kurzschluss, wie beim Umschalten der Polarität durch ein Kehrschleifenmodul aber auch bei einer Entgleisung. Es scheinen dann wieder durchgehend Präambeln generiert zu werden.
Es gelingt mir dann auch leider nicht den Railcom-Cut mit dem Kommando "<C RAILCOM ON>" im laufenden Betrieb wieder erfolgreich einzuschalten.
Nach einem kompletten Neustart von DCC-EX-5.6.5 und Einschalten des RailCom-Cuts per "<C RAILCOM ON>" klappt dann wieder alles bestens.

Kannst Du das nachvollziehen? Gibt es eine plausible Erklärung für dieses Verhalten? Wie bekommt man die Lücke "kurzschlussfest" eingeschaltet.

MfG

vik

Bis jetzt noch nicht. Ich könnte mir aber vorstellen dass der Timer der für den cutout verantwortlich ist umgestellt wurde, also eines der Register überschrieben wurde. Das bekommen wir auch noch raus.

Bei jedem Kurzschluß oder nur manchmal?

Grüße,
Harald

Hallo Harald, ich glaube schon ziemlich regelmäßig., aber ob wirklich jedesmal, kann ich nicht mit Sicherheit sagen. Woran genau könnte man einfach feststellen, dass ein Kurzschluss aufgetreten ist, aber keinerlei sichtliche Auswirkungen gehabt hat?

Gibt es eine Möglichkeit das regelmäßige Generieren der Lücke schon beim Compilieren fest zu legen, anstatt erst beim Start in einer mySetup-Datei oder erst nach Initialisierung zur Laufzeit?

MfG

vik

Nabend.
Schließe mich vik in Beitrag #69 an. Eine feste Aktivieurng durch Löschen der "//" Zeichen in der passenden Datei davor einer Befehlszeile im Sketch wäre schön. Dann hat man bereits beim booten den cutout. Vielleicht zentral in "config.h" machbar? In "config.h" kann man ja praktischerweise z. B. schon wifi handling, kurze Adresse 99 statt 128, Weichenbefehle umkehren, Motorshieldauswahl, etc. einstellen. Oder hab ich es übersehen und es ist schon dort angelegt?
Ansonsten, falls nicht machbar, bleibt ja die Befehlszeile <C RAILCOM ON> im JMRI Dialog nach dem Booten problemlos übrig. Darüber schalte ich auch meine 2 Ausgänge vom Motorshield bei Bedarf auf DC statt DCC hin und her.
Alternative wäre die Datei "my Automation" zu nutzen. Kann ich das RC cutout damit statt config.h auch einschalten?
Ich robbe mich an das Thema by "learning by doing, try and error" heran.
Danke schön.
Gruß.
Frank

Ich hab den Fehler gefunden, muss aber über die Lösung noch etwas nachdenken. Das Grundproblem ist dass analogWrite(9,207) OCR2B=207 setzt aber analogWrite(9,0)  - Spezialfall 0 - nicht OCR2B=0 setzt. Für Details siehe .arduino15/packages/arduino/hardware/avr/1.8.6/cores/arduino/wiring_analog.c Da wünscht man sich man wäre nicht auf sowas angewiesen, wenn man alles wie Frank in ASM schreibt hat man solche Pronbleme nicht - lol.



Wer irgendwelche Kommandos automatisch ausführen will kann es so machen wie in der Doku beschrieben:



Grüße,
Harald.

o.k. die Lösung myAutomation.h reicht schon. Ich hab nur für einen Freund gefragt.

Hallo Harald, hört sich sehr überzeugend an, Ich warte aber sehr gern bis Du ein gefixtes Release frei gibst

MfG

vik

Hallo,

Was hat AnalogWrite hier für eine Funktion? Das ist doch komplett Plattform spezfisch was das genau tut

Grüße,  Peter W

Hallo Roland, das hört sich für mich - als vorwiegend manueller Rangierer - mit dem Ziel  eines Gleisbildstellwerkes (mit jederzeit aktueller Belegtmeldung einschließlich DCC-Adressen - sehr attraktiv an!  
stelle mich schon mal gern als Beta-Tester hinter DCC-EX 5.6.5 - auf Basis des Arduino Mega 2560 (und ggf. auch anderen Zentralen mit Railcom-Cut) zur Verfügung...

MfG

vik

Hallo Harald,

brakePin ist doch im AVR Kontext immer 9. Also ist der Vergleich doch überflüssig, da bereits eine äußere AVR Klammerung existiert.

Dann könnte der Code doch so aussehen:



LG
threedots

Natürlich nicht. Wir supporten noch andere Motorshields und Uno nicht gleich Mega


Drosselt in dem Fall mit HF PWM den inrush current (da es genug Mobas gibt, die beim Einschalten erstmal kräftig alle Kondensatoren füllen und wenn man da abschaltet dann bekommt man die nie "ans Netz"). Alternativ kann man eine dicke Drossel in die Zuleitung vom Powersupply legen.

An anderen Stellen wird es mit niedriger Frequenz für PWM DC verwendet.

Grüße,
Harald.

Ah ok, den UNO hatte ich nicht auf dem Schirm!

LG
threedots

Da hab ich das jetzt anders gelöst, indem ich während "inrush control" den Cutout abstelle (ist ja sowieso Kurzschluss, während der Zeit braucht man keinen Cutout).

Für den ESP32 wird sowieso dann alles anders ganz anders wenn ich mit "cutout auf ESP32" fertig werde.

Grüße,
Harald.

Hallo Harald,Hhm, heißt das weiter mit der 5.6.5 aber einer mysSetup.h oder myAutmation.h mit speziellen Einstellungen?

MfG

vik

Version 5.6.6 ist zum Download freigeschaltet. Bugfix RailCom behoben von haba, Beitrag #79

Hallo Frank,Oh Danke, doch eine neues Release, das hatte ich (Beitrag #79) gerade nicht so verstanden.

Wenn ich jetzt den cutout auf ESP32 hinbekomme, testet mir das jemand mit allen möglichen und unmöglichen Detektoren die schon in der Schublade rumliegen?

Grüße,
Harald

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

Ich könnte testen. mein Equipment:  
- WeMos D1 R32/ESPDUINO-32 board
- EX‑MotorShield8874
- TAMS RCD-2

Ich habe jetzt auch eine Z21WLANMaus. Wo finde ich einen aktuellen Sketch mit z21 Unterstützung?

Gruß Uli

Immo gibts noch keinen Support fürs Z21 Protokoll. Somit auch kein Support für eine W-LAN Maus oder eine smarte Z21 App an der DCC-EX CS. Das WiFi Modul unterstützt im Moment WiThrottle und die Engine Driver App.

Heute morgen habe ich gesehen, dass Haba nochmals nach Erscheinen der Vers. 5.6.6 an der Software gefeilt hat.

Hallo Harald, na klar, sobald als möglich.
Gibt es auch für diese Brücke
https://www.ebay.de/itm/116719458169?itmmeta=01...9:g:cLcAAeSw2YBquV6I
Aussicht auf eine, Lücke oder kann das nicht funktionieren?

MfG

vik

Warum der TB6612FNG ungeeignet sein wird:

liefert nur ca. 1 A → viel zu wenig für Lok + Booster
ausgelegt für 3–13 V, aber nicht für Gleisspannung unter Last
keine Kurzschluss‑Erkennung
keine galvanische Trennung
nicht für DCC‑Signale spezifiziert
Shield‑Layout für D1 Mini, nicht für Arduino‑basierte DCC‑EX‑Zentrale
Damit würde er sofort überlastet, heiß werden oder abschalten, sobald eine Lok fährt oder ein Kurzschluss entsteht.

Die Mutigen die einen Cutout auf ESP32 haben wollen können sich an v5.9.8-Devel wagen (github oder ex-installer). Das ist aber noch im Beta. Trotzdem glaube ich nicht dass irgendwas explodiert. Ab 5.7 (also auch bei 5.9) ist auch nix mehr mit Mega oder Uno (wie schon früher besprochen).

RailCom Cutout für Gleis X (A bis D) wird mit <= X MAIN><= X RAILCOM> angeschaltet (am besten mit AUTOSTART und PARSE in myAutomation.h, geht aber auch zum Testen via USB Serial). So man kann ein Gleis mit und eins ohne haben wenn man will.

Also z.B. für Gleis A:

AUTOSTART
PARSE("<= A MAIN>")
PARSE("<= A RAILCOM>")
// wenn gewünscht auch noch PARSE("<1 A>")
DONE

Wir werden irgendwann auch noch ein EXRAIL-Kommando dafür nachschieben oder so.

Außer RailCom ist ab 5.9 auch der WIFI-Setup jetzt anders:

<C WIFI ssid password>                       // Set WiFi STA ssid and password (in quotes, like "mySSID" and "myPassword")
<C WIFI TEMP ssid password>           // Set WiFi STA ssid and password temporarily (in quotes)
<C WIFI AP ssid password>                // Set WiFi to AP mode with given ssid and password (in quotes)
<C WIFI AP ssid password channel> // Set WiFi to AP mode with given ssid and password and channel (in quotes)

Auserdem merkt sich ESP32 die Einstellungen auch über Powerdown (außer TEMP, klaro).

Auch enthällt 5.9 noch viele andere Neuerungen die wir dann mit 6.0 hoffentlich auch dokumentiert veröffentlichen werden.

Wenn es nicht passt kann man ja einfach auf 5.6.6 zurück, dann ist wieder alles beim Alten.

Grüße,
Harald.

Der TB9051FTG fuktioniert nicht, er ist zu langsam bei der Schubumkehr. Also mach ich mir auch bei TB6612FNG keine Hoffnungen und da extra einen kaufen bei nur 1A Kapazität um es auszuprobieren hab ich keine Zeit. Aber es hält dich niemand auf es zu probieren.

Grüße,
Harald.

@Harald

1. Ich geh ja mal davon aus, dass das neue Abenteuer ESP32 dann auch sauber bzgl. hardware assambly in Text und Bild kommuniziert werden wird.

2. Wat is denn nu mit deiner Nacharbeit nach erscheinen der 5.6.6 lieber Harald? Ist das nur ausprobieren oder soll das eine 5.6.7 nun werden?

Gruß.

Wem unsere Anleitungen nicht gut genug / allumfasend genug sind kauft sich eine CSB1 von einem unserer Händler.

Wer beitragen will darf gerne was fotografieren und schreiben (als Markdown).


Kannst du im git log nachlesen und dann selber beurteilen ob es so wichtig ist dass man deswegen eine neue Version macht.
https://github.com/DCC-EX/CommandStation-EX/com...b7e02fdc6496c5189073

Grüße,
Harald.

Jo die wird mit ESP32 Technologie angeboten. Also die Party geht für Interessierte dann definitiv weiter.

Dokumentiert ist die DCC-EX-CS1 schon. Alles grün soweit.

Viel Spaß weiterhin am Tüfteln allesamt.

LG Frank

Hallo Harald,
Danke für den Hinweis. Leider funktioniert der Link bei mir irgendwie nicht richtig.

MfG

vik
----
ADMIN: Link repariert

Hi,

ich bin dann mal dabei beim Testen. Wenn mein Sniffer mitspielt!
LG
threedots

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

Hallo Roland, sollte man auf dem Bild/Display schon einen Hinweis auf den Cut erkennen können (außer der hohen Versionsnummer) ?

MfG

vik

Nöö

Da wir in v5.9.8-Devel kleinen Bug gefunden haben gibts jetzt v5.9.9-Devel (Hatte mit Empfang von UDP zu tun, also nicht RailCom).

Grüße,
Harald.

Hallo Uli,könntest Du schon Decoder empfehlen, mit dem Du mit dem genannten Equipment keinerlei Probleme hattest, Dir die aktuell eingestellten DCC-Adressen - einschließlich Aufgleisrichtung - anzeigen zu lassen?

MfG

vik

Mit Zimo Decodern konnte ich teilweise Erfolge erzielen, aber nicht immer und auch nicht immer reproduzierbar. Mit ESU Decodern hatte ich noch kein Glück.

Ich musste aber erst mal mir der WIFI Konfiguration klarkommen. Bisher hatte ich diese in der config.h definiert. So wie ich Harald`s Post #88 verstanden habe muss das jetzt in der AUTOSTART Routine in der myAutomation.h erfolgen.


bei mir funktioniert jedoch nur diese Schreibweise:

PARSE("<C WIFI \"mySSID\" \"mySSID\">")

Wo und wie definiere ich jetzt aber den Hostnamen ??

Gruß Uli

Brauchst das nur einmal eingeben im Terminal/Serial. Der ESP32 merkt es sich dann.

<C HOSTNAME "ULIBAHN" >

geht auch.
Grüße,
Harald