[Hardi]

Hallo Zusammen,

ich habe den Fehler im Feuer Algorithmus gefunden. Da hab ich mal ohne zu denken eine kleine Verbesserung einbauen wollen…
Bei 7 LEDs (wie im Märchen) hat das gut funktioniert. Aber nicht bei mehr als 7 LEDs.

In der nächsten Version der Bibliothek werde ich das verbessern. Wer jetzt schon ein größeres Feuer entfachen dem schicke ich gerne eine Zwischenversion der Bibliothek zum Testen.

Hardi

[Hardi]

Hallo Bodo,

Zitat

---

Hallo Bodo,

:
:
Ich schau gleich mal wo meine Optokoppler sind. Der Tag hat noch drei Stunden…

Hardi

---

Ich habe versagt. Der erste Test des DCC Empfangs funktioniert erst jetzt. 1.5 Stunden zu spät ;-( Aber zu meiner Entschuldigung: Ich hab erst um 23 Uhr angefangen. Mit Hilfe Deiner und der Dokumentation von Franz-Peter ist es mir gelungen DCC Zubehörbefehle zu empfangen und auf dem Bildschirm auszugeben. Dazu habe ich einfach das NmraDccAccessoryDecoder_1.ino Beispiel benutzt.

Meine MS2 wiederholt den DCC Einschaltbefehl drei Mal, den Ausschaltbefehl ein Mal mit einer Periode von 8-9ms. Aber das sind nur die allerersten Beobachtungen. Die Zahl vor dem "notifyDccAccTurnoutOutput" ist die millis() Ausgabe welche ich hinzugefügt hab.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 

notifyDccAccState: 20,5,6,8
notifyDccAccTurnoutBoard: 5,3,0,1
63128  notifyDccAccTurnoutOutput: 20,0,1
notifyDccAccState: 20,5,6,8
notifyDccAccTurnoutBoard: 5,3,0,1
63136  notifyDccAccTurnoutOutput: 20,0,1
notifyDccAccState: 20,5,6,8
notifyDccAccTurnoutBoard: 5,3,0,1
63145  notifyDccAccTurnoutOutput: 20,0,1
notifyDccAccState: 20,5,6,8
notifyDccAccTurnoutBoard: 5,3,0,1
63154  notifyDccAccTurnoutOutput: 20,0,1
notifyDccAccState: 20,5,6,0
notifyDccAccTurnoutBoard: 5,3,0,0
63414  notifyDccAccTurnoutOutput: 20,0,0
notifyDccAccState: 20,5,6,0
notifyDccAccTurnoutBoard: 5,3,0,0
63422  notifyDccAccTurnoutOutput: 20,0,0 
 

Das muss ich mir „Heute Abend“ noch mal in ruhe anschauen…

Vielen Dank Euch allen, dass es mit Eurer Hilfe so einfach ist mal schnell ein paar DCC Signale zu lesen!

Damit sollte die Integration von DCC in die MobaLedLib kein Problem mehr sein.

Hardi

[Bodo]

Hallo Hardy,

Zitat von Hardi im Beitrag MobaLedLib: 768 LEDs, Servos, Sound, …………… Neu: Version 3.0.0

---

Hallo Speedy,

Zitat von speedy200 im Beitrag MobaLedLib: 768 LEDs, Servos, Sound, …………… Neu: Version 3.0.0

---

kann man nicht die Ausgänge des Arduino DCC auf die Tasteingänge Deiner MobaLed setzen?

Würde man zwei Arduinos benötigen, ist ja aber kein Kostenfaktor mehr.

---

Ja, das ginge sicherlich. Aber es geht noch viel einfacher. Die beiden Arduinos können z.B. über eine serielle Verbindung miteinander reden. Dazu benötigt man nur zwei Leitungen zwischen den Arduinos und ein paar Zeilen Programmkode. Auf diese Weise können dann beliebig viele verschiedene Signale ausgetauscht werden.

---

spontan hätte ich da jetzt Zweifel, dass das bei abgeschalteten Interrupts funktioniert . Wenn das Timing bei den LEDs so kritisch ist, dass die Interrupts abgeschaltet werden müssen, dann kommt m.E. nur eine aktive Abfrage von externen Zuständen in Frage, aber keine Empfangstechnik, die in Echtzeit reagieren muss.

Die Idee mit der Protokollierung auf dem Seriellen Monitor ist gut und auch für andere Zwecke hilfreich ... das werde ich auch mal testen.

Viele Grüße, Bodo

[Railcar]

Hi,
also ich weiß nicht ob es ratsam ist auch noch das MobaLeds Ein-Aus-Knöpfchen-Drück-Signal über die DCC Leitungen zu schalten. Von der Definition her ist DCC als reines Fahrsignal gedacht und wird sowieso schon von vielen für Signale und Weichen zweckentfremdet. Meiner Meinung nach bringt das nur zusätzlichen, überflüssigen Trafic auf die Leitung. Dann doch lieber an das MobaLed Modul einen Eingang (über Opto-Koppler) an den dann jeder das anschliessen möchte was er will.
Davon den DCC Encoder Teil mit auf die MobaLed latine zu setzen würde ich absehen. Wenn jemand nun Loconet zum schalten (zur Signalverteilung) nutzen möchte, was dann?
Lieber einen Optokopler isolierten Eingang am MobaLed Modul an den ich dann anschliessen kann was ich möchte.

@Bodo
Du hast doch so etwas ähnliches auf der Decoderplatine, der DCC Teil ist bei dir doch steckbar, so eine ähnliche Lösung für MobaLed?

Und warum keinen zweiten Arduino (Nano), wer 70 oder 80 Euro für einen popeligen DCC Weichendecoder ausgibt, wird doch auch 3 Euro für nen Nano erübrigen können?!
Die Platine gibts für n Appel und n Ei beim freundlichen Chinesen (ich weiss, Bodo, du bestellst bei Aisler ) und die Bauteile sind Pfennigbeträge.

Ulrich

[MicroBahner]

Hallo,

Zitat

---

Von der Definition her ist DCC als reines Fahrsignal gedacht und wird sowieso schon von vielen für Signale und Weichen zweckentfremdet. Meiner Meinung nach bringt das nur zusätzlichen, überflüssigen Trafic auf die Leitung.

---

Das ist so nicht ganz richtig. Die Ansteuerung von Signalen und Weichen ist integraler Bestandteil der DCC-Definitionen (Zubehör-Telegramme). Das bringt auch nicht großartig mehr traffic auf die Leitungen, da diese Telegramme nicht ständig wiederholt werden.
Kritischer ist es, wenn ein Funktionsdecoder für solche Zwecke benutzt wird. Dafür werden Fahr-Telegramme genutzt, die ständig wiederholt werden, und dann wirklich den traffic auf der Leitung erhöhen.

Hardi hatte mich per Mail angesprochen, und da habe ich ihm schon geschrieben, dass ich den Empfang von DCC-Signalen ( oder ganz allgemein Interruptbasierten Datenaustausch ) kritisch sehe, wenn die Interrupts so lange gesperrt werden müssen. Wobei seriell sicher nicht so kritisch ist, wie DCC, aber dann nur mit sehr niedrigen Baudraten ( 9600 Baud erzeugt schon ca. alle 1ms einen Interrupt ). Man muss sich auch klar sein, das selbst micros() und millis() in diesem Fall nicht mehr axakt arbeiten, und sehr ungenau werden.

Edit: Wäre es nicht vielleicht auch eine Überlegung wert, statt der WS2812 die APA102C zu nehmen? Ok, man braucht einen Draht mehr, aber die Ansteuerung ist dafür vom Timing vollkommen unkritisch und lässt sich z.B. über die SPI-Schnittstelle machen. Da kann dann der Nano locker noch andere Aufgaben übernehmen.

[Bodo]

Hallo zusammen,

lustig - meine MS2 scheint die Befehle immer 6x zu senden - 4 mal in kurzem Abstand und dann noch zwei "Nachzügler". Deckt sich aber mit meiner obigen Beobachtung mit delay(100) - dann sieht man die ersten vier und die beiden anderen als jeweils ein Blinken. Ist aber jetzt auch nur "auf die Schnelle". Den Code habe ich mal angehängt, falls jemand selber testen oder auf Fehlersuche gehen will.

Beispielausgabe bei mir:

1
2
3
4
5
6
7
8
9
10
11
12
13
 

DCC-Zubehördekoder - Befehlsmonitor
38975 ms 	 Adresse 2	grün
38982 ms 	 Adresse 2	grün
38988 ms 	 Adresse 2	grün
38995 ms 	 Adresse 2	grün
39249 ms 	 Adresse 2	grün
39257 ms 	 Adresse 2	grün
43804 ms 	 Adresse 1	rot
43811 ms 	 Adresse 1	rot
43819 ms 	 Adresse 1	rot
43825 ms 	 Adresse 1	rot
44055 ms 	 Adresse 1	rot
44062 ms 	 Adresse 1	rot
 

Würde andererseits bedeuten, dass man die Interrupts durchaus "mal" für 12ms abschalten kann … ist jetzt eben die Frage, in welchen Zyklen das für die LEDs nötig ist .

Viele Grüße, Bodo

[TecnoWorld]

Zitat

---

Würde andererseits bedeuten, dass man die Interrupts durchaus "mal" für 12ms abschalten kann … ist jetzt eben die Frage, in welchen Zyklen das für die LEDs nötig ist .

---

Die LEDs brauchen nicht immer "geupdated" zu werden. Die behalten den letzten Stand.

Bastel dir ein "dirty" Flag, und setze dieses in jedem Effekt/Ausgabe, die am Zustand der Leds was ändern sollen.
Nur wenn der Zustand der Leds "dirty" ist, machst Du ein "Update".
So hast Du genug Zeit, auch dein DCC zu empfangen

LG,
Ingolf

[TecnoWorld]

Zitat von Hardi im Beitrag MobaLedLib: 768 LEDs, Servos, Sound, …………… Neu: Version 3.0.0

---

Die ATSAMC21 Prozessoren spielen aber auch in einer ganz anderen Liga (Hab gerade mal Googeln müssen was das für Teile sind). Ich vermute das sie trotzdem nicht Teurer sind als ein Arduino.

Mir gefällt an der Arduino Programmierung, dass sie so unendlich wenig Ressourcen haben. 32 KByte FLASH und nur 2 KByte RAM. Das zweite Tolle ist die aktive Community.

---

Stimmt, die Prozessoren kosten ca. $1,10 bis $2,70 je nach Flashgröße.

Der ATSAMC21E15 hat auch nur 32k Flash und 4kRAM. Reicht für die normalen Module.
Nur manchmal braucht man halt mehr RAM.

Den ATSAMD21 gibt es ja auch für Arduino.
Ist so gut wie das Gleiche wie der C21, nur hat der C21 5V anstelle 3,3V, hat ein CAN-Modul drin und Hardware Division/Wurzel. Ist für raue Industrie-Umgebungen gedacht.

Problem bei Arduino ist, das es Open-Source ist, aber keiner so richtig weiß, was in den ganzen Bibliotheken passiert.
Man muss halt damit zufrieden sein, wie es ist. Und oft reicht mir das aber nicht. Ich benutze deswegen gar kein Framework, und erhalte so Programme die schnell und Speicher effizient sind.

[Hardi]

Hallo Zusammen,

ich hoffe es ist O.K., wenn ich nicht jedem einzeln antworte…
Es freut mich sehr, dass Ihr euch so intensiv an der Diskussion beteiligt. Und jede noch so abwegige Idee kann die Gedanken in die richtige Richtung lenken.

Zitat

---

also ich weiß nicht ob es ratsam ist auch noch das MobaLeds Ein-Aus-Knöpfchen-Drück-Signal über die DCC Leitungen zu schalten.

---

Man kann mit der Bibliothek sehr schön Signale, Schranken und Andreaskreuze ansteuern. In den Beispielen habt Ihr das gesehen. Für diesen Fall ist eine Integration in das Steuerprogramm der Anlage sicherlich Sinnvoll. Bei der Beleuchtung der Hauser ist es weniger wichtig. Und da die Zubehörbefehle nur bei einer Änderung auf dem Schienensignal gesendet werden (Post #80 von Franz-Peter und Messung von Bodo #81 und mir) ist es unkritisch.

Aber das einlesen der DCC Signale ist für mich in erster Linie eine interessante Herausforderung. Da ist es eigentlich schon fast schade, dass diese mit der Hilfe der DCC Experten so einfach zu meistern ist.

Zitat

---

Und warum keinen zweiten Arduino (Nano), wer 70 oder 80 Euro für einen popeligen DCC Weichendecoder ausgibt, wird doch auch 3 Euro für nen Nano erübrigen können?!

---

Ja warum nicht? Aus sportlichem Ehrgeiz? Aber ich habe mich schon dazu durchgerungen das Problem mit zwei Prozessoren zu lösen. Das ist sicherlich die beste Lösung.
Das bestätigt auch Franz-Peter:

Zitat

---

Hardi hatte mich per Mail angesprochen, und da habe ich ihm schon geschrieben, dass ich den Empfang von DCC-Signalen ( oder ganz allgemein Interruptbasierten Datenaustausch ) kritisch sehe, wenn die Interrupts so lange gesperrt werden müssen.

---

Zitat

---

Edit: Wäre es nicht vielleicht auch eine Überlegung wert, statt der WS2812 die APA102C zu nehmen? Ok, man braucht einen Draht mehr, aber die Ansteuerung ist dafür vom Timing vollkommen unkritisch und lässt sich z.B. über die SPI-Schnittstelle machen. Da kann dann der Nano locker noch andere Aufgaben übernehmen.

---

Soweit ich weiß sind die WS281x basierten LEDs am weitesten verbreitet. Ich habe noch keine LEDs mit zusätzlicher Taktleitung auf kleinen Platinen gesehen. Aber vielleicht war ich auch zu sehr auf die WS281x fixiert. Ich weiß auch nicht ob es ICs ohne integrierte LED mit einem Taktsignal gibt.
Und es könnte sogar sein, dass die zusätzliche Leitung am Ende sogar teurer ist als ein weiterer Nano. Insbesondere da der zweite Prozessor ja nur dann benötigt wird, wenn man das Signal direkt von der Schiene lesen will. Wenn man die Daten über den CAN Bus liest benötigt man keinen zusätzlichen Arduino, weil der CAN Transceiver die Daten filtern zwischenspeichern kann.

Durch die Verwendung der FastLED Bibliothek ist es aber fast egal welche LED Typen man verwendet. Die Bibliothek unterstützt sehr viele verschiedene LEDs. Dazu muss nur eine einzige Programmzeile angepasst werden.

Zitat

---

lustig - meine MS2 scheint die Befehle immer 6x zu senden - 4 mal in kurzem Abstand und dann noch zwei "Nachzügler".

---

Bodo: Wenn ich das richtig sehe sind unsere beiden Messungen identisch. Allerdings habe ich nur einen Tastendruck gezeigt und Du zwei verschiedene Tasten.
Wenn eine Taste gedrückt wird, dann wird das 4mal gesendet. Wenn sie wieder losgelassen wird dann wird das 2mal geschickt.
So sieht meine Messung aus, wenn ich nur eine Zeile pro Ereignis ausgebe:

1
2
3
4
5
6
7
8
9
 

63128  notifyDccAccTurnoutOutput: 20,0,1	
63136  notifyDccAccTurnoutOutput: 20,0,1	dt:8ms
63145  notifyDccAccTurnoutOutput: 20,0,1	dt:9ms
63154  notifyDccAccTurnoutOutput: 20,0,1	dt:9ms
 
63414  notifyDccAccTurnoutOutput: 20,0,0	dt:260ms
63422  notifyDccAccTurnoutOutput: 20,0,0 	dt:8ms
 
 

Und hier Deine Zeilen für einen Tastendruck:

1
2
3
4
5
6
7
8
9
 

38975 ms 	 Adresse 2	grün
38982 ms 	 Adresse 2	grün		dt:7ms
38988 ms 	 Adresse 2	grün		dt:6ms
38995 ms 	 Adresse 2	grün		dt:7ms
 
39249 ms 	 Adresse 2	grün		dt:245ms
39257 ms 	 Adresse 2	grün		dt:4ms
 
 

Die Pause entspricht der Zeit wie lange die Taste gedrückt wurde. Wenn man die Taste längere Zeit hält, dann kommt noch mal ein Messageblock.

Zitat

---

Würde andererseits bedeuten, dass man die Interrupts durchaus "mal" für 12ms abschalten kann … ist jetzt eben die Frage, in welchen Zyklen das für die LEDs nötig ist .

---

Die LEDs sollten alle 20 – 30ms aktualisiert werden, wenn sich etwas ändert. Ingolf hat darauf hingewiesen. Wenn man nur Lichter in den Häusern ansteuert, dann ändert sich nur ganz selten etwas. Wenn man das langsame aus- und abblenden der LEDs, die TV Simulation, das Feuer oder einen anderen dynamischen Effekt benutzt, dann müssen die LEDs sehr schnell aktualisiert werden.
Die Messungen von Bodo und mir zeigen, dass es kein exaktes Timing für die wiederholung eines Signals gibt. Dadurch kann man keine festen Pausen definieren in denen auf DCC gelauscht wird.

=> Ich mach jetzt einfach mal an der Dual Core Lösung weiter. Klingt doch auch schön. Auch wenn es 1.77€ teuer ist…

Zitat

---

Problem bei Arduino ist, das es Open-Source ist, aber keiner so richtig weiß, was in den ganzen Bibliotheken passiert.
Man muss halt damit zufrieden sein, wie es ist. Und oft reicht mir das aber nicht. Ich benutze deswegen gar kein Framework, und erhalte so Programme die schnell und Speicher effizient sind.

---

Aber man hat jederzeit die Möglichkeit in den Code der anderen zu schauen und diesen zu verbessern. Man muss nicht immer das Rad neu erfinden…
Ich schreibe aber auch oft schnell ein eigenes Programm. Allein schon, weil es Spaß macht… Und außerdem verwendet ein guter Programmierer keinen fremden Code

Ich hoffe ich habe keine Fragen vergessen. Wenn doch, dann meldet euch.

Hardi

[bertr2d2]

Hallo Hardi,

ich hatte mich vor einiger Zeit auch mal mit den WS2812 beschäftigt. Das Timing ist herausfordernd aber man kann durch geschickte Ausnutzung der möglichen Zeitparameter einiges machen. Diese Seite ist mir damals aufgefallen:
NeoPixels Revealed: How to (not need to) generate precisely timed signals

Zitat

---

Die LEDs sollten alle 20 – 30ms aktualisiert werden, wenn sich etwas ändert. Ingolf hat darauf hingewiesen. Wenn man nur Lichter in den Häusern ansteuert, dann ändert sich nur ganz selten etwas. Wenn man das langsame aus- und abblenden der LEDs, die TV Simulation, das Feuer oder einen anderen dynamischen Effekt benutzt, dann müssen die LEDs sehr schnell aktualisiert werden.
Die Messungen von Bodo und mir zeigen, dass es kein exaktes Timing für die wiederholung eines Signals gibt. Dadurch kann man keine festen Pausen definieren in denen auf DCC gelauscht wird.

---

Laut Aussage der oben genannten Seite ist nur das Timing des Low Signals kritisch. Beim High Signal hat man einigen Spielraum. Auf der o.g. Seite steht weiter:

Zitat

---

Q: Could I save time by using the gaps in between individual bits for image computation rather than waiting until the end of a pixel?
A: If your algorithm is fine grained enough to be efficiently broken into 24 very short work units per pixel, then this could be tremendously efficient -and impressive! Please send what you come up with!

---

Also müsste sich doch was machen lassen wie DCC Decoding (Interrupt gesteuert ?) ohne zweite MCU, oder ?
[quote=Hardi]
Und außerdem verwendet ein guter Programmierer keinen fremden Code
[/quote]
Ein schlauer Programmierer erkennt wenn der Code eines anderen besser ist

Gruß

Gerd

[MicroBahner]

Zitat

---

Die Pause entspricht der Zeit wie lange die Taste gedrückt wurde. Wenn man die Taste längere Zeit hält, dann kommt noch mal ein Messageblock.

---

Das, was ihr bei euren Messungen seht ( beim Drücken und Loslassen der Taste an der MS2), sind 2 verschiedene Telegramme. Als das DCC-Zubehörtelegramm definiert wurde, hatte man da eigentlich ausschließlich an die Doppelspulenantriebe gedacht. Deshalb enthält das Telegramm 3 Informationen:

1. Die Weichen/Signaladresse (bestehend aus Decoderadresse und Weichenindex)
2. Die Weichen/Signalstellung (Geradeaus/Abbiegend bzw HP0, HP1)
3. den Spulenzustand ( EIN/AUS )

Die MS2 simuliert da das klassische Weichenstellpult: Taste drücken = Spule ein, Taste loslassen=Spule aus. Dementsprechend seht ihr die Telegramme beim Drücken. bzw. Loslassen der Taste.
Das ist für den Antrieb natürlich nicht ganz ungefährlich: wird das 'Spule AUS' Telegramm nicht erkannt, brennt die Spule durch. Insofern ist es eigentlich unlogisch, dass das AUS-Telegramm nicht so oft wiederholt wird, wie das Einschalttelegramm. Allerdings verlassen sich eigentlich alle Decoder für Doppelspulenantriebe nicht auf das 'AUS' Telegramm, sondern schalten die Spule selbständig nach einer - meist per CV einstellbaren - Zeit aus. Dann ist das AUS-Telegramm an sich vollkommen überflüssig.

Wie oft die einzelnen Telegramme wiederholt werden, ist auch nicht festgelegt, und bei den einzelnen Zentralen oder auch PC-Programmen recht unterschiedlich.
Wenn ich mich recht erinnere, ist es z.B. bei der Multimaus anders als bei der MS2. Das weis ich aber nicht mehr genau und müsste es nochmal ausprobieren.

Es gibt auch ein 'erweitertes Zubehör-Telegramm', das nicht mehr auf Doppelspulenatriebe fokussiert ist. Gedacht ist es im wesentlichen für Signale mit vielen verschiedenen Signalbildern. Das scheint aber nicht so weit verbreitet zu sein (die NmraDcc Lib erkennt das aber ).

Der zusätzliche Aufwand, für die DCC-Decodierung einen eigenen Arduino zu verwenden, ist sicher überschaubar, und man vermeidet eine Reihe Probleme aufgrund des kritischen Timings der WS2812B. Auch einen Ansteuerung mit LocoNet ist dann ja möglich. Wenn man eh schon beim Arduino-Basteln ist, wird man dafür wohl kaum einen kommerziellen Decoder einsetzen.

Zitat

---

Und außerdem verwendet ein guter Programmierer keinen fremden Code

---

Na, na, dann dürftest Du das ganze Arduino-System und die Libs nicht einsetzen .

[TecnoWorld]

Noch als Tip, wenn man die Leds nicht permanent aktualisiert.
Die Leds sind recht empfindlich bei langen Leitungen. Sowohl was Impulsform als auch Störimpulse angeht.
Um Überschwinger durch Leitungskapazitäten zu vermeiden, sollte man immer einen 30-100R Widerstand in die Datenleitung legen.
Auch wenn die Kette unterbrochen wird und wo anders fortgesetzt wird (Verteiler).

Desweiteren sollte die Datenleitung bei Nichtsenden aktiv auf L gezogen werden.

Nochmal kurz zu Arduinio:
Die Prozessoren (oder so ähnliche) gibt es ja auch für die Arduino-Plattform. https://store.arduino.cc/genuino-zero
Da kann man halt auch die ganzen Arduino-Libs drauf laufen lassen und die NeoPixel-Lib funktioniert dann auch korrekt per DMA, meines Wissens (was man so im Netz liest).

Ich habe halt die LEDs (3 Stränge) dauerthaft laufen per DMA. Das heißt, man hat die maximale Updaterate die sich ergibt aufgrund der an einem Strang angeschlossener LEDs.
Das war der Grund auf 3 Stränge zu gehen und 64 Leds/Strang zu definieren. Damit habe ich eine Updaterate von ca. 500Hz (800kHz/64Leds/24bit), das reicht für die meisten Effekte
Das Schreiben der Werte in den RAM erfolgt völlig unabhängig von der Ausgabe, deswegen kann sich der Prozessor weiter um Protokolle/Effekte und andere Dinge kümmern.

Also vielleicht, anstatt 2 Prozessoren zu nehmen, einfach mal den Arduino-Typ wechseln... Dank dieser Arduino-Libs sollte ja alles ohne Anpassung einfach portierbar sein.

LG,
Ingolf

[MicroBahner]

Zitat

---

Da kann man halt auch die ganzen Arduino-Libs drauf laufen lassen

---

Vorsicht, längst nicht jede Lib funktioniert mit allen erhältlichen Plattformen. Lediglich die 'Standard' Libs sind bei allen 'offizeilen' Plattformen lauffähig. Wobei das dann unterschiedliche Lib's sind, die aber von der IDE automatisch richtig eingebunden werden.
Bei zusätzlich installlierten Lib's muss man da gegebenenfalls selbst drauf achten, auf welchen Plattformen die lauffähig sind.

Zitat

---

Also vielleicht, anstatt 2 Prozessoren zu nehmen, einfach mal den Arduino-Typ wechseln

---

Der von dir verlinkte Arduino spielt aber preislich in einer ganz anderen Liga. Selbst für einen Zero-Clone bekommst Du locker 5 Nano Clone. Da bist Du also mit 2 Prozessoren noch wesentlich günstiger.

Es sei denn der Ehrgeiz, dass alles auf einen Prozessor zu bringen ist entscheiden . Dann wären allerdings die STM32F1 Prozessoren besser. Die gib'ts für vergleichbares Geld wie den Nano und unterstützen auch DMA. Und eine NeoPixel Lib (mit DMA ) gibt's dafür auch.
Aber ich glaube wir schweifen ab, denn dafür muss man dann doch etwas tiefer einsteigen .

[Hardi]

Hallo Gerd,

Zitat

---

ich hatte mich vor einiger Zeit auch mal mit den WS2812 beschäftigt. Das Timing ist herausfordernd aber man kann durch geschickte Ausnutzung der möglichen Zeitparameter einiges machen. Diese Seite ist mir damals aufgefallen:
NeoPixels Revealed: How to (not need to) generate precisely timed signals

---

Vielen Dank für den Hinweis. Jetzt wo Du das sagst erinnere ich mich daran. Es gibt auch eine Bibliothek die das Ausnutzt und den Interrupt immer wieder aktiviert. Diese hab ich in Verbindung mit dem Infrarot Empfang verwendet. Das hat am Schreibtisch super funktioniert. Am realen Objekt wurden nur die ersten 30 oder 40 LEDs aktualisiert. Zwei Tage später habe ich festgestellt, das die ersten LEDs WS2812 und die Folgenden WS2812B waren. Wenn man weiß nach was man sucht, dann findet man auch schnell, dass das Timing bei den „B“ Typen kritischer ist ;-(

Hardi

[Hardi]

Hallo Franz-Peter,

Zitat

---

Das, was ihr bei euren Messungen seht ( beim Drücken und Loslassen der Taste an der MS2), sind 2 verschiedene Telegramme.

---

Da bin ich mir nicht so sicher. Bodo und ich verwenden beide die MS2 zur Generierung der Signale. Diese erzeugt nur den Ersten von Dir genannten Typ. Ich denke die Ausgaben unterscheiden sich weil wir verschiedene Programme verwenden. Wenn ich am großen Rechner bin werde ich das mal überprüfen.

Der zweite Typ ist mir auch aufgefallen. Dazu wollte ich Dich schon in einer PN Fragen (Damit nicht die ganze Welt lesen kann dass ich keine Ahnung von DCC hab). Vorher wollte ich aber noch was darüber lesen um mich nicht ganz zu blamieren. Zu Spät...
Aber vielleicht kannst Du mir und den anderen Stummis eine Tip zum lesen geben?

Zitat

---

Zitat

---

Und außerdem verwendet ein guter Programmierer keinen fremden Code

---

Na, na, dann dürftest Du das ganze Arduino-System und die Libs nicht einsetzen .

---

Ich verwende die Libs sehr gerne. Das könnte im Umkehrschluß bedeuten, dass ich kein...

Hardi

[Hardi]

Hallo Zusammen,

Zitat

---

Ich denke die Ausgaben unterscheiden sich weil wir verschiedene Programme verwenden.

---

Es ist tatsächlich so wie ich vermutet hatte. Das Programm von Bodo und mir reagieren beide auf den gleichen Event: „notifyDccAccState()“. Bodos Programm gibt allerdings den „State“ nicht aus. Darum sehen die ersten 6 Ausgabezeilen gleich aus.

Bodos Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 

void notifyDccAccState( uint16_t Addr, uint16_t BoardAddr, uint8_t OutputAddr, uint8_t State ){
  // Weichenadresse berechnen
  word wAddr = Addr+isROCO;            // Roco zählt ab 0, alle anderen lassen die ersten 4 Weichenadressen frei
  // Testen ob eigene Weichenadresse
  for ( int i = 0; i< adressAnzahl; i++ ) {
    if (  wAddr == weichenAdr[i] ) {
      Serial.print(millis(),DEC);
      Serial.print(" ms t Adresse ");
      Serial.print(weichenAdr[i],DEC);
      Serial.print("t");
      if ( OutputAddr & 0x1 ) {
        Serial.println("grün");
      }
      else {
        Serial.println("rot");
      }
    }
  }
}
 
 

Die von mir verwendeten Zeilen:

1
2
3
4
5
6
7
8
9
10
11
12
13
 

void notifyDccAccState( uint16_t Addr, uint16_t BoardAddr, uint8_t OutputAddr, uint8_t State)  // **
{
  Serial.print("notifyDccAccState: ") ;
  Serial.print(Addr,DEC) ;
  Serial.print(',');
  Serial.print(BoardAddr,DEC) ;
  Serial.print(',');
  Serial.print(OutputAddr,DEC) ;
  Serial.print(',');
  Serial.println(State, HEX) ;
}
 
 

In meinem Testprogramm, das Nmra Beispiel „NmraDccAccessoryDecoder_1.ino“, werden zusätzlich noch die „notifyDccAccTurnoutBoard“ und die „notifyDccAccTurnoutOutput“ Ereignis Funktion verwendet. Darum werden drei Zeilen pro „DCC Turnout“ Paket erzeugt. Ich hatte das so verstanden, dass es sich dabei um unterschiedliche Schreibweisen der gleichen Information handelt.
Franz-Peter: Kannst Du das bestätigen?

Der zweite DCC Typ wird mit der Funktion „notifyDccSigState“ ausgegeben. Ich weiß aber nicht wie ich das mit der MS2 erzeugen kann.

Hardi

[MicroBahner]

Hallo Hardi,

Zitat

---

Zitat

---

Das, was ihr bei euren Messungen seht ( beim Drücken und Loslassen der Taste an der MS2), sind 2 verschiedene Telegramme.

---

Da bin ich mir nicht so sicher. Bodo und ich verwenden beide die MS2 zur Generierung der Signale. Diese erzeugt nur den Ersten von Dir genannten Typ.

---

Ich bin mir jetzt nicht sicher, was Du mit dem ersten bzw zweiten Typ meinst. Wenn es da um die erweiterten Zubehörtelegramme geht - die erzeugt die MS2 in der Tat nicht. Das hatte ich aber auch nicht gemeint. Die MS2 erzeugt Beim Drücken der Taste ein 'Spule EIN' Telegramm, und beim loslassen der Taste ein 'Spule AUS' Telegramm. D.h. es ist schon der gleiche Telegrammtyp, aber mit unterschiedlichem Inhalt. Es ist also nicht einfach eine Wiederholung des identischen Telegramms.

Zitat

---

Es ist tatsächlich so wie ich vermutet hatte. Das Programm von Bodo und mir reagieren beide auf den gleichen Event: „notifyDccAccState()“. Bodos Programm gibt allerdings den „State“ nicht aus. Darum sehen die ersten 6 Ausgabezeilen gleich aus.

---

„notifyDccAccState()“ ist die 'alte' Version der Callbackroutine, die bei neuen Programmen nicht mehr verwendet werden sollte. 'State' ist dabei der Schaltzustand der Spule.

Zitat

---

In meinem Testprogramm, das Nmra Beispiel „NmraDccAccessoryDecoder_1.ino“, werden zusätzlich noch die „notifyDccAccTurnoutBoard“ und die „notifyDccAccTurnoutOutput“ Ereignis Funktion verwendet. Darum werden drei Zeilen pro „DCC Turnout“ Paket erzeugt. Ich hatte das so verstanden, dass es sich dabei um unterschiedliche Schreibweisen der gleichen Information handelt.
Franz-Peter: Kannst Du das bestätigen?

---

Diese beiden Callbacks sind die Nachfolger des „notifyDccAccState()“. Sie unterscheiden sich in der Interpretation der Adressinformation: "Decoder Adressing" oder "Output Adressing". Letzendlich ist es aber der gleiche Telegrammtyp auf den sie reagieren. Die Adressinformation wird nur anders interpretiert. Wie der Decoder die Adressinformation interpretieren soll, steht in CV29, Bit6.

Zitat

---

Der zweite DCC Typ wird mit der Funktion „notifyDccSigState“ ausgegeben. Ich weiß aber nicht wie ich das mit der MS2 erzeugen kann.

---

Auch das ist aber die alte 'depredated' Variante des Callbacks. Die aktuelle Variante ist „notifyDccSigOutputState“ . Die MS2 kann diesen Telegrammtyp meines Wissens nicht erzeugen.

[Hardi]

Hallo Ingolf,

Zitat

---

Die Leds sind recht empfindlich bei langen Leitungen. Sowohl was Impulsform als auch Störimpulse angeht.
Um Überschwinger durch Leitungskapazitäten zu vermeiden, sollte man immer einen 30-100R Widerstand in die Datenleitung legen.
Auch wenn die Kette unterbrochen wird und wo anders fortgesetzt wird (Verteiler).

---

Das mit dem Widerstand wolle ich immer schon mal verstehen.
Die LEDs Platinen und auch die WS2811 Module haben immer einen 75 Ohm Widerstand in der Datenleitung (R1 auf dem Bild):


Im Internet findet man das das eine „Serienterminierung“ ist: https://www.mikrocontroller.net/articles/Wellenwiderstand
Beim CAN Bus, TV Kabel, … kenne ich das. Aber nur als „Parallelterminierung“ mit widerständen am Ende.
=> Schon wieder was gelernt.

Der Widerstand am Ausgang des Arduinos ist vermutlich dazu da, das der Eingangspin der ersten Leuchtiode nicht kaputt geht wenn die Versorgung des Arduinos vor der Versorgung der LEDs angeschaltet wird. Das findet man z.B. hier: https://www.mikrocontroller.net/topic/363069#4079679
Ich werde mich mal in Unkosten stürzen und zerstörende Versuche mit den LEDs machen (7 Cent pro Stück! Aber ich hab mir fest vorgenommen maximal 3 LEDs zu opfern).

Hardi

[Hardi]

Hallo Franz-Peter,

Danke für die Info. Ich habe sofort die aktuelle Version der Nmra Bibliothek installiert.

Hardi

[MicroBahner]

Hallo Hardi,
die hat auch den Vorteil, dass die Callbacks in der nmradcc.h wesentlich besser dokumentiert sind . ( In der vorherigen Version waren sie eigentlich gar nicht dokumentiert ).

[TecnoWorld]

Zitat

---

Das mit dem Widerstand wolle ich immer schon mal verstehen.
Die LEDs Platinen und auch die WS2811 Module haben immer einen 75 Ohm Widerstand in der Datenleitung

---

Hallo Hardi,

Naja.
Eine Datenleitung hat eine Induktivität und eine Kapazität.
Wenn man nun (einfach gesagt) mit niedriger Impedanz diese Leitung treibt, hat man am anderen Ende der Leitung eine Schwingung. Das führt dazu, das ein Impuls kürzer oder sogar als 2 Impulse erkannt wird.

Wenn man nun einen Widerstand in Reihe schaltet, begrenzt man den Strom und damit die Slew rate.

Jetzt sehen die Impulse wieder wohlgeformt aus

Hast du Oszi und Logic Analysator zur Hand?

[Hardi]

Hallo Ingolf,

Du wirst es nicht glauben, ich habe vor 100 Jahren mal E-Technik studiert. Aber offensichtlich ist die Vorlesung über Serienterminierung bei mir wegen „Baggersee“ ausgefallen.

Ja, ich habe einen Oszi und finde, dass es wichtig ist hier mal ein Paar Bilder mit und ohne „Terminator“ zu zeigen (Stummis stehen auf Bilder). Vielleicht kommst Du ja mal dazu welche zu machen...

Hardi

[Hardi]

Hallo Thomas, Hallo DCC Fahrer,

Zitat von ThKaS im Beitrag #59

---

Kann man in Deine Lösung irgendwie DCC integrieren. Sodass die NANOs direkt über DCC ansteuerbar werden und ggfls parallel zu möglichen Push-Buttons auch in eine PC-Steuerung integriert werden können.

---

JA, jetzt kann man das!

Es hat, wie immer länger gedauert als gedacht. Eigentlich ist es gar nicht so schwierig. Aber wenn man Stunden damit verbringt nach Fehlern im Programm zu suchen welche durch falsche Verdrahtung generiert wurden…

In dem Video sieht man, dass ich zwei Arduinos über eine drei Adrige Leitung miteinander verbunden habe (Tx, GND und eine „Send_Enable“ Leitung). Auf dem linken DCC-Arduino läuft ein kleines Programm welches die DCC Daten mit der „NmraDCC“ Bibliothek einliest und über die serielle Schnittstelle an den rechten LED-Arduino schickt. Dieser liest die Daten ein und steuert damit die Signale.

Das Problem bei der Geschichte war, dass die FastLED Bibliothek zum Aktualisieren der LEDs die Interrupts sperren muss, weil das Timing der Datenübertragung sehr kritisch ist. Darum können die DCC Signale nicht direkt eingelesen werden. Das Problem existiert auch beim Empfang über die serielle Schnittstelle. Aber hier kann man dem DCC-Arduino über eine die „Send_Enable“ Leitung sagen, wann er die Daten verschicken darf. Dieses Steuerverfahren wurde früher immer bei der seriellen Schnittstelle (RTS/CTS) eingesetzt. Dummerweise ist es beim Arduino standardmäßig nicht vorhanden weshalb ich es nachbauen musste.

Die DCC Signale können natürlich parallel zu den anderen Schaltern (Push Button und Schaltermatrix) der Bibliothek verwendet werden. So können z.B. die Signale und Schranken über DCC von der Modellbahnzentrale gesteuert werden und die anderen LEDs und Funktionen können über externe Schalter bedient werden.

Das Einlesen der DCC Signale ist kein fester Bestandteil der Bibliothek. Es sind ja nur ein paar Zeilen, die man in sein Programm einbauen kann. Dazu wird es in der nächsten Version der MobaLedLib zwei weitere Beispiele (Sender und Empfänger) geben die zeigen wie das gemacht wird.

Die Programmteile zum Senden der DCC Zubehör befehle (DCC-Arduino) können z.B. auch in das Programm von Franz-Peter (viewtopic.php?f=5&t=144916&hilit=DIY+Zubeh%C3%B6rdekoder) integriert werden. Dann hat der DCC-Arduino noch andere Aufgaben und die Investition der 1.77€ für den zweiten Nano lohnen sich.

Hardi

[ThKaS]

Danke

Moin Hardi

Bin schon gespannt, wie die Lösung einsetzbar ist.
Kannst Du mir vorab noch erklären, wie der DCC-Nano zu den DCC-Adressen für die möglicherweise unterschiedlichen Ereignisse in der „Lichterkette“ kommt?
Oder geht das „Einfach“ aus der nmra-lib hervor?

[Ingolf]

Guten Morgen Hardi,

toll gemacht !
Meine LED´s sind auch vor 2 Tagen gekommen, ich hoffe, ich kann am WE loslegen.

Wir hatten mal über die Ansteuerung der LED´s über den Wemos D1 mini gesprochen, es geht, aber die 1. LED muß "geopfert" werden zur
Pegelanpassung. Ich werde zwischendurch mal eine Statusanzeige für meinen ioBroker zusammenlöten. Werde berichten.

Auf der Moba möchte ich zum probieren mein Bahnhofsgebäude mit deinem System beleuchten, die LED´s sollen zufallsgesteuert an und aus
gehen, einzelne LED´s ständig leuchten. Mal sehen, ob ich so was Sketch - mäßig hinbekomme.

Die Signalsteuerung über DCC - geil gemacht, da gibt es sicher noch mehr Möglichkeiten, was damit anzustellen wäre, z.B. verschiedene
Beleuchtungsszenarien.

Bis die Tage

Grüße Ingo