[Bodo]

Hallo,

nach Ändern der Parameter musst Du den Dekoder einmal im "Inimode" starten - vorhandene CVs werden sonst unabhängig von der geänderten Tabelle wieder aus dem Eprom geladen.

Viele Grüße, Bodo

[nanunana]

interface.h Zeile hinzugefügt, habe keine Widerstände auf der Arbeit

1
 

#define FIXMODE INIMODE;
 

Danke und Grüsse

[Railcar]

Hallo Decoderbastler,

ich habe ein Problem(chen) mit dem Nano Eigenbaudecoder - ohne Loconet.

Nachdem für einige Monate Sendepause mit Moba war habe ich nun wieder den Decoder vorgeholt und habe festgestellt dass ich die CVs nicht mehr auslesen kann. Es wird immer no_ACK ausgegeben. D.h. der Decoder sendet kein ACK Signal., die Werte entsprechen 255.
Meines Wissens nach ist das ACK Signal eine 60mA Last für die der Decoder einen Verbraucher aktiviert.

Verstehe ich hier etwas falsch oder fehlt dem Decoder einfach nur eine Last die er aktivieren kann um das 60 mA "Signal" zu erzeugen, Wenn ja - Wo sollte die Last angeschlossen werden?
Ulrich

[MicroBahner]

Hallo Ulrich,

Zitat

---

habe ich nun wieder den Decoder vorgeholt und habe festgestellt dass ich die CVs nicht mehr auslesen kann.

---

Hat es denn schonmal funktioniert?

Zitat

---

Meines Wissens nach ist das ACK Signal eine 60mA Last für die der Decoder einen Verbraucher aktiviert.

---

Ja, und zwar für ca 6ms.

Zitat

---

Wo sollte die Last angeschlossen werden?

---

Dafür ist der 'AckPin' im Decoder da. Die Pinnummer wird in 'interfaces.h' festgelegt.
Hier mal ein Auszug einer möglichen Schaltung:


Wenn es schonmal ging, musst Du das aber schon so haben.

[Railcar]

Hallo Franz-Peter,

Ja, das hat schon mal sehr gut geklappt, ich konnte die CVs schreiben und auch auslesen. Wir hatte im März schon mal PNs getauscht deswegen.

Ich hab den ACK pin bei mir auf pin 3 gelegt und auch in der DCC_Zubehoerdecoder.h auf pin 3 gelegt.

1
2
3
4
5
 

//----------------------------------------------------------------
// Hardwareabhängige Konstante ( nicht per CV änderbar)
//----------------------------------------------------------------
const byte dccPin       =   2;
const byte ackPin       =   3;
 

Wenn ich nun versuche den Decoder zu lesen kommt die Fehlermeldung das kein ACK erkannt wird, d.h. es wird kein 60mA Stromimpuls erkannt.

Nun der seltsame Effekt - stelle ich eine analoge LOK auf die Schienen, der Decoder hängt direkt an der Einspeisung des Prog. Gleises, werden Werte vom Decoder gelesen, mal stimmen sie (CV8=13, CV1=20, etc) mal stimmen sie nicht. Daher meine Vermutung das irgendetwas fehlt um das 60 mA Signal zu erzeugen.

Welchen Einfluß auf die 60mA haben denn die verbauten Teile, insbesondere die Widerstände im ACK Kreis?

Ulrich

[MicroBahner]

Hallo Ulrich,

Zitat

---

Welchen Einfluß auf die 60mA haben denn die verbauten Teile, insbesondere die Widerstände im ACK Kreis?

---

Der zugeschaltete Lastwiderstand ist der R8 ( 100 Ohm ). Aber klar, wenn Optokoppler oder Schalttransistor hin sind, geht es natürlich auch nicht.

Zitat

---

Ich hab den ACK pin bei mir auf pin 3 gelegt und auch in der DCC_Zubehoerdecoder.h auf pin 3 gelegt.

---

Bei den Versionen ab 6.0 ( Loconet-fähig ) musst Du den Pin in Interfaces.h definieren. Der ist ja interfaceabhängig ( bei LocoNet gibt's den nicht ). Welche Version hast Du denn im Einsatz?
Und hast Du, seit es damals funktioniert hat, überhaupt eine neue Firmware aufgespielt? Wenn nicht kann es ja eigentlich nur an der HW liegen.

[Railcar]

Franz-Peter,
Danke für deine Hilfe soweit, aber ich glaube ich habe mehr als Zuviel Zeit mit dem nicht funktionierenden Decoder verbracht. Mir ist meine Zeit viel zu wertvoll als das ich mich über so etwas ärgere.
Die Sache hat sich hiermit erledigt und die Restmülltonne ist wieder mal etwas voller.

Ulrich

[md95129]

Vielleicht ein wenig Off-Topic, aber viele von uns betreiben die Arduinos nach dem Programmieren mit einem Steckernetzteil. Diese sind ueblicherweise nicht geerdet (kein "Schuko"-Stecker). Ich habe nun kuerzlich (und zum ersten Mal) ein Erlebnis gehabt, das mich nachdenklich stimmt.
Ich hatte ein System aus Arduino-DCC++, Microbahners Zubehoerdecoder, einem Raspberry-Pi mit JMRI-Software und alten Handys als Fahrregler aufgebaut. Die Verbindung zwischen Raspberry-Pi und Arduino DCC++ war ueber Bluetooth realisiert. So weit so gut, Alles funktionierte. Ich hatte dann einen zweiten Raspberry-Pi fuer meinen Laser in Betrieb genommen, als das Unglueck geschah: Das 5V Steckernetzteil (CE-TUEV etc.) hat die HDMI-Interfaces meiner gesamten Heiminstallation zerschossen. Es stellte sich heraus, dass das Steckernetzteil ca. 60V AC ueberlagert hatte. Es war nicht nur statische Aufladung oder ein Kriechstrom, da ich bei der Fehlersuche ordentlich eine "gewischt" bekam - zum Glueck ist die Netzspannung hier nur 127V. Als ich die Masse eines USB-Kabels, das an den RasbPi angeschlossen war, gegen Erde hielt, hat es kraeftig und anhaltend Funken gezogen. Auch ein zweites Netzteil der gleichen Marke verhielt sich aehnlich. Alle anderen Netzteile, die an der gleichen Steckdose eingesteckt waren, verhielten sich "normal". Moral: Wenn moeglich, geerdete Netzteile verwenden (wer will schon Fremdspannung auf der Anlage). Ich werde mich wegen der beiden Netzteile mit dem hiesigen "TUEV-> OSHA" in Verbindung setzen.
Regards

[nofear87]

Hallo Zusammen,

ich versuch gerade den Zubehördecoder zum laufen zu bekommen, als Zentrale nutze ich DCC++.

In der DCC_Zubehoerdecoder.h habe ich folgende Änderungen vorgenommen:

const byte DccAddr = 1; // DCC-Decoderadresse

const byte iniTyp[] = { FSERVO, FSERVO };
const byte out1Pins[] = { A3, A2 }; // output-pins der Funktionen
const byte out2Pins[] = { NC, NC };
const byte out3Pins[] = { NC, NC };

const byte iniFmode[] = { SERVOMOD, SERVOMOD };
const byte iniPar1[] = { 30, 30 };
const byte iniPar2[] = { 150, 150 };
const byte iniPar3[] = { 8, 8 };
const byte iniPar4[] = { 0, 0 }; // nur für Lichtsignale!

Da ich mir nicht sicher war ob DCC Befehle ankommen, habe ich mit dem NrmaAccessoryDecoder_1 Beispiel getestet:

notifyDccAccTurnoutOutput: 1, 1, 1
notifyDccAccTurnoutOutput: 2, 1, 1

notifyDccAccTurnoutOutput: 1, 0, 1
notifyDccAccTurnoutOutput: 2, 0, 1

Leider regt sich bei den Servos, welche an A3 und A2 hängen garnichts. Lediglich nach dem anschließen an USB bewegt sich einer der Servos für einen Bruchteil einer Sekunde.

Das Layout, welches ich nutze ist von Jürgen. Anbei noch ein Foto:

https://photos.google.com/share/AF1QipNC...lhkdktpb3czcXNR

Wie könnte ich mich potentiellen Fehler nähren?

Gruß
Robert

[MicroBahner]

Hallo Robert,
sonst hast Du an der DCC_Zubehoerdecoder.h nichts verändert? Das sieht auf den ersten Blick mal ok aus.
Hattest Du die vorher schonmal unverändert hochgeladen? Wenn Ja, musst Du beim Starten mal die Steckbrücke für den IniMode setzen, damit die veränderten CV-Werte übernommen werden.
Das im Layout die Pinreihenfolge an den Servoanschlüssen nicht der Reihenfolge im Servostecker entspricht hast Du berücksichtigt? (Beim Servo ist der + Anschluß in der Mitte ).

Ansonsten könntest Du auch mal den seriellen Monitor starten und den DebugModus aktivieren ( in src/DebugDefs.h bei der Zeile

1
2
 

//#define DEBUG
 
 

die Kommentarzeichen entfernen. Da wird dann beim Start die aktive Konfiguration ausgegeben, und Du siehst auch, ob Telegramme empfangen werden.

[nofear87]

Danke für die schnelle Rückmeldung.

Nein, ich habe nur die Änderungen welche ich hier gepostet habe vorgenommen.

Ja die Servo-Verkabelung passt meiner Meinung nach.

Nach aktivieren von Debug bekomme ich nur die folgende Ausgabe:

1
2
3
 

Betr:1023 -> Mode=Std
 
 

Leider keine Konfiguration und auch keine DCC Telegramme.

Edit: Ich habe auch gerade nochmal im Init Modus gestartet und anschließend wieder im Standard-Modus. An der Ausgabe ändert sich leider nichts. Was könnte ein Grund für die fehlenden Konfigurationen und DCC Telegramme sein?

Gruß
Robert

[MicroBahner]

Hallo Robert,
ich habe eben festgestellt, dass es im Debug-Modus eine Inkompatibilität zwischen den aktuellen MobaTools und dem Zubehördecoder gibt.
Das muss ich mir noch genauer anschauen.
Als Workaround könntest Du bei den MobaTools auf die Version 1.0.3 zurückgehen, die funktioniert für deinen Fall genauso.

[MicroBahner]

Hallo Robert,
was mit noch aufgefallen ist: wenn ich das Bild richtig interpretiere, benutzt Du den Drehencoder zur Justierung der Servos nicht. Dann solltest Du auf jeden Fall auch die Zeile

1
2
 

//#define ENCODER_AKTIV       // Wird diese Zeile auskommentiert, wird der Encoder nicht verwendet. 
 
 

entsprechend anpassen ( standardmäßig ist die Zeile nicht auskommentiert ).

[nofear87]

Hallo Franz-Peter,

den Decoder möchte ich gerne noch nutzen. Ich habe nur noch keinen passenden gefunden, die Anfrage an Jürgen läuft Schließlich ist die Möglichkeit der Justierung ein sehr nettes Feature, welches du da eingebaut hast.

Was soll ich sagen: In der Zwischenzeit läuft der Decoder bei mir. Warum es die Probleme gab kann ich nicht sagen. Nach dem 3ten mal Initialisieren läuft alles wie gewünscht. Eine Konfiguration gibt er allerdings immer noch nicht über den seriellen Monitor aus. Aber das ist nicht so schlimm. Ich bin erstmal glücklich.

Vielen lieben Dank nochmal für die Hilfe an der Stelle!!!

Gruß
Robert

[MicroBahner]

Hallo Robert,

Zitat

---

Eine Konfiguration gibt er allerdings immer noch nicht über den seriellen Monitor aus.

---

Liegt ja auch, wie oben geschrieben, an der aktuellen MobaTools Version. Die Ursache habe ich auch schon gefunden. Da es nur den Debug-Modus betrifft, wird das aber erst in der nächsten größeren Release behoben sein.

Edit: Es gibt aber auch noch einen einfacheren Workaround: Du must nur in der DCC_Zubehoerdecoder.ino die Zeile

1
 

#include "Interface.h"
 

auskommentieren oder löschen.

[nofear87]

Zitat

---

Hallo Robert,

Zitat

---

Eine Konfiguration gibt er allerdings immer noch nicht über den seriellen Monitor aus.

---

Liegt ja auch, wie oben geschrieben, an der aktuellen MobaTools Version. Die Ursache habe ich auch schon gefunden. Da es nur den Debug-Modus betrifft, wird das aber erst in der nächsten größeren Release behoben sein.

Edit: Es gibt aber auch noch einen einfacheren Workaround: Du must nur in der DCC_Zubehoerdecoder.ino die Zeile

1
 

#include "Interface.h"
 

auskommentieren oder löschen.

---

Guten Morgen,

entschuldige, das hatte ich überlesen. Vielen Dank für den Hinweis. Ich probiere es aus.

Gruß
Robert

[md95129]

Hi guys,
ich moechte mich heute ganz besonders bei Franz-Peter (Microbahner) fuer seine tollen Arbeiten an Zubehoerdecoder und Moba-Tools bedanken. Ich habe damit inzwischen ein komplettes System zusammengestellt, das ich hier vorstellen moechte:



Da ich mehrere Arduino Unos uebrig hatte, habe ich das Ganze damit aufgebaut. Im Detail:
- DCC++ Zentrale (1) https://github.com/DccPlusPlus/BaseStati...-DCC--Plus-Plus.
- Zubehoerdecoder (2) mit 6 Servos (5) und einem Doppelblinker (9). Der Drehencoder ( dient natuerlich zum Einstellen der Servos.
- DCC gesteuerte Drehscheibe (3) mit Schrittmotor unter Verwendung der Moba-Tools. Die Drehscheibe wird als Satz von Weichen angesprochen.
- Verteilerkasten (4). Hier wird natuerlich auch das Gleis angeschlossen.
- Raspberry Pi (6). Dieser Minicomputer laeuft unter Linux mit JMRI (https://www.jmri.org/), einer freien Modellbahnsoftware. Der Raspbi ist nicht galvanisch mit den anderen Komponenten verbunden, sonder verkehrt ueber Bluetooth mit der DCC++ Zentrale und ueber WiFi mit den drahtlosen Fahrtreglern.
- Diese Fahrtregler (7) - nur einer gezeigt - sind entweder Android Handys, Tablets oder I-phone/pads. Die Software fuer die Androidsysteme https://enginedriver.mstevetodd.com/ ist kostenlos, diejenige fuer Apple (http://www.withrottle.com/html/home.html) kosten ein wenig (Test SW fuer eine Lok frei). Mit den Handys/Tablets lassen sich auch Weichen schalten
In dem Bild oben habe ich aus Uebersichtsgruenden die Stromversorgungen weggelassen. Die Gehaeuse sind aus Acryl mit dem Laser geschnitten (Ich habe mit dem ganzen System so viel Geld gespart, dass ich mir dieses Geraet leisten konnte ). Die Gesamtkosten sind minimal:
- DCC++ Zentrale: Arduino + Motorshield ca. 15€
- Zubehoerdecoder: Arduino + Prototypshield ca. 6€
- Servos von Ebay im Zehnerpack ca. 10€, Halterungen von einem Freund in 3D gedruckt (als Ausgleich fuer Laserarbeiten)
- Drehscheibe: Arduino + Prototypshield + Schrittmotor ca. 8€ , Rest mit dem Laser geschnitten bzw. aus dem Schrott gerettet. Gehauese fehlt noch, da das Prototypshield noch nicht fertig bestueckt ist.
- Raspberry Pi: ca. 35€ (koennte auch durch einen PC ersetzt werden)
- Handys/Tablets: sind sowieso vorhanden.
Die Probleme bei der Inbetriebnahme:
- Am Ausgang der 6N137 Optokoppler musste ich einen 100pf Kondensator vom Ausgang gegen Masse einbauen, andernfalls kamen die Impulse nicht richtig durch. Die Massnahme macht fuer mich keinen Sinn, ich kam durch Zufall darauf. Leider sind die Probleme weg, wenn man ein Oszilloskop anschliesst. Es koennte ein Problem der Motortreiber an der DCC++ Zentrale sein (Spikes, die die NMRA Software durcheinanderbringen).
- Zwei fehlerhafte Steckernetzteile fuer den Raspbi haben mir mehrere Geraete zerschossen, ohne den Raspbi selbst zu beschaedigen.
Ansonsten war die Inbetriebnahme ein Vergnuegen, besonders mit Franz-Peters Software.
Als Loks setze ich Selbstbaumodelle mit einem selbstentwickelten Decoder ein, aber das ist eine andere Geschichte (viewtopic.php?f=50&t=145389).
Nochmals vielen Dank an Franz-Peter und eine klitzekleine Bitte: Es waere schoen, wenn die Auf/Abschwellzeiten "riseTime" der blinkenden LEDs mit ins Headerfile uebernommen werden koennten, da sie dann einfacher zu editieren sind, weil sie fuer manche Zwecke zu langsam sind.
Regards

[MicroBahner]

Ein sehr schönes Projekt, danke fürs Vorstellen . Wie man sieht, kann man da viel Geld sparen . Aber die Zeit dafür muss man dann natürlich auch als Hobby betrachten

[MicroBahner]

Hallo Henner,
noch eine Frage zu deinem Wunsch mit der 'riseTime'. Hättest Du das individuell für einzelne Led-Funktionen gebraucht, oder global als define z.b. für Blink-Leds und Lichtsignale? Individuell wird sicher etwas schwieriger, da ja eigentlich keine Parameter mehr frei sind. Da müsste man neue definieren.

[md95129]

Hallo Franz-Peter,
im Augenblick ist ja der Parameter fuer alle BlinkLEDs auch fest, siehe Zeile 139 in FuncClasses.cpp:

1
2
 

                _ledS[i]->riseTime( 500 );	
 
 

d.h. eine riseTime fuer alle LEDs wuerde genuegen. Die 500ms fuer das Auf/Abblenden der Signale sieht gut aus, nur fuer z.B. einen Warnblinker am Bahnuebergang ist es meiner Meinung nach zu lang. Ich habe es auf 200 gesetzt; das sieht fuer diese Anwendung besser aus.
Regards

[MicroBahner]

Hallo Henner,
also eigentlich keine erweiterte Funktionalität, nur eine zentrale, bequemere Änderbarkeit der derzeit festen Werte? Für Blinkleds und Lichtsignale ist es eh schon getrennt, da das 2 verschiedene Klassen sind. Also einfach 2 defines in der Konfig-Datei.

[md95129]

Genau, deswegen ja auch das Wort "klitzeklein" .

[Irgendwannwirdswas]

Hallo,
auch von mir erstmal vielen herzlichen Dank für dieses tolle Projekt .
Mit dem Teil lassen sich tolle Dinge darstellen -- auch wenn jeder kleine Schritt mit meinen laienhaften Kenntnissen schon eine größere Qual darstellt. Bis allein mal das Optokopler-Interface lief hat es ewig gedauert -- ein kleiner 300pf Kondensator hat dann Wunder gewirkt .... aber erstmal drauf kommen!
Seit heute funktioniert dann auch das Drehencoderinterface zur Servoverstellung. Nun gut, hat auch nur 3 Stunden gedauert bis ich herausgefunden habe dass der 10k Widerstand R19 auch benötigt wird, damit beim Wiedereinschalten die Werte nicht wieder überschrieben werden. Und noch eine weitere halbe Stunde dass als Nebenwirkung dieser Konstellation beim Aufspielen neuen Codes die Decoderadresse nicht geändert wird -- also Arduino dann beim Neubespielen immer von der Platine lösen und schon geht es wieder.

Eine Frage zu den Adressen: ist es korrekt, dass die maximale Decoderadresse im Sketch 255 ist? Hab mich beim Rumspielen gewundert dass der Decoder mit veränderten Adressen nicht mehr ansprechbar war (blöd: halt Compilerfehler ignoriert) und entnehme das nach einigem Suchen aus

1
 

const byte DccAddr
 

Hat das einen Grund in bewussten Beschränkungen, z.B. der DCC-Library oder ist das einfach nur Zufall? Ich glaube eigentlich an letzteres, denn der arduinobasierte DCC Sniffer kann die von Rocrail erzeugten Adressen >255 interpretieren.
Denke da mal so ein bisserl voraus an tolle Spielereien die in ferner Zukunft mit dem Decoder möglich wären ... Einzellampen für Häuser oder sowas, da könnten 255 Adressen in ganz ferner Zukunft vielleicht mal knapp werden (Anm: die MobaLEDLib steht irgendwann auch noch mal auf dem Plan, in der Arduino-Welt führen ja viele Wege nach Rom ...)

Beste Grüße
Achim

[MicroBahner]

Hallo Achim,

Zitat

---

ist es korrekt, dass die maximale Decoderadresse im Sketch 255 ist? ...

1
 

const byte DccAddr
 

---

Das dürfte noch ein Relikt sein ops: . Der Sketch kann schon auch mit höheren Adressen umgehen. Wenn Du beim Initiieren die Adresse automatisch vergibst, funktioniert das auch. Wenn Du höhere Adressen fest vergeben willst, ändere die Zeile einfach entsprechend ab:

1
 

const int DccAddr = 1024;
 

[211064]

Hallo allerseits,

ich möchte an meinem Arduino-Decoder Signale von Erbert betreiben, die einen gemeinsamen +-Pol haben. Dazu muss ich die entsprechenden Ausgänge invertieren. Bei roten und grünen LEDs reicht das völlig aus; mit den 5 V, die der Arduino zur Verfügung stellt, leuchten sie (mir) hell genug. Ein Problem habe ich mit weißen LEDs, die eine deutlich größere Spannung brauchen. Wenn ich gegen Masse schalten würde, könnte ich einen ULN2003 dazwischen setzen. Aber ich muss ja gegen + schalten - und stehe auf dem Schlauch. Was mache ich da?