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