[Robokalle]

Hallo zusammen,

ich brauchte einen Lichtsignal Decoder für 1 Signal auf ein Modul.
Meist waren diese ausgelegt für mehrer Signale.
Bei der suche stieß ich auf die Arduino nmradcc.h. -> Attiny85 von Digispark diese gibt es schon ab 1.25(29.12.2017) ein Brückengleichrichter und ein 22kOhm Widerstand.

Fertig ist der LED Lichtsignal Decoder für 1 Signal.

Und das ganze unter 1,50€ Die Signal LEDs brauchen aber einen angepassten Widerstand da die Versorgungspannung über 5Volt des Digispark geht. 220Ohm Widerstände funktionieren einwandfrei.

Die Links für die Software auf www.robokalle.de

Video über den Bau und Software bei https://www.youtube.com/watch?v=1CZm-1rwTGs&feature=youtu.be

viel Spass beim Nachbau.

Gruß Robokalle

[md95129]

Robokalle,
mich gruselt es immer ein bischen, die eingebauten Schutzdioden (trotz 22k Widerstand in Reihe) zur Spannungsbegrenzung des DCC Signals zu verwenden. Ich habe bei meinen Decodern sicherheitshalber noch eine Schottky-Doppeldiode an den Eingang gesetzt. Andererseits ist bei 1,50€ auch mal ein Ausfall zu verschmerzen . Ansonsten ein weiterer netter Einsatz des Tiny!
Regards

[franz_H0m]

Hallo Robokalle,

(was die Leute damals ihren Kindern für Namen gegeben haben )

Zitat

---

Fertig ist der LED Lichtsignal Decoder für 1 Signal.

---

cooler Minimaldecoder - Eingangspannung kaum geglättet, voll rauf mit der Digitalspannung und funktioniert. Ich hätte Sorge, dass in einem störungsreicheren Milieu das nicht so zuverlässig geht, aber bin bereit, mich eines besseren belehren zu lassen.

Hast Du davon welche schon richtig im Betrieb?

Zitat

---

Ich habe bei meinen Decodern sicherheitshalber noch eine Schottky-Doppeldiode an den Eingang gesetzt.

---

Henner, in Reihe mit dem 22k?

[md95129]

Die Doppeldiode liegt praktisch parallel zu den Eingangskappdioden des ATtiny. Durch die kleine Durchlassspannung sprechen die eingebauten Dioden nicht an. Aber das ist nur mein "Sicherheitsbeduerfnis". Einen kleinen Kondensator zum Ueberbruecken der kurzen Aussetzer waehrend des Umschalten des DCC Signals halte ich auch fuer eine gute Ergaenzung.
Regards

[Robokalle]

Hallo zusammen,

der Digispark hat einen 4,7 uF Keramik Kondensator mit an Board.
Beim testen mit einem Nano brauchte ich einen 10uF in der 5V-Leitung (Piepst sonst).

Langzeiterfahrung habe ich keine. Aber bei einem Lichtsignal kann nicht viel kaputt gehen oder verschalten.
Das mit einem zusätzlich Stütz-Elko kann bestimmt nicht verkehrt sein.

Gruß Kalle

[md95129]

Hallo Kalle,
jetzt muss ich zurueckrudern: Deine Loesung mit den eingebauten Schutzdioden zur Begrenzung der Eingangsspannung ist absolut richtig. In der Referenz-Anwendung 2508 von Atmel wird diese Schaltung ausdruecklich fuer einen Netz-Nulldurchgangsschalter vorgeschlagen. Der Strom sollte unter 1mA bleiben, was ja bei den 22kOhm der Fall ist. Also gibt es nichts mehr zu kritteln an Deiner Schaltung/Anwendung . Bei meinem Decoder hatte ich einen Prozessor verwendet, der nur eine Schutzdiode gegen Masse hatte (wegen 3V/5V Kompatibilitaet), deswegen mein (ueberfluessiger) Einwand...
Regards

[franz_H0m]

Hallo Kalle,

Zitat

---

...der Digispark hat einen 4,7 uF Keramik Kondensator mit an Board... Das mit einem zusätzlich Stütz-Elko kann bestimmt nicht verkehrt sein.

---

Es hat ja auch Vorteile, nicht überall massig Kondensatoren einzusetzen, dann müssen die auch nicht immer geladen werden, zieht weniger Strom.


Also Dein Decoder: genial einfach, einfach genial!

[Bodo]

Hallo,

genial einfach . Ich bin bisher gar nicht auf die Idee gekommen, es mal mit einem ATtiny zu versuchen. Müsste ja dann auch unabhängig von der Digispark-Platine funktionieren ... Der Universal-Dekoder von Franz-Peter (Microbahner) benötigt mehr als 8 KB, aber Deine schlankere Version oder andere Eigenentwicklungen müssten es ja dann tun.
Beim Neukauf von Bauteilen hat das Digispark-Board natürlich den Vorteil, dass der Spannungsregler bis max.35V schon drauf ist - die Nanos sind ja laut Spezifikation nur bis 12V freigegeben. Bei einer festen Installation auch kein Problem, aber das Digispark-Board dürfte damit sogar Teppich-/Tischbahning-tauglich sein.


Viele Grüße, Bodo

[B-B]

Hallo zusammen,

eine Frage an die Experten, ist es möglich ein Servo mit DCC auf der kleinen Platine zu steuern?
Wenn ja, bitte einen Schubser wie es am einfachsten ginge.

LG
Bernd

[MicroBahner]

Hallo Bernd,
in den Beispielen von Geoff Bunza, die bei der nmradcc-Lib dabei sind, wird die SoftwareServo Lib verwendet. Die Pulse die sie erzeugt sind zwar nicht sehr genau, und während der Pulse blockiert der Sketch, aber sie müsste eigentlich auch auf dem ATtiny85 laufen.

[B-B]

Hallo Franz Peter,

Ok dann werde ich mal darein fuxen


LG
Bernd

[JoWild]

Hallo Kalle,
die Idee ist Klasse ,
aber wenn man eine lesbare Anleitung schreibt, ist das wesentlich einfacher zu verstehen und auch zu realisieren.

Danke

[Robokalle]

Hallo zusammen,

@Bernd
Beispiele gibt es bei den nmradcc.lib bei den Beispielen. Ich habe probeweiser die SoftwareServo.h mit eingebunden und ein Testaufruf der Funktion gemacht. Das wird schon sehr eng mit dem Speicher. Die Stromversorgung vom Servo sollte auch nicht über den Digispark gehen. Wird bei den 60mA schon warm.

@JoWild

Zitat

---

aber wenn man eine lesbare Anleitung schreibt,

---

da happert es bei mir, sorry

Gruß Kalle

[FlorianG]

Hallo,
unter https://rudysmodelrailway.wordpress.com/...nction-decoder/ gibt es auch ein Beispiel, bei welchem der Digispark über einen Optokoppler angeschlossen wird, das Anschlussschema dafür ist auf https://rudysmodelrailway.wordpress.com/software/. Auf diese Weise kann er auch als Funktionsdecoder mit einer DCC-Adresse, 5 Ausgängen und Steuerung über F1-F12 genutzt werden oder als DCC-Decoder für mehrere DCC-Adressen (frei wählbar, müssen nicht aufeinander folgend sein)

[Robokalle]

Hallo zusammen,

heute habe ich 4 Decoder gebaut und einer hat auf umliegenden Adressen reagiert. Programmiert war Adresse 341 reagiert hat er bis 346.
Muss ich noch genauer untersuchen.

Fehler von mir siehe unten.

[s]ACHTUNG es gibt Toleranzen bei den Attiny85. Manche werten die DCC-Adressen in höheren Adressbereichen nicht sauber aus. Diese reagieren auf die umliegenden Adressen.[/s]

Gruß Kalle

[Flo_85]

Zitat

---

ACHTUNG es gibt Toleranzen bei den Attiny85. Manche werten die DCC-Adressen in höheren Adressbereichen nicht sauber aus. Diese reagieren auf die umliegenden Adressen.

Gruß Kalle

---

Wird der Attiny auf dem Modul mit dem internen Taktgeber betrieben? Wenn ja ist zu 99% dort die Ursache des Problems. Denn die internen Taktgeber sind alles andere als genau. Das heisst auch die Timer laufen mehr oder weniger ungenau. Im oberen Adressbereich kommen im DCC Signal sehr viele Einser, also kurze Impulse, hintereinander. Wenn da der Timer zu weit abweicht (hängt auch von der Software und der Art der Auswertung des Signals ab) kommt es genau zu diesem Phänomen, der Decoder liest eine 0 obwohl es eine 1 ist und schon reagiert er auf eine andere Adresse weil es durch den "Zahlendreher" seine Adresse ist. Das es nicht bei allen auftritt ist auch klar, schließlich ist die Abweichung immer "bis zu xy%" - manche haben weniger und da funktioniert es dann.

Die interne Taktgeber sind auch nicht temperaturkompensiert, wenn du also pech hast tritt das Problem im Sommer bei einem der anderen auch auf.

[Robokalle]

Hallo zusammen, habe den Fehler gefunden.

1 Falsch gesetzte Fuse "Selbstprogrammierung disable"

1 Adressen eingabe fehler.

1
2
3
4
5
6
 

#define Adressen 1
//byte ledpins [] = {8,9,10,11,12}; // Uno
byte ledpins [] = {0,1,3,4,5}; //Attiny85
 
int DCC_ADDR = 1;   // DCC-Adresse 
 

Ändern wollte ich DCC_ADDR in 341 geändert habe ich Adressen-> somit hat er alle weiteren 341 Adressen mit ausgewertet.

Beim Testen trat der fehler auf. Jetzt dachte ich es wäre der Resetpin der kein I/O war -> also Fuse umprogrammiert.

Das Programmetool myAVR ProgTool kann aber keine eFuse lesen/schreiben !? und schrieb trotzdem FF(vorher FE) rein.

Damit war der Kreislauf geschlossen. Ich bemerkte den Softwarefehler von mir. Aber es wurde keine neu Softwareversion aufgespielt. Er
programmierte sich ja nicht mehr.
Bis ich rausfand das es an der Fuse lag.

Alles in Ordnung kein Tolleranzen und so.

Gruß Kalle

[MTB-Ontour]

Hi Kalle,

ist Dir auch schon eine MM-Variante der lib untergekommen?
Ansonsten bin ich schwerst begeistert von der Idee, die Digisparks dazu zu verwenden.

Danke und Gruß

Michael

[Robokalle]

Hallo Michael,

Zitat

---

ist Dir auch schon eine MM-Variante der lib untergekommen?

---

schau mal hier

https://github.com/666c796e6e/LibMotorola

Gruß Kalle

[Bodo]

Hallo,

ich habe nun mal einen nachgebaut ... klappt im Prinzip gut. Ist das richtig, dass ich eigentlich noch Transistoren nachschalten müsste, um mit den Viessmann-Signalen auf gemeinsames "+" zu kommen ? Im Video scheinen die Ausgänge vom gemeinsamem "+" bei "Hell" auf "-" gezogen zu werden - bei mir scheinen sie dagegen bei "Hell" auf "+" (und damit aus) zu gehen.
Ob es reicht, die Signalbild-Definitionen umzukehren (Nullen und Einsen tauschen) habe ich jetzt noch nicht getestet. Ich habe nämlich noch nicht entschieden, ob ich dem "Dekoder" nicht doch noch eine Endstufe spendieren soll, damit die Signale mit den Vorwiderständen so angeschlossen werden können, wie sie aus der Packung kommen. Und ob das ganze in die C-Gleis-Bettung passt, habe ich auch noch nicht getestet .

Viele Grüße, Bodo

[hu.ms]

Sehe ich das richtig und man könnte das teil auch als kostengünstigen funktionsdecoder für die led-beleuchtung in wagen verwenden?
Vorausgesetzt, die stromstärke wird nicht überschritten. Könnte man in diesem fall einen transistor für bis zu 100mA nachschalten?
Und noch: ich würde einen smd-gleichrichter verwenden.

Hubert

[DerMödlinger]

Hallo Hubert!

Der Decoder reagiert auf Zubehörbefehle, nicht auf Fahrbefehle.

[hu.ms]

Ist aus meiner sicht egal ob ich eine led in einem signal oder in einem wagen schalte.

Hubert

[DerMödlinger]

Servus Hubert!

Natürlich kann man das machen.
Aber die Beleuchtung schalten kann man dann eben nicht über Lokadressen sondern nur über Weichenadressen.
Und eine fahrtrichtungsabhängige Beleuchtung für Front- und Rücklicht geht damit nicht.
Außerdem sind die Signalbilder fix im Code definiert. Also alle Ausgänge ein geht damit auch nicht so ohne Änderungen im Code.
Functionmapping ist ebenfalls nicht vorgesehen.

LG
AP

[Bodo]

Hallo zusammen,

leider ist es ja hier inzwischen Standard, nicht zwischen Hard- und Software zu unterscheiden ... die Dekoder-Software ist natürlich genau auf die Anwendung als Lichtsignal-Dekoder abgestimmt, die NMRA-Library kann aber beides.

Die hier vorgestellte Hardware passt vermutlich in einen H0-Wagen problemlos rein - in Personenwagen aber ganz sicher nicht unsichtbar. Da ist m.E. ein kleiner handelsüblicher Funktionsdekoder sinnvoller. Wenn es aber "ums Prinzip" oder um einen Wagen mit genügend von außen unsichtbarem Freiraum geht, sollte es funktionieren. Allenfalls eine zusätzliche Pufferung des Bausteins wird vermutlich nötig sein, um Kontaktunterbrechungen zu überbrücken.

Viele Grüße, Bodo