Oli hatte Platinensätze zum Beleuchten von Wagen hier in Forum vorgestellt. Er hatte eine PluX Schnittstelle für den Dekoder vorgesehen. Es kam nun die Frage auf, welchen bezahlbaren Dekoder nehmen, wenn man jeden Wagen mit einem Dekoder ausrüsten möchte, um elektrisch leitende Kupplungen zu vermeiden.
In der Diskussion hatte ich den Fipps von Digital Bahn angeführt. Ich habe schon einige Wagen mit diesem Dekoder ausgestattet. Wenn man jedoch Wagen etwas umfangreicher mit Lichtfunktionen ausstatten will, sind die verfügbaren Ausgänge schnell erschöpft. Zum Anderen störte mich, dass man entweder mehreren Wagen die gleiche Adresse geben muss oder das Einschlten des Lichts in Arbeit ausartet. Sollen die Züge neu zusammengestellt werden, müssen u.U. die Wagen zum Ändern der Adresse aufs Programmiergleis. Meine Erwartungen erfüllten sie also nicht so recht.
Da es hier immer mal Projekte mit Arduinos gab, bekundete Oli sein Interesse, sich damit auseinander setzen zu wollen.
Also haben wir beschlossen, es mal zu versuchen. Ob nun der Weg das Ziel ist oder ein preiswerter Funktionsdekoder für Wagen, soll erstmal offen bleiben. Wer Interesse hat, ist herzlich eingeladen, mitzumachen, Ideen zu liefern, Wünsche zu äußern. Es sind einige Fargen zu klären, wo Unterstützung willkommen ist.
Ich sehe z.Z. zwei Zwischenziele: ins Thema einarbeiten und ein Pflichtenheft für den Funktionsdekoder zu erstellen.
In diesem Eröffnungsbeitrag möchte ich einige Anregungen geben, wie man sich dem Thema nähern kann.
Vom Fipps war schon die Rede. Ich habe einen ohne Pic verwendet und habe ihn mit einen Arduino Pro Mini verbunden, um eine Hardware zum Testen zur Verfügung zu haben. Vom Fipps wird in diesem ersten Versuch das Auskoppeln des DCC Signals und die Stromversorgung genutzt.
Das gelbe und blaue Kabel ist die Verbindung zum Programmiergerät, was hier als Mini DCC Zentrale dient, das blaue ist die Verbndung der Masse zwischen Fipps und Pro Mini, das orangene VCC (5V) zur Versorgung des Pro Mini vom Fipps und damit aus dem Gleis (die VCC Verbindung zum FTDI ist hier zu diesem Zweck unterbrochen), das schwarze das DCC Signal zum Lesen des Protokolls durch den Pro Mini und das weiße ist nicht angeschlossen und soll dem Quitieren von Lese- und Programmierbefehlen in einem stäteren Versuch dienen.
Alternativ zum Fipps kann auch eine der Schaltungen verwendet werden, die Philipp Gathow uns hier vorstellt. Die Schaltung mit dem Optokoppler 6N136 habe ich auch ausprobiert. Es ist die Edelausführung und sollte auf alle Fälle funktionieren. Da wir einen Funktionsdekoder bauen wollen, der aus der Schiene mit Strom zu versorgen ist, kann also der Optokoppler zum Potentialtrennen eingespart werden.
Am Programmiergerät sind eine Adresse, eine Richtung, eine Geschwindigkeit und Funktionen eingestellt. Philipp bieten auf seiner Seite auch die Software für einen DCC-Monitor an. Ich habe sie verwendet, jedoch funktonierte sie nicht, da sich offenbar der Timer1 und die serielle Schnittstelle gegenseitig stören. Ich habe die DCC Erkennung testweise durch eine timerfreie Version ersetzt. Der Monitor gibt die erkannten DCC Befehle auf den PC Bildschirm über die serielle Schnittstelle aus.
Das sieht dann passend zu den Eingaben am Programmiergerät so aus.
Hiermit soll der Startschuss gegeben sein. Manfred
Hallo, Das Projekt klingt interessant, doch Frage ich mich, wieso nicht einfach die Esu oder Tams Beleuchtungsplatinen mit integriertem Digitaldecoder verwenden?
Mit bis zu 6 getrennt schaltbaren Lichtgruppen, 2 5V-LED-Anschlüssen und einem weiteren AUX-Ausgang bleiben fast keine Wünsche offen - und das bei einem Preis von ca. 18€ pro Waggon.
Zitat von BR365 im Beitrag #2Hallo, Das Projekt klingt interessant, doch Frage ich mich, wieso nicht einfach die Esu oder Tams Beleuchtungsplatinen mit integriertem Digitaldecoder verwenden?
Mit bis zu 6 getrennt schaltbaren Lichtgruppen, 2 5V-LED-Anschlüssen und einem weiteren AUX-Ausgang bleiben fast keine Wünsche offen - und das bei einem Preis von ca. 18€ pro Waggon.
Weil die dann eventuell doch nicht in alle Wagen einsetzbar sind? Zudem kann ich mir bei Manfred und Oli vorstellen, das neben dem Bastelspass bei der angedachten Menge des Projektes die einzelne Platine billiger wird.
Viele Grüße Steffen
DR Ep.III und IV, Pilz Standard und Tillig Elite, Digikeijs DR5000, DR4088/LN CS, DR4033, DR4018, WDec04b, Zimo, ESU, Kres FlexDec, I-Train Plus; TCB , Programmer: ESU, MXULFA, Lenz, D&H Schaut mal hier rein: Modellbau Club Jahnsbach Offizieller Sponsor der Modellbahnproduzierenden Industrie
ich spitze schon eine Weile auf den Seiten von Fichtelbahn umher, die haben da einen 1a-Beleuchtungsdecoder zum Selbstbau. Schaut euch den doch mal an, da braucht ihr vielleicht das Rad nicht neu erfinden.
Details gibt es hier, das ist OpenSource, die veröffentlichen also alles mögliche, damit man das gut nachbauen kann. Leider kann man die Platinen und Bauteile im Moment nicht in deren Shop kaufen, da das Projekt überarbeitet wird. Ich werde da auf jeden Fall zuschlagen, dieser Decoder names DCCrail sieht wirklich gut aus mit allen Funktionen, und das auch zu einem sehr kleinen Preis.
Dekoder mit ähnlichen Eigenschaften hatte ich vor über 10 Jahren von AMW verbaut. Sie waren ein paar Euro teurer, hatten aber ähnliche Eigenschaften. Da sie mich nicht so recht überzeugt hatten, habe ich dann keine weiter verbaut. Da hat sich nun 10 Jahre später nichts geändert, deshalb gibt es ja dieses Projekt.
@Falko Im Vorfeld dieses Projektes hatte ich mir die Dekoder von der Fichtelbahn angeschaut. Ein paar Schaltungsideen waren sicher nutzbar. Aber dabei bin ich nicht über die Wagendekoder gestolpert. Das liegt aber schon recht nah an dem, was wir vorhaben.
Falko, vielen Dank für diesen Hinweis.
An einigen Stellen möchte Oli mehr und an anderen ich. Auf der virtuellen Eröffnungskonferenz am letzten Wochenende haben wir beschlossen, diesen Ansatz als Grundlage für unser Projekt zu nutzen. Damit sind schon einige Vorarbeiten erledigt. Wir wollen jedoch beim Arduino und C++ bleiben, weshalb es z.B. der pinkompatieble Prozessor ATmega328p sein soll, den ich auch auf dem Susi-Modul einsetze. Es gibt einige Stellen, wo wir eben mehr wollen. Wir haben aber auch beschlossen, einen Kontakt zu den Fichtelbahner zu suchen. Vielleicht sind ja ihre Ideen zum Überarbeiten ähnlich unseren Wünschen.
Als ersten Projekt haben wir uns unabhängig von einander für die 4 achsigen Rekowagen von Heris entschieden. Dieses Projekt wollen wir gemeinsam durchführen, um unsere Ideen und Erfahrungen austauschen zu können.
Hier sieht man, was als erstes abgedeckt werden soll:
Wenn die ersten Ergebnisse vorliegen, soll geprüft werden, ob die Wagen von Brawa ohne großen Aufwand mit abgedeckt werden können.
Erster Entwurf für das Verteilen der LEDs für die Wagenbeleuchtung bei den Rekowagen.
Einige Punkte wie es weitergehen kann: In die Technik und Programmierumgebung des Arduinos weiter einarbeiten. An den Wagen sollen Lichttests mit LEDs 0603 durchgeführt werden, ob die oben geplante Position der LEDs sinnvoll ist. Die Brauchbarkeit der NMRAdcc Bibliothek soll überprüft werden. Die Schaltung der Fichtelbahner soll vollständig verstanden werden. Frontplatinen und Verbindung mit der Hauptplatine weiter gestalten.
Bevor dur soviel Energie in das Projekt steckst, sei dir gesagt, das die Fichtelbahner an einer Rev.5 des Beleuchtungsdecoders arbeiten, welche aber zugegebener Maßen schon einige Zeit auf sich warten lässt. Ich warte auch schon aufgeregt seit langen auf neue Infos.
Zu den LEDs... Ist das jetzt eine "Uni-Platine" die in allen der Heris Rekowagen unterschiedlich bestückt zum Einsatz kommt, oder ist das eine Platine für einen bestimmten Wagentyp, die so mit LEDs komplett bestückt wird? Weil bei letzterem würde ich dir raten, die Lichtpunkte zu reduzieren. 31LEDs, + Schlusslicht/Steurwagenbeleuchtung usw.... Das kostet dich sehr schnell sehr viel Strom! Selbst bei nur 2-3mA pro LED bist du da schnell bei 100mA pro Wagen. Da brauchst du an Pufferspeichern mit Goldcaps nicht mehr zu denken... Ich bin jetzt bei Brawas Preußen bei bis zu 23 LEDs pro Wagen angekommen...Selbst mit nur 2mA pro LED sieht das Teil aus, wie die Supernova im Solarium...und mit dem puffern mit Goldcaps bin ich an der "kotzgrenze" angekommen.
Apropos Pufferspeicher... Die Fichtelbahner gehen hier den Weg über Lipo-Akkus. Das ist in meinen Augen ein Problem, für die Leute, die Ihr Rollmaterial nur selten einsetzen. Die Akkus lassen sich nicht von der Schaltung trennen. Ergo: Sie sind in kürzester Zeit tiefentladen, was zum Schnelltot des Akkus führt!
also überrumpeln wollte ich Dich mit meinen Vorschlägen nicht. :-) Natürlich werden nicht für jeden Wagen alle LEDs verwendet. Aber man erkennt, dass die Inneneinrichtungen teilweise starke Unterschiede aufweisen. Und bei jedem Wagen sollen ja auch alle Räume getrennt schaltbar sein, und das alles mit einer Uni-Platine. Daher sieht das im Moment etwas "unübersichtlich" aus. Für alle Interessierten kann ich das Layout noch durch mögliche Gruppierungen ergänzen. Dabei habe ich alle LEDs gruppiert, die nie gemeinsam verwendet werden und daher auf den gleichen Ausgang gelegt werden können:
Es werden also im schlimmsten Fall (dem Dienstwagen...) 20 LEDs benötigt. Das kann/muss ggf. noch weiter reduziert werden.
Eine andere Sache, die mir noch einfällt, ist der Güterwagen, der zum Hilfszug gehört. Irgendwie braucht der ja auch eine Spitzenbeleuchtung. Ich habe mir das noch nicht angesehen und es kann auch warten. Aber es sollte einmal angesprochen werden. Vielleicht kann man auch die Frontplatine der Rekos dafür anpassen.
Wie ich sehe, kullern bei Dir auch die kurzen Rekowagen über die Anlage. Dazu schreibe ich bei Gelegenheit auch noch etwas, was wir aus denen gemacht haben.
Es bleibt also weiter spannend. Ideen und Anregungen sind natürlich jederzeit gerne gesehen.
Viele Grüße, Oli
„Gib jedem Tag die Chance, der schönste deines Lebens zu werden.“ (Mark Twain)
Zitat von DRG-ler im Beitrag #6Ich bin jetzt bei Brawas Preußen bei bis zu 23 LEDs pro Wagen angekommen...Selbst mit nur 2mA pro LED sieht das Teil aus, wie die Supernova im Solarium...
Womit steuerst Du diese LEDs an? Verwendest Du einen separaten Dekoder oder was integriertes? Das wir bei derart vielen LEDs in den unteren mA Bereich müssen, war mir bewusst. Ich verwende schon seit langem sparsame Versionen von LEDs und wundere mich dann manchmal, was für Werte für den Vorwiderstand gewählt werden.
Zitat von DRG-ler im Beitrag #6...und mit dem puffern mit Goldcaps bin ich an der "kotzgrenze" angekommen.
Was willst Du uns damit sagen? Ist kein Effekt mehr zu spüren?
Zitat von DRG-ler im Beitrag #6Apropos Pufferspeicher... Die Fichtelbahner gehen hier den Weg über Lipo-Akkus. Das ist in meinen Augen ein Problem, für die Leute, die Ihr Rollmaterial nur selten einsetzen. Die Akkus lassen sich nicht von der Schaltung trennen. Ergo: Sie sind in kürzester Zeit tiefentladen, was zum Schnelltot des Akkus führt!
Die Verwendung der Lopis hatte ich bis jetzt nur zur Kenntnis genommen und noch keine Nachforschungen zu Vor- und Nachteilen angestellt. Wie ist der Satz "Wichtig: Lipozelle mit Tiefentladungsschutz verwenden!!" zu bewerten? So damit nicht genau dies verhindert werden?
Oli will viele Ausgänge für noch mehr LEDs haben. Die sollen vielleicht auch noch dimmbar sein.
Im Susi-Modul werden die statischen Ausgänge mit digitalWrite() und die dimmbaren mit analogWrite() geschaltet. Das Dimmen wird auf diese Weise von der Hardware umgesetzt. Jedoch gibt es beim ATmega328p (Arduino Uno, Pro Mini, Nano) maximal 6 dimmbare Ausgänge, wenn keine Timer anderweitig verwendet werden. Will man sie verwenden, muss das Layout auch Rücksicht darauf nehmen. Sollen nun noch Effekte umgesetzt werden, sind dazu Timer notwendig. So geht es also nicht.
Es heißt also sich Gedanken über ein Softdimmen zu machen, welches möglichst viele Ausgänge gleichzeitig dimmen kann. Im Susi-Modul wird jeder Ausgang einzeln betrachtet, d.h. es muss jeder einzeln geschaltet werden. Bis jetzt ist dies kein Problem. Beim Softdimmen eine Flut von Befehlen, die den Prozessor überfordern dürften.
Ein anderer Wunsch ist es, für möglichst jeden Wagentyp eine eigene Platine zu entwicklen. Damit dies effektiv möglich ist, müssen Bausteine entwickellt werden, die sich leicht und flexibel an die notwendigen Gegenheiten anpassen lassen. Für die Software heißt dies, sie muss sich ohne Programmänderungen durch Definitionstabellen, wie z.B. die CVs im Dekoder an die Gegebenheiten anpassen lassen.
Die Programmierung muss also die Anforderungen dynamisch (Zugriff auf Variablen stattt Konstanten) umsetzen können und für das Dimmen äusserst effektiv sein.
Wie wird die Funktionskette sein:
Man wählt am Handregler eine Funktionstaste, die mittels des Digitalsystems zum Dekoder übertragen wird. An Hand des Mapping im Dekoders werden die Funktionsausgänge ermittelt, die geschaltet werden müssen. In den oben genannten Definitionstabellen für die Platine, auf der der Dekoder plaziert ist, werden abhngig vom Layout die Pins des Prozessors festgelegt, die den entsprechenden Ausgang zugeordnet ist. Mit den oben aufgeführten Befehlen können die ermittelten Pins geschaltet werden. Diese Befehle sind jedoch extrem langsam und sind somit für eine Dimmen vieler Ausgänge vollkommen ungeeignet.
Das Dimmen soll mit einer Fequenz von 62Hz in 32 (0 kein Dimmen) Dimmstufen erfolgen. Das ergibt eine Fequenz von 2kHz. Damit bleibt für das Ein- und Ausschalten der Ausgänge in der Dimmschleife sehr wenig Zeit, um Befehle auszuführen. Der Rest des Dekoders soll ja auch noch laufen, das DCC Signal erkennen und umsetzen.
Es muss also möglichst viel in das Vorfeld, also außerhalb der Dimmschleife, verlegt werden. Mein erster Gedanke war: es muss möglich sein, alle Bits (die Pins) eines Ports gemeinsam mit einem Befehl zu setzen. Um dies ausführen zu können, müssen jedoch die Pins den Ports und Bits des Prozessors zugeordent werden. Es waren also Funktionen zu suchen, mit denen man dies erledigen kann. Selber machen, war hier die letzte Wahl, da dies sehr handwareabhängig ist.
Ich habe nun ein Testprogramm geschrieben, bei dem mit dem Timer2 der Takt für das Dimmen erzeugt wird. Ich habe dann das PortB für die Tests ausgewählt und habe die ersten 6 Bits als Ausgänge ausgewählt. Dies sind dann beim Arduino die Pins 8 bis 13. Es soll fiktiv das Pin 12 des Arduinos geschaltet werden. Dabei sollen die Pins 10 und 11 dimmbar sein und Port 8, 10 und 12 sind eingeschaltet. Um die Problemstellung auf das Wesentliche zu konzentrieren, ist dies in diesem Testprogramm statisch angelegt. Es kann also im Moment nichts geschaltet werden und es gibt nur eine Dimmstufe für die beiden gedimmten Ausgänge.
Zu Beginn des Programm, wird die Portverwaltung initialisiert. Dabei muss das Stellen der Bits des Ports auf Output auch noch dynamischer gestaltet werden. Wobei dies eigentlich nicht zeitkritisch sein sollte. Am Ende Programmausschnitts ist die erste der beiden Befehlfsguppen die jenige, die zum Beginn eines Dimmzykluses die Ausgänge einschaltet und die Zweite, die sie nach dem Ablauf der Dimmzeit wieder ausschaltet.
Da die LEDs gegen VCC geschaltet sind, arbeiten die Ausgänge invertiert, d.h. Pin aus bedeutet LED an.
activPinsPortB = B00111111; // Benutzte Pins des Ports statePortB = B00010101; // Status (an/aus) der pins des Ports dimmedPinsPortB = B00001100; // gedimmte Pins des Ports inverted = true; // Port soll invers betrieben werden
// aktive Pins fuer das Dimmen einschalten if (inverted) *out &= dimmMaskOnPortB; else *out |= dimmMaskOnPortB;
// aktive Pins fuer das Dimmen ausschalten if (inverted) *out |= dimmMaskOffPortB; else *out &= dimmMaskOffPortB;
Ergänzung am 17.09.2017 Das Coding funktioniert in der dargestellten statischen Version. Werden jedoch die Bits der ersten Variablen durch Bitmanipulationen durch Z.B. das Auswerten von DCC- oder Susi-Nachrichten gesetzt, haben sich Probleme gezeigt. Da uf der einen Seite das Programm so nicht mehr existiert und somit korrekt dargestellt werden kann, und auf der anderen Seite der Sinn dieses Beitrag nicht beeinträchtigt wird, überlasse ich es dem Experimentierfreudigen, eine für ihn funktionierende Variante zu finden. In der jetzigen Programmversion unterscheide ich nicht mehr zwischen gedimmten und ungedimmten LEDs. Alle eingeschalteten LEDs werden zu Beginn eines Dimmzykluses eingeschaltet, aber nur die gedimmten LEDs werden nach Ablauf der Dimmzeit wieder ausgeschaltet. Damit entfallen die Variablen statePortB und dimmedPinsPortB für die Unterscheidung zwischen gedimmten und ungedimmten LEDs.
Wie soll es weiter gehen: Neben dem oben Aufgeführten sollen die Pins schaltbar sein, weitere Ports und alle Dimmstufen sollen unterstützt werden. Verläuft dies ebenfalls erfolgreich, werde ich es in den Susi-Modul intergrieren. Dabei ist die Ports-Klasse des Moduls anzupassen und von Pin auf Portbetrieb umzustellen. Diese Klasse soll dann auch für den Wagendekoder Verwendung finden.
Wenn wir Glück haben, haben wir dann 16 dimmbare Pins (Ausgänge). War nicht irgendwo die Rede von über 20? Ideen sind gesucht. Ich habe da schon welche. Eine hat sich als Sackgasse erwiesen, da in einer Interuptroutine nicht anwendbar. Aber ich habe noch eine.
Mal sehen, ob ich jemanden neugierig machen könnte Manfred
Zitat von dr iv im Beitrag #9 Das Dimmen soll mit einer Fequenz von 62Hz in 32 (0 kein Dimmen) Dimmstufen erfolgen. Das ergibt eine Fequenz von 2000kHz. Damit bleibt für das Ein- und Ausschalten der Ausgänge in der Dimmschleife sehr wenig Zeit, um Befehle auszuführen. Der Rest des Dekoders soll ja auch noch laufen, das DCC Signal erkennen und umsetzen.
da liegst Du aber kräftig daneben. 62Hz mit 32 Stufen macht knapp 2kHz und nicht 2000kHz (=2MHz). Wenn der Controller mit 8MHz rennt, bleiben 4000 Instructions minus ISR zwischen zwei Interrupts des Timers und das ist eine Menge Holz. DCC-Decodierung läuft eh im Interrupt und die Umsetzung ist zeitunkritisch. Und wenn das wirklich nicht reichen sollte (glaube ich aber nicht) dann kann ein 328 bis 20MHz.
Zitat von dr iv im Beitrag #9Mal sehen, ob ich jemanden neugierig machen könnte
Neugierig nicht, da ich für so viele dimmbare Ausgänge in einem Fahrzeug keine sinnvolle Verwendung habe, aber es hat noch nie geschadet, über den Tellerrand zu schauen.
Thomas
Das Schöne an einheitlichen Standards ist es, dass es so viele verschiedene davon gibt. Toleranz ist die Erkenntnis, dass es sinnlos ist, sich aufzuregen.
ja es sollten 3 Nullen oder das k werden. Habe es korrigiert.
Aus dem Gespilee hat sich nun ergeben, dass der Aufwand z.B. beim digitalWrite zum Arduino Projekt gehört und nicht zum C++. Es hat auch sehr viel mit der Portabilität der Programme bzgl. der vom Arduino unterstützten Prozessoren zu tun. Im Prinzip ist der der obigen Lösung der Aufwand immer noch da. Nur eben nicht bei jeder Ausgabe sondern genau einmal pro Bit und Port. Beim Soft-Dimmen zahlt sich das dann richtig aus. Bei der BR110 habe ich bei den roten LEDs 15kOhm drin. Trotzdem war es mir noch zu hell und habe sie gedimmt. Wenn wir jetzt noch Effekte einbauen wollen, brauchen wir dafür sinnvollerweise Timer. So macht das in meinen Augen erstmal Sinn mit Software zu dimmen. Bei der 110 musste ich auch das Layout so gestalten, dass ich die dimmbaren Ausgänge verwende. Wenn alle dimmbar sind, braucht man sich da keine Gedanken mehr drüber machen. Auch werden die Platinen für die Wagen schmal sein und viele Leitungen haben müssen. Jeder Schnörkel der wegfällt, ist da von Vorteil. Du schreibst ja selber, dass Du keine Probleme mit der Befehlsausführung siehst. Warum dann künstlich verknappen, wenn es dann eh da ist und geht. Ich überlege eigentlich eher zu 8MHz zu gehen, da da kein Quarz benötigt wird. Ds sind 2 Pins mehr.
Wir haben jetzt mal unabhängig voneinander Lichttests gemacht und sind da beide auf 0,5mA pro LED gekommen. Und das könnte noch zu hell sein. Die Widerstände möchte ich dann nicht umlöten müssen und es ist schön, wenn man Spielraum hat.
Endlich kann ich nun auch mein Problem im Susi-Modul lösen, wo ich auf Dein Anraten den digitalRead durch ein bitRead ersetz habe, damit die ISR schnell genug wird. Eigentlich ist das Programm so angelegt, dass man den Pin vorgeben kann, was aber momentan nun erstmal hart verdrahtet ist und demzufolge nicht allgemeingültig funktioniert.
Es ist also eine gute Möglichkeit, IOs in ISR Routinen flexibel aber dennoch effizient zu programmieren, damit es mit der ISR auch funktioniert..
Moin Manfred, da würde ich eh anders rangehen. RAM hat der 328 ausreichend, also für jeden anzusprechenden Port 32 Byte ablegen, die beim Eintreffen eines Befehls errechnet und abgelegt werden - da ist Zeit und so häufig passiert das ja auch nicht. Erfordert etwas Intelligenz in der Software und der Planung, damit da nix flackert. In der ISR selber werden dann die 'vorgefertigten' Bytes bei jedem Lauf über einen Zähler mit Indexfunktion an die Ports geschaufelt. Schneller geht es wohl dann nicht mehr. Es geht mir nicht um 'künstliches Verknappen' von Möglichkeiten in der Lichtsteuerung, von mir aus kann man da auch noch je Fahrzeugende einen weiteren Prozessor an SUSI hängen und im Führerpult die Sifa-Lampe blinken lassen. (Das gibt dann auch mehr Platz im Fahrzeug, da nur ein Bus benötigt wird.) Es wird in der Baugröße H0 einfach nicht mehr sinnvoll anwend- und steuerbar, wie man leider immer öfter beobachten kann. Und da sehe ich die Schere zwischen Aufwand und Nutzen immer weiter auseinander gehen. Sicherlich kann das für ein vor der Nase stehendes Funktionsmodell in 0 oder 1 attraktiv sein, aber langsam gleitet das in die Richtung 'mein Haus - mein Boot - meine Funktionsausgänge' ab. Im Moment haben die Hersteller den Trend zu immer mehr Funktionen entdeckt, aber leider bleibt eine saubere Antriebs-/Fahrwerkskonstruktion dabei meist auf der Strecke, von einer auch nur halbwegs brauchbaren Soundsteuerung garnicht zu reden (wie ein Video von der Brawa 94 hier vor ein paar Tagen eindrucksvoll bewiesen hat - da schüttelt es den Hund samt der Hütte. Das ist aber nur meine vollkommen unmaßgebliche Meinung und es gilt sowieso: Leben und leben lassen und es ist ein Hobby. Viel Spaß beim Entwickeln und Bauen!
Thomas
Das Schöne an einheitlichen Standards ist es, dass es so viele verschiedene davon gibt. Toleranz ist die Erkenntnis, dass es sinnlos ist, sich aufzuregen.
im zweiten Teil Deiner Antwort schweifst Du schon recht vom Thema ab. Aber Recht hast Du schon und ich sehe auch oft den Mehrwert nicht, wozu ich einen Haufen Geld ausgeben soll. Ordentlicher Antrieb, ordentliche Räder und ordentliche Achslagerung sind mir wichtiger. Den Schnickschnack mache ich selber. Da weiss ich wenigsten, wo ich mich beschweren kann und auch u.U. eine Lösung bekomme. Habe gerade mal wieder die Hotline bei Roco überfordert. Sie wünschten mir dann noch viel Spass am Hobby. Den werde ich haben, aber wohl anders als sie es interpretiert haben wollten. Weiter Käufe sind nun erstmal zurückgestellt, bis das Problem behoben werden konnte.
Es geht also um mein Hobby. Und das ist schon seit Jahrzehnten eine Kombination aus Modellbahn und Elektronik. Und 1987/88 kam dann noch mein erster Heimcomputer dazu. Es geht also nicht um " meine Funktionsausgänge", sondern um Spielereien und Erfahrungsaustausch. Das Ziel ist dabei eigentlich egal.
Das Thema heißt "Ein Funktionsdekoder für Wagen könnte es werden". Wenn da als erster Beitrag eine Kaufempfehlung für einen primitiven Wagendekoder für viel Geld kommt, hat man das Thema nicht verstanden und verbindet Modellbahn mit Kaufen. WIe heißt es so schön: Thema verfehlt, fünf, setzen!
Es soll darum gehen, sich mit den kleinen Kisten auseinander zu setzen und es sollen Anregungen dazu gegeben werden. Ich will aber auch nicht die 1000ste Befehlsbeschreibung hier einstellen. Das können andere besser. Es ist schon bemerkenswert, dass eine Reihe von Leuten nur "Funktionsdekoder für Wagen" lesen, aber nicht dahinter blicken. Scheint ein Problem der Zeit zu sein. Nur an der Oberfläche kratzen.
Genau aus diesem Grund stelle ich hier momentan kein vollständiges Programm ein. Das wird nur mal daufgespielt, wenn überhaupt, es wird sich gefreut, dass es funktioniert, und dann liegt die Kiste in der Ecke bis sie in den Müll geht. Da man sich nicht wirklich damit auseinander gesetzt hat, werden die Möglichkeiten nicht erkannt.
Wenn man so eine Klasse für Ports hat, wie weit ist es da noch zu einem weichen Übergang von Signalbildern? Viel Brauchbares habe ich dazu bisher nicht gefunden. Und wenn, war es meist fest eingebunden in das Projekt und nur mit erheblich Aufwand herauszulösen. Verlangt nicht unser Hobby viel Fantasie? Wo bleibt sie hier?
Das der 328 austreichend RAM hat, kann ich so nicht sagen. Habe ihn schon mal beim Susi-Modul gegen die Wand gefahren, weil er ausgeschöpft war. Man wundert sich nur, dass die Kiste nicht mehr mag.
Bei den Dimmwerten orientiere ich mich da etwas an den Zimo Dekodern. Da gibt es 8 mögliche Dimmgruppen (vom Adressraum her gesehen) , also 7 Dimmwerte und "Dimmen ausgeschaltet". Es können also maximal 7 Werte plus Einschalten sein. Ob ich es nun so machen, wie Du es beschreibst, oder nur 8 Werte vorsehe und die dann an die Dimmstufen in der ISR Routine binde, habe mich noch nicht entschieden. Also die bekannte Entscheidung zwischen Platz und Zeit.
Da wir asynchrone Programmausführung haben, kann es sein, dass ein Dimmzyklus gestartet wird. Die gedimmten LEDs geht an. Dann wird eine dieser LEDs durch einen DCC Befehl ausgeschaltet und damit das Dimmen weggenommen. Dann kommt im Dimmzyklus der Moment, wo die LED wieder ausgeschaltet werden soll, was ja nun für diese LED nicht mehr passiert, da die Masken nicht mehr zum Einschalten passen. Die LED leuchtet also lustig weiter und alle wundern sich. Da die Zeit hier mit spielt, ist es extrem schwer, diese Art von Fehlern zu finden. Da hilft nur, die Probleme verstanden zu haben und ordentlich zu programmieren. Das Problem kann man z.B. umgehen, indem man von den Werten eine Kopie im Dimmzyklus anlegt. Dann wären wir schon bei 64 bzw. 16 Byte. Pro Port wären dies dann 192 bzw 48 Byte. Haben wir wiklich genügend RAM? Mal sehen wie es ausgeht.
Die Frage, wo Ports hernehmen, wenn die Hardware keine mehr bietet, beschäftigt mich auch. Da Buskontroller mit 8 Bit rein und 8 Bit raus recht groß sind, fällt das aus. Bis jetzt habe ich genau einen gefunden. Serielle Interface bedienen scheitert, wenn man etwas in ISR Poutinen machen will, um sie zu steuern. Somit fällt diese Linie mit ihren zahlreichen Möglichkeiten auch aus. Das Ding müsste also die notwendige Inteligenz selber haben. Ah, zweiter Prozessor wäre die Lösung, Die Idee habe ich auch schon gehabt. Susi? Wo kommt der Master her, der den Bus treibt. Gut Zugriff auf Programmcoding hätte ich.
Mich beschäftig schon seit einiger Zeit folgende Zeile aus der aktuellen Bedienungsanleitung von Zimo Dekodern auf Seite 32:
#394 / ZIMO Konfig. 4 / Bit 2 / 0 / Bit 2 = 1: I²C an SUSI-Schnittstelle
Was ist dies? Was kann man damit machen? Wo gibt es eine Beschreibung, wie das logische Protokoll aussieht. Bis jetzt habe ich nichts dazu gefunden.
Ich habe aber das hier gefunden. Und es funktioniert. Hatten wir nicht schon eine Port-Klasse für den zweiten Prozessor? Na noch nicht ganz, aber sie ist im Werden.
Also vergiss die ESU 94. Bei den Herbstneuheiten ist auch bis jetzt nichts dabei. Also Anlage weiter bauen und Ardoinos weiter ärgern.
um mich in ein Thema hineinzuarbeiten brauche ich (persönlich!) immer ein konkretes Ziel. Irgendwas mal ausprobieren ohne etwas Konkretes erreichen zu wollen, macht mir wenig Spaß und die Zeit ist auch immer recht knapp. Für Modellbahnanwendungen hat der 328 meiner Erfahrung nach in den meisten Fällen ausreichend RAM, ich sehe auch hier keinen Engpass. Pro Port ein Byte x Anzahl Dimmstufen reicht aus. Dieses Bytearray wird bei jedem Befehl auf einen Ausgang eines Ports angepasst, in der ISR muss da nichts getan werden. Etwas Intelligenz muss das Programm aber eben haben. Beispiel: Pin 0 eines Ports wird betrachtet Step_Dimmzyklus voll_eingeschaltet 1/16_gedimmt aus 0 0bxxxx xxx1 0bxxxx xxx1 0bxxxx xxx0 1 0bxxxx xxx1 0bxxxx xxx1 0bxxxx xxx0 2 0bxxxx xxx1 0bxxxx xxx0 0bxxxx xxx0 3 0bxxxx xxx1 0bxxxx xxx0 0bxxxx xxx0 4 0bxxxx xxx1 0bxxxx xxx0 0bxxxx xxx0 5 0bxxxx xxx1 0bxxxx xxx0 0bxxxx xxx0 6 0bxxxx xxx1 0bxxxx xxx0 0bxxxx xxx0 7 0bxxxx xxx1 0bxxxx xxx0 0bxxxx xxx0 8 0bxxxx xxx1 0bxxxx xxx0 0bxxxx xxx0 9 0bxxxx xxx1 0bxxxx xxx0 0bxxxx xxx0 .. ..... 32 0bxxxx xxx1 0bxxxx xxx0 0bxxxx xxx0
Die Programmintelligenz besteht dann darin, die Tabelle beim Einschalten eines Ports, also Bit 0 auf 1 setzen, von oben nach unten und beim Ausschalten, also Bit 0 auf 0 setzen, von unten nach oben anzupassen. Damit gibt es kein Aufblitzen.
Den Satz: Zitat "Serielle Interface bedienen scheitert, wenn man etwas in ISR Routinen machen will, um sie zu steuern. " verstehe ich nicht. Serielle Schnittstellen bedient man immer im Interrupt, ggf. mit einem kleinen Ringpuffer. Effektiver geht es nicht.
I²C würde ich mir nicht antun, das ist relativ langsam und auch anfällig; hier reicht SPI aus.
Und um es mal auf die Spitze zu treiben: Wenn ich unbedingt (also wirklich unbedingt haben will) so viele Ausgänge benötige, dann würde ich einen dicken µC im BGA-Gehäuse (ATMega2560) auf 4-lagiger Leiterplatte nehmen, bestücken lassen und glücklich sein 8-)) Bei 0,5mA pro Ausgang braucht man auch keine Treiber.
Thomas
Das Schöne an einheitlichen Standards ist es, dass es so viele verschiedene davon gibt. Toleranz ist die Erkenntnis, dass es sinnlos ist, sich aufzuregen.
die obige Matrix zeigt mir, dass Du aus der prozeduralen Welt kommst. Als ich in die objektorientierte Welt eingestiegen bin, dachte ich auch, wie bekommt man da effektiv Massenprozesse hin? Mit den richtigen Konzepten ist dies auch effektiv möglich und man bekommt vieles vom System geschenkt, wie das Aufräumen des Hauptspechers oder die Parallelisierung. Ohne z.B. die Vererbung und die Ereignisverarbeitung der objektorientieren Programmierweise, wären viele moderne Softwaresanwendungen nicht denkbar. Ein prozedural denkender Programmierer hätte nie eine Change, in der gegeben Zeit etwas brauchbares abzugeben. Ich kenne nun beide Welten und möchte aber die objektorientierte nicht mehr missen. Im Bereich der Hardwareprogramierung hat das prozedurale Programmieren noch eine Daseinsberechtigung, aber notwendig iat sie auch nicht wirklich. Nur wieviele der Programmierer bewegen sich noch auf dieser Ebene der Hardwareprogrammierung? Gut hier haben wir es damit zu tun. Trozdem überwiegen für mich die Vorteile des objektorientieren Programmierens, auch wenn man sich wegen der Schwachbrüstigkeit der Technik mal ein paar Gedanken mehr machen muss als normal übich wäre.
Zum Dimmen: Es sind also momentan bei mir Vekoren mit 32 Byte für die Dimmstufen geworden. Und dies 2 mal. Die dann nochmals pro Port, was in der konkreten Anwendung verwendet wird.
Im ersten Verkor werden die Ausgänge verwaltet. Dabei wird im Feld mit dem Index [0] bei aktiven Ausgang dieser eingeschaltet. Und im Feld mit dem Index [Dimmwert] wieder ausgeschaltet. Nicht gedimmte aber eingeschaltet Ausgäge werden dabeu nie ausgeschaltet. Da, wie ich bereits mal geschrieben hatte, nur sieben verschiedene Dimmwerte möglich sind, die aber allen Ausgängen zugeordet werden können, ist der Vektor so eher schwach besetzt. D.h. vieles ist null. Die Verwaltung vereinfacht sich dadurch in meinen Augen gewaltig, da für einen eingeschalteten, nicht gedimmten Ausgang ein Bit, und für einen eingeschalteten, gedimmten Ausgang zwei Bits zu setzen sind. Nur beim Ausschalten oder dem Ändern des Dimmwertes muss der ganze Vektor betrachet und der Inhalt gelöscht werden. Der Inhalt des zweite Vektors wird unter Berücksichtigung des möglichen invertierten Betriebs zu Beginn des Dimmzykluses aus dem ersten Vektor auf Anforderung bei Änderungen übernommen. Mit der Programmzeile
leiste ich mir den Luxus, die nicht besetzten Felder mit dem Index [1] bis [31] des Vektors bei der Verarbeitung in dem Dimmzyklus zu übergehen.
Ich habe mir mal den Spass gemacht und habe alle 10ms 4 Bytes über I²C an einen Sklaven gesendet und dort empfangen und ausgewertet. Nach 2 Stunden Betrieb waren keine Fehler aufgetreten. Ich denke mal, die Aussage die Fehleranfälligkeit rührt aus der Verwendung als Bussprotokoll unter Anlagen her. Wäre die Aussage also hier zutreffend? Das schnell genug wäre noch zu prüfen. Wie ich mir die Umsetzung vorstelle, wird da aber keine Schnelligkeit gebraucht. Mit SPI gäbe es ja noch eine Alternative.
Da ich nun ein privates "Wirtschaftunternehmen" betreibe, muss ich auch auf die Wirtschaftlichkeit achten. Da passt der ATMega2560 mit 4 lagigen Leiterplatinen momentan überhaupt nicht ins Konzept für derartige Projekte. Auch gehen moderne Konzepte eher zu verteilten Szenarien als zu Monsteranwendungen. Sie lassen sich besser skalieren. Hier bezüglich der Ausgänge. Und es ist mehr als ein Sklave möglich.
Das mit den Treibern bei den LEDs sehe ich auch so. Da ich nicht weiss, was an dem Susi-Modul mal so dran hängen wird, sind da die Ausgänge mit Treibern bestückt, die einen normalen (nicht invertierten) Betrieb erfordern. Bis jetzt kann ein Mudul nur als Ganzes normal oder invertiert betrieben werden. Da einzelne Ausgängex beim Wagendekoderu.u. Treiber benötigen, muss in diese Fällen dann noch nach Lösungen gesucht werden.
Ach ja, auch ich habe dabei ganz konkrete Ziele. Sie haben aber nicht unbedingt was mit Modellbahn und Materiellen zu tun. Den Luxus kann ich mir mittlerweile leisten. Ich muss ja meine Zeit nicht mehr durch den Verkauf meiner Arbeitskraft reduzeiren. Somit bleibt mir die Hast nach 'mein Haus - mein Boot - meine Ziele' erspart.
hier ist ja nun länger nichts passiert. Das heisst aber nicht, dass bei mir bzgl. des Themas nichts passiert ist.
Meine Entenfamile, bestehend aus einer Entenmutter und zwei Kücke,n waren der Meinung, dass ich wieder mal ein Lebenszeichen geben soll.
Nach den Beiträgen hier war nun die Frage, in welcher Sprache sich die Enten unterhalten wollen. Sie habe sich auf das I²C Protokoll geeinigt und haben einen Dialekt entwickelt, wie sie sich über diesen Kanal unterhalten können. Die Mutter hat dann erstmal ein Veto eingelegt und festgelegt, dass nur sie Kommandos gibt und die Kücken gehorchen sollen. Wenn die Kücken mal etwas größer sind, kann es auch eine Anfrage mit Antwort geben, so dass die Kücken ihre Wünsche an die Mutter formulieren können.
Nachdem nun alle fleißig geübt haben, funktioniert die Kummunikation recht ordentlich und die Kücken führen die Komendo der Mutter kommentarlos und korrekt aus. Z.Z. ist es möglich, dass alle Kücken das gleiche Komando ausführen. Die Mutter kann aber auch jeden Kücken spezifische Kommenados erteilen.
So sieht das dann mit 3 Arduinos aus.
Rechts am USB Kabel ist die Mutter und daneben die beiden Kücken. Das USB Kabel dient hier nur der Spannungsversorgung.
Alle Mitglieder der Familie führen ihre Kommunikation über 4 Kabel. Auch wenn der Mutter noch Kücken aus dem Brutschrank untergeschoben werden, bleibt es bei den 4 Leitungen, zwei sind Datenleitungen, Masse und VCC. Versorgen sich die Kücken selber, kann auch die VCC Leitung noch entfallen. Nur dann weiss das Kücken nach einem Futterverlust nicht mehr, was es tun soll. In dem Fall sollte man der Mutter noch einen Wiederholspeicher für die Kommandos gönnen, dass sie ihre Kücken regelmäßig mit Instruktionen versorgen kann.
Was soll das ganze?
Besser ist es natürlich, wenn es in die Wagen kommt und die Wagen gekoppelt sind. Da hatte die DR ja reichlich von.
Viele Grüße vom Entenhof äh von der Arduinofarm Manfred
größere Dinge klappen eigentlich nie beim ersten Mal. Besonders gilt dies als privater Einzelkämpfer, wo dann oft das 3. und 4. Auge und entsprechende Prüftechnik fehlt. So hatte ich bei der letzten Bestellung die Gunst der Stunde genutzt und einen ersten Entwurf für eine Wagenplatine erstellt, wohlwissend, dass nicht alle Probleme gelöst sind. Aber so lassen sich die Ideen doch besser überprüfen und z.B. der Einbau überprüfen.
So sieht nun der erste Entwurf zusammengebaut für einen Reko Sitzwagen aus.
Auf der Unterseite sind die Varianten des Bestückens mit LEDs für die im Beitrag #5 dargestellten Wagen zu sehen.
Die Platine auf das Untergestell des Wagens aufgesetzt.
Ganz links sind die Gleichrichter zu sehen. Am Elko liegt + des Dekoders an, der z.B. für den Anschluss von Kupplungen benötigt wird. Ein Treiber dafür ist vorgesehen, wurde aber noch nicht bestückt. Unter dem Elko befindet sich die 5V Spannungsversorgung. Sie versorgt den Prozessor und die LEDs. Jede LED (außer dem Rücklicht) wird von einem Ausgang des Prozessors über einen 20kOhm Widerstand getrieben und ist so einzeln steuerbar. Zwischen der Spannungsversorgung und dem Prozessor sind die Baugruppen für das Auswerten und Quitieren des DCC Signals zu sehen. Der zweite Prozessor wird für diesen Wagen nicht benötigt und ist deshalb nicht bestückt. Das ist dann auch noch mal eine Spielwiese. Momentan ist für jeden Prozessor eine eigene Spannungsversorgung vorgesehen. Es ist zu klären, ob dies überhaupt notwendig ist. Thomas hatte mir auch einen Regler für 250mA genannt, der getestet werden kann.
Was geht nun? Der Wagen wird über Drähte aus der Schiene mit einer DCC Gleisspannung versogt. Eine Versorgung über die Räder steht noch aus. Der Prozessor ist mit einem einfachen Programm versehen, der die Ausgänge einschaltet. Es fehlt also die DCC Signalauswertung. Auch das Quitieren von Programmierbefehlen ist noch zu implementieren und zu testen. Railcom ist nicht an Bord. Auch ist nichts zum Puffern vorgesehen und ist noch schaltungstechnisch einzubringen.
Insgesammt habe ich bis jetzt wenig Fehler im Layout feststellen können, die leicht zu beheben und zu umgehen waren.
So sieht es nun bei Dunkelheit aus.
Die LEDs haben eine Farbtemperatur von 6500°K, was einer Leuchtstoffröhre recht nahe kommen soll.
Nun will ich den Wagen mit einer Stromabnahme versehen, die Programme sind zu entwickeln, wobei in der ersten Stufe es nur um das Ein- und Ausschalten geht. Auch soll das Rücklicht getestet werden. Das Programmieren des Dekoders wäre wünchenswert. Da der Prozessor auf der Platine mit neuer Software versorgt werden kann, kann dies schrittweise erfolgen. Bei den Lokplatinen habe ich das jetzt etwa 50 mal praktiziert und es funktioniert recht gut und zuverlässig. Wenn er dann mal auf Reise gehen darf, wird wohl noch der Einbau einer Stromspeicherung notwendig sein.
Da ich noch eine Platine habe, werde ich dann auch mal die Maximalausprägung für den Mannschaftswagen des Hilfszugs testen. Der bekommt dann auch eine Spitzenbeleutung. Die Platinenteile dafür sind bereits vorhanden und können so auch ausprobiert werden. Das Versogen des 2. Prozessors mit Kommandos funktioniert ja schon, wie ich es im vorhergehenden Beitrag beschrieben habe. Dieser Teil der Software ist schon an Bord.
nun habe ich mich auch etwas mit der NMRAdcc Bibliothek angefreundet und schaffe ich es mittels eine Zentrale die Beleuchtung einschliesslich Rücklicht zu schalten.
Das Verwalten der CVs und die Möglichkeit sie zu Programmieren ist nun eine der weiteren Aufgaben.
Die Klasse für das Schalten der Funktionsausänge konnte ich unverändert und das Zuordnen der Funktionstasten zu den Ausgängen mit einigen Anpassungen vom Susi-Modul übernehmen. Der Wagen besitzt nun eine Hauptadresse, unter der er ansprechbar ist und auch über POM programmierbar sein soll. Auf diesem Weg soll es möglich sein, im eine Zweitadresse zu zuweisen.
Nun möchte ich das Zuordnen erweitern. Es soll Zuordnungen geben, die jeweils nur auf die Erstadresse oder die Zeitadresse reagieren. Besitzt der Wagen nur die Erstadresse, werden alle Zuordnungen berücksichtig.
So ist es denkbar, dass die Zuordnung der Beleuchtung unter der Zweitadresse abgelegt wird und das Rücklicht unter der Erstadresse.
Besitzt der Wagen nur eine Erstadresse, wäre also unter dieser jegliche Funktionen zu schalten. Wird der Wagen einem Zug zugeodnet, bekommt der Wagen als Zweitadresse die Adresse des Zuges wie auch alle weiteren Wagen. D.h. die Beleuchtung wäre nur noch über die Adresse des Zuges für alle Wagen mit dieser Adresse zu schalten. Das Rücklicht wäre aber auch weiterhin nur unter der Erstadresse schaltbar, denn es sollen ja nicht alle Rücklichter aller Wagen gleichzeitig schaltbar sein.
Ich muss mir also für den Betieb des zusammengestellen Zuges 3 Adresse vermerken, die Adresse des 1. und letzten Wagen und die Zugadresse, um alle Funktionen bei Lokwechsel schalten zu können.
Hat jemand eine Idee, wie ich des u.U. mit dem Merken nur einer Adresse bewerktstelligen könnte. Das Zusammenstellen des Zuges soll mittels POM erfolgen, damit die Wagen nicht einzeln auf das Programmiergleis müssen. Beim oben beschrieben Zusammenstelle, wäre also bei jedem Wagen nur die Zweitadresse zu setzen und beim Auflösen des Zuges zu löschen. Dr Vorschag sollte also nicht in einer POM Progrmmierorgie enden.
bei der Suche nach Lösungen für andere Aufgabenstellungen haben sich Lösungen für eine beliebige Anzahl von LEDs (bis 100) und deren freizügiges Dimmen, ohne den Prozessor dabei zu überlasten, ergeben. Eine erste Platine ist entworfen und könnte produziert werden.
Das Entwicklen der Software für den Wagendekoder ist auch weiter vorangeschritten. Momentan habe ich aber ein Problem mit dem Auslesen und Programmieren des Dekoders. Es mag nicht funktionieren. Da mir unklar ist, ob es an der Soft- oder Hardware liegt, möchte ich vor eine Produktion der Platine, das Problem unbedingt noch klären.
Zum Bestätigen (acknowledge) habe ich in der Software die Methode void notifyCVAck(void) , die von der NMRAdcc Bibliothek vorgegeben wird, ausgeprägt. Es wird ein Ausgang für 8 ms auf hoch gesetzt. Die Hardware für den Test besteht aus einer Diodenbrücke. Es wird das DCC-Signal zum Analysiseren der Befehle ausgekoppelt (Widerstand mit weißem Kabel. Durch die Diodenbrücke entsteht Masse (blaues Kabel) und +. Zwischen beiden ist ein Transistor BC849C und ein Widerstand 220 Ohm angeodnet. Der Transistor wird über ein Widerstand 22kOhm (gelbes Kabel) vom Ausgang des Prozessors angesteuert und soll den notwendigen Lastanstieg von 60mA für das Erzeugen der Bestätigung bereitstellen.
Bei Auslesen mittels einer Zentrale wartet sie eine kurze Weile, bis sie meldet, dass die CV nicht asulesbar wäre. Die Methode notifyCVAck wird mehrfach (wie erwartet zum Bestimmen der Werte der einzelnen Bits der CV) ausfgerufen, und das richtige Pin wird angesteuert. Der Elko und die Spannungsversorgung sind in dem Test wegen einer fehlenden Brücke abgekoppelt und sollten so das Ergebnis nicht beeinflussen.
Kann mir jemand Tipps zum Lösen des Problems geben. Da ich Fehler in der NMRAdcc Bibliothek gefunden habe, wäre es hilfreich, wenn mir jemand bestätigen könnte, das die Bibliothek an dieser Stelle korrekt funktioniert. Im Zusammenhng mit der NMRAdcc Bibliothek habe ich bis jetzt immer nur Hardwarelösngen mit Optokopplern gefunden. Da es ein beweglicher Dekoder werden soll, suche ich eine weniger aufwendige Lösung. Kennst da jemand Lösungsvorschläge?
H0-Modellbahnforum.de - das Forum mit der Forumbahn!
»
Technik und Steuerung von Fahrzeugen und Anlage
»
Digitaltechnik
»
Ein Funktionsdekoder für Wagen könnte es werden
17.08.2017 11:55 (zuletzt bearbeitet: 17.08.2017 11:58)
Thema drucken
Antworten
