Anzeige:
THEMA: Kennt Ihr schon DCC++?
THEMA: Kennt Ihr schon DCC++?
Lokschrauber - 25.06.17 13:57
Hallo liebe Forumsmitglieder,
seit knapp einem Jahr bin ich Digitalkonvertit, was durch die Überlassung einer digitalen Lok durch einen Forumskollegen hier begann (Danke, Werner🙂). Irgendwie wollte ich digital nur mal ausprobieren, und wollte aber verstehen, wie das alles funktioniert. Deswegen wollte ich keine fertige Zentrale, sondern Selbstbau, und bin bei Recherchen auf DCC++ gestossen. Als Zentrale wird ein Arduino mit Motorshield verwendet, der z.B. über USB aus einer java-basierten GUI angesprochen wird.
https://sites.google.com/site/dccppsite/home
Seitdem habe ich alles darauf aufgebaut, und bin hochzufrieden. Ich kann die Benutzeroberfläche und -funktionalität genau an meine Wünsche anpassen, und wenn mal die Kommunikation mit einem Decoder doch nicht so tut, sind es höchstens ein paar Zeilen C++ oder Java-Code, um dem Beine zu machen. Und man versteht mit der Zeit sehr gut, wie Zentrale, Decoder und Programmierung zusammenspielen - das ist richtig kurzweilig. Wenn also jemand als Modellbahner Interesse an hardwarenaher Programmierung hat, ist er damit genau richtig.
Da der ganze Ansatz Open-Source ist, gibt es auch viele Online Ressourcen, die einen unterstützen.
Z.B. http://www.trainboard.com/highball/index.php?forums/dcc.177/
Da ich hier im Forum aber nichts darüber gefunden habe, wollte ich hier mal diese kleine Bekanntgabe machen, und hoffe, das es Euch gut interessiert!
Liebe Grüße
Euer Lokschrauber
seit knapp einem Jahr bin ich Digitalkonvertit, was durch die Überlassung einer digitalen Lok durch einen Forumskollegen hier begann (Danke, Werner🙂). Irgendwie wollte ich digital nur mal ausprobieren, und wollte aber verstehen, wie das alles funktioniert. Deswegen wollte ich keine fertige Zentrale, sondern Selbstbau, und bin bei Recherchen auf DCC++ gestossen. Als Zentrale wird ein Arduino mit Motorshield verwendet, der z.B. über USB aus einer java-basierten GUI angesprochen wird.
https://sites.google.com/site/dccppsite/home
Seitdem habe ich alles darauf aufgebaut, und bin hochzufrieden. Ich kann die Benutzeroberfläche und -funktionalität genau an meine Wünsche anpassen, und wenn mal die Kommunikation mit einem Decoder doch nicht so tut, sind es höchstens ein paar Zeilen C++ oder Java-Code, um dem Beine zu machen. Und man versteht mit der Zeit sehr gut, wie Zentrale, Decoder und Programmierung zusammenspielen - das ist richtig kurzweilig. Wenn also jemand als Modellbahner Interesse an hardwarenaher Programmierung hat, ist er damit genau richtig.
Da der ganze Ansatz Open-Source ist, gibt es auch viele Online Ressourcen, die einen unterstützen.
Z.B. http://www.trainboard.com/highball/index.php?forums/dcc.177/
Da ich hier im Forum aber nichts darüber gefunden habe, wollte ich hier mal diese kleine Bekanntgabe machen, und hoffe, das es Euch gut interessiert!
Liebe Grüße
Euer Lokschrauber
Arnold_Huebsch - 25.06.17 14:14
Hello!
Es gibt mehrere DCC Zentralen am Arduino, Leistungsseite wird gerne mit Motor Shields gemacht. Wer das tut sollte aber bedenken, daß das Signal am Gleis potentiell HF stört und zusätzlich unter Umständen Spannungsspitzen am Gleis auftauchen. Die sind oft 3-5fach höher als die Speisespannung. Die Folgen kann wohl jeder erahnen.
Habe selbst mehrere dieser Bibliotheken ausprobiert und suche derzeit nach einer sinnvollen Endstufe die die Flanken beschränkt. Ziel weniger HF Störungen und vor allem keine Überschwinger. Meine derzeitige Schutzmaßnahme ist ein DSR. Der beschnibbelt zwar die Spannungsspitzen behebt aber nicht das Flankenproblem.
Wenn sich jemand mit der Technik auseinandersetzen will ist das auf jeden Fall eine gute Ausgangsplattform. Die HF Störungen sind bei moderaten Strömen auch nicht sooo tragisch, Man wird vermutlich nur seine nähere Geographie damit belästigen. Außerdem gibt's genug kommerzielle Produkte die um keinen Deut besser sind.
-AH-
Es gibt mehrere DCC Zentralen am Arduino, Leistungsseite wird gerne mit Motor Shields gemacht. Wer das tut sollte aber bedenken, daß das Signal am Gleis potentiell HF stört und zusätzlich unter Umständen Spannungsspitzen am Gleis auftauchen. Die sind oft 3-5fach höher als die Speisespannung. Die Folgen kann wohl jeder erahnen.
Habe selbst mehrere dieser Bibliotheken ausprobiert und suche derzeit nach einer sinnvollen Endstufe die die Flanken beschränkt. Ziel weniger HF Störungen und vor allem keine Überschwinger. Meine derzeitige Schutzmaßnahme ist ein DSR. Der beschnibbelt zwar die Spannungsspitzen behebt aber nicht das Flankenproblem.
Wenn sich jemand mit der Technik auseinandersetzen will ist das auf jeden Fall eine gute Ausgangsplattform. Die HF Störungen sind bei moderaten Strömen auch nicht sooo tragisch, Man wird vermutlich nur seine nähere Geographie damit belästigen. Außerdem gibt's genug kommerzielle Produkte die um keinen Deut besser sind.
-AH-
Lokschrauber - 25.06.17 14:42
Danke für diese Ergänzung, Arnold - du hast vollkommen recht; da die Endstufe einfach hart durchschaltet, kann da einiges an HF Inhalt drin sein. Wegen Überschwingern hatte ich vor ca. vier Wochen mal das Oszilloskop am Gleis, und zumindest bei meinem Aufbau waren es nur vernachlässigbare Überschwinger. Die Gleisinduktivität wird das ja auch beeinflussen, daher kann das aber von Aufbau zu Aufbau verschieden sein. --> Der Besitz eines Oszilloskops ist bei dieser Art von Zentrale ebenfalls hilfreich.
Gruss, Thomas
Gruss, Thomas
Hallo Arnold,
wenn man einen integrierten Motortreiber als Endstufe nimmt, kann man die Steilheit der Flanken nicht beeinflussen. Ein Beispiel sind die auf dem L298 oder MC33932 basierenden Shields. Eine diskrete Lösung (Gatetreiber plus MOSFETs) wäre hier geschickter, da man in die Gateleitung Widerstände einfügen kann, die dann zusammen mit der Gatekapazität für ein langsameres Schalten und somit nicht so steile Flanken sorgen. Übertreiben sollte man es allerdings nicht, da dann die MOSFETs zu warm werden.
Wenn das Motor Shield also diskret aufgebaut wäre, könnte man die Flanken beeinflussen. Leider habe ich auf die Schnelle so kein Shield gefunden.
Grüße,
Dietmar
wenn man einen integrierten Motortreiber als Endstufe nimmt, kann man die Steilheit der Flanken nicht beeinflussen. Ein Beispiel sind die auf dem L298 oder MC33932 basierenden Shields. Eine diskrete Lösung (Gatetreiber plus MOSFETs) wäre hier geschickter, da man in die Gateleitung Widerstände einfügen kann, die dann zusammen mit der Gatekapazität für ein langsameres Schalten und somit nicht so steile Flanken sorgen. Übertreiben sollte man es allerdings nicht, da dann die MOSFETs zu warm werden.
Wenn das Motor Shield also diskret aufgebaut wäre, könnte man die Flanken beeinflussen. Leider habe ich auf die Schnelle so kein Shield gefunden.
Grüße,
Dietmar
Erstmal zu DCC++:
Ja, ich hab einen Versuchsaufbau gemacht und es funktioniert. Allerdings hat das Program ein paar Schwächen, z.B. werden Funktionsbefehle nie refreshed. Auch muss das Program noch etwas abgespeckt werden wenn man die RAM für mehr Refreshslots im Uno unterbringen will. So in der Größenordnung 25-30 gleichzeitige Loks mit Funktionen wär schon fein. Ich hab angefangen alles was ich nicht brauche rauszuschmeißen (z.B. Lesen von Inputs) und das Program auf einfacher, kleiner zu reduzieren. "Intrelligenz" kann man ja in einem Computer daneben (mit richtigem OS) reinstecken, dafür gibts ja JMRI oder RocRail. Ich hätte das gerne mit dem Orginalauthor koordiniert. Aber leider ist vom Orginalauthor totale Stille, weder in dem USA Forum noch auf Email Reaktion. Dann hat bei mit das "hoppla, wenig Zeit" zugeschlagen. Ich hoffe das bessert sich während der Sommerferien etwas.
Zu den Flanken:
Ich seh da keinen großen Unterschied zu den wenigen kommerziellen Produkten die ich schon unter dem Oszi angeguckt habe. Arnold, du hast da vielleicht einen besseren Überblick. Große Überschwinger hab ich eigentlich nur bei Aufbauten gesehen wo der Booster mit so 10m Kabel zum Anlagenteil angeschlossen war.
Hat jemand Erfahrung mit "China-Motorendstufen" aus diskreten MosFETs die man vielleicht so verändern könnte dass es passt?
Der Besitz eines Oszi ist oft hilfreich, wenn man es allerdings wie ich nur so alle 1/2 Jahr mal auspackt dann ist man immer etwas "rostig" bei der Bedienung.
Grüße,
Harald.
Ja, ich hab einen Versuchsaufbau gemacht und es funktioniert. Allerdings hat das Program ein paar Schwächen, z.B. werden Funktionsbefehle nie refreshed. Auch muss das Program noch etwas abgespeckt werden wenn man die RAM für mehr Refreshslots im Uno unterbringen will. So in der Größenordnung 25-30 gleichzeitige Loks mit Funktionen wär schon fein. Ich hab angefangen alles was ich nicht brauche rauszuschmeißen (z.B. Lesen von Inputs) und das Program auf einfacher, kleiner zu reduzieren. "Intrelligenz" kann man ja in einem Computer daneben (mit richtigem OS) reinstecken, dafür gibts ja JMRI oder RocRail. Ich hätte das gerne mit dem Orginalauthor koordiniert. Aber leider ist vom Orginalauthor totale Stille, weder in dem USA Forum noch auf Email Reaktion. Dann hat bei mit das "hoppla, wenig Zeit" zugeschlagen. Ich hoffe das bessert sich während der Sommerferien etwas.
Zu den Flanken:
Ich seh da keinen großen Unterschied zu den wenigen kommerziellen Produkten die ich schon unter dem Oszi angeguckt habe. Arnold, du hast da vielleicht einen besseren Überblick. Große Überschwinger hab ich eigentlich nur bei Aufbauten gesehen wo der Booster mit so 10m Kabel zum Anlagenteil angeschlossen war.
Hat jemand Erfahrung mit "China-Motorendstufen" aus diskreten MosFETs die man vielleicht so verändern könnte dass es passt?
Der Besitz eines Oszi ist oft hilfreich, wenn man es allerdings wie ich nur so alle 1/2 Jahr mal auspackt dann ist man immer etwas "rostig" bei der Bedienung.
Grüße,
Harald.
Arnold_Huebsch - 26.06.17 11:10
Hello!
Ja das soll ja auch nicht sein, es gibt Decoder die sich da zerwürfeln wenn man mehrfach aussendet.
Wobei's daduch natürlich offene Punkte zB bei RailCom gibt. Wird der Weichendecoder nicht refreshed dann hat der auch keine Chance in Kanal2 was zu antworten. Aber das sprengt ohnehin die Ziele der Arduinozentrale.
-AH-
Zitat - Antwort-Nr.: 4 | Name: haba
[...] z.B. werden Funktionsbefehle nie refreshed [...]
Ja das soll ja auch nicht sein, es gibt Decoder die sich da zerwürfeln wenn man mehrfach aussendet.
Wobei's daduch natürlich offene Punkte zB bei RailCom gibt. Wird der Weichendecoder nicht refreshed dann hat der auch keine Chance in Kanal2 was zu antworten. Aber das sprengt ohnehin die Ziele der Arduinozentrale.
-AH-
Zitat - Antwort-Nr.: | Name:
Ja das soll ja auch nicht sein, es gibt Decoder die sich da zerwürfeln wenn man mehrfach aussendet.
Wie meinst du das? Nach NMRA müssen alle Befehle an mobile Decoder zyklisch wiederholt werden. Soll ich die Stelle im Standard raussuchen? Wenn nicht, dann bleibt z.B. das Licht oder der Sound aus wenn gerade in dem Augenblick Dreck auf den Schienen ist.
Grüße,
Harald.
Hallo Harald,
ich glaube, Arnold dachte da an stationäre Funktionsdecoder.
Viele Grüße
Carsten
ich glaube, Arnold dachte da an stationäre Funktionsdecoder.
Viele Grüße
Carsten
Lokschrauber - 26.06.17 17:36
Hallo,
@Harald: ich habe eine Java-Routine in den DCC++ Controller dazuprogrammiert, die den zyklischen Refresh der Funktionsbefehle macht, weil mich das genervt hat, dass plötzlich bei einer Lok unter der Fahrt das Licht ausgeht. Das ist halt das Schöne - was nicht passt, wird passend gemacht. Standardmässig werden nur Fahrbefehle im Kommandoregister der BaseStation eingetragen und zyklisch gesendet. Du hast wahrscheinlich meinen Post im Trainboard gesehen, oder?
@Arnold: Mein Refresh ist nur "niederfrequent", um genau diesen Effekt des Aufhängens zu vermeiden. Also fährt die Lok im Schlimmsten Fall mal 5Sek. ohne Licht, bis das jeweilige Kommando wieder einmal gesendet wird. Aber ich muss nicht händisch eingreifen.
Sonnige Grüsse
Thomas
@Harald: ich habe eine Java-Routine in den DCC++ Controller dazuprogrammiert, die den zyklischen Refresh der Funktionsbefehle macht, weil mich das genervt hat, dass plötzlich bei einer Lok unter der Fahrt das Licht ausgeht. Das ist halt das Schöne - was nicht passt, wird passend gemacht. Standardmässig werden nur Fahrbefehle im Kommandoregister der BaseStation eingetragen und zyklisch gesendet. Du hast wahrscheinlich meinen Post im Trainboard gesehen, oder?
@Arnold: Mein Refresh ist nur "niederfrequent", um genau diesen Effekt des Aufhängens zu vermeiden. Also fährt die Lok im Schlimmsten Fall mal 5Sek. ohne Licht, bis das jeweilige Kommando wieder einmal gesendet wird. Aber ich muss nicht händisch eingreifen.
Sonnige Grüsse
Thomas
Arnold_Huebsch - 26.06.17 20:35
Folks!
Mein Kommentar bezog sich auf die Magnetartikel Decoder, das habe ich offensichtlich Überinterpretiert weil da stand "Funktionsbefehle", das hat mich zu Magnetartikeldecoder geleitet.
Bei Fahrzeugdecoder gehört natürlich laufend ein Refresh. Das ist ja die Funktionssicherung im DCC System.
-AH-
Mein Kommentar bezog sich auf die Magnetartikel Decoder, das habe ich offensichtlich Überinterpretiert weil da stand "Funktionsbefehle", das hat mich zu Magnetartikeldecoder geleitet.
Bei Fahrzeugdecoder gehört natürlich laufend ein Refresh. Das ist ja die Funktionssicherung im DCC System.
-AH-
Zitat - Antwort-Nr.: | Name:
@Harald: ich habe eine Java-Routine in den DCC++ Controller dazuprogrammiert, die den zyklischen Refresh der Funktionsbefehle macht, weil mich das genervt hat, dass plötzlich bei einer Lok unter der Fahrt das Licht ausgeht.
Ah, ich versuch es in den Arduino zu bekomen, weil da gehörts meiner Meinung nach logisch rein.
Seh ich auch so, braucht halt Zeit. Ich programmier recht langsam, dafür nicht so buggy (hoffe ich).
Nö, da war in letzter Zeit viel gekloppe. Hattu direkt URL?
Gruß,
Harald.
PS:
@Arnold: Achso, dann sind wir ja einer Meinung.
Gehört ja eigentlich in den Arduino und das ist auch mein Plan im SRAM soviel Platz zu schaffen dass der Arduino das auch macht.
Ich habe jetzt zumindest mal das eingeschlafene Repo geforkt und meine Änderungen in ein eigenes Repo bei Github hochgeladen.
https://github.com/habazut/dcc-ardu
Mein Plan ist das weiter in Richtung "slim", weiterzuentwickeln. Damit meine ich dass der Arduino das machen soll was der Arduino gut kann, also z.B. Refresh aber z.B nicht Weichenlagen im EEPROM lagern. Das kann ein Computer mit OS an dem der Arduino hängt bedeutend besser. Ob der "richtige" Computer dann DCC++Controller, JMRI oder RocRail dazu anwendet spielt keine Rolle.
Durch reines Aufräumen im Quellcode und Verschieben der Strings ins FLASH-Memory bin ich jetzt soweit gekommen dass ich im SRAM Platz für 50 Slots habe.
Grüße,
Harald.
Hallo,
sowas in der Art habe ich auch mal zusammen gesteckt mit einem Arduino, Motorshield, Schieberegler, On-Off-On Switch. Da habe ich einfach 4 "Slots" in einem Array of Byte Array implementiert wo Fahrbefehle, Funktionen und Schaltbefehle rein abgelegt werden können. Wenn das erste Byte nicht Null ist, wird das jeweilige der 4 möglichen Telegramme aufs Gleis ausgegeben, klassisch im Kreis ringelreih mit DCC Timing per Interrupt.
Das hat mit verschiedenen kommerziellen und nicht kommerziellen Decodern sauber funktioniert.
Grüße, Peter W
sowas in der Art habe ich auch mal zusammen gesteckt mit einem Arduino, Motorshield, Schieberegler, On-Off-On Switch. Da habe ich einfach 4 "Slots" in einem Array of Byte Array implementiert wo Fahrbefehle, Funktionen und Schaltbefehle rein abgelegt werden können. Wenn das erste Byte nicht Null ist, wird das jeweilige der 4 möglichen Telegramme aufs Gleis ausgegeben, klassisch im Kreis ringelreih mit DCC Timing per Interrupt.
Das hat mit verschiedenen kommerziellen und nicht kommerziellen Decodern sauber funktioniert.
Grüße, Peter W
😲😲😲😏🤔🤔🤔
Wie geil..!!
Ich verstehe nur Bahnhof.. 😁 Was für ein Moba Forum ja scho viel ist..😂
Sorry.. Echt suuper.. Hab das grad nem ahnungslosen Kollegen vorgelesen.. Super..👍
Will niemand blöd kommen..
Aber DAS ist echt Hardcore Moba at its best..
Mal sehen wann ich dafür reif bin..
Grüße Pijon...
Wie geil..!!
Ich verstehe nur Bahnhof.. 😁 Was für ein Moba Forum ja scho viel ist..😂
Sorry.. Echt suuper.. Hab das grad nem ahnungslosen Kollegen vorgelesen.. Super..👍
Will niemand blöd kommen..
Aber DAS ist echt Hardcore Moba at its best..
Mal sehen wann ich dafür reif bin..
Grüße Pijon...
Zitat - Antwort-Nr.: | Name:
Da habe ich einfach 4 "Slots" in einem Array of Byte Array implementiert wo Fahrbefehle, Funktionen und Schaltbefehle rein abgelegt werden können.
Der Sport ist hier dass die Interruptroutine die Bits kontinuoerlich rausschiebt aber das Program natürlich genau da im RAM wo die Interruotroutine werkelt die DCC-Befehle nicht ändern darf, sonst gibts Bitsalat. Z.Z. ist das sehr RAM intensiv mit doppelten Slots gelöst currentReg->ap (ap steht für active packet) aber das braucht ja doppelt so viel RAM per slot. Da sollte sich noch was machen lassen.
Auch braucht es noch einen Interfacebefehl um die Anzahl der zur Verfügung gestellten Slots abzufragen.
Zitat - Antwort-Nr.: | Name:
... habe ich auch mal zusammen gesteckt mit einem Arduino, Motorshield ...
Wer die Hardware hat darf gern testen, auch wenn ich noch kein regelrechtes "Release" gemacht habe. Alles was auf Github landet habe ich zumindest in meinem Uno gefahren. Mega hab ich keinen, die Änderungen sind aber minimal und beschrieben.
Grüße,
Harald.
Zweisystemlok - 17.10.19 10:29
@13
Da ist überhaupt nichts Hardcore, Porno oder sonstwas - das ist gang und gebe und gängiger Standard im Modellbahnbereich.
Ob man einen Schieberegler (wie der alte längliche grüne FMZ Handregler von Fleischmann) oder einen normales Potentiometer (der bekannte Drehregler) nimmt, ist ein optischer Unterschied. Auf Elektronikebene werden beide mit 3 Anschlüssen geliefert, verlötet und an die restliche Elektronik angeschlossen.
Der Arduino, Mega oder Uno ist die Prozessorplatine und das Motorschield ist der Ausgang der zwischen dem Prozessor und dem Gleisanschluß sitzt (ob auf einer getrennten und geteckten Platine oder auf einer gemeinsamen ist wurscht) - die Funktionsweise ist gleich und den Rest was die Software angeht hat Harald schon erklärt.
Ps: Alle diese Komponenten - egal ob Topaktuell oder zwei Jahre alt, oder noch älter - werden bspw. im Heißwolf Regler, Piko Handregler, Fleischmann Profiboss, Roco Lokmaus, etc. verwendet - nur da ist halt ein Gehäuse drum und der Benutzer sieht vom Innenleben nichts.
Gruß, Michael
Ps: Vor 25 Jahren sah der/ein Prototyp noch so aus, Lochrasterplatine und Handgefädelt - siehe Bilder :)
Die von Zweisystemlok zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login
Da ist überhaupt nichts Hardcore, Porno oder sonstwas - das ist gang und gebe und gängiger Standard im Modellbahnbereich.
Ob man einen Schieberegler (wie der alte längliche grüne FMZ Handregler von Fleischmann) oder einen normales Potentiometer (der bekannte Drehregler) nimmt, ist ein optischer Unterschied. Auf Elektronikebene werden beide mit 3 Anschlüssen geliefert, verlötet und an die restliche Elektronik angeschlossen.
Der Arduino, Mega oder Uno ist die Prozessorplatine und das Motorschield ist der Ausgang der zwischen dem Prozessor und dem Gleisanschluß sitzt (ob auf einer getrennten und geteckten Platine oder auf einer gemeinsamen ist wurscht) - die Funktionsweise ist gleich und den Rest was die Software angeht hat Harald schon erklärt.
Ps: Alle diese Komponenten - egal ob Topaktuell oder zwei Jahre alt, oder noch älter - werden bspw. im Heißwolf Regler, Piko Handregler, Fleischmann Profiboss, Roco Lokmaus, etc. verwendet - nur da ist halt ein Gehäuse drum und der Benutzer sieht vom Innenleben nichts.
Gruß, Michael
Ps: Vor 25 Jahren sah der/ein Prototyp noch so aus, Lochrasterplatine und Handgefädelt - siehe Bilder :)
Die von Zweisystemlok zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login
Hallo,
ähm naja der Lolboss ist nicht mal annähernd auf dem Niveau des Arduino, und der ist schon primitiv. Die Lokmaus ist auch primitiv aber hat relativ viel Speicherplatz im Controller da hier eine komplexere Zentralenlogik drin ist und alle Lok- und Weichenzustände vorgehalten werden (keine Ahnung wie viele gleichzeitig).
Leider ist die H-Brücke auf dem Motorshield in bipolarer Technik gefertigt, also antik. Aber es gibt auch bessere Motor Controller break-out Boards. Die kommerziellen Kompaktgeräte haben zumeist diskrete, nicht eigensichere Endstufen mit billigen MOSFETs - die fetzt es gerne mal durch.
Ad Foto: Ist er nicht süß der alte Motorroller?.png)
Grüße, Peter W
ähm naja der Lolboss ist nicht mal annähernd auf dem Niveau des Arduino, und der ist schon primitiv. Die Lokmaus ist auch primitiv aber hat relativ viel Speicherplatz im Controller da hier eine komplexere Zentralenlogik drin ist und alle Lok- und Weichenzustände vorgehalten werden (keine Ahnung wie viele gleichzeitig).
Leider ist die H-Brücke auf dem Motorshield in bipolarer Technik gefertigt, also antik. Aber es gibt auch bessere Motor Controller break-out Boards. Die kommerziellen Kompaktgeräte haben zumeist diskrete, nicht eigensichere Endstufen mit billigen MOSFETs - die fetzt es gerne mal durch.
Ad Foto: Ist er nicht süß der alte Motorroller?
Grüße, Peter W
Beitrag editiert am 17. 10. 2019 22:28.
Zweisystemlok - 17.10.19 21:21
Profiboss hab ich nie gehabt, ist Made by Uhlenbrock - soviel zum Thema Hausverbot im Nachbarthread (man kann sich auch mit Vorsatz Probleme ins Haus holen, ich brauch diesen sch......laden nicht mehr!).
Die 68K in reinkultur wurde noch bis 1996 gefertigt von Motorola.
Gruß, Michael
Die 68K in reinkultur wurde noch bis 1996 gefertigt von Motorola.
Gruß, Michael
Pardon, ich meinte den Lokboss. Habe es oben korrigiert. Der ist auch von U und bei dem benötigt man wenigstens keinen Support.
Den Profiboss hatte ich auch nie, der war eher selten und mir gefiel die Lösung des elektrischen Anschlusses nicht.
Grüße, Peter W.
Den Profiboss hatte ich auch nie, der war eher selten und mir gefiel die Lösung des elektrischen Anschlusses nicht.
Grüße, Peter W.
Hallo,
ähm... also ich möchte meine Profibosse nimmer missen!
Schön handlich und zuverlässig - und auch am Loconet als Handregler verwendbar.
meint
Roger
.png)
ähm... also ich möchte meine Profibosse nimmer missen!
Schön handlich und zuverlässig - und auch am Loconet als Handregler verwendbar.
meint
Roger
Jetzt hab ich mir den Teil von JMRI angesehen der einen Arduino mit DCC++ steuern soll. *Schauder*. Dass das überhaupt funktioniert hat wahr mehr Glück als Talent. Da werde ich wohl auch noch ein paar Zeilen Java schreiben und Pull Requests absetzen. JMRI ist im Gegensatz zu DCC++ ja kein eingeschlafenes Projekt. Wer auch noch intressiert ist kann sich ja melden.
Grüße,
Harald.
PS: Für Lokbosse, Profibosse und Bosse mit Hausverbot gibts andere Threads.
Grüße,
Harald.
PS: Für Lokbosse, Profibosse und Bosse mit Hausverbot gibts andere Threads.
Ist ja wieder einige Zeit vergangen. Seitdem sind meine Änderungen in JMRI eingepflegt (zumindest seit 4.17.5) und da sich der Orginalauthor von DCC++ nicht mehr rührt habe ich jetzt einen eigenen Fork von DCC++ hier, dcc-ardu genannt: https://github.com/habazut/dcc-ardu Mit dem kann man jetzt bis zu 50 gleichzeitige Loks steuern. Auf der Branch updateflags räume ich gerade den Code noch etwas mehr auf und baue die interne Logik um so dass ich dann noch mehr Platz im RAM habe um noch mehr gleichzeitige Adressen in den Update-Loop hineinzubekommen. Auch muss ich mir überlegen ob ich das mit den Funktionen (also Licht etc) dabei lasse dass nur JMRI da zyklisch den Refresh macht oder ob ich das auch noch in DCC++ einbaue. Zur Zeit ist nur die Geschwindigkeit im zyklischen Refresh des Arduinos drin. Bei Fragen einfach Kontakt aufnehmen, ich sehe auch gern mehr Tester
Grüße,
Harald.
Grüße,
Harald.
Ich habe noch einige Fehler gefunden, z.B. war en die Programmiergleisfunktionen total daneben. Da meine ersten Test erfolgreich waren gibts jetzt eine neue Version 1.3.0 auf Github. https://github.com/habazut/dcc-ardu
Gebraucht wird:
* Gleichspannung (so 1.5V höher als gewünschte Gleisspannung)
* 1 Arduino Uno
* 1 Motorshield
* 2 Jumperkabel
* Kabel zum Anschließen der Gleise
* Computer mit USB
Damit kann man grundlegende Funktionen testen (*), für die eigentliche Bedienung empfehle ich aber JMRI. Mehr Tests vor allem in Zusammenspiel mit JMRI werden sicher noch gebraucht.
Grüße,
Harald.
(*) Die Zeichen, z.B. <R 1 1 1> die man in die USB-Serieverbindung reinschreibt werden nicht angezeigt, als kein "Echo", Antwort kommt erst nach ausgeführtem Kommando.u
Gebraucht wird:
* Gleichspannung (so 1.5V höher als gewünschte Gleisspannung)
* 1 Arduino Uno
* 1 Motorshield
* 2 Jumperkabel
* Kabel zum Anschließen der Gleise
* Computer mit USB
Damit kann man grundlegende Funktionen testen (*), für die eigentliche Bedienung empfehle ich aber JMRI. Mehr Tests vor allem in Zusammenspiel mit JMRI werden sicher noch gebraucht.
Grüße,
Harald.
(*) Die Zeichen, z.B. <R 1 1 1> die man in die USB-Serieverbindung reinschreibt werden nicht angezeigt, als kein "Echo", Antwort kommt erst nach ausgeführtem Kommando.u
Hallo,
so jetzt habe ich auch mitgelesen.
Kann mir wer sagen was der Unterschied oder was an dem hier beschriebenen besser ist für die Moba als eine Kaufzentrale, wie z.B. meine DR 5000?
Es erscheint mir doch mit viel Aufwand und tüftelei verbunden, um Loks digital fahren zu lassen.
Viele Wege führen zum Ziel, aber das hier hört sich nach einem zweiten Hobby neben der Moba für mich an.
Viele Grüße
Michael
der das auch nicht versteht.
so jetzt habe ich auch mitgelesen.
Kann mir wer sagen was der Unterschied oder was an dem hier beschriebenen besser ist für die Moba als eine Kaufzentrale, wie z.B. meine DR 5000?
Es erscheint mir doch mit viel Aufwand und tüftelei verbunden, um Loks digital fahren zu lassen.
Viele Wege führen zum Ziel, aber das hier hört sich nach einem zweiten Hobby neben der Moba für mich an.
Viele Grüße
Michael
der das auch nicht versteht.
Hallo Harald,
ich kannte DCC++ tatsächlich nicht, warum auch immer das an mir vorbei gegangen ist. Ich schaue mir die Tage auch mal den Source an. Arduino Mega habe ich noch einen rumliegen, Motorshield ist bestellt.
Ich werde es mal mit Rocrail testen. Auf einem Mega. Mit Ethernet. Kann also nichts schief gehen
Gruß,
Martin
ich kannte DCC++ tatsächlich nicht, warum auch immer das an mir vorbei gegangen ist. Ich schaue mir die Tage auch mal den Source an. Arduino Mega habe ich noch einen rumliegen, Motorshield ist bestellt.
Ich werde es mal mit Rocrail testen. Auf einem Mega. Mit Ethernet. Kann also nichts schief gehen
Gruß,
Martin
Ich weiss nicht ob Rocrail das DCC++ Protokoll unterstützt. Wenn ja, dann kann es wahrscheilich nicht nach der Anzahl der Slots fragen was ich in JMRI ergänzt habe, so das wird dann der Default, das ist max 20 Loks oder so. So zu Rocrail kann ich dir nicht helfen. Man kann ja aber auch so von Hand testen.
Ich habe es nur mit dem Uno getestet da ich keinen Mega habe. USB-Serie und JMRI hier, also auch kein Ethernet. Habe aber nix in der Ecke geändert so sollte immer noch gehen auch mit dem Mega.
Grüße,
Harald.
Zitat - Antwort-Nr.: | Name:
aber das hier hört sich nach einem zweiten Hobby neben der Moba für mich an.
Es gibt auch Mobahner die setzen auf die Zweitspur. Oder bauen soviel Landschaft dass keine Züge mehr Platz haben.
Ich bin eben dabei mir sowas wie einen SPROG (falls der bekannt ist) zu bauen, halt Open Source wo ich selber bestimme was
mein Teil können soll.
Grüße,
Harald.
Hallo Harald,
Es gibt für DCC++ Rocrail Unterstützung:
https://wiki.rocrail.net/doku.php?id=dccpp:dccpp-en
In wie weit das funktioniert finde ich dann noch raus.
Gruß,
Martin
Es gibt für DCC++ Rocrail Unterstützung:
https://wiki.rocrail.net/doku.php?id=dccpp:dccpp-en
In wie weit das funktioniert finde ich dann noch raus.
Gruß,
Martin
Zitat - Antwort-Nr.: 26 | Name: haba schrieb am 10.03.20 23:04
Zitat - Antwort-Nr.: | Name:
aber das hier hört sich nach einem zweiten Hobby neben der Moba für mich an.
Es gibt auch Mobahner die setzen auf die Zweitspur. Oder bauen soviel Landschaft dass keine Züge mehr Platz haben.
Ich bin eben dabei mir sowas wie einen SPROG (falls der bekannt ist) zu bauen, halt Open Source wo ich selber bestimme was
mein Teil können soll.
Grüße,
Harald.
Moin,
Bis jetzt habe ich davon noch nichts gehört, was kann der SPROG denn genau?
Auch Firmware Updates der Decoder und Soundprojekte aufspielen?
-> im Manual habe ich dazu nichts gefunden
Viele Grüße, Franzi
Hallo Franzi,
Interessante Frage - wie soll das Deiner Meinung nach gehen?
Ist das naiv oder provokant gemeint?
Dazu muss man vom jedem Hersteller folgendes kennen:
- Wie identifiziert man den Decoder Typ?
- Wie ist das Ladefile aufgebaut?
- Wie bringt man den Decoder in den Lademodus?
- Wie schiebt man das Ladefile über das Gleis in den Decoder?
- Welches Handshake benutzt der Decoder?
Und wenn Du Glück hast, benutzt ein Hersteller kein Verschlüsselungsverfahren...
Grüße, Peter W
Interessante Frage - wie soll das Deiner Meinung nach gehen?
Ist das naiv oder provokant gemeint?
Dazu muss man vom jedem Hersteller folgendes kennen:
- Wie identifiziert man den Decoder Typ?
- Wie ist das Ladefile aufgebaut?
- Wie bringt man den Decoder in den Lademodus?
- Wie schiebt man das Ladefile über das Gleis in den Decoder?
- Welches Handshake benutzt der Decoder?
Und wenn Du Glück hast, benutzt ein Hersteller kein Verschlüsselungsverfahren...
Grüße, Peter W
Zitat - Antwort-Nr.: 29 | Name: Peter W. schrieb am 11.03.20 15:52
Hallo Franzi,
Interessante Frage - wie soll das Deiner Meinung nach gehen?
Ist das naiv oder provokant gemeint?
Dazu muss man vom jedem Hersteller folgendes kennen:
- Wie identifiziert man den Decoder Typ?
- Wie ist das Ladefile aufgebaut?
- Wie bringt man den Decoder in den Lademodus?
- Wie schiebt man das Ladefile über das Gleis in den Decoder?
- Welches Handshake benutzt der Decoder?
Und wenn Du Glück hast, benutzt ein Hersteller kein Verschlüsselungsverfahren...
Grüße, Peter W
Moin,
Es ist eine Frage ...
Mir stellt sich die Frage, wozu ich so ein Gerät benötige, wenn sowieso eine Zentrale oder dergleichen vorhanden ist, die die vorhandenen Funktionen ebenso beherrscht.
Daher die Frage, was es für einen Vorteil hat, solch ein Gerät zu benötigen.
Viele Grüße, Franzi
Hallo Leute,
ich finde die letzten Kommentare hier nicht unbedingt produktiv. Wenn man als Konsument Open Source vom Konzept her nicht versteht oder nicht mag, bitte einfach heraushalten. Und wenn man Produzent kommerzieller Produkte ist, dann bitte mit offenen Karten spielen. Ich weiß nicht, ob die Projekte von Harald am Ende Erfolg haben - wie immer man den auch messen möchte. Es ist bei Open Source durchaus inhärent, daß viele Projekte einen langsamen oder auch schnellen Tod finden. Aber gerade deshalb ich fände es nicht schön, wenn jetzt sein Engagement, das vielleicht auch anderen hilft, sie inspirit oder motiviert, hier zerredet wird. Das schließt ja nicht aus, Kritik zu üben. Bei Diskussionen um Gleispläne funktioniert das in der Regel ja auch.
Gruß
Klaus
ich finde die letzten Kommentare hier nicht unbedingt produktiv. Wenn man als Konsument Open Source vom Konzept her nicht versteht oder nicht mag, bitte einfach heraushalten. Und wenn man Produzent kommerzieller Produkte ist, dann bitte mit offenen Karten spielen. Ich weiß nicht, ob die Projekte von Harald am Ende Erfolg haben - wie immer man den auch messen möchte. Es ist bei Open Source durchaus inhärent, daß viele Projekte einen langsamen oder auch schnellen Tod finden. Aber gerade deshalb ich fände es nicht schön, wenn jetzt sein Engagement, das vielleicht auch anderen hilft, sie inspirit oder motiviert, hier zerredet wird. Das schließt ja nicht aus, Kritik zu üben. Bei Diskussionen um Gleispläne funktioniert das in der Regel ja auch.
Gruß
Klaus
Hallo an die letzten Schreiber hier,
kann es nicht einfach sein, dass man schlicht und einfach wissen will, was ein SPROG ist und macht?
Nicht jeder ist ein IT-Nerd, der sowas aus dem Ärmel schütteln kann...
Ich selber habe da nur eine vage Vorstellung von so einem Teil und fände eine fachliche Auskunft durchaus interessant.
Stattdessen wird wild spekuliert und irgendwie interpretiert, welche bösen Absichten der Frager schon wieder hat -- geht´s noch?
Auf eine Frage einfach mal sachlich antworten, ohne gleich irgendwelche bösen Absichten zu unterstellen -- ist das so schwierig?
Kopfschüttelnde Grüße
Michael
kann es nicht einfach sein, dass man schlicht und einfach wissen will, was ein SPROG ist und macht?
Nicht jeder ist ein IT-Nerd, der sowas aus dem Ärmel schütteln kann...
Ich selber habe da nur eine vage Vorstellung von so einem Teil und fände eine fachliche Auskunft durchaus interessant.
Stattdessen wird wild spekuliert und irgendwie interpretiert, welche bösen Absichten der Frager schon wieder hat -- geht´s noch?
Auf eine Frage einfach mal sachlich antworten, ohne gleich irgendwelche bösen Absichten zu unterstellen -- ist das so schwierig?
Kopfschüttelnde Grüße
Michael
Zitat - Antwort-Nr.: 31 | Name: KMal schrieb am 11.03.20 17:31
Hallo Leute,
ich finde die letzten Kommentare hier nicht unbedingt produktiv. Wenn man als Konsument Open Source vom Konzept her nicht versteht oder nicht mag, bitte einfach heraushalten. Und wenn man Produzent kommerzieller Produkte ist, dann bitte mit offenen Karten spielen. Ich weiß nicht, ob die Projekte von Harald am Ende Erfolg haben - wie immer man den auch messen möchte. Es ist bei Open Source durchaus inhärent, daß viele Projekte einen langsamen oder auch schnellen Tod finden. Aber gerade deshalb ich fände es nicht schön, wenn jetzt sein Engagement, das vielleicht auch anderen hilft, sie inspirit oder motiviert, hier zerredet wird. Das schließt ja nicht aus, Kritik zu üben. Bei Diskussionen um Gleispläne funktioniert das in der Regel ja auch.
Gruß
Klaus
Moin,
Ich möchte gern verstehen, was dieses angesprochene Gerät macht.
Bei anderen Selbstbauprojekten wird dies ja auch beschrieben ..
Es spielt am Ende auch keine Rolle ob es für MICH sinnvoll ist, nur bevor ich mit einem solchen Nachbau Projekt beginne, wäre es doch schon sinnvoll zu wissen, ob es für MICH einen Mehrwehrt darstellt.
Irgendwas zu bauen, nur weil ICH es kann ist für MICH dann doch nicht so erstrebenswert.
Viele Grüße, Franzi
Hallo,
May I Google that for you?
https://dccwiki.com/SPROG
https://www.sprog-dcc.co.uk/
Es handelt sich um ein eigenständiges DCC Lokdecoder Programmiergerät. Es ist für Leute interessant, die mit einem (Klein-)Computer arbeiten möchten und keine teure Zentrale dazu benutzen wollen z.B. wenn diese an der Anlage steht oder durch den Fahrbetrieb belegt ist.
Ich selbst verwende zu diesem Zweck den ESU Programmer, und im Verein benutzen wir den Zimo MXULFA beim Stammtischbahning, wogegen bei Ausstellungen meist eine Zentrale aufgebaut wird.
Grüße, Peter W
May I Google that for you?
https://dccwiki.com/SPROG
https://www.sprog-dcc.co.uk/
Es handelt sich um ein eigenständiges DCC Lokdecoder Programmiergerät. Es ist für Leute interessant, die mit einem (Klein-)Computer arbeiten möchten und keine teure Zentrale dazu benutzen wollen z.B. wenn diese an der Anlage steht oder durch den Fahrbetrieb belegt ist.
Ich selbst verwende zu diesem Zweck den ESU Programmer, und im Verein benutzen wir den Zimo MXULFA beim Stammtischbahning, wogegen bei Ausstellungen meist eine Zentrale aufgebaut wird.
Grüße, Peter W
Zitat - Antwort-Nr.: 34 | Name: Peter W. schrieb am 11.03.20 19:31
Hallo,
May I Google that for you?
https://dccwiki.com/SPROG
https://www.sprog-dcc.co.uk/
Es handelt sich um ein eigenständiges DCC Lokdecoder Programmiergerät. Es ist für Leute interessant, die mit einem (Klein-)Computer arbeiten möchten und keine teure Zentrale dazu benutzen wollen z.B. wenn diese an der Anlage steht oder durch den Fahrbetrieb belegt ist.
Ich selbst verwende zu diesem Zweck den ESU Programmer, und im Verein benutzen wir den Zimo MXULFA beim Stammtischbahning, wogegen bei Ausstellungen meist eine Zentrale aufgebaut wird.
Grüße, Peter W
Moin,
lass es einfach
Viele Grüße, Franzi
Beitrag editiert am 11. 03. 2020 19:50.
Zitat - Antwort-Nr.: | Name:
Es gibt für DCC++ Rocrail Unterstützung:
https://wiki.rocrail.net/doku.php?id=dccpp:dccpp-en
In wie weit das funktioniert finde ich dann noch raus.
Das habe ich mir jetzt mal durchgelesen. Kommentare:
* Die maximale Anzahl der Slots is bei mir jetzt gerade 100 aber das kann man bei mir mit <#> abfragen so
dass sich ein Steuerprogram darauf einstellen kann. Für JMRI hab ich das dann auch für das "andere Ende"
implementiert.
* Ich habe keinen Support für Sensoren (ich seh irgendwie nicht ein warum man das durch den
gleichen Arduino jagen muss wenn man das braucht)
* Ich habe keinen Support um I/O im EEPROM zu speichern.
>> The rail power must be set to on before using the Programming Track.
* Mach ich automatisch wenn nicht an (und auch wieder aus).
* Der Orginalcode ist sehr "optimistisch" im Timing was das Programmieren anbelangt und
har erstmal etwas gewartet (warum ist mir nicht klar) bis er auf Acks hörte. Bei einem
schnellen Decoder war da der Ack schon vorbei. Auch waren alle positiven Stromflanken
Acks. Das kann so sein, muss aber nicht.
>> HEX File https://github.com/DccPlusPlus/BaseStation
* Naja, da ist der HEX-file nicht sondern eben die orginal Source.
Ich mach mir ja den HEX-file selber. Das geht so:
Zitat - Antwort-Nr.: | Name:
$ git clone https://github.com/habazut/dcc-ardu
$ cd dcc-ardu/DCCpp_Uno/
$ arduino &
# DCCpp_Uno.ino im arduino GUI öffnen
# Serielle Schnittstelle wählen
# Upload (Pfeilsymbol) drücken
Ich weiss nicht ob ein fertiger Hexfile was bringt aber da ist der für 1.3.0
https://raw.githubusercontent.com/habazut/dcc-a.../DCCpp_Uno_1.3.0.hex
Grüße,
Harald.
Zitat - Antwort-Nr.: | Name:
... wenn sowieso eine Zentrale oder dergleichen vorhanden ist, die die vorhandenen Funktionen ebenso beherrscht.
Zentralen haben manchmal Einschränkungen. Z.B.
* Anzahl der zu steuernden Loks
* Anzahl der unterstützten Funktionstasten
* CV-Programmierung für "hohe" CV
* Größe/Gewicht
* Preis
* Computerinterface/Steuerung mit dem Tablett
So ein kleiner Arduino ist vielleicht zu einer "richtigen" Zentrale wie ein Moped zu einem "richtigen" Auto aber ich kann das Moped aufbohren so dass es genau das macht was ich will und manchmal ist man sogar mit einem Moped schneller am Ziel.
Dann gibt es gewisse Dinge die werde ich erstmal zur "Gewichtsersparung" weglassen aber wenn sie jemand braucht kann es ja implementiert werden, da Open Source:
* 14 und 28 Fahrstufen
* Registerprogrammierung
Bis jetzt kann man auch nur auf einem Ausgang fahren (und PoM) und der andere Ausgang ist das Programmiergleis. Beide sind unabhängig voneinander auch gleichzeitig benutzbar. Ich habe aber da schon so eine Idee wie man das softwaremäßig umschalten könnte, so dass der Programmierausgang zum Fahrausgang werden kann. Bis jetzt muss man noch einen Schalter einbauen wenn man auf dem Programmiergleis fahren will. Also jetzt ist es ungefähr so wie eine Zentrale von Digitrax.
Grüße,
Harald.
Beitrag editiert am 12. 03. 2020 16:23.
Gestern abend hab ich mit JMRI 4.19.4 und meinem Arduino mit meinem DCC++ erfolgreich alle CV von zwei sehr verschiedenen Loks ausgelesen. Einerseits einer recht neuen Fleischmann 1044 mit Zimo-Sound und andererseits einer uralten 221 mit Kühndecoder. Beides war erfolgreich wenn man mal davon absieht dass der Kühndecoder versucht die Lok vom Proggleis zu wandern da die Ackpulse den Motor offenbar immer in die gleiche Richtung fahren. Ich hab jetzt nicht jeden CV mit einer anderen Zentrale verifiziert aber das Resultat sieht erstmal richtig aus.
Grüße,
Harald.
Grüße,
Harald.
Wenn hier jemand mitliest der schon DCC++ anwendet dann hab ich jetzt einen Branch im Git zum testen:
https://github.com/habazut/dcc-ardu/tree/genratepreamble
Ich hab da ein paar intressante Sachen "unter der Haube" gemacht und es wäre fein wenn noch jemand mehr als ich sahen könnte dass es
noch wie vorher funktioniert. Wenn dann alles so funktioniert wie gewollt dann werden die Änderungen natürlich so gemacht im Release.
Hintergrund: Vorher wurden für die Lagerung der DCC-Präambel fast 3 Bytes (mal Anzahl möglicher Loks) verschwendet und man konnte die Länge der Präambel auch nicht einfach ändern. Also wird von mir jetzt die Präambel programmatisch erzeugt, sind ja immer 14-22 1-Bits. Damit das geht musste ich intern ein paar Sachen umkrempeln.
Grüße,
Harald.
https://github.com/habazut/dcc-ardu/tree/genratepreamble
Ich hab da ein paar intressante Sachen "unter der Haube" gemacht und es wäre fein wenn noch jemand mehr als ich sahen könnte dass es
noch wie vorher funktioniert. Wenn dann alles so funktioniert wie gewollt dann werden die Änderungen natürlich so gemacht im Release.
Hintergrund: Vorher wurden für die Lagerung der DCC-Präambel fast 3 Bytes (mal Anzahl möglicher Loks) verschwendet und man konnte die Länge der Präambel auch nicht einfach ändern. Also wird von mir jetzt die Präambel programmatisch erzeugt, sind ja immer 14-22 1-Bits. Damit das geht musste ich intern ein paar Sachen umkrempeln.
Grüße,
Harald.
Mit der neuen Version https://github.com/habazut/dcc-ardu/
hab ich das hier produziert: https://habazut.github.io/dcc-ardu/bitpattern.html
Grüße,
Harald.
Es wäre ganz geschickt wenn es noch mehr Leute gäbe, die mein DCC++/dcc-ardu ausprobieren wollen. Weil alleine werde ich bestimmt nicht alle Bugs für alle Motorshields und alle Decodervarianten finden. Dafür bekommt man dann auch eine sehr günstige Zentrale die auch sehr flexibel ist, man kann ja die "Motorhaube" öffnen und nachgucken wie alles funktioniert. Wenn man will. Was ich mich frage ist warum die Resonanz doch etwas müde ausfällt. Gibt es keinen Bedarf oder ist es doch intressant _aber_ man traut sich dann doch nicht so ganz aus den Einzelteilen ein funktionierendes Ganze zusammenzubekommen? Aber da ich die Fragen oder noch offenen Probleme nicht kenne, kann ich sie auch nicht beantworten. Zur Zeit bin ich daran die Messung von Strom und Spannung im Arduino soweit hinzubekommen dass man der Werten auch glauben kann (z.Z. sind sie nämlich noch je nach Motorshield einen Umrechnungsfaktor X falsch). Achja und wenn man mithelfen will braucht man nicht unbedingt programmieren können. Es gibt auch noch andere Sachen zu tun wie z.B. Beschreibungen verfassen oder mit Bildern illustrieren und oder was auch immer. Die Meiste Information über DCC++/acc-ardu ist immer noch auf Englisch und das hilft nicht unbedingt allen.
Achja, falls jemand schon einen Booster selber gebaut hat und der sich am Eingang mit einem Signal von 5V 20mA zufrieden gibt, dann braucht man zum "nur fahren" kein Motorshield.
Frohe Ostern und bleibt gesund,
Harald.
Achja, falls jemand schon einen Booster selber gebaut hat und der sich am Eingang mit einem Signal von 5V 20mA zufrieden gibt, dann braucht man zum "nur fahren" kein Motorshield.
Frohe Ostern und bleibt gesund,
Harald.
Wenn jemand ausprobieren will ob ich die RailCom-Lücke richtig hinbekommen habe, der kann sich ja bei mir melden.
Grüße,
Harald.
Grüße,
Harald.
Hallo Harald,
Im Trainboard Forum werden Anstrengungen unternommen, das DCC++System weiterzupflegen und all die ganzen Forks usw. zusammenzuführen. Vielleicht wäre ein Kontakt dorthin auch gut?
https://www.trainboard.com/highball/index.php?t...project-2020.130071/
Gruß Thomas
Im Trainboard Forum werden Anstrengungen unternommen, das DCC++System weiterzupflegen und all die ganzen Forks usw. zusammenzuführen. Vielleicht wäre ein Kontakt dorthin auch gut?
https://www.trainboard.com/highball/index.php?t...project-2020.130071/
Gruß Thomas
Guck mal auf Seite 27: https://www.trainboard.com/highball/index.php?...-2020.130071/page-27
Wie sagte der Igel zum Hase als sie ein Wettrennnen machten? "Bin schon da".
Der experimentelle Code der eine Railcom-Lücke produziert ist in der Branch
https://github.com/habazut/dcc-ardu/tree/digitalwritefast (ok, blöder Name)
Ich seh ne Lücke, hab bis jetzt aber noch keinen Detector eingeschleift und kann also nicht sehen ob
da erstmal die Ausgänge miteinander verbunden werden und ob dann auch in der Railcom Lücke ein
Strom vom Decoder fließen kann. Aber wie gesagt, RailCom ist nicht mein Hauptthema und da bin
ich noch am Anfang. Triggersignal für ein Oszi ist auf Pin4.
Grüße,
Harald.
Da ich hier im Forum immer wieder höre, dass die neuen Zentralen keine Registerprogrammierung mehr können, würde ich mal gern wissen ob ich für DCC++ auf dem Arudino Registerprogrammierung implementieren soll, oder ob die Anwender mit solchen Problemem ("ich will mit der Orginalplatine weiterfahren") sowieo nie einen Arduino mit DCC++ in Betrieb nehmen würden. Wenn das dann eh keiner anwenden würde, dann brauch ich mir die Zeit ja nicht zu nehmen.
Grüße,
Harald.
Grüße,
Harald.
Ich habe heute per Zufall dieses Kickstarter-Projekt hier entdeckt:
https://www.kickstarter.com/projects/wasatchsca...ntroller/description
Ich bin nicht verwandt oder verschwägert mit dem Projekt, kann auch nichts darüber sagen, weder positiv noch negativ. Ich dachte nur, es würde zu diesem Thread passen.
Gruß
Klaus
Edit: URL korrigiert (Beschreibung)
https://www.kickstarter.com/projects/wasatchsca...ntroller/description
Ich bin nicht verwandt oder verschwägert mit dem Projekt, kann auch nichts darüber sagen, weder positiv noch negativ. Ich dachte nur, es würde zu diesem Thread passen.
Gruß
Klaus
Edit: URL korrigiert (Beschreibung)
Beitrag editiert am 23. 06. 2020 00:14.
Zitat - Antwort-Nr.: | Name:
Ich habe heute per Zufall dieses Kickstarter-Projekt hier entdeckt: (...Firebox...)
Also das hängt so zusammen:
Da der Gregg, der vor langem DCC++ ins Leben gerufen hat zumindest von der Modellbahnbildfläche verschwunden ist haben mehrere Personen (am Anfang unabhänging voneinander) angefangen den Faden wieder aufzunehmen, weil es ist doch eine recht coole Idee. Inzwischen haben wir zusammengefunden und versuchen unsere Anstrengungen zu koordinieren. Wir haben verschiedene Talente im Team, u.A. den David der Hardware kann und die FireBox designt hat. Auch ist eine Webpage am Entstehen https://dcc-ex.github.io/ (also einige Tage alt) und die Software/Firmware wird auch von Grund auf überarbeitet, weil das Orginal vom Design her nicht so ausbaubar ist (was ich auch gemerkt habe) und wir einen im Team haben der gut struktuierte Software hinbekommt. So ich werde versuchen ihn zu unterstützen weil er schreibt schneller neue Software als ich. Er hat aber noch nicht so viele Jahre Erfahrung mit den Tücken von DCC (schon mal den Standard gelesen?! Function groups? Refresh? Repeat? Accessory subadress?). Wie auch immer, es ist das Ziel dass die Software auf folgende Hardware passen wird.
* Arduino Uno mit verschiedenen Motorshields
* Arduino Mega mit verschiedenen Motorshields und WiFi
* FireBox (hat 2 Ausgänge und WiFi integriert)
Die grundlegende Software zur Steuerung ist erstmal JMRI über die DCC++ Befehle (klassich + erweitert) und um die 50 Loks sollen gleichzeitig hantiert werden, gerne mehr (bei 100 bin dann wahrscheinlich sogar ich zufrieden).
Koordiniert und gebabbelt wird auf Discord, wenn jemand mitmachen will, lasst es mich wissen.
Die Software sollte dann beim Release auch einen RaiCom cutout produzieren und die Firebox hat auch Hardware für einen Detektor an Bord. Ob das mit den Arduinos geht werden wir noch sehen, hängt wahrscheinlich auch stark vom Motorshield ab.
Grüße,
Harald.
Schoenes Projekt auf kickstarter. Aber keine Angabe der Versandkosten und leider mit Early Birds.
Gruss
Peter
Gruss
Peter
Nimm Kontakt auf. Frag ihn. Vielleicht sogar inklusive.
Tja, kann man nix machen aber ich glaub der David hat die Resonanz unterschätzt.
Grüße,
Harald.
Hallo Harald,
weißt Du eigentlich, ob das Projekt als Open Source Hardware angelegt ist? Mich würden die Komponenten interessieren, die da verbaut sind. Ich hatte mir auch schon mal Gedanken gemacht, wie ich soetwas aufbauen würde.
Klaus
weißt Du eigentlich, ob das Projekt als Open Source Hardware angelegt ist? Mich würden die Komponenten interessieren, die da verbaut sind. Ich hatte mir auch schon mal Gedanken gemacht, wie ich soetwas aufbauen würde.
Klaus
Hallo Harald,
zum Thema Registerprogrammierung:
Ich selbst habe nur noch ganze wenige Original Arnold/Lenz Decoder, wovon ich 2 ab und zu laufen lasse (BR140 und BR111) solange die Decoder noch leben, dafür benutze ich den alten FL Lokboss, der sowieso nur 14 Fahrstufen kann und bei der Adressprogrammierung verschiedene Methoden hintereinander anwendet (Address only, Register, CV). Ein ET88 dient derzeit nur als Vitrinenmodell, der Decoder ist so alt dass er das Ribi nur bei FS 0 (Nothalt) einliest und der Motor ist ganz schrecklich, auch hatte der Steuerwagen ab Werk gar keinen F-Decoder - der Spaßfaktor ist da eher gering. Das Fahrzeug möchte ich auf GAM, Sound, stromführende Kupplung und ggf. F-Decoder umbauen. Für diese Arbeit hatte ich noch keine Muße, da habe ich lieber Spaß mit aktuellen Decoder und aktuellen Digitalgeräten.
Also ich denke dass potentielle alte Arnold Kunden eher kaum in die Verlegenheit kommen werden, einen Arduino zu nutzen. Das ist schon sehr speziell.
Grüße, Peter W.
zum Thema Registerprogrammierung:
Ich selbst habe nur noch ganze wenige Original Arnold/Lenz Decoder, wovon ich 2 ab und zu laufen lasse (BR140 und BR111) solange die Decoder noch leben, dafür benutze ich den alten FL Lokboss, der sowieso nur 14 Fahrstufen kann und bei der Adressprogrammierung verschiedene Methoden hintereinander anwendet (Address only, Register, CV). Ein ET88 dient derzeit nur als Vitrinenmodell, der Decoder ist so alt dass er das Ribi nur bei FS 0 (Nothalt) einliest und der Motor ist ganz schrecklich, auch hatte der Steuerwagen ab Werk gar keinen F-Decoder - der Spaßfaktor ist da eher gering. Das Fahrzeug möchte ich auf GAM, Sound, stromführende Kupplung und ggf. F-Decoder umbauen. Für diese Arbeit hatte ich noch keine Muße, da habe ich lieber Spaß mit aktuellen Decoder und aktuellen Digitalgeräten.
Also ich denke dass potentielle alte Arnold Kunden eher kaum in die Verlegenheit kommen werden, einen Arduino zu nutzen. Das ist schon sehr speziell.
Grüße, Peter W.
Zitat - Antwort-Nr.: | Name:
weißt Du eigentlich, ob das Projekt als Open Source Hardware angelegt ist?
Nein, das hab ich den David noch nicht gefragt. Mach das. Oder wenn du an der HW-Entwicklung Spaß hast frag ob er will das du mitmachst. Musst dich aber darauf gefasst machen dass es dann streckenweise recht schnell geht.
Für die Firebox würde das mir nix bringen weil ich es sowieso nicht besser (weder von der Qualität als auch vom Preis) hinbekommen würde. Ich bin überhaupt skeptisch ob "selber für die Moba designen" in irgend einer Weise sich lohnt im Vergleich zu Hardware die schon in großen Stückzahlen produziert wird wie z.B. Arduinos oder andere IoT Komponenten. Ich denke dass sich höchstens das Motorshield lohnt da man da spezielle Sachen wie RailCom-Detektor dann draufpacken kann aber ich glaube der David hat dann gedacht "da mach ich dann gleich alles". Ob das was bringt oder in der Zukunft eher hinderlich ist werden wir sehen.
Grüße,
Harald.
EIne eigene Schaltung ist ja schon nicht schlecht. Und dank der tollen Bauteile, die man heute bekommt, ist das alles relativ einfach - Microcontroller, H-Bridge, Strom-/Spannungsmesser und noch ein paar diskrete Bauteile. Auf der anderen Seite hast Du recht. Soetwas lohnt sich erst, wenn da eine gewisse Stückzahl herauskommt. Da sind eine Menge Fixkosten drin (von der Arbeitszeit mal ganz abgesehen). Ich werde das mal beobachten. Auch wenn ich mal E-Technik (als Nebenfach) studiert habe, liegen meine letzten Elektronik-Entwicklungen schon Jahrzehnte zurück und die waren auf niedrigeren Niveau. Da käme es mir nicht ungelegen, wenn jemand anderes etwas passendes entwickelt (ich hätte auch den SAMD21 genommen oder gar seinen größeren Bruder).
Klaus
Klaus
Hallo Harald,
habe mal versucht Deine Version auf eine Mega2560 + orginal Motorshield zu benutzen.
Die Cuts für Vin und Brake-Disable (Prog und Main) sind gemacht, und auch die fliegende Drahtverbindung zwischen Pin2 und 13.
( https://github.com/DccPlusPlus/Documentation/b...20Pin%20Mappings.pdf )
Mit JRMI DecoderPro bekomme ich dann aber keine Rückmeldung, d.h. ich kann keine CV's auslesen.
Die Lok ruckelt rythmisch. also scheint ein Gleissignal für die Programmierung/Auslesen erzeugt zu werden.
Was habe ich übersehen ?
VG wassi
habe mal versucht Deine Version auf eine Mega2560 + orginal Motorshield zu benutzen.
Die Cuts für Vin und Brake-Disable (Prog und Main) sind gemacht, und auch die fliegende Drahtverbindung zwischen Pin2 und 13.
( https://github.com/DccPlusPlus/Documentation/b...20Pin%20Mappings.pdf )
Mit JRMI DecoderPro bekomme ich dann aber keine Rückmeldung, d.h. ich kann keine CV's auslesen.
Die Lok ruckelt rythmisch. also scheint ein Gleissignal für die Programmierung/Auslesen erzeugt zu werden.
Was habe ich übersehen ?
VG wassi
Ich habe einen Uno, kann also z.Z. das auf einem Mega nicht testen, habe aber vor einen Mega zu bestellen.
1. Welche Version hast du genau runtergeladen? Steht im DCCpp_Uno.h "11.0.8+haba" ist die neuste.
2. Kann man programieren, also z.B. CV1 ändern?
3. Kannst du irgendwie die Spannung an A0 und A1 messen? Die Spannung die dein Motorshield an die Eingänge legen sollte ist proportional zum Strom von Haupt- bzw Programmiergleisausgang, also sollte ein Scope und/oder Voltmeter bei Stromverbrauch und Ack da was anzeigen. Bei einem Ack leider nur so um die 0.1V für 6ms. Aber man kann ja mit einem Widerstand ausprobieren ob die Stromanzeige überhaupt reagiert. Fürs Haupgleis gibs eine Anzeige, Kommando <c>. Antwort <a NNNN> in mA was aber von JMRI als 1024tel ausgewertet und in eine dann falsche Prozentanzeige umgerechnet wird.
4. Kannst du die Kommandos auch mit einem Terminalprogram anstatt mit JMRI geben? Also wenn man z.B
<R 1 0 0> an DCC++ schreibt sollte man <r 0 0 3> zurück bekommen oder <r 0 0 -1> wenn nix gelesen werden konnte.
5. Für recht viel Debug über Serial kann man auch noch "#define DEBUGACK 1" im Sketch Debug anmachen, dann sieht man im Terminal was passiert und welche Stromwerte reinkommen (in mA).
Grüße,
Harald.
1. Welche Version hast du genau runtergeladen? Steht im DCCpp_Uno.h "11.0.8+haba" ist die neuste.
2. Kann man programieren, also z.B. CV1 ändern?
3. Kannst du irgendwie die Spannung an A0 und A1 messen? Die Spannung die dein Motorshield an die Eingänge legen sollte ist proportional zum Strom von Haupt- bzw Programmiergleisausgang, also sollte ein Scope und/oder Voltmeter bei Stromverbrauch und Ack da was anzeigen. Bei einem Ack leider nur so um die 0.1V für 6ms. Aber man kann ja mit einem Widerstand ausprobieren ob die Stromanzeige überhaupt reagiert. Fürs Haupgleis gibs eine Anzeige, Kommando <c>. Antwort <a NNNN> in mA was aber von JMRI als 1024tel ausgewertet und in eine dann falsche Prozentanzeige umgerechnet wird.
4. Kannst du die Kommandos auch mit einem Terminalprogram anstatt mit JMRI geben? Also wenn man z.B
<R 1 0 0> an DCC++ schreibt sollte man <r 0 0 3> zurück bekommen oder <r 0 0 -1> wenn nix gelesen werden konnte.
5. Für recht viel Debug über Serial kann man auch noch "#define DEBUGACK 1" im Sketch Debug anmachen, dann sieht man im Terminal was passiert und welche Stromwerte reinkommen (in mA).
Grüße,
Harald.
Hallo Harald,
hatte die 11.0.4+haba aus link@44, jetzt den aus dem master-branch mit 11.0.8+haba drauf
CV's schreiben geht
Spannung A0 unbelastet 92mV, mit 220ohm last 114mV
A1 unbelastet 87mV, mit 220ohm last 106mV
im "Terminal" antwort auf c cmd 50 (unbelastet) und 65 (belastet)
im Terminal bekomme ich auf <R 1 0 0> <r 0 0 -1> zurück
VG wassi
PS: #define DEBUGACK 1 in welchen File ? Habe es nicht gefunden bzw. in DCCpp_UNO.h brachte es keine Änderung
hatte die 11.0.4+haba aus link@44, jetzt den aus dem master-branch mit 11.0.8+haba drauf
CV's schreiben geht
Spannung A0 unbelastet 92mV, mit 220ohm last 114mV
A1 unbelastet 87mV, mit 220ohm last 106mV
im "Terminal" antwort auf c cmd 50 (unbelastet) und 65 (belastet)
im Terminal bekomme ich auf <R 1 0 0> <r 0 0 -1> zurück
VG wassi
PS: #define DEBUGACK 1 in welchen File ? Habe es nicht gefunden bzw. in DCCpp_UNO.h brachte es keine Änderung
Beitrag editiert am 02. 07. 2020 15:46.
unbelastet sollte um de 0 sein.
Zitat - Antwort-Nr.: | Name:
Spannung A0 unbelastet 92mV, mit 220ohm last 114mV
A1 unbelastet 87mV, mit 220ohm last 106mV
Da ist was faul, weil unbelastet sollte die Spannung um die 0V sein. Geht der Current sense vom Chip wirklich zu A0 und A1 dann?
Exakt wieviel die Spannung mit korrekt angeschlossenen Currentsense dann steigt (per Ampere) hängt vom Motorshield ab. Ich habe bei 15V und einem angeschlossenen 91Ohm Widerstand einen Strom von 164mA. Das gibt dann bei mir eine Spannung von 480mV an A0 und im Arduino bekommt ich den Wert 96 aus dem AD-Wandler. Ohne Belastung habe ich auf A0 eine Spannung von unter 5mV
DEBUGACK wird in PacketRegister.cpp angewendet so in DCCpp_Uno.h sollte es schon gehen. Sonst einfach
eine Zeile vor dem ersten #ifdef DEBUGACK ein #define DEBUGACK hinknallen.
Es kann sehr wohl sein dass man für dein Motor shield sehen muss wo der Currentsense ist und dann der Konvertierungsfaktor berechnen.
Hmmmm, könnten die analogen Inputs noch als _output_ definiert sein?!
Das können wir fixen:
Such mal in DCCpp_Uno.ino nach "void setup(){"
und schreib da in die nächsten Zeilen:
pinMode(CURRENT_MONITOR_PIN_MAIN, INPUT);
pinMode(CURRENT_MONITOR_PIN_PROG, INPUT);
Das könnte helfen.
Grüße,
Harald.
Hallo Harald,
das mit dem #DEBUGACK hat sich geklärt, die zusätzlichen Ausgaben sieht man nur im Terminal, nicht im DCC++ Monitor, mein Fehler
Ich habe mal ACK_SAMPLE_THRESHOLD auf 10 (war 55 ) gesetzt, damit geht jetzt das CV lesen.
Kann es sein, das die ADC Kalibrierung beim MEGA anders ist als beim UNO ?
beim Auslesen von <v> bekomme ich <v45.84>, dabei liegen nur 12V an ?
Ansonsten, der MEGA ist kein orginal, sondern ein China-Clone mit .
Ein Test mit einem ebenfalls nicht orginal UNO (saintsmart) liefert <v2.89>, c ist weiterhin 45
Als Motorshield habe ich den orginal (?) von Ardunino ( https://store.arduino.cc/arduino-motor-shield-rev3 https://www.arduino.cc/en/uploads/Main/arduino_MotorShield_Rev3-schematic.pdf ), steht jedoch V5 drauf
VG wassi
PS: mein Motor-Shield sieht wie dieses hier aus https://www.rs-online.com/designspark/arduino-stepper-motor-control (offensichtlicher Unterschied mitte rechts)
https://www.reichelt.de/arduino-shield-motorste...stct=pos_1&nbc=1
das mit dem #DEBUGACK hat sich geklärt, die zusätzlichen Ausgaben sieht man nur im Terminal, nicht im DCC++ Monitor, mein Fehler
Ich habe mal ACK_SAMPLE_THRESHOLD auf 10 (war 55 ) gesetzt, damit geht jetzt das CV lesen.
Kann es sein, das die ADC Kalibrierung beim MEGA anders ist als beim UNO ?
beim Auslesen von <v> bekomme ich <v45.84>, dabei liegen nur 12V an ?
Ansonsten, der MEGA ist kein orginal, sondern ein China-Clone mit .
Ein Test mit einem ebenfalls nicht orginal UNO (saintsmart) liefert <v2.89>, c ist weiterhin 45
Als Motorshield habe ich den orginal (?) von Ardunino ( https://store.arduino.cc/arduino-motor-shield-rev3 https://www.arduino.cc/en/uploads/Main/arduino_MotorShield_Rev3-schematic.pdf ), steht jedoch V5 drauf
VG wassi
PS: mein Motor-Shield sieht wie dieses hier aus https://www.rs-online.com/designspark/arduino-stepper-motor-control (offensichtlicher Unterschied mitte rechts)
https://www.reichelt.de/arduino-shield-motorste...stct=pos_1&nbc=1
Beitrag editiert am 03. 07. 2020 07:12.
Also die Voltanzeige geht nur wenn man einen 1:10 Spannungsteiler selber baut.
Die Stromanzeige sollte nach
pinMode(CURRENT_MONITOR_PIN_MAIN, INPUT);
pinMode(CURRENT_MONITOR_PIN_PROG, INPUT);
wenn kein Strom verbraucht wird auch um die 0 anzeigen (also unter 5mA)
Wenn Versorgungsspannung und ein angeschlossener Widerstand bekannt sind kann man ja seine Stromanzeige justieren. Das macht man indem man die CURRENT_CONVERSION_PROMILLE in CurrentMonitor.h justiert.
Beispiel: Du hast
#if MOTOR_SHIELD_TYPE == 0
#define CURRENT_CONVERSION_PROMILLE 2969
#endif
aber deine Messwerte sind einen Faktor 1.5 zu klein. Also dann 2969 * 1.5 = 4455 (auf integer gerundet). Das ist besser als am ACK_SAMPLE_THRESHOLD rumzuschrauben weil wenn die Messung falsch ist dann ist auch der Kurzschlussschutz falsch.
Grüße,
Harald.
PS apropos Unterschiede:
Der 16DIL den es bei dir nicht gibt ist ein 4077D exor der wahrscheinlich durch einzelne Komponenten ersetzt wurde. Ist Eingangsseite der Motorbrücke.
Was Rolle spielt ist der LM358 OPamp gleich neben den Anschlüssen für A0 und A1, wenn da was geändert wurde dann ändert sich das Verhältnis.
Die Stromanzeige sollte nach
pinMode(CURRENT_MONITOR_PIN_MAIN, INPUT);
pinMode(CURRENT_MONITOR_PIN_PROG, INPUT);
wenn kein Strom verbraucht wird auch um die 0 anzeigen (also unter 5mA)
Wenn Versorgungsspannung und ein angeschlossener Widerstand bekannt sind kann man ja seine Stromanzeige justieren. Das macht man indem man die CURRENT_CONVERSION_PROMILLE in CurrentMonitor.h justiert.
Beispiel: Du hast
#if MOTOR_SHIELD_TYPE == 0
#define CURRENT_CONVERSION_PROMILLE 2969
#endif
aber deine Messwerte sind einen Faktor 1.5 zu klein. Also dann 2969 * 1.5 = 4455 (auf integer gerundet). Das ist besser als am ACK_SAMPLE_THRESHOLD rumzuschrauben weil wenn die Messung falsch ist dann ist auch der Kurzschlussschutz falsch.
Grüße,
Harald.
PS apropos Unterschiede:
Der 16DIL den es bei dir nicht gibt ist ein 4077D exor der wahrscheinlich durch einzelne Komponenten ersetzt wurde. Ist Eingangsseite der Motorbrücke.
Was Rolle spielt ist der LM358 OPamp gleich neben den Anschlüssen für A0 und A1, wenn da was geändert wurde dann ändert sich das Verhältnis.
Beitrag editiert am 03. 07. 2020 14:33.
[Programmiergleis ERLEDIGT. Siehe unten]
Hallo, ich bin auch gerade dabei das auszuprobieren. Arduino (Eleego) und Shield zusammengebaut.
Züge kann ich auf dem Gleis (H0) fahren lassen.
Weichen möchten zwar umschalten, zuckeln aber nur kurz. Vielleicht ist der Output nicht hoch genug(?). Habe das Shield an 14V meines Selbstbau-Boosters von meinem Papa gehängt.
Programmiergleis: Die Loks ruckeln kurz, was ja ein gutes Zeichen ist, aber das Auslesen klappt nicht. Nur 2 CVs gehen sporadisch. Der 17ner liefert Werte zwischen 109 und 207 (aber nur jedes 15. Mal kommt ein Wert), der CV 18 liefert 96. Manchmal geht nach 10 Versuchen auch der 33. Da kommt 1 zurück. Alle anderen liefern Fehler. Value -1. Deine Änderungen am Code habe ich probiert, aber es ändert leider nichts.
Ein <R 29 0 82> liefert
[RX: r0|82|29 -1] Program Reply:
Callback Num: 0
Callback Sub: 82
CV: 29
Value: -1
Bin gespann ob ich noch rausfinde woran das liegen kann. Habt Ihr eine Idee?
Habe einfach mal rumprobiert und im PacketRegister.h von 55 auf 10 (wie empfohlen). Das brachte keine Änderung.
Dann habe ich die Zahl auf 155 hochgesetzt und JIPPIE: Ich kann die CVs auslesen. Es kommen keine Fehler mehr
Ergänzung: Habe die kleine BR 80 durch Ludmilla ersetzt und dort gibt es in ca 30% der Fälle Probleme beim Auslesen. Erneutes Auslesen klappt dann meist. Versuche es mit noch höheren Werten....
Ergänzung2: Der ICE funktionierte nur mit CVs des Standarddecoders. Die Intellisound-CVs gingen gar nicht (>=897).
Also habe ich ACK_SAMPLE_THRESHOLD 255 gesetzt und alles klappt mit allen Loks ohne Fehler <glücklich>
Hallo, ich bin auch gerade dabei das auszuprobieren. Arduino (Eleego) und Shield zusammengebaut.
Züge kann ich auf dem Gleis (H0) fahren lassen.
Weichen möchten zwar umschalten, zuckeln aber nur kurz. Vielleicht ist der Output nicht hoch genug(?). Habe das Shield an 14V meines Selbstbau-Boosters von meinem Papa gehängt.
Programmiergleis: Die Loks ruckeln kurz, was ja ein gutes Zeichen ist, aber das Auslesen klappt nicht. Nur 2 CVs gehen sporadisch. Der 17ner liefert Werte zwischen 109 und 207 (aber nur jedes 15. Mal kommt ein Wert), der CV 18 liefert 96. Manchmal geht nach 10 Versuchen auch der 33. Da kommt 1 zurück. Alle anderen liefern Fehler. Value -1. Deine Änderungen am Code habe ich probiert, aber es ändert leider nichts.
Ein <R 29 0 82> liefert
[RX: r0|82|29 -1] Program Reply:
Callback Num: 0
Callback Sub: 82
CV: 29
Value: -1
Bin gespann ob ich noch rausfinde woran das liegen kann. Habt Ihr eine Idee?
Habe einfach mal rumprobiert und im PacketRegister.h von 55 auf 10 (wie empfohlen). Das brachte keine Änderung.
Dann habe ich die Zahl auf 155 hochgesetzt und JIPPIE: Ich kann die CVs auslesen. Es kommen keine Fehler mehr
Ergänzung: Habe die kleine BR 80 durch Ludmilla ersetzt und dort gibt es in ca 30% der Fälle Probleme beim Auslesen. Erneutes Auslesen klappt dann meist. Versuche es mit noch höheren Werten....
Ergänzung2: Der ICE funktionierte nur mit CVs des Standarddecoders. Die Intellisound-CVs gingen gar nicht (>=897).
Also habe ich ACK_SAMPLE_THRESHOLD 255 gesetzt und alles klappt mit allen Loks ohne Fehler
<glücklich>Beitrag editiert am 03. 07. 2020 16:17.
Also ich glaube ich muss mal erklären wie das mit dem Strom erkennen funktioniert.
Das Motorshield hat einen Ausgang auf dem eine Spanung anliegt die proportional zum Strom sein soll. Leider ist das mit exakt wieviel Spannung da ankommt per mA sehr unterschiedlich je nach IC auf dem Shield und auch noch nach Shield und Shieldversion/clone/whatever. Der Dokumentation glauben kann man scheinbar sowieso nicht.
Dann wird diese Spannung vom Arduino gemessen, im Vergleich zu einer Referenzspannung. Normal ist das "5V" ( (*)mehr dazu unten) aber es gibt glaube ich auch Arduinos da ist das 3.3V. Der AD-Umwandler gibt dann eine Zahl aus zwischen 0 und 1023 wobei 1023 der Referenzspannung entspricht. Diesen Wert muss man jetzt also auf mA zurückrechnen damit man solche Sachen wie Acks (>60mA) oder Kurzschlüsse mit so wenig Fehler wie möglich erkennen kann. Nur am THRESHOLD rumschrauben ist da nicht das Beste.
Meiner Meinung ist das am Einfachsten wenn man das nach U=R*I mit bekannten U und R ausrechnet, also I=U/R und dann den Korrektionsfaktor selber eingibt. Das habe ich bis jetzt noch nicht einfach gemacht für den Anwender weil ich erst kürzlich daraufgekommen bin welcher Sumpf das ist. Auch ist z.Z. bei DCC++ einiges los, vielleicht gibts nächste Woche ne ganz neue Code base, wer weiss. Auch kann man bis jetzt nur mit <c> den Wert auf dem Hauptgleis (A) ausgeben, die Korrektur die man dann reinkompiliert gilt dann aber für beide Ausgänge. Da dies ein uCPU ist habe ich um Gleitkommaberechnungen zu vermeiden den Korrekturwert in PROMILLE angegeben. Also 1000 ist 1,000 und 2969 ist 2,969 für MEIN Shield.
(*) Beim Arduino ist die Referenzspannung gleich der Versorgungsspannung. Wenn die aber vom USB kommt kann die schwanken, sagen wir mal 4,8 bis 5.2V, das ist einiges in Prozent. Deshalb messe ich beim Startup des Programs die internen 1,1V des CPU und rechne dann rückwärts den Fehler. Ob das aber immer so funktioniert wie es soll weiss ich noch nicht so genau. Das Teil ist wahrscheinlich genauer wenn man es nochmal seperat mit Strom versorgt aber dann braucht man nochmal ne Stromquelle für den Arduino weil die zum Fahren vom Shield ist ja zu hoch.
Grüße,
Harald.
Das Motorshield hat einen Ausgang auf dem eine Spanung anliegt die proportional zum Strom sein soll. Leider ist das mit exakt wieviel Spannung da ankommt per mA sehr unterschiedlich je nach IC auf dem Shield und auch noch nach Shield und Shieldversion/clone/whatever. Der Dokumentation glauben kann man scheinbar sowieso nicht.
Dann wird diese Spannung vom Arduino gemessen, im Vergleich zu einer Referenzspannung. Normal ist das "5V" ( (*)mehr dazu unten) aber es gibt glaube ich auch Arduinos da ist das 3.3V. Der AD-Umwandler gibt dann eine Zahl aus zwischen 0 und 1023 wobei 1023 der Referenzspannung entspricht. Diesen Wert muss man jetzt also auf mA zurückrechnen damit man solche Sachen wie Acks (>60mA) oder Kurzschlüsse mit so wenig Fehler wie möglich erkennen kann. Nur am THRESHOLD rumschrauben ist da nicht das Beste.
Meiner Meinung ist das am Einfachsten wenn man das nach U=R*I mit bekannten U und R ausrechnet, also I=U/R und dann den Korrektionsfaktor selber eingibt. Das habe ich bis jetzt noch nicht einfach gemacht für den Anwender weil ich erst kürzlich daraufgekommen bin welcher Sumpf das ist. Auch ist z.Z. bei DCC++ einiges los, vielleicht gibts nächste Woche ne ganz neue Code base, wer weiss. Auch kann man bis jetzt nur mit <c> den Wert auf dem Hauptgleis (A) ausgeben, die Korrektur die man dann reinkompiliert gilt dann aber für beide Ausgänge. Da dies ein uCPU ist habe ich um Gleitkommaberechnungen zu vermeiden den Korrekturwert in PROMILLE angegeben. Also 1000 ist 1,000 und 2969 ist 2,969 für MEIN Shield.
(*) Beim Arduino ist die Referenzspannung gleich der Versorgungsspannung. Wenn die aber vom USB kommt kann die schwanken, sagen wir mal 4,8 bis 5.2V, das ist einiges in Prozent. Deshalb messe ich beim Startup des Programs die internen 1,1V des CPU und rechne dann rückwärts den Fehler. Ob das aber immer so funktioniert wie es soll weiss ich noch nicht so genau. Das Teil ist wahrscheinlich genauer wenn man es nochmal seperat mit Strom versorgt aber dann braucht man nochmal ne Stromquelle für den Arduino weil die zum Fahren vom Shield ist ja zu hoch.
Grüße,
Harald.
Zitat - Antwort-Nr.: | Name:
Weichen möchten zwar umschalten, zuckeln aber nur kurz. Vielleicht ist der Output nicht hoch genug(?). Habe das Shield an 14V meines Selbstbau-Boosters von meinem Papa gehängt.
"An Booster gehängt" verstehe ich nicht. Das Shield will eine stabile Gleichspannung. Am Gleis kommen dann so 0,5V weniger an.
Es sollte eigentlich ein Befehl zum Umstellen kommen worauf dann der Weichendecoder einen lang genugen Puls zum Stellen der Weiche erzeugt. Wenn allerdings genau in dem Augenblick die Spannung zusammenbricht wird das nix. Haben die Weichendecoder eine eigene Versorgung oder sitzen die nur am DCC Signal?
Ich habe CV über 255 ausprobiert aber ich weiss nicht ob ich einen Decoder mit solchen CV habe. Ist das hinter SUSI?
Grüße,
Harald.
Hallo,
Susi CVs bzw. Soundbanks bei Piko fangen bei CV 900 an, da gibt es noch den Banking Index CV 1021. Über CV 256 liegen die CV Banks, Index CV 31 und CV 32 sind zu beachten.
Schau mal die Anleitung zu ESU Loksound 5 und zu Piko Smartdecoder Sound an. Die Piko sind scheinbar eine Herausforderung beim CV Lesen, mit ESU Programmer und Zimo MXULFA gibt es da Schwierigkeiten bei den hohen CVs - Timing?
Grüße, Peter W
Susi CVs bzw. Soundbanks bei Piko fangen bei CV 900 an, da gibt es noch den Banking Index CV 1021. Über CV 256 liegen die CV Banks, Index CV 31 und CV 32 sind zu beachten.
Schau mal die Anleitung zu ESU Loksound 5 und zu Piko Smartdecoder Sound an. Die Piko sind scheinbar eine Herausforderung beim CV Lesen, mit ESU Programmer und Zimo MXULFA gibt es da Schwierigkeiten bei den hohen CVs - Timing?
Grüße, Peter W
CV266 hab ich schon mal in einem Decoder bearbeitet, so das geht.
Da ich weder ESU Loksound 5 noch Piko Smartdecoder Sound habe ist es schwer für mich die Firmware damit zu testen. Wahrscheinlich wird es in Zukunft sowieso eine andere code base. mal sehen.
Aber ich hab genug andere intressante Kandidaten.
https://media.discordapp.net/attachments/713190...759484/pulsetran.png
Wie passt sowas zu einem Puls der 6ms (+-1ms) lang sein soll?
Wenn das dann die Zentrale nicht versteht sagt man die Zentrale ist schuld?
Grüße,
Harald.
Da ich weder ESU Loksound 5 noch Piko Smartdecoder Sound habe ist es schwer für mich die Firmware damit zu testen. Wahrscheinlich wird es in Zukunft sowieso eine andere code base. mal sehen.
Aber ich hab genug andere intressante Kandidaten.
https://media.discordapp.net/attachments/713190...759484/pulsetran.png
Wie passt sowas zu einem Puls der 6ms (+-1ms) lang sein soll?
Wenn das dann die Zentrale nicht versteht sagt man die Zentrale ist schuld?
Grüße,
Harald.
@haba. Hallo Harald,
danke für Deine Erklärungen.
Mein Vater hat einen Booster gebaut, der "hintern" noch diverse Ausgänge hat (Ground, 14V, 15V, 16V, 25V). Vorne kommt seriell das DCC-Signal raus. Nachdem die Rechner heutzutage selten noch serielle und paralelle Anschlüsse haben, sind wir dabei DCC++ mit dem Arduino der per USB angeschlossen werden kann auszuprobieren. Mangels passendem Netzteil für das Shield habe ich nur die Ausgänge des Boosters verwendet. Da kommt hinten kein DCC-Signal raus, sondern die entsprechende Spannung.
Die Weichendecoder sind am Gleis angeschlossen.
Bei meinem Vater wirkt sich das ebenso aus: Anscheinend bricht die Spannung beim Schaltvorgang ein, denn die LED der Weiche wird auch kurz ziemlich dunkel und dann wieder hell.
Wenn man 2 Züge fahren läßt wird der Chip auf dem Shield auch ziemlich heiß.
Anscheinend brauchen wir doch noch einen "gescheiten" Booster, der mehr verkraftet als das Motorshield.
VG
Siegmund
danke für Deine Erklärungen.
Mein Vater hat einen Booster gebaut, der "hintern" noch diverse Ausgänge hat (Ground, 14V, 15V, 16V, 25V). Vorne kommt seriell das DCC-Signal raus. Nachdem die Rechner heutzutage selten noch serielle und paralelle Anschlüsse haben, sind wir dabei DCC++ mit dem Arduino der per USB angeschlossen werden kann auszuprobieren. Mangels passendem Netzteil für das Shield habe ich nur die Ausgänge des Boosters verwendet. Da kommt hinten kein DCC-Signal raus, sondern die entsprechende Spannung.
Die Weichendecoder sind am Gleis angeschlossen.
Bei meinem Vater wirkt sich das ebenso aus: Anscheinend bricht die Spannung beim Schaltvorgang ein, denn die LED der Weiche wird auch kurz ziemlich dunkel und dann wieder hell.
Wenn man 2 Züge fahren läßt wird der Chip auf dem Shield auch ziemlich heiß.
Anscheinend brauchen wir doch noch einen "gescheiten" Booster, der mehr verkraftet als das Motorshield.
VG
Siegmund
Zitat - Antwort-Nr.: | Name:
Nachdem die Rechner heutzutage selten noch serielle und paralelle Anschlüsse haben, sind wir dabei DCC++ mit dem Arduino der per USB angeschlossen werden kann auszuprobieren.
Klar, USB.
Zitat - Antwort-Nr.: | Name:
Wenn man 2 Züge fahren läßt wird der Chip auf dem Shield auch ziemlich heiß.
Bei den Motorshields gibts auch echte Reinfälle (Fehlkonstruktionen? Murxclones?). Wenn die H-Brücke L298P so eine flache Kapsel hat, die man zwecks Wärmeableitung mit einer Kupferfläche auf dem Board verlöten sollte, dann isses dumm wenn weder Kupferfläche noch Lötung existiert. Ja, ich hab zwei solche Motorshields
Wenn man zwischen Chip und Board an der Schmalseite ein Papier drunterschieben kann dann hat man das Problem.
Siehst auf dem Bild die beiden Lötbatzen an den Schmalseiten des Chips? So soll es aussehen.
https://cdn.vellemanformakers.com/wp-content/up...27152656/ka03-11.jpg
Wenn nicht dann isses wahrscheinlich Murx.
EDIT: Das Velleman hat keinen Stromfühler, also auch nix
Siehe https://www.1zu160.net/scripte/forum/forum_show.php?id=1199383&ins#aw29Zitat - Antwort-Nr.: | Name:
Mangels passendem Netzteil für das Shield habe ich nur die Ausgänge des Boosters verwendet.
Laptop Netzteil 16V. Wichtig wegen der Spannung ist dass die VIN Brücke auf dem Motorshield getrennt ist, der uCPU bekommt dann den Strom vom USB.
Grüße,
Harald.
Beitrag editiert am 05. 11. 2020 09:57.
Hallo ihr Bastler und Tüftler! Habe die Beiträge hier gerade überflogen und nutze ebenfalls dcc++ für vier Module. Gerne teste ich die Tage auch mal die dcc-ardu an. Ich bin selbst nicht der große Programmierer, wollte aber einfach mal ein motivierendes DANKE da lassen! Ich finde es Super, dass sich hier Leute die Arbeit machen und andere daran teilhaben lassen!
Nochmals vielen Dank!
Nochmals vielen Dank!
Gern geschehen.
Ja, ich finde das ganz intressant zum austüfteln. Der Teufel steckt aber im Detail. So hat erst kürzlich ein Mitstreiter im DCC++ Team herausgefunden, dass es beim alten DCC++ (sagen wir mal "Classic") von Gregg sich der Code im Interrupt verhaspeln kann und dann legt die H-Brücke möglcherweise Gleichstrom aufs Gleis. Wenn dann die Loks auf "analog an" eingestellt sind hat man ein "volle Pulle" Szenario. So der Rat ist immer: Analog im Decoder "Aus".
Auch sehen wir erst jetzt, wenn sich das etwas weiter verbreitet, wie übel die Motorshields oft aufgebaut sind. Sowas zu konstruieren ist wahrscheinlich schwieriger als nur Einsen und Nullen wo weder Wärmeableitung noch Spannungstoleranzen eine große Rolle spielen.
Grüße,
Harald.
Ja, ich finde das ganz intressant zum austüfteln. Der Teufel steckt aber im Detail. So hat erst kürzlich ein Mitstreiter im DCC++ Team herausgefunden, dass es beim alten DCC++ (sagen wir mal "Classic") von Gregg sich der Code im Interrupt verhaspeln kann und dann legt die H-Brücke möglcherweise Gleichstrom aufs Gleis. Wenn dann die Loks auf "analog an" eingestellt sind hat man ein "volle Pulle" Szenario. So der Rat ist immer: Analog im Decoder "Aus".
Auch sehen wir erst jetzt, wenn sich das etwas weiter verbreitet, wie übel die Motorshields oft aufgebaut sind. Sowas zu konstruieren ist wahrscheinlich schwieriger als nur Einsen und Nullen wo weder Wärmeableitung noch Spannungstoleranzen eine große Rolle spielen.
Grüße,
Harald.
Da magst du recht haben Harald. Ich nutze einen Nachbau des Arduino Motorshields mit dem L298. Aktuell aber eben auch nur im kleinen Rahmen mit einer Lok. Da spürt man noch nicht viel von Erwärmung.
Beim dcc++ von Gregg hatte ich große Probleme, als es auf einem China billig Arduino Uno laufen sollte. Da wurden dann die dcc Kommandos wild durcheinander aufs Gleis gegeben. Lok blieb plötzlich stehen, fuhr auf einmal im Rangiergang und ging dann wieder auf volle Pulle.
Da scheint es also durchaus auch Qualitätsunterschiede zu geben.
Angesteuert wird mein arduino dcc++ übrigens über jmri auf einem raspberry mit 7" Touchscreen. Das kann ich durchaus empfehlen, auch wenn es zwischendurch etwas hakelig ist.
Viele Grüße, ich spiele deine Version mal auf und gebe dann Rückmeldung, wie es klappt.
Matthias
Beim dcc++ von Gregg hatte ich große Probleme, als es auf einem China billig Arduino Uno laufen sollte. Da wurden dann die dcc Kommandos wild durcheinander aufs Gleis gegeben. Lok blieb plötzlich stehen, fuhr auf einmal im Rangiergang und ging dann wieder auf volle Pulle.
Da scheint es also durchaus auch Qualitätsunterschiede zu geben.
Angesteuert wird mein arduino dcc++ übrigens über jmri auf einem raspberry mit 7" Touchscreen. Das kann ich durchaus empfehlen, auch wenn es zwischendurch etwas hakelig ist.
Viele Grüße, ich spiele deine Version mal auf und gebe dann Rückmeldung, wie es klappt.
Matthias
Hallo,
ea gibt doch noch viele andere, modernere Motortreiber mit MOSFET Brücke, anstatt des altbackenen, bipolaren L298. Die Chinesen können halt gut abkupfern, aber da sie nicht um die Ecke denken oder bewusst Schritte weglassen, kommt dann sowas zustande. Was braucht man eine Kühlfläche, funktioniert ja
Grüße, Peter W
ea gibt doch noch viele andere, modernere Motortreiber mit MOSFET Brücke, anstatt des altbackenen, bipolaren L298. Die Chinesen können halt gut abkupfern, aber da sie nicht um die Ecke denken oder bewusst Schritte weglassen, kommt dann sowas zustande. Was braucht man eine Kühlfläche, funktioniert ja
Grüße, Peter W
Da Gregg von der Bildfläche verschwunden ist (ich habe bis jetzt noch niemanden gefunden der weiss wohin oder warum) gibt es inzwischen mindestens 5 verschiedene Codes die auf dem Arduino oder vergleichbarer HW ein DCC-Signal generieren, alles zwischen "Bugfix" von Greggs Code und "Total Rewrite". Zumindest die Authoren dieser 5 Projekte koordinieren ihre Anstrengungen und das Ziel ist irgendwann nur noch eine Codebase zu unterhalten weil die jetztige Situation ist nicht gerade die Beste.
https://github.com/DCC-EX/BaseStation-Classic
https://github.com/DCC-EX/BaseStation-EX
https://github.com/DCC-EX/CommandStation-DCC
https://github.com/Asbelos/CVReader
https://github.com/habazut/dcc-ardu
Auch gibts eine Homepage: https://dcc-ex.github.io/ (auch wenn da meine Version nicht gelistet ist, macht nix. Von der Codebase her gefällt mir das CVReader Rewrite am besten).
Es werden Kontakte zu JMRI geplfegt damit das Kommandointerface mit JMRI kompatibel bleibt und kompatibel ausgebaut wird.
Grüße,
Harald.
https://github.com/DCC-EX/BaseStation-Classic
https://github.com/DCC-EX/BaseStation-EX
https://github.com/DCC-EX/CommandStation-DCC
https://github.com/Asbelos/CVReader
https://github.com/habazut/dcc-ardu
Auch gibts eine Homepage: https://dcc-ex.github.io/ (auch wenn da meine Version nicht gelistet ist, macht nix. Von der Codebase her gefällt mir das CVReader Rewrite am besten).
Es werden Kontakte zu JMRI geplfegt damit das Kommandointerface mit JMRI kompatibel bleibt und kompatibel ausgebaut wird.
Grüße,
Harald.
Weil hier die Diskussion aufkam, habe ich die Tage mal wieder nach H-Bridges gegoogelt. Als ich mir die Spezifikationen so durchlas, ist mir wieder ein Punkt aufgefallen, den schon mal ein anderer DCC-Bastler thematisiert hatte: Einige H-Brücken sind ungeeignet, weil sie zu lange Umschaltzeiten haben. So brauchte ein Baustein, den ich gefunden hatte, 15µs, um die High-Side auszuschalten, und weitere 5µs, um die Low-Side einzuschalten (die Rückrichtung ging etwas schneller). Die DCC-Spezifikation schreibt aber eine Flankensteilheit von mindestens 2,5V/µs zwischen ±4V vor. Der Baustein war also viel zu langsam.
Klaus
Klaus
Japp, so isses. Wenn jemand Tips für eine gute H-Brücke hat dann her damit. Ich sag mal was ich bis jetzt habe und was ich davon halte:
Basierend auf L298 auch "Original Motor Shield v3" genannt:
- Bipolares Urgestein
- Oft schlampig umgesetzt (ohne Kühlung - wird mir früher oder später abrauchen)
- Stromessung über 0.15 Ohm + OpAmp ungenau
+Strommessung auch im Bremsbetrieb
+Überall zu bekommen
Basiered auf MC33926 auch "Pololu Dual MC33926 Motor Shield" genannt:
+Mosfet, man kann auch kurz 8A durchjagen
+Strommessung durch eigenen Ausgang der 0,24% der Stroms abgibt
-Strommessung nur wenn die Brücke treibt
-nur 0.5V/A am Sense Output
-Man muss rumlöten wenn man die beiden Enable Eingänge (^D2) seperat zum Arduino haben will
Ich habe eigentlich _nicht_ vor gehabt selber eine H-Brücke machen zu müssen nur um zu etwas zu bekommen was funktioniert so wie ich will. Ein fertiges Shield wäre schon fein. Naja, andere haben früher resigniert über die HW die es zu kaufen gibt und haben mehr Talent für Hardware. Siehe FireBox.
Grüße,
Harald.
Ich bin übrigends dankbar über Rückmeldungen, sowohl positive als auch negative. Am nützlichsten sind die Rückmeldungen der Art: "Alles wäre leicht gewesen wenn nicht ...." Gerade die "...." sind von der Entwicklerseite oft schwer (voraus)zu sehen. Wo hakelt es?
* Arduino IDE installieren?
* Sketch wählen?
* Sketch download?
* Config.h editierem?
* Motor board jumpers setzen?
* Vin trennen
* ....
Grüße,
Harald.
* Arduino IDE installieren?
* Sketch wählen?
* Sketch download?
* Config.h editierem?
* Motor board jumpers setzen?
* Vin trennen
* ....
Grüße,
Harald.
Noch eine Warung: Das Shield mit MC33926 auch "Pololu Dual MC33926 Motor Shield" genannt funktioniert für unsere Zwecke GAR NICHT.
Für Programmieren auf dem Programmiergleis ist der Stromfühler untenrum zu ungenau, darf nach Datenblatt sogar bis 300mA nix anzeigen.
Für Kehrschleifenautomatiken ist die im Chip eingebaute Kurzschlusssicherung viel zu nervös, da geht der Chip dann in "Fault" und schaltet innerhalb von 8 Mikrosekunden (!) ab wenn das Netzteil dann kurzzeitig einen satten Stromstoß von um die 9A liefern kann.
Also leider nix für uns, Ich hab Lehrgeld bezahlt, das braucht ihr nicht auch.
Grüße,
Harald.
Für Programmieren auf dem Programmiergleis ist der Stromfühler untenrum zu ungenau, darf nach Datenblatt sogar bis 300mA nix anzeigen.
Für Kehrschleifenautomatiken ist die im Chip eingebaute Kurzschlusssicherung viel zu nervös, da geht der Chip dann in "Fault" und schaltet innerhalb von 8 Mikrosekunden (!) ab wenn das Netzteil dann kurzzeitig einen satten Stromstoß von um die 9A liefern kann.
Also leider nix für uns, Ich hab Lehrgeld bezahlt, das braucht ihr nicht auch.
Grüße,
Harald.
Mal ein Zwischenbericht. Gestern hab ich zum ersten Mal meine Moba vom Handy aus und einem Arduino gesteuert. Der Weg dorthin war allerdings etwas steinig. Man nehme
* Handy mit Android
* App Enginedriver
* Arduino Mega
* Motor Shield (hier das mit dem L298)
* ESP-01 mit ESP8266 "Dingens"
* Software von Asbelos https://github.com/Asbelos/CVReader
Das größte Problem war das ESP-"Dingens". Die bekommt man für wenig Geld und enthalten so ungefähr alles was man braucht damit man mit dem Arduino auch per WiFi kommunizieren kann. In der Theorie sollte das alles enthalten aber oft ist die Firmware die auf dem Dingens drauf ist alt und nicht mit der Dokumentation übereistimmend. Da muss man dann einen Flash-Adapter haben oder aus einem Arduino basteln und dann auch noch die richtigen Binaries im Netz finden und die richtige Beschwörungsformel zum flashen. Etwas einfacher sind Arduino-Mega die das ESP-Dingens schon integriert haben, da muss man sich zumindest nicht mit Kabeln rumschlagen.
Was noch zu tun ist: Also es braucht noch eine Art "Bauanleitung" oder "Rezept". Für Android, Enginedriver, Arduino, Motorshield und CVReader ist das eigentlich recht simpel, doch für das Dingens eine größere Herausforderung wenn man nicht Glück hat und da schon eine relativ neue Firmware drauf ist. Bei den ESP-01 die ich neulich gekauft habe war Firmware von 2016 drauf. Ja, die könnten (hätten können daten?) sich auch übers Netz vom Mutterschiff in China updaten aber das Mutterschiff von 2016 war schon wieder abgesegelt. Bei den Versionen von 2018 wurde ein anderes Mutterschiff angerufen und das war dann noch da. Von dort bekam man dann den gleichen Binärblob wie aus deren git. https://github.com/espressif/ESP8266_NONOS_SDK/tree/master/bin/at/512%2B512 So wenns funktioniert ist alles im grünen Bereich, wenn nicht braucht man fast einen Hexenmeister.
Ich bin jetzt nicht so der Reklamemensch mit eigenem Kanal auf der Tube aber wenn jemand was machen will und vielleicht sogar dabei aufschreiben wie es denn geht (ich bin da während dem Experimentieren nicht immer so gut) dann steh ich gerne mit Rat zur Verfügung.
Warnung oder Ermunterung: Ich hab das alles ganz ohne Windows gemacht, so erwartet von mir keine Tips über COM Driver für Win10.
Grüße,
Harald.
* Handy mit Android
* App Enginedriver
* Arduino Mega
* Motor Shield (hier das mit dem L298)
* ESP-01 mit ESP8266 "Dingens"
* Software von Asbelos https://github.com/Asbelos/CVReader
Das größte Problem war das ESP-"Dingens". Die bekommt man für wenig Geld und enthalten so ungefähr alles was man braucht damit man mit dem Arduino auch per WiFi kommunizieren kann. In der Theorie sollte das alles enthalten aber oft ist die Firmware die auf dem Dingens drauf ist alt und nicht mit der Dokumentation übereistimmend. Da muss man dann einen Flash-Adapter haben oder aus einem Arduino basteln und dann auch noch die richtigen Binaries im Netz finden und die richtige Beschwörungsformel zum flashen. Etwas einfacher sind Arduino-Mega die das ESP-Dingens schon integriert haben, da muss man sich zumindest nicht mit Kabeln rumschlagen.
Was noch zu tun ist: Also es braucht noch eine Art "Bauanleitung" oder "Rezept". Für Android, Enginedriver, Arduino, Motorshield und CVReader ist das eigentlich recht simpel, doch für das Dingens eine größere Herausforderung wenn man nicht Glück hat und da schon eine relativ neue Firmware drauf ist. Bei den ESP-01 die ich neulich gekauft habe war Firmware von 2016 drauf. Ja, die könnten (hätten können daten?) sich auch übers Netz vom Mutterschiff in China updaten aber das Mutterschiff von 2016 war schon wieder abgesegelt. Bei den Versionen von 2018 wurde ein anderes Mutterschiff angerufen und das war dann noch da. Von dort bekam man dann den gleichen Binärblob wie aus deren git. https://github.com/espressif/ESP8266_NONOS_SDK/tree/master/bin/at/512%2B512 So wenns funktioniert ist alles im grünen Bereich, wenn nicht braucht man fast einen Hexenmeister.
Ich bin jetzt nicht so der Reklamemensch mit eigenem Kanal auf der Tube aber wenn jemand was machen will und vielleicht sogar dabei aufschreiben wie es denn geht (ich bin da während dem Experimentieren nicht immer so gut) dann steh ich gerne mit Rat zur Verfügung.
Warnung oder Ermunterung: Ich hab das alles ganz ohne Windows gemacht, so erwartet von mir keine Tips über COM Driver für Win10.
Grüße,
Harald.
Man kann auch die Benutzeroberfläche ganz im Browser machen. Hier sendet der Browser direkt DCC++ Kommandos über USB (Experimental Web Platform features) an den Arduino:
https://www.youtube.com/watch?v=BkgsEOjxWaU
Bis jetzt noch nette Spielerei, aber vielleicht in Zukunft zum Programmieren...
Ich finde da andere Sachen mehr nützlich wie z.B.
https://www.youtube.com/watch?v=wW02EF3i3X8
aber das zeigt zumindest: Es geht voran.
Grüße,
Harald.
https://www.youtube.com/watch?v=BkgsEOjxWaU
Bis jetzt noch nette Spielerei, aber vielleicht in Zukunft zum Programmieren...
Ich finde da andere Sachen mehr nützlich wie z.B.
https://www.youtube.com/watch?v=wW02EF3i3X8
aber das zeigt zumindest: Es geht voran.
Grüße,
Harald.
Hmm, mit WebUSB hat sich Google was ganz tolles einfallen lassen. Da kann man ja nur darauf warten, bis angeschlossene USB-Devices gehackt und/oder gelesen werden. So Webcams sind bestimmt ganz lustig 
Oder Fotoapparate oder Speichermedien. Irgendwie werden sie schon DAUs dazu bekommen, die Freigaben zu erteilen. Während es vielleicht durchaus auch sinnvolle Anwendungsfällte geben könnte (wie vielleicht in dem Beispiel), halte ich diese Browser-Erweiterung für hochriskant.
Klaus
Oder Fotoapparate oder Speichermedien. Irgendwie werden sie schon DAUs dazu bekommen, die Freigaben zu erteilen. Während es vielleicht durchaus auch sinnvolle Anwendungsfällte geben könnte (wie vielleicht in dem Beispiel), halte ich diese Browser-Erweiterung für hochriskant.Klaus
Die Kamera und das Mic hat der Browser ja schon seit der letzten Videokonferenz
Aber ich mach da jetzt keine Diskussion auf über Accessmodelle und Rollen in diesem Thread, könnte ja gut sein wenn ich in meiner Rolle als Moba-Lokführer eine andere Benutzerrolle haben könnte als als Kunder meiner Bank.Wenn du den .zip runterlädst kannst ja zumindest durchgucken was exwebthrottle so macht. Extern greift es auf
Zitat
https://cdn.jsdelivr.net/npm/round-slider@1.6.1/dist/roundslider.min.css
https://code.jquery.com/jquery-3.2.1.js
https://code.jquery.com/ui/1.12.1/jquery-ui.js
https://cdn.jsdelivr.net/npm/round-slider@1.6.1/dist/roundslider.min.js
diese js zu. Sonst ist nicht viel drin (kann ja jeder gucken was Mani und Fred programmiert haben).
Ich brauch nicht so sehr einen Regler, aber eine Alternative zu JMRI DecoderPro im Browser wär recht nett.
Grüße,
Harald.
Hi Harald,
wie kompatibel ist DCC++-EX zu Sketchen für DCC++ ?
Gruß
Arne
wie kompatibel ist DCC++-EX zu Sketchen für DCC++ ?
Gruß
Arne
Auf welche Seite? Serie oder zum Motorshield? Oder bugkompatibel?
Erstmal verstehen alle die DCC++ Kommandos die z.B. JMRI oder andere Software ausgibt. Aber in Zukuft wird es da noch Erweiterungen geben müssen.
Es gibt DCC++ "Classic". Das wird nicht mehr weiter gepflegt.
Es gibt DCC++EX. Das ist die "Extended" Version die DCC++ Classic ersetzen soll. Ob das unter der Haube allerdings dann noch auf Classic basiert oder ob das dann auf dem Rewrite "Asbelos" basiert ist noch nicht ganz klar. Ich hab auch das Classic verbessert mach da aber nicht mehr groß weiter weil das Grundkozept von der Asbelosversion besser ist.
Was willst du genauer wissen?
Ob die neuen Sachen besser funktionieren? Ja, ich denke schon (vor allem mehr korrent nach Standard)
Ob es auf deiner HW funktioniert? - Wahrscheinlich - Was hast denn für HW?
Wenn du selber den Code modofiziert hast wird es wahrscheinlich Anpassungen brauchen.
Grüße,
Harald.
Erstmal verstehen alle die DCC++ Kommandos die z.B. JMRI oder andere Software ausgibt. Aber in Zukuft wird es da noch Erweiterungen geben müssen.
Es gibt DCC++ "Classic". Das wird nicht mehr weiter gepflegt.
Es gibt DCC++EX. Das ist die "Extended" Version die DCC++ Classic ersetzen soll. Ob das unter der Haube allerdings dann noch auf Classic basiert oder ob das dann auf dem Rewrite "Asbelos" basiert ist noch nicht ganz klar. Ich hab auch das Classic verbessert mach da aber nicht mehr groß weiter weil das Grundkozept von der Asbelosversion besser ist.
Was willst du genauer wissen?
Ob die neuen Sachen besser funktionieren? Ja, ich denke schon (vor allem mehr korrent nach Standard)
Ob es auf deiner HW funktioniert? - Wahrscheinlich - Was hast denn für HW?
Wenn du selber den Code modofiziert hast wird es wahrscheinlich Anpassungen brauchen.
Grüße,
Harald.
Hi,
mir geht es darum ob ich einfach die libaries tausche und dann neu complimiere oder ob ich alles neu machen muß.
Arduino Nano
L298
Gruß
Arne
mir geht es darum ob ich einfach die libaries tausche und dann neu complimiere oder ob ich alles neu machen muß.
Arduino Nano
L298
Gruß
Arne
@Harald:
Das hast Du, glaube ich, in den falschen Hals bekommen. Das war kein Vorwurf gegen Dich oder die Jungs, die das programmiert haben. Es ging mir allgemein um das Risikopotential des USB-Zugriffs aus dem Browser heraus.
Klaus
Das hast Du, glaube ich, in den falschen Hals bekommen. Das war kein Vorwurf gegen Dich oder die Jungs, die das programmiert haben. Es ging mir allgemein um das Risikopotential des USB-Zugriffs aus dem Browser heraus.
Klaus
@KMal: Nee, nix falscher Hals, alles im grünen Bereich, hab das nicht als Vorwurf ausgefasst. "Sandboxing" ist schwierig und wenns nicht funktioniet gefährlich.
@4-4-0: Das Ziel ist es dass es auf dem Uno genauso wie früher funktioniert, also Sketch in der Arduino IDE kompilieren, reinladen und fertig. Es gibt sogar zwei die arbeiten an einem Installer. Ob das aber außer für Windows was wird (da braucht man ja sowas höre ich) weiss ich icht. Mit dem neuen Code kann man sogar die Pins besser anpassen als früher wo man die Jumper Kabel setzten musste. Da es auf dem Uno läuft sollte es auch auf dem Nano gehen. Ob das allerdings gerade jetzt jemand probiert hat weiss ich nicht. Der L298 ist unkritisch. Auch sind in Zukunft mehr als 12 Loks möglich und die Funktionen sind auch endlich im Refreshloop. Also mal probieren, der Code der am meisten kann, den findet man da: https://github.com/Asbelos/CVReader
Grüße,
Harald.
@4-4-0: Das Ziel ist es dass es auf dem Uno genauso wie früher funktioniert, also Sketch in der Arduino IDE kompilieren, reinladen und fertig. Es gibt sogar zwei die arbeiten an einem Installer. Ob das aber außer für Windows was wird (da braucht man ja sowas höre ich) weiss ich icht. Mit dem neuen Code kann man sogar die Pins besser anpassen als früher wo man die Jumper Kabel setzten musste. Da es auf dem Uno läuft sollte es auch auf dem Nano gehen. Ob das allerdings gerade jetzt jemand probiert hat weiss ich nicht. Der L298 ist unkritisch. Auch sind in Zukunft mehr als 12 Loks möglich und die Funktionen sind auch endlich im Refreshloop. Also mal probieren, der Code der am meisten kann, den findet man da: https://github.com/Asbelos/CVReader
Grüße,
Harald.
soldier333 - 19.08.20 07:04
@Harald,
ist dies neue DCC++EX oder Asbelos auch schon in Rocrail verwendbar?
Grüße
Peter
ist dies neue DCC++EX oder Asbelos auch schon in Rocrail verwendbar?
Grüße
Peter
@haba,
danke für die Info ich Versuchs dann mal.
Gruß
Arne
danke für die Info ich Versuchs dann mal.
Gruß
Arne
Wie meinen "in"? DCC++ ist ja nicht in RocRail "drin".
Doch:
* Die Kommandos auf DCC++ Ebene waren nicht 100% exakt definiert, sollten sich aber nicht geändert haben sondern
es sind nur neue dazugekommen. So die Antwort auf "backwards compat?" ist: Sollte schon.
* Ich mach kein RocRail wegen Lizenz und Einstellung des Entwicklers dazu, so RocRail
Support musst du woanders finden. Inwieweit DCC++ mit RocRail geht: Weiss nicht.
* JMRI ist sozusagen "supported" von der Community die ich kenne, so wenn Rocrail sich so verhällt wie JMRI dann gehts.
Grüße,
Harald.
Moin,
Ich habe mir in den Kopf gesetzt, eine kleine (transportable), aber komfortable Möglichkeit zu schaffen, die Decoder zu programmieren und zu verwalten.
Dabei habe ich jetzt auch DCC++ begonnen zu probieren.
Es ist etwas schade, dass es inzwischen mehrere Forks gibt, von denen ich die Unterschiede nicht ergründen konnte.
Bei DCC++ EX gibt es inzwischen eine Website (ist auch nur halbfertig, aber immerhin)
https://dcc-ex.com/
Dort im Angebot gibt es auch Installer, die die Software ohne Arduino IDE usw. aufspielen kann (können soll, habe ich nicht ausprobiert)
Ich habe mir das angebotene aktuelle Release als *.zip heruntergeladen.
Da ich die Arduino IDE sowieso eingerichtet habe, ist das für mich der einfachste Weg.
Überraschend: Das entpackte *.zip konnte ohne irgendwelche Anpassungen für meinen UNO kompiliert werden.
Meine Hardware: ein UNO-Clone aus der Grabbelkiste und ein Motorshield-Clone, welches es auch für ca 5 EUR in China gibt, aber ich habe es wegen der Geschwindigkeit bei Amazon bestellt: https://amzn.to/3348xIU (war das Letzte )
Zusätzlich habe ich mir einen Raspi 3B+ mit 10'' Touchscreen fertig gemacht und dort JMRI aufgespielt.
Das für mich als unkomplizierte Mobile Lösung, JMRI fkt natürlich auf jedem PC und Mac
Für meinen ersten rudimentären Test hatte ich natürlich die Kabelage an den Anschluss für das Hauptgleis angeschlossen .... UND ... der Versuch den Decoder in der MAK (DH10C) auszulesen ist ersteinmal grandios gescheitert.
Das lag an verschiedenen Dingen: Zum Einen, dass die Programmierung scheinbar nur am PGM Anschluss (es gibt eine Option in JMRI Hauptgleis oder Programmiergleis zu nutzen, dies hatte aber keine Wirkung) funktioniert, zum Anderen - das muss man wissen - muss in JMRI die Spannung eingeschaltet werden. (Dies ist bei meiner bisherigen Hardware nicht notwendig, bzw wird die Gleisspannung erstmal abgeschaltet)
Ich finde auch diese Kombi eine recht schicke Lösung, die aber vor allem am Anfang Hilfe bedarf.
Wer keine fertige Hardware zum Gegencheck hat, tut sich bei der Fehlersuche bei der Inbetriebnahme schwer.
Ich will demnächst auch die Variante mit dem ESP8266 als WiFi am Arduino testen, da habe ich noch nicht so recht verstanden, was dort für eine Firmware drauf sein muss, dass es funktioniert.
Zumal der ESP selber recht viel "Bums" hat um als eigenständiger Microprozessor Aufgaben zu übernehmen (bei Mir zB ein Feinstaubsensor, seit knapp 3 Jahren)
Mal sehen, JMRI scheint eher in den USA eine Fangemeinde zu haben. Die D&H Templates sind nicht besonders aktuell.
Wenn ich alles am Laufen habe, schaue ich da mal nach, ist aber - wie bei allen anderen auch - eine Zeitfrage.
Viele Grüße, Franzi
Die von vbh zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login
Ich habe mir in den Kopf gesetzt, eine kleine (transportable), aber komfortable Möglichkeit zu schaffen, die Decoder zu programmieren und zu verwalten.
Dabei habe ich jetzt auch DCC++ begonnen zu probieren.
Es ist etwas schade, dass es inzwischen mehrere Forks gibt, von denen ich die Unterschiede nicht ergründen konnte.
Bei DCC++ EX gibt es inzwischen eine Website (ist auch nur halbfertig, aber immerhin)
https://dcc-ex.com/
Dort im Angebot gibt es auch Installer, die die Software ohne Arduino IDE usw. aufspielen kann (können soll, habe ich nicht ausprobiert)
Ich habe mir das angebotene aktuelle Release als *.zip heruntergeladen.
Da ich die Arduino IDE sowieso eingerichtet habe, ist das für mich der einfachste Weg.
Überraschend: Das entpackte *.zip konnte ohne irgendwelche Anpassungen für meinen UNO kompiliert werden.
Meine Hardware: ein UNO-Clone aus der Grabbelkiste und ein Motorshield-Clone, welches es auch für ca 5 EUR in China gibt, aber ich habe es wegen der Geschwindigkeit bei Amazon bestellt: https://amzn.to/3348xIU (war das Letzte
)Zusätzlich habe ich mir einen Raspi 3B+ mit 10'' Touchscreen fertig gemacht und dort JMRI aufgespielt.
Das für mich als unkomplizierte Mobile Lösung, JMRI fkt natürlich auf jedem PC und Mac
Für meinen ersten rudimentären Test hatte ich natürlich die Kabelage an den Anschluss für das Hauptgleis angeschlossen .... UND ... der Versuch den Decoder in der MAK (DH10C) auszulesen ist ersteinmal grandios gescheitert.
Das lag an verschiedenen Dingen: Zum Einen, dass die Programmierung scheinbar nur am PGM Anschluss (es gibt eine Option in JMRI Hauptgleis oder Programmiergleis zu nutzen, dies hatte aber keine Wirkung) funktioniert, zum Anderen - das muss man wissen - muss in JMRI die Spannung eingeschaltet werden. (Dies ist bei meiner bisherigen Hardware nicht notwendig, bzw wird die Gleisspannung erstmal abgeschaltet)
Ich finde auch diese Kombi eine recht schicke Lösung, die aber vor allem am Anfang Hilfe bedarf.
Wer keine fertige Hardware zum Gegencheck hat, tut sich bei der Fehlersuche bei der Inbetriebnahme schwer.
Ich will demnächst auch die Variante mit dem ESP8266 als WiFi am Arduino testen, da habe ich noch nicht so recht verstanden, was dort für eine Firmware drauf sein muss, dass es funktioniert.
Zumal der ESP selber recht viel "Bums" hat um als eigenständiger Microprozessor Aufgaben zu übernehmen (bei Mir zB ein Feinstaubsensor, seit knapp 3 Jahren)
Mal sehen, JMRI scheint eher in den USA eine Fangemeinde zu haben. Die D&H Templates sind nicht besonders aktuell.
Wenn ich alles am Laufen habe, schaue ich da mal nach, ist aber - wie bei allen anderen auch - eine Zeitfrage.
Viele Grüße, Franzi
Die von vbh zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login
Beitrag editiert am 06. 09. 2020 17:51.
Ja, es gibt z.Z noch einige Forks aber die Leute reden miteinander. Alle sind im Discord Chat.
Es wird auf einen Code rauslaufen, der dann wahrscheinlich DCC-EX heissen wird. Aber das muss sich noch etwas setzen. Jetzt gerade diese Woche würde ich aus Stabilitätsgründen den da https://github.com/Asbelos/CVReader empfehlen bis das Release von DCC-EX aus der Tür ist.
Empfehle ich nur für Leute die es nicht schaffen selber das IDE zu installieren und auf den Upload Button zu drücken, also nicht für Dich
Da ist dann aber wahrscheinlich der Uno überfordert weil der ESP will einen eigenen UART für seine Serieverbindung haben. Der Uno hat nur einen und über den geht ja USB-Serial. Also lieber gleich einen Megaclone für EUR 12, da ist dann das RAM auch nicht so eng. Wobei wenn du JMRI am laufen hast kannst du ja WiFi da anbinden und USB nehmen. ESP am Arduino ist eigentlich nur um mal schnell mit EngineDriver ne Lok fahren zu können alternativ wenn USB zu umständlich oder zu weit weg vom Computer für USB wäre.
Beim Aufspielen von ESP Firmware kenn ich mich leider auch schon mehr aus als dass mir lieb ist. Es sollte halt eine relativ neue AT-Kommando Firmware drauf. Ich wollte mir auch noch mehr mit dem ESP basteln, Temperatur im Aquarium über MQTT z.B.
Unterstützung vom PoM wird überprüft. Bei geeigneter HW sollte mit DCC-EX dann in der Zukuft sogar PoM+RailCom möglich sein.
Finde ich auch immer lästig und mein eigener Clone macht das automatisch. Mal sehen ob ich auch noch einen Patch hinbekomme
der das vor dem Release noch fixt.
Ja, ich muss zugeben, hab auch schon lang keine Template update mehr eingeschickt und bei D&H hab ich auch nicht so den Durchblick. Wenn die Hersteller das selber machen würden, dann wäre das für mich ein _Mehrwert_ um solche Decoder zu kaufen weil dann bräuchte ich kaum mehr in der Anleitung nachsehen.
<Propaganda>
Hallo Hersteller, lest ihr mit? Macht ihr mit? Oder kocht ihr lieber euer eigenes Süppchen (*). Eine proprietäre Software mit den "eigenen" Decoderbeschreibungen ist für mich nichts wert weil erstens funktioniert das dann nur für einen Bruchteil meiner Decoder (ich hab so viele verschiedne Decoder) und zweitens müsste ich dann wahrscheinlich Windows oder MacOS nehmen.
</Propaganda>
EDIT: Zu Motorshields: Da gibts viel Mist. Die DeekRobot Motorshields haben wie meines auch leider die Kühltabs an den Schmalseiten nirgendwo angelötet. So Dauerstrom 2A ist nix. Von Vellemann gibts nen Clon der hat zumindest auf dem Bild Lötpukte an der richtigen Stelle.
NOCH EIN EDIT: Das Velleman ist auch Mist, da kein Stromfühler drauf
Siehe https://www.1zu160.net/scripte/forum/forum_show.php?id=1199383&ins#aw29
Grüße,
Harald.
(*) Es gibt kein Hinderniss so eine Template zu verfassen und sie unter der GPL JMRI zu geben und sie gleichzeitig unter einer anderen Lizenz in der eigenen Software zu verwenden. Wenn man sie selber verfasst hat kann man welche multiplen Lizenzen draufpappen die man möchte.
Es wird auf einen Code rauslaufen, der dann wahrscheinlich DCC-EX heissen wird. Aber das muss sich noch etwas setzen. Jetzt gerade diese Woche würde ich aus Stabilitätsgründen den da https://github.com/Asbelos/CVReader empfehlen bis das Release von DCC-EX aus der Tür ist.
Empfehle ich nur für Leute die es nicht schaffen selber das IDE zu installieren und auf den Upload Button zu drücken, also nicht für Dich
Zitat - Antwort-Nr.: | Name:
Ich will demnächst auch die Variante mit dem ESP8266 als WiFi am Arduino testen,
Da ist dann aber wahrscheinlich der Uno überfordert weil der ESP will einen eigenen UART für seine Serieverbindung haben. Der Uno hat nur einen und über den geht ja USB-Serial. Also lieber gleich einen Megaclone für EUR 12, da ist dann das RAM auch nicht so eng. Wobei wenn du JMRI am laufen hast kannst du ja WiFi da anbinden und USB nehmen. ESP am Arduino ist eigentlich nur um mal schnell mit EngineDriver ne Lok fahren zu können alternativ wenn USB zu umständlich oder zu weit weg vom Computer für USB wäre.
Beim Aufspielen von ESP Firmware kenn ich mich leider auch schon mehr aus als dass mir lieb ist. Es sollte halt eine relativ neue AT-Kommando Firmware drauf. Ich wollte mir auch noch mehr mit dem ESP basteln, Temperatur im Aquarium über MQTT z.B.
Unterstützung vom PoM wird überprüft. Bei geeigneter HW sollte mit DCC-EX dann in der Zukuft sogar PoM+RailCom möglich sein.
Finde ich auch immer lästig und mein eigener Clone macht das automatisch. Mal sehen ob ich auch noch einen Patch hinbekomme
der das vor dem Release noch fixt.
Ja, ich muss zugeben, hab auch schon lang keine Template update mehr eingeschickt und bei D&H hab ich auch nicht so den Durchblick. Wenn die Hersteller das selber machen würden, dann wäre das für mich ein _Mehrwert_ um solche Decoder zu kaufen weil dann bräuchte ich kaum mehr in der Anleitung nachsehen.
<Propaganda>
Hallo Hersteller, lest ihr mit? Macht ihr mit? Oder kocht ihr lieber euer eigenes Süppchen (*). Eine proprietäre Software mit den "eigenen" Decoderbeschreibungen ist für mich nichts wert weil erstens funktioniert das dann nur für einen Bruchteil meiner Decoder (ich hab so viele verschiedne Decoder) und zweitens müsste ich dann wahrscheinlich Windows oder MacOS nehmen.
</Propaganda>
EDIT: Zu Motorshields: Da gibts viel Mist. Die DeekRobot Motorshields haben wie meines auch leider die Kühltabs an den Schmalseiten nirgendwo angelötet. So Dauerstrom 2A ist nix. Von Vellemann gibts nen Clon der hat zumindest auf dem Bild Lötpukte an der richtigen Stelle.
NOCH EIN EDIT: Das Velleman ist auch Mist, da kein Stromfühler drauf
Siehe https://www.1zu160.net/scripte/forum/forum_show.php?id=1199383&ins#aw29
Grüße,
Harald.
(*) Es gibt kein Hinderniss so eine Template zu verfassen und sie unter der GPL JMRI zu geben und sie gleichzeitig unter einer anderen Lizenz in der eigenen Software zu verwenden. Wenn man sie selber verfasst hat kann man welche multiplen Lizenzen draufpappen die man möchte.
Beitrag editiert am 05. 11. 2020 09:59.
Hallo Harald,
Danke für Deine Antwort
Zum WiFi: Danke für den Hnweis . Ja da ist es wirklich sinnvoller den Mega zu benutzen, klar kann die Sotware das emulieren, aber da bleibt weniger Rechenzeit für den "Hauptzweck" übrig, vor allem Dinge wie Interrupts muss man nicht sinnlos verbraten.
Die Asbelos Version schaue ich mir auf jeden Fall noch an.
Viele Grüße,
Franzi
Danke für Deine Antwort
Zum WiFi: Danke für den Hnweis . Ja da ist es wirklich sinnvoller den Mega zu benutzen, klar kann die Sotware das emulieren, aber da bleibt weniger Rechenzeit für den "Hauptzweck" übrig, vor allem Dinge wie Interrupts muss man nicht sinnlos verbraten.
Die Asbelos Version schaue ich mir auf jeden Fall noch an.
Viele Grüße,
Franzi
Nicht nur das, wenn dir ein Interrupt zur falschen Zeit zuschlägt dann ist entweder das DCC-Signal dahin oder das Zeichen das über Serial reinkommen soll.
Ich hab die autopower Branch selber noch nicht getestet, aber da sollte von mir ein Auto-Power-on fürs Programmiergleis implementiert sein auch wenn man es abgeschaltet hat.
"It compiles -> It ships"
Grüße,
Harald.
PS: Jetzt, 2 commits später sollte es auch funktionieren, zumindest hab ich es jetzt bei mir erfolgreich getestet.
Beitrag editiert am 08. 09. 2020 22:32.
Hallo Harald,
Ich habe das Repo nur geholt und mal versucht zu kompilieren.
Es fehlt der Hinweis, dass die Bibliothek "DIO2" in den Arduino Libraries installiert sein muss.
Danach ließ sich alles kompilieren. Getestet habe ich noch nicht, ich warte noch auf das WiFi Shield - ich habe einfach keine Lust, mir wegen ein paar Tagen Warten ein Shield selber zusammenzulöten
Viele Grüße, Franzi
Ich habe das Repo nur geholt und mal versucht zu kompilieren.
Es fehlt der Hinweis, dass die Bibliothek "DIO2" in den Arduino Libraries installiert sein muss.
Danach ließ sich alles kompilieren. Getestet habe ich noch nicht, ich warte noch auf das WiFi Shield - ich habe einfach keine Lust, mir wegen ein paar Tagen Warten ein Shield selber zusammenzulöten
Viele Grüße, Franzi
Moin,
Nun wollte ich es doch Wissen und habe einen Arduino Mega ausgegraben.
Der erste Versuch aus https://github.com/Asbelos/CVReader war mit dem "Standard" Sketch (Beispiele: CVReader_basic.ino)
Kurz dazu: Man muss eben erahnen , wie man die mitgelieferten Beispiele benutzt:
Die jeweilige *.ino in den Hauptordner anstelle der CVReader.ino kopieren und nun damit die Arduino IDE starten
Die Beispiele müssen im Hauptordner entsprechend immer in "CVReader.ino" umbenannt werden.
Zunächst die Basic Variante:
Etwas irritiert hat mich, dass es hier im seriellen Monitor keinerlei Ausgabe gibt, dass die Version gestartet wurde.
In Verbindung mit JMRI hat das automatische Ein/Ausschalten der Spannung am Programmiergleis geklappt
Da nun die bestellten WiFi Shields aus China noch auf sich warten lassen, hab ich mir aus einem vorhandenen ESP Modul "schnell" eins selber zusammengelötet:
Dazu muss man wissen: Das Einzige, was in diesem Zusammenhang benötigt wird, ist der serielle Port des ESP Moduls (RX/TX)
Diese beiden Anschlüsse müssen gekreuzt auf dem Arduino angeschlossen werden.
Hier muss man unbedingt eine Pegelanpassung vornehmen: Zwischen RX am ESP und TX am Arduino ein Widerstand von 1K, vom RX am ESP nach GND ein Widerstand von 2K
TX am ESP kann direkt mit RX am Arduino verbunden werden.
Hmmm ... und jetzt? Der Mega besitzt 3 serielle Ports. Nur aus dem Source konnte ich erahnen, dass in dem Fall ohne Änderungen der Port 1 genutzt wird (RX Pin19, TX Pin18)
Das ESP Modul niemals an 5V anschließen! Diverse DEV- Boards haben 5V Anschlüsse mit Spannungsregler, die nackten Module aber nicht.
Damit kamen dann endlich Debug Ausgaben, dass versucht wird, WiFi zu initialisieren.
Um zu erreichen, dass sich das Modul mit dem heimischen WLAN verbindet, muss man etwas weiter unten im Source noch die eigenen Zugangsdaten eintragen, bevor man alles kompiliert und auf den Arduino lädt:
Damit hat es dann geklappt, dass sich die (Android) APP "Engine Driver Throttle" mit dem DCC++ verbinden konnte.
Hierzu muss man die IP Adresse des DCC++ Devices ermitteln:
Entweder im Router nachsehen, oder nach dem erfolgreichen Initialisieren im seriellen Monitor der Arduino IDE.
Ja, so sieht das alles schon gut aus.
Danke an Alle für die Arbeit bis hier
Viele Grüße, Franzi
Nun wollte ich es doch Wissen und habe einen Arduino Mega ausgegraben.
Der erste Versuch aus https://github.com/Asbelos/CVReader war mit dem "Standard" Sketch (Beispiele: CVReader_basic.ino)
Kurz dazu: Man muss eben erahnen
, wie man die mitgelieferten Beispiele benutzt:Die jeweilige *.ino in den Hauptordner anstelle der CVReader.ino kopieren und nun damit die Arduino IDE starten
Die Beispiele müssen im Hauptordner entsprechend immer in "CVReader.ino" umbenannt werden.
Zunächst die Basic Variante:
Etwas irritiert hat mich, dass es hier im seriellen Monitor keinerlei Ausgabe gibt, dass die Version gestartet wurde.
In Verbindung mit JMRI hat das automatische Ein/Ausschalten der Spannung am Programmiergleis geklappt
Da nun die bestellten WiFi Shields aus China noch auf sich warten lassen, hab ich mir aus einem vorhandenen ESP Modul "schnell" eins selber zusammengelötet:
Dazu muss man wissen: Das Einzige, was in diesem Zusammenhang benötigt wird, ist der serielle Port des ESP Moduls (RX/TX)
Diese beiden Anschlüsse müssen gekreuzt auf dem Arduino angeschlossen werden.
Hier muss man unbedingt eine Pegelanpassung vornehmen: Zwischen RX am ESP und TX am Arduino ein Widerstand von 1K, vom RX am ESP nach GND ein Widerstand von 2K
TX am ESP kann direkt mit RX am Arduino verbunden werden.
Hmmm ... und jetzt? Der Mega besitzt 3 serielle Ports. Nur aus dem Source konnte ich erahnen, dass in dem Fall ohne Änderungen der Port 1 genutzt wird (RX Pin19, TX Pin18)
Das ESP Modul niemals an 5V anschließen! Diverse DEV- Boards haben 5V Anschlüsse mit Spannungsregler, die nackten Module aber nicht.
Damit kamen dann endlich Debug Ausgaben, dass versucht wird, WiFi zu initialisieren.
Um zu erreichen, dass sich das Modul mit dem heimischen WLAN verbindet, muss man etwas weiter unten im Source noch die eigenen Zugangsdaten eintragen, bevor man alles kompiliert und auf den Arduino lädt:
Zitat
Serial1.begin(115200); // BAUD rate of your Wifi chip/shield
WifiInterface::setup(Serial1,
F("<<eigene SSID>>"), // Router name
F("<<eigenes Passwort>>"), // Router password
Damit hat es dann geklappt, dass sich die (Android) APP "Engine Driver Throttle" mit dem DCC++ verbinden konnte.
Hierzu muss man die IP Adresse des DCC++ Devices ermitteln:
Entweder im Router nachsehen, oder nach dem erfolgreichen Initialisieren im seriellen Monitor der Arduino IDE.
Ja, so sieht das alles schon gut aus.
Danke an Alle für die Arbeit bis hier
Viele Grüße, Franzi
Zitat - Antwort-Nr.: | Name:
In Verbindung mit JMRI hat das automatische Ein/Ausschalten der Spannung am Programmiergleis geklappt
Na also. Wobei man JMRI noch beibringen muss wie man in Zukunft dann Haupt- und Prorammiergleis seperat an- und ausschaltet.
Zitat - Antwort-Nr.: | Name:
Etwas irritiert hat mich, dass es hier im seriellen Monitor keinerlei Ausgabe gibt, dass die Version gestartet wurde.
Ok, notiert.
Zitat - Antwort-Nr.: | Name:
Hier muss man unbedingt eine Pegelanpassung vornehmen: Zwischen RX am ESP und TX am Arduino ein Widerstand von 1K, vom RX am ESP nach GND ein Widerstand von 2K
Hab ich bis jetzt nicht gemacht und es hat noch nicht geraucht.
Ja, dann wäre es dahin. Ich habe es bis jetzt am 3.3V vom Mega will mir aber noch eine eigene Versorgung basteln weil die Dinger ziehen kurzzeitig recht viel Strom.
Zitat - Antwort-Nr.: | Name:
Um zu erreichen, dass sich das Modul mit dem heimischen WLAN verbindet, muss man etwas weiter unten im Source noch die eigenen Zugangsdaten eintragen
Es gibt auch noch ne Variante. Man kann über Serie mit dem <+> Kommando direkt mit dem ESP reden:
Also
<+CWJAP="ESSID","PASSWORD">
(cutpaste in die Serielle Verbindung) und das ESP behällt das dann auch über einen Reset und CWReader setzt es nicht neu wenn eine Verbindung da ist.
Zitat - Antwort-Nr.: | Name:
Kurz dazu: Man muss eben erahnen , wie man die mitgelieferten Beispiele benutzt
Ist noch kein Release aber schön dass soweit schon mal funktioniert.
Grüße,
Harald.
Hallo Harald,
Danke für deine Antworten
Ich habe ein paar Tage mit Forschungsarbeiten verbracht ... die Chinesen versenden im Moment im Eiltempo ... 10 Tage hat es gedauert, bis alles hier war:
China Hardware:
(die Angebote werden vermutlich nicht Lange existieren, daher noch der Suchbegriff dazu)
WeMOS Mega + WiFi R3 ATmega2560 + ESP8266 USB-TTL For Mega NodeMCU
11,29 EUR + 1,18 EUR Versand
https://www.ebay.de/itm/WeMOS-Mega-WiFi-R3-ATme...p2060353.m2749.l2649
L298P Shield R3 DC Motor Driver Module 2A H-Bridge 2 way For Arduino UNO 2560
5,15 EUR + 1,35 EUR Versand
https://www.ebay.de/itm/L298P-Shield-R3-DC-Moto...p2060353.m2749.l2649
Hardware Preis: 18,97 EUR
Das WiFi Board funktioniert nach etwas Recherche sehr gut.
Bei Bedarf stelle ich eine Anleitung ein, wie die Jumper wann gesetzt werden müssen.
Es ist aber notwendig, den Serial-Port für den ESP auf "3" zu ändern, es gibt nur die Option 0 oder 3, 0 macht keinen Sinn ..
Gibt es denn zum Asbelios Projekt irgendwo eine Diskussion (nicht das ich schon gesucht habe und nichts gefunden habe)?
Ich komme im Moment nicht weiter, ich habe aus allen möglichen Anleitungen einen eigenen Throttle gebastelt
Merkwürdigerweise wird bei all diesen Projekten nicht einmal der Status der Gleisspannung geprüft, es wird einfach beim Start des Reglers das Gleis abgeschaltet ...
Ebenso wird nicht geprüft, ob irgendeine andere Steuerung die gewünschten Adressen schon benutzt, es wird einfach ohne Rückmeldung "abgeschossen" das mag funktionieren, finde ich aber nicht so unbedingt toll
Da komme ich zu meinen Fragen:
- ist es denn irgendwie vorgesehen, dass man die vorhandenen Steuerungen auslesen kann?
Das Einzige, was ich gefunden habe ist <s>, das gibt im Moment aber nur <p0|1> und den Softwarestand zurück
Da ich ja hier die Gleis und Programmierspannung getrennt einstellen kann, wäre es vielleicht sinnvoll, diese auch
hier getrennt zurückzugeben? <p 0|1 main|prog>
- und eine Frage zu deiner Hilfe von Oben um die WLAN Daten einzutragen:
im Source wird folgendes eingetragen:
laut der Doku bewirkt CWJAP_CUR aber "Configuration Not Saved in the Flash"
nachdem was ich gefunden habe, wäre CWJAP_DEF der Befehl, um die Daten dauerhaft zu speichern?
Viele Grüße, Franzi
Danke für deine Antworten
Ich habe ein paar Tage mit Forschungsarbeiten verbracht ... die Chinesen versenden im Moment im Eiltempo ... 10 Tage hat es gedauert, bis alles hier war:
China Hardware:
(die Angebote werden vermutlich nicht Lange existieren, daher noch der Suchbegriff dazu)
WeMOS Mega + WiFi R3 ATmega2560 + ESP8266 USB-TTL For Mega NodeMCU
11,29 EUR + 1,18 EUR Versand
https://www.ebay.de/itm/WeMOS-Mega-WiFi-R3-ATme...p2060353.m2749.l2649
L298P Shield R3 DC Motor Driver Module 2A H-Bridge 2 way For Arduino UNO 2560
5,15 EUR + 1,35 EUR Versand
https://www.ebay.de/itm/L298P-Shield-R3-DC-Moto...p2060353.m2749.l2649
Hardware Preis: 18,97 EUR
Das WiFi Board funktioniert nach etwas Recherche sehr gut.
Bei Bedarf stelle ich eine Anleitung ein, wie die Jumper wann gesetzt werden müssen.
Es ist aber notwendig, den Serial-Port für den ESP auf "3" zu ändern, es gibt nur die Option 0 oder 3, 0 macht keinen Sinn ..
Gibt es denn zum Asbelios Projekt irgendwo eine Diskussion (nicht das ich schon gesucht habe und nichts gefunden habe)?
Ich komme im Moment nicht weiter, ich habe aus allen möglichen Anleitungen einen eigenen Throttle gebastelt
Merkwürdigerweise wird bei all diesen Projekten nicht einmal der Status der Gleisspannung geprüft, es wird einfach beim Start des Reglers das Gleis abgeschaltet ...
Ebenso wird nicht geprüft, ob irgendeine andere Steuerung die gewünschten Adressen schon benutzt, es wird einfach ohne Rückmeldung "abgeschossen" das mag funktionieren, finde ich aber nicht so unbedingt toll
Da komme ich zu meinen Fragen:
- ist es denn irgendwie vorgesehen, dass man die vorhandenen Steuerungen auslesen kann?
Das Einzige, was ich gefunden habe ist <s>, das gibt im Moment aber nur <p0|1> und den Softwarestand zurück
Da ich ja hier die Gleis und Programmierspannung getrennt einstellen kann, wäre es vielleicht sinnvoll, diese auch
hier getrennt zurückzugeben? <p 0|1 main|prog>
- und eine Frage zu deiner Hilfe von Oben um die WLAN Daten einzutragen:
im Source wird folgendes eingetragen:
Zitat
StringFormatter::send(wifiStream, F("AT+CWJAP_CUR="%S","%S"rn"), SSid, password);
laut der Doku bewirkt CWJAP_CUR aber "Configuration Not Saved in the Flash"
nachdem was ich gefunden habe, wäre CWJAP_DEF der Befehl, um die Daten dauerhaft zu speichern?
Viele Grüße, Franzi
Alles wird auf Discord diskutriert. Frag mich nicht warum gerade Discord. IRC auf Stereoiden. Ist halt so geworden. https://discord.gg/y2sB4Fp
Zitat - Antwort-Nr.: | Name:
Ich komme im Moment nicht weiter, ich habe aus allen möglichen Anleitungen einen eigenen Throttle gebastelt
EngineDriver fuzt "out of the box" direkt oder via JMRI.
Zitat - Antwort-Nr.: | Name:
ist es denn irgendwie vorgesehen, dass man die vorhandenen Steuerungen auslesen kann?
Ja, also Verbesserungen zum DCC++ Protokoll sind angedacht, werden auch gemacht aber vorsichtig dass man z.B. auch mit älteren JMRI kompatibel bleibt.
Aber wenn man mit EngineDriver sich direkt verbindet dann ist es das EngineDriver Protokoll das verarbeitet wird und nicht das DCC++ Protokoll.
Zitat - Antwort-Nr.: | Name:
laut der Doku bewirkt CWJAP_CUR aber "Configuration Not Saved in the Flash"
Ja. Wenn es in der Arduino-firmware drin steht dann macht die das ja dann bei jedem Start des Arduinos und
es braucht nicht im ESP flash zu landen. Wenn man das aber will dann CWJAP_DEF.
Ältere ESP Firmwares haben CWJAP das wie CWJAP_DEF funktioniert, neuere haben CWJAP_CUR und CWJAP_DEF.
Man kann auch über Serial direkt ein <+CWJAP_DEF="ESSID","PASSWORD"> machen wenn man im Code nicht sein Password reinschreiben will, dann landet es nur im ESP flash (beim CVReader geht das). Beim Start sollte CWReader begreifen dass Netz schon da ist und nicht neu machen.
Fährst du den ESP als eigenen AP oder im Heim-WiFi? Wir brauchen noch mehr Erfahrungsberiche wie alles angewendet wird was wir uns so ausdenken.
Grüße,
Harald.
Hallo,
Dankeschön, da habe ich ja noch zu lesen).png)
Ich bin mir da noch nicht sicher, meine Überlegung dazu:
Ich nehme dafür einen kleinen mobilen Router, den man bei Bedarf in ein beliebiges Netz als Bridge hängen kann.
sowas z.B:
https://www.amazon.de/gp/product/B073TSK26W/ref...49PJKO73YV&psc=1
Der mobile Router verwaltet das MoBa Netzwerk, es ist damit nicht notwendig, die gesamte Gerätschaft andauernd umzukonfigurieren.
Ich habe zuerst den Raspi als Bridge/AccessPoint konfiguriert, aber wenn sich die Anforderung ändert, ist es immer ein erheblicher Aufwand, die Config anzupassen.
Was ich noch nicht verstanden habe: kann ich zu dem WiFi noch ein Ethernetshield am Mega betreiben?
Das wäre ein Backup, wenn mal das mobile Netzwerk nicht geht, aber ein "normales" Netz vorhanden ist
Viele Grüße, Franzi
Dankeschön, da habe ich ja noch zu lesen
Zitat - Antwort-Nr.: 96 | Name: haba schrieb am 16.09.20 13:03
Fährst du den ESP als eigenen AP oder im Heim-WiFi? Wir brauchen noch mehr Erfahrungsberiche wie alles angewendet wird was wir uns so ausdenken.
Ich bin mir da noch nicht sicher, meine Überlegung dazu:
Ich nehme dafür einen kleinen mobilen Router, den man bei Bedarf in ein beliebiges Netz als Bridge hängen kann.
sowas z.B:
https://www.amazon.de/gp/product/B073TSK26W/ref...49PJKO73YV&psc=1
Der mobile Router verwaltet das MoBa Netzwerk, es ist damit nicht notwendig, die gesamte Gerätschaft andauernd umzukonfigurieren.
Ich habe zuerst den Raspi als Bridge/AccessPoint konfiguriert, aber wenn sich die Anforderung ändert, ist es immer ein erheblicher Aufwand, die Config anzupassen.
Was ich noch nicht verstanden habe: kann ich zu dem WiFi noch ein Ethernetshield am Mega betreiben?
Das wäre ein Backup, wenn mal das mobile Netzwerk nicht geht, aber ein "normales" Netz vorhanden ist
Viele Grüße, Franzi
Das ist ja ein cooles kleines Ding mit OpenWRT, sehr sympatisch.
Da das Ethernetshield anders mit dem Arduino kommuniziert wie das ESP-Dingens muss man dafür auch extra wieder neuen Code schreiben
Aber ich glaube da arbeitet auch jemand dran
Grüße,
Harald.
Da das Ethernetshield anders mit dem Arduino kommuniziert wie das ESP-Dingens muss man dafür auch extra wieder neuen Code schreiben
Aber ich glaube da arbeitet auch jemand dran
Grüße,
Harald.
Es gibt ein neues Video: https://www.youtube.com/watch?v=gyZQB2e_7_g
DCC-EX Release geplant nächsten Monat.
Grüße,
Harald.
DCC-EX Release geplant nächsten Monat.
Grüße,
Harald.
Jetzt wären Betatester für das DCC-EX Release ganz praktisch.
Über die benötigte Hardware https://dcc-ex.com/start/diy-starter-kit/
Der Installer will glaube ich noch nicht so ganz, so danach holt man
sich den Code von github (git clone oder als Zipfile)
https://github.com/DCC-EX/CommandStation-EX/
und drückt das dann in den Arduino
https://dcc-ex.com/start/arduino-ide-setup/
Fragen? Na dann fragt halt. Werden wahrscheinlich noch einen Thread aufmachen müssen. Also den da: https://www.1zu160.net/scripte/forum/forum_show.php?id=1199383
Grüße,
Harald.
Über die benötigte Hardware https://dcc-ex.com/start/diy-starter-kit/
Der Installer will glaube ich noch nicht so ganz, so danach holt man
sich den Code von github (git clone oder als Zipfile)
https://github.com/DCC-EX/CommandStation-EX/
und drückt das dann in den Arduino
https://dcc-ex.com/start/arduino-ide-setup/
Fragen? Na dann fragt halt. Werden wahrscheinlich noch einen Thread aufmachen müssen. Also den da: https://www.1zu160.net/scripte/forum/forum_show.php?id=1199383
Grüße,
Harald.
Nur registrierte und eingeloggte User können Antworten schreiben.
Einloggen ->
Noch nicht registriert? Hier können Sie Ihren kostenlosen Account anlegen: Neuer N-Liste Account
Zum Seitenanfang
© by 1zu160.net;