Hallo, um meine Wohnung etwas aufzuhübschen plane ich den Einsatz leistungsarmer (keine Luxeon) LEDs für eine Art Background-Beleuchtung. Die Anzahl der LEDs soll < 64 sein und Standardtypen (20mA, 2 - 3,5V Flussspannung) werden wohl reichen. Eigentlich möchte ich vermeiden, zu jeder LED einen separaten Draht zu ziehen um diese einzeln ansteuern zu können. Meine Idee: Ich spendiere jeder LED einen ATTiny und komme so mit 3 Leitungen aus (wie eine Art Lichterkette mit einzeln ansteuerbaren Lämpchen). -> Vcc -> GND -> BUS Über die Bus-Leitung würde ich die Tinys mittels eines Masterprozessors ansprechen (LED an, LED aus, LED Lichtstärke, ...). Hat jemand bereits einmal etwas ähnliches realisiert? Wie kann man das Vorhaben mit minimalem Bauteileaufwand realisieren? Wie könnte man den Bus am einfachsten umsetzen (physical layer)? Ich bin in der Lage Leiterplatten zu ätzen, zu bestücken sowie die Controller in C/C++ zu programmieren - daran wird es nicht hängen ;-) Gruß, Alex
mit einem mc an jeder led könntest du jeweils dateneingänge an datenausgänge hängen und so das signal immer schön neu aufbereiten. das würde "unendlich weit" funktionieren wenn zwischen den einzelnen stationen die länge nicht zuuuuu groß wird. dei daten solltest du schön langsam mit nur geringer baud/schrittrate senden. dann denke dir ein einfaches protokoll aus, etwa jede led/mc bekommt eine eigene feste adresse Mit dem master adressierst du dann die einzelnen leds und gibst ihnen noch zusätzlich helligkeitsinformationen mit, welcher der mc dann per pwm umsetzt. Startbyte| Adresse | Helligkeitswert | Stopbyte das ganze sendest du permanent. So etwas ist sehr leicht zu programmieren und umzusetzen, soweit du alles erst einmal auf einem schönen leeren blatt papier entwickelst und dann erst ans löten und tippen gehst ;-).
Hi Alex, hab was ähnliches schon mal gemacht. Hab aber nur max. 6 Abnehmer und max. 5m Leitung. In der ersten Version hatten ich mal einen 74HCT14 als Ausgangstreiber verwendet. Hatte dann Anstiegszeiten von >1µs pro Flanke bis ich auf einem vernünftigem Pegel war. Bei einem sehr langsamem Timing bekommt man es dann schon irgendwie hin. War aber nicht befriedigend. Ich geh mal davon aus Du mit 64 Abnehmern noch langsamere Flanken bekommst. Hab die ganze Geschichte mittlerweiler mit RS485 gelöst. Funktioniert soweit ganz gut. Setzte allerdings ATMegas ein, so dass ich eine UART habe. Sollte Dein ATTiny keine UART haben, kannst Du ja auch eine Software-UART implementieren. Bei RS485 Treibern kannst Du die Std.Bauteile nur mit max.32 Nodes am Bus betreiben. Aber es gibt Bausteine, die bis zu 256 Nodes erlauben. Jeder ATMega hat bei mir eine eigene Adresse ( 1..255 ). Die schick ich bei jedem Kommando mit raus. Darüber kann ich dann die ATMega einzeln ansprechen. Ich hatte übrigens auch einige Probleme mit dem Spannungsabfall über die Leitung ( Flachbandleitung mit 0.014mm² ). Teilweise hat mir die BOD beim Einschalten meiner Verbraucher den Prozessor resetet. Markus
Mit einem Tiny pro LED geht das schon. Aufbereiten des Signals würde ich schon machen, also jeweils einen Dateneingang und einen Datenausgang am Tiny vorsehen, an den wiederum der nächste Dateneingang anzuschließen ist. An jedem Dateneingang sollte der Datenbus mit 10k nach Masse terminiert werden. Unbedingt nötig ist ein Elko von mindestens 100µF und eine Keramikpille direkt am Tiny, die Spannungseinbrüche vermindern. Der Spannungsabfall über der Gesamtleitung könnte abgefangen werden, wenn man die Betriebsspannung etwas höher wählt und jedem Tiny-LED-Gespann noch einen Low-Drop-Festspannungsregler mit gibt.
Hallo, erstmal danke für euer Feedback. Aktuell plane ich mit 12V Betriebsspannung, so dass ein Regler pro Tiny fällig ist. Da so ein Controller < 1 mA bei 1 MHz (interner RC-Oszi) braucht sollte die verheizte Leistung egal sein. Aus dem stegreif hätte ich alle Controller mit einer Art Stichleitung auf den Bus gehangen - euren Kommentaren zufolge wohl eher nicht so gut :-) Ich werde mir einmal überlegen, was ein daisy-chaining bedeutet. Für das verteilen der Adressen ist es auf jeden Fall praktisch, weil der Master die Adressen dann erst nach dem Einschalten verteilt und alle Slaves identischen Binärcode haben können. Konzept: Master sendet "set address xyz" und erster Slave der noch nicht konfiguriert ist nimmt die Adresse und sendet ACK. Das macht der Master solange, bis kein ACK mehr kommt, dann haben alle Slaves eine Adresse. Als Baudrate genügt denke ich < 1 kBaud, ich möchte ja keine Lichtorgel bauen :) Der Bus sollte allerdings schon bidirektional funktionieren, Kollisionserkennung ist aber nicht nötig. So können die Slaves melden wenn ein Cmd erfolgreich empfangen wurde, macht das Debuggen denke ich einfacher und man könnte die Software variabler gestalten. Eine RS485 Transceiver je Node möchte ich aus Kostengründen eher vermeiden. Eigentlich sollte es doch ein simpler Pull-Up gegen Vcc 5V (hat doch ein Tiny intern) machen. Gruß, Alex
Wenn Du einen bidirektionalen Bus brauchst, dann ist das DaisyChaining ehrer ungeeignet, weil recht aufwändig. In dem Fall sollte der DatenBus in der Tat eine druchgehende Leitung sein und recht niederohmig ausgeführt werden. Spendiere jedem Tiny einen Pullup, nimm einen externen von maximal 10k, die internen sind zu hochohmig. Als Bustreiber verwende npn Transistoren, die den Bus nach Masse ziehen können. Auf die Weise kann jedes Modul senden und empfangen. Im Idle-Zustand ist Deine Busleitung dann high. 12V als Betriebsspannung sind aber etwas hoch für Controller, die mit 5V laufen. Im eingeschalteten Zustand der LED mußt Du dann bereits 140mW an Wärme abführen, für einen kleinen Linearregler schon unnötig viel. 7-9V sollten auch reichen.
Zur Spannungsversorgung hab ich letztendlich ein Schaltznetzteil verwendet, was ich einfach auf 5,6V im Leerlauf gedreht hab und ein Kabel mit entsprechendem Querschnitt. Hab dann immer noch um die 4.5-4.8V an den Controllern und spar mir somit die U-Regler.
Was spricht denn gegen 24V auf der Leitung und jeweils einen MC34063A fuer 22cts, plus etwas Huehnerfutter ?
Hi, die 12V hatte ich angesetzt, damit jeder Tiny je 3 gleichartige LEDs (Serienschaltung) ansteuern kann (geschalten über einen npn Transistor gegen Masse), um etwas mehr Lichtstrom je Node zu erhalten. Wie ist das mit dem npn-Transistor als Bustreiber zu verstehen? Ich klemme eine Serienschaltung von Pull-Up und Transistor zwischen Vcc (5V) und GND. Zwischen Pull-Up und Transistor liegt das Potential der Busleitung. Dort klemme ich einen als Eingang geschaltenen IO-Pin der Tiny an. An die Transistorbasis kommt ein als Ausgang geschaltener Pin. Korrekt? Gruß, Alex
>An die Transistorbasis kommt ein als Ausgang geschaltener Pin. >Korrekt? Mit Vorwiderstand, sonst korrekt. Ich würde allerdings die Busleitung nicht direkt an den µC legen, ich würde ein Angstgatter dazwischen legen. Einfach um eine (kleine) Trennung zwischen Kabel und µC zu erreichen.
"Angstgatter" Zu welchem Zweck und von welchem Type, sorry, habe da nicht so die Erfahrung .... Alex
Ein einfacher Widerstand von der Busleitung zum Controllereingangspin reicht, Wert von 2.2kOhm-4.7kOhm. Den Transistorkollektor kann man mit 270 Ohm an die Busleitung anschließen, dann hat man auch für den Transistor einen Kurzschlußschutz.
Angehängte Dateien:
-
Vorschlag.GIF
10 KB
Hallo, ich habe mal ein bischen in Eagle rumexperimentiert, vielleicht hat ja jemand von euch eine Meinung zur entstandenen Schaltung. Am liebsten würde ich die 2K auf BUS_IN jedoch wieder entfernen. Ich versuche den Hühnerfutteranteil gering zu halten, da ich den ganzen Kram ja dann x-mal löten darf ... :-) Gleichzeitig soll die Platinengröße der Slaves natürlich minimiert werden, damit diese besser verbastelt werden können. Alex
Sieht gut aus die Schaltung. R3 kann 4k7 sein. Eine Programmierschnittstelle in Form eines kleinen 5-pol. Steckers / Buchsenleiste würde ich noch vorsehen. An IC2 muß von 5V nach Masse 10µF, C2 sollte nicht kleiner 100µ sein, der 100n-Kondensator muß direkt an den Controller. >Am liebsten würde ich die 2K auf BUS_IN jedoch wieder entfernen. Ich >versuche den Hühnerfutteranteil gering zu halten, da ich den ganzen Kram >ja dann x-mal löten darf ... :-) Najaa - nach einem gnügend starken Spannungspuls auf Deiner Busleitung darfst Du sehr viele Controller neulöten, wenn Du auf diesen einen Widerstand verzichten willst. Du darfst auch nicht vergessen, daß sehr lange Leitungen für Fremdinduktion empfänglich sind.
Travel Rec. wrote: > Eine Programmierschnittstelle in Form eines kleinen > 5-pol. Steckers / Buchsenleiste würde ich noch vorsehen. Beim Prototyp evtl. sinnvoll. Ansonsten sollte es der Dannegger'sche Bootloader auch tun, und der erspart den separaten Stecker.
Wenn du den R4 weglässt, und den R6 in zw Emitter T2 und Masse legst, hast du gleich eine feine Konstantstromquelle für die LEDs. Iled = 4,4V/R6 PS: BC847 ist der SMD Typ den 547
Der Bootloader setzt soweit ich weiß einen UART voraus, somit wird das wohl hier nichts. Aktuell plane ich Fassungen für die Tinys (DIL Gehäuse) zu nehmen, so dass ich sie auf einem Dummy-Board programmiere und dann auf die Platine setze. Die Rolle der 10µ auf der Sekundärseite des Spannungswandlers ist mir nicht ganz klar. Laut Datenblatt des 78L05 (TO92 Gehäuse) wird keine weitere externe Beschaltung benötigt. Energie puffert bereits der Elko auf der Primärseite, wozu also das zusätzliche C? Gruß, Alex
@MatthiasL Wie kommst du auf die 4,4 V? Was außer dem Emitterwiderstand begrenzt dann noch den Strom, den der Controller in die Basis hineinschickt? Wenn ich deine Formel für 20 mA If nehme komme ich auf ein R von 220 Ohm. Der Basisstrom sollte etwa (5V-0.7V)/220 = ca. 20 mA sein. Soviel braucht es doch eigentlich nicht, um den Transistor durchzuschalten. Alex
>Was außer dem Emitterwiderstand begrenzt dann noch den Strom, den der >Controller in die Basis hineinschickt? Der Transistor begrenzt sich selbst. Es fließt nur soviel Basisstrom, wie nötig ist, um den (von dir) eingestellten Kollektorstrom fließen zu lassen. Das nennt sich Stromgegenkopplung. >Wie kommst du auf die 4,4 V? Erfahrungswert für diesen Transistor: Ube=0,6V, bei 5V => Betriebsspannung ergibt das 4,4V über R6 >Der Basisstrom sollte etwa >(5V-0.7V)/220 = ca. 20 mA sein. Soviel braucht es doch eigentlich nicht, >um den Transistor durchzuschalten. Nein. Das ist der Emitterstrom, den du einstellst. Da der BC547 ein B von sagen wir mal 100 hat, bedeutet das, dass 20mA/100=200µA in die Basis fließen (müssen). Somit ist der Kollektorstrom (gleich LEDstrom) 20mA-200µA=19,8mA. Würde mehr Basisstrom fließen, dann fließt mehr Kollektorstrom. Dadurch steigt die Spannung über besagtem WIderstand. Die Spannung zwischen Basis(5V) und Emitter sinkt => Basisstrom sinkt... (Ist eine Art Regelkreis) Der größte Vorteil dieser Schaltung ist: Der Transistor kann nicht in die Sättigung geraten, was beim schnellen Schalten (PWM) durchaus zu beachten ist..
Durch den Emitterwiderstand fließt ja auch der Kollektorstrom, womit der Basisstrom geringer wird. Ist eine Standardschaltung für eine Stromquelle. Macht hier Sinn, weil Spannungsschwankungen dann sich wenig auswirken.
10 uF brauchst du ausgangsseitig am 7805 nicht unbedingt, 100nF in der Nähe des 7805 reichen auch. Wenn der Controller nahe beim 7805 liegt, reicht auch nur ein 100nF direkt am Controller (nahe=2-3cm Leitungslänge).
Alexander wrote:
> Der Bootloader setzt soweit ich weiß einen UART voraus
Nein.
Hallo, dann mal ein leicht modifizierter Vorschlag mit den angeregten Änderungen. Eventuell werde ich wohl noch T1, R3 und R5 rausnehmen. Der Tiny kann laut Datenblatt 40 mA an einem IO-Pin ab. Der Pull-Up gegen Vcc für die Busleitung bringt für jeden Slave 0.5 mA (5V/10K), bei max. 64 Slaves sind das 32 mA, das sollte also passen. Was das für die Störsicherheit bedeutet muss ich mal sehen, nachstellen kann man es wohl erst wenn alles zusammengebaut ist. Bei Verwendung des Daisy-Chain Konzepts würde sich ja die wirksame Buslänge reduzieren (bspw. < 1m je Leitungsabschnitt). Vielen Dank nochmal für eure hilfreichen Beiträge, Alex
R3 weg und T1 durch einen BS170 ersetzen. Kann man bei diesen Tinys nicht den Reset-Eingang wegschalten und einen I/O-Pin draus machen ? Würde Teile und Probleme sparen. T2 kann man durch einen BS170 ersetzen, das würde aber nicht wirklich was bringen. Wozu R5 ? Überspannungsimpulse ? R2 und R5 weg und einen internen Pull-Up nutzen. Wenn den alle uCs aktiviert haben, sollte das ja dicke reichen. Ich würde sogar den T1 weglassen und notfalls ein paar Portpins parallel schalten und zwischen Eingang und Ausgang umschalten. Da kann man ja nichts falsch machen, weil nur Pull-Ups und Push-Pull-Ausgänge nur gegen Masse.
Bernd: ich denke, Deine Vorschläge sind kontraproduktiv.
Hallo, das klingt ja nach einem interessanten Projekt. Noch ein Vorschlag: Ich würde zum einen alle Bauteile, vor allem Transistoren (=BC847) und Attinys in SMD ausführen. Für den Attiny bräuchtest du dann natürlich entweder einen Bootloader oder eine kleine Sockelleiste. So ersparst du dir bei jeder einzelnen Platine die Bohrungen, was ja schon alleine für den Attiny + Transistoren bei 64 Bus-Teilnehmern 896 Bohrungen sind... Ansonsten sieht deine Schaltung gut aus! Schöne Grüße, Alex
Travel Rec. wrote:
> Bernd: ich denke, Deine Vorschläge sind kontraproduktiv.
Wahrscheinlich denken das aber nicht alle hier - vor allem der
Threadöffner spricht immer wieder davon, die Platine zu minimieren, das
Hühnerfutter zu vermeiden etc.
Mit welchem meiner Vorschläge hast Du denn das Problem ?
>Mit welchem meiner Vorschläge hast Du denn das Problem ? Den Eingangsschutzwiderstand wegzulassen und die Transistoren ohne Basisvorwiderstände zu betreiben. Auch MOSFETs sollten einen kleinen Gatewiderstand haben, schon gerade dann, wenn man mit PWM arbeiten will. Es nützt nichts, an der falschen Stelle zu sparen und dabei die Schaltungssicherheit zu gefährden. Das Hühnerfutter gibt es auch sehr klein, in SMD 0603 zum Beispiel, dann ist der Controller das größte Bauteil, under das alles andere (außer dem Regler, den LEDs und den Elkos) darunter paßt. Auch Transistoren gibt es in SMD.
Was das mit der Adressierung angeht: Hier noch ein mögliches Verfahren, das keinen bidirektionalen Bus braucht: Du verbindest alle Knoten (einschließlich Master) folgendermaßen: [Knoten] [Knoten] [Knoten] [-ein ] +--[-ein ] +--[-ein ] [ aus-]--+ [ aus-]--+ [ aus-]------.... Immer schön Ausgang von Knoten n auf den Eingang von Knoten n+1. Zur Adressierung: Der Master sendet ein "Initialisieren!"-Kommando mit einer Startadresse (z.B. 0) raus, folglich wird sie vom ersten Knoten in der Kette empfangen. Dieser Knoten merkt sich die Adresse (0), errechnet wiederum ein "Initialisieren!"-Kommando mitsamt einer neuen Adresse (z.B. durch Erhöhen der eigenen, neue Adresse wäre dann also 1) und schickt das Kommando ab. Es wird vom nächsten Knoten empfangen, der dasselbe tut, und so werden alle Knoten der Kette fix durchadressiert. Lediglich der Master muss lange genug warten, die Wartezeit lässt sich wohl leicht ausrechnen. Im Betrieb werden dann Kommandos (Helligkeit etc.) immer mit einer Adresse beginnen. Der Master schickt das Kommando los, und der erste Knoten vergleicht die Adresse mit seiner eigenen. Identisch? --> Auswerten und fertig. Unterschiedlich? --> Kommando unverändert weiterschicken.
Travel Rec. wrote: >>Mit welchem meiner Vorschläge hast Du denn das Problem ? > > Den Eingangsschutzwiderstand wegzulassen und die Transistoren ohne > Basisvorwiderstände zu betreiben. Auch MOSFETs sollten einen kleinen > Gatewiderstand haben, schon gerade dann, wenn man mit PWM arbeiten will. > Es nützt nichts, an der falschen Stelle zu sparen und dabei die > Schaltungssicherheit zu gefährden. Das Hühnerfutter gibt es auch sehr > klein, in SMD 0603 zum Beispiel, dann ist der Controller das größte > Bauteil, under das alles andere (außer dem Regler, den LEDs und den > Elkos) darunter paßt. Auch Transistoren gibt es in SMD. Alles richtig - für SMD. Aus den bisherigen Posts entnahm ich aber Bohren und selbst löten mit bedrahteten Teilen, darum die Empfehlungen. Aber ich bin jetzt still ! Basta
>äh was sprich gegen i^2c?
2 Leitungen, kompliziertes Protokoll. Siehe Eröffnungspost.
@Compy Das Daisy-Chaining hat nur einen gewichtigen Nachteil: Latenz Bei 1 kBaud und 64 Nodes wird die Nachricht (angenommen 10 Bit) quasi n-mal durchgereicht. Bis ein ACK vom Slave zurückkommt dauert es dann noch einmal. Ein langsames Lauflicht o.Ä. ist damit dann schon nicht mehr realisierbar. Eventuell werde ich mich doch einmal mit SMD-Bauteilen auseinandersetzen müssen, das verkompliziert jedoch aufgrund der dann verringerten Strukturgrößen (Leiterbahnbreite, usw.) sowohl das Routing als auch das Selber-Ätzen (beim Bestücken seh ich kein Problem). Alex
@ Compy (Gast)
Ja, und der Ausgang des letzten Teilnehmers geht wieder auf den Eingang
des Masters. Somit weiß der, wieviel Teilnehmer vorhanden sind und kann
nach selbigem Prinzip (falls nötig) auch Pakete von dem Slaves
empfangen.
>Das Daisy-Chaining hat nur einen gewichtigen Nachteil: Latenz
Nicht unbedingt. Warum das ganze nicht ohne Adressen benutzen:
Die von Compy beschriebene Initialisierung könnte nur zur Ermittlung der
Anzahl der Teilnehmer dienen ( am Besten ein 0x4D vom Master
durchschicken bis es wieder zurückkommt)
Beim Datenverkehr für die Leds wird das ganze dann als Schieberegister
verwendet:
bsp: es gibt 4Teilnehmer:
Der Master sendet immer 5Bytes raus:
S1,S2,S3,S4
Dadurch dass jeder Teilnehemr weiß, der wievielte er in der Kette ist,
kann er nur auf das eine Byte (Word,DWord..) hören, und beim
Weitersenden diese Information durch eine eigene Ino Rx zurücksenden:
Master: Tln1 TLn2 Tln3 Tln4 Master
=> S4S3S2S1 => S4S3S2R1 => S4S3R2R1 => S4SR3R2R1 => R4R3R2R1 =>
Somit entsteht eine sehr geringe Latenz, bidirektionale Komm....
Dazu brauchst Du aber ein 2. Datenkabel, nämlich das vom letzten Slave zum Master zurück. Das Ganze geht auch mit einer Leitung und den beschriebenen open-Collector-Stufen. Dann kann jeder dirket bekommen, was ihm zusteht und gegebenenfalls antworten. Natürlich mit festverteilten Adressen. Die Datenrate wird sicher schneller als 1kBaud zuverlässig funktionieren. Wenn man spezielle Bitformate benutzt (3 Pulse: Startbit, 2 Pulse logisch High, 1 Puls logisch Low), muß man nur kurze Zeit ein bestimmtes Timing einhalten (Pulsdauer) und kann das Protokoll sogar unterbrechen, um später weiterzusenden. Es gibt 1000 Möglichkeiten.
Ist ja auch ein Forum ;-)
Da ich auf den Slaves in C programmieren möchte und der Takt möglichst niedrig sein soll (1 MHz bspw.) sehe ich nicht soviel Luft, um mit der Baudrate noch sehr hoch zu kommen. Beim physischen Protokoll schwanke ich aktuell zwischen: a.) Manchester Codierung b.) Pulsbreitencodierung Auf jeden Fall werde ich eine bitweise Synchronisierung brauchen, da die Controller mit ihren internen Oszillatoren bei schwankenden Temperaturen (evtl. auch als open-air Lichtkette) funktionieren sollen. Nur der Master bekommt einen Quarz. Tendieren tue ich zu b.), weils noch etwas einfacher zu implementieren ist, wobei beide Sachen keine Klimmzüge erfordern :)
Bei 1Mhz Taktrate bekommst Du aber kaum noch flimmerfreie Software-PWMs bei genügend Auflösung hin. Der Tiny 13 vefügt über internen 9,6Mhz-Taktgenerator, damit wird´s schon eher ´was.
Da der Tiny45 eine HW-PWM Unit hat sollte das kein Problem sein. 1MHz/256 macht ca. 3.9 kHz Damit sollte ich die 8 Bit PWM ohne Flimmern ausreizen können, wenn es sein muss.
Der 13er hat auch Hardware-PWM, man muß nur gucken, daß man mit den Pins klar kommt, da etliche Mehrfachbelegungen präsent sind.
hi, Da sich hier so viele kompetente Leute versammelt haben und ich keinen neuen Thread aufmachen will schreib ich mal hier rein. Habe etwas ähnliches vor, nur dass ich das mit nur einem Controller lösen will, der mehrere TLC5922 (Konstantstrom LED Treiber) daisy-chained ansteuert. Mit einem Treiber funktioniert das Programm schon, allerdings bin ich mir nicht sicher ob das so bleibt wenn ich viele weitere Treiber anschließe und das über ca 15 Meter. Laut Datenblatt hat der Treiber ein delay von bis zu 300ns für Data IN --> Data OUT (vorrausgesetzt ich hab mich da nicht vertan) Außerdem habe ich Bedenken, dass meine SCLK Leitung nach x Metern kein eindeutiges Signal mehr raus gibt. Kann mich da irgendwer aufklären wie weit das alles unkritisch ist? Vielen Dank Kai
Mehrere Datenleitungen in einem Kabel über weite Strecken ist kritisch wegen Übersprechen. Eine Datenleitung zwischen Masse und Vcc ist unkritischer. 30 Meter bei 19kBaud und gut terminiertem Bus ist kein Problem.
Zur Übertragung der Daten hatte ich an RJ12 Stecker gedacht, die haben 6 Pins, 5 brauche ich... gibt es da irgendeine andere geschickte Lösung wie ich bis zu 30 Treiber (15 Meter) relativ schnell (max 10ms für alle Treiber) mit möglichst nicht 35 Datenleitungen ansteuern kann? Wie sieht das mit der Verzögerung beim daisy chainen aus? Ist das ein Problem?
>gibt es da irgendeine andere geschickte Lösung wie ich bis zu 30 Treiber >(15 Meter) relativ schnell (max 10ms für alle Treiber) mit möglichst >nicht 35 Datenleitungen ansteuern kann? Ja, jedem LED-Treiber einen kleinen Tiny vorsetzen und mit einer einzigen Datenleitung, wie oben beschrieben, arbeiten. Dein Problem wird aber eher der hohe Stromverbrauch der vielen LEDs sein und der demzufolge hohe Spannungsabfall über die Länge des Kabels.
Stromversorgung geschieht über ein PC Netzteil, das die LEDs mit 12V und die Treiber mit 5V versorgt. Da ist genug Luft nach unten... Den Tiny wollte ich mir sparen, aber wenn das so dann funktioniert, werd ich mich wohl dafür entscheiden Vielen Dank schonmal für die Kommentare
Sind gerade mal 1.20 EUR Aufpreis pro Modul bei einem Tiny13. Und man kann viele verrückte Dinge machen.
bei tme.pl bekomm ich den auch für unter 80 Cent, aber mir ging es auch eher um eine Aufwandminimierung, weil das daisy-chaning schon existiert und ich mir kein neues Protokoll ausdenken muss. Der Treiber will halt auch für jede LED (bei mir sinds 15) die Helligkeitswerte übertragen bekommen, womit ich bei 112 Bit/Treiber bin
Was ist besser: 1) mehr Leitungen oder 2) mehr Intelligenz auf dem Modul? Ganz abgesehen von weniger Problemen bei der Datenübertragung und direkter Autonomie auf jedem Modul würde ich mich für die zweite Variante entscheiden.
Hallo, da nun endlich Wochenende ist, habe ich mal wieder Zeit weiter an diesem Projekt zu werkeln. Ich habe mal das aktuelle Schematic in den Anhang gepackt. Den Programmierstecker habe ich einmal fakultativ hinzugefügt, man muss ihn ja nicht bestücken. Ich hoffe es lässt sich öffnen, ich musste mir ein paar zusätzliche Libs von der cadsoft-Homepage organisieren (für den Tiny sowie die pinheader). Beim Routen stoße ich jedoch auf ein paar Probleme: 1. Wie kann ich für ein Bauteil festlegen, ob es auf dem Top- oder Bottomlayer platziert werden soll. Aus Platzgründen möchte ich lieber mit zwei Layern arbeiten. Die Platine werde ich wohl bei PCBPool machen lassen, die verlangen 50€ für eine Europakarte doppelseitig inkl. Durchkontaktierung. 2. Wie kann ich die Schaltung, wenn sie denn mal fertig geroutet ist, n-mal duplizieren. Ziel ist eigentlich 6-8 Platinchen auf einer halben Europakarte unterzubringen. Oder kümmert sich darum dann der Dienstleister selbst? Gruß, Alexander
zu 1. Indem du manuell routest. Wird sowieso besser. zu 2. Schematic schließen. Alles kopieren und wieder einfügen (das ist die Schere) zur sch: Ich würde über den R3 den R3 noch einen kleinen C vorsehen, vielleicht so 1nF. Er muss ja nicht bestückt werden, je nach Frequenz der Busleitung. Evtl sollte/könnte auch der R2 etwas verkleinert werden... Sonst sollte das gehen
zu 1: Ich glaube Du musst zuerst das Bauteil per Move/F7 an den Mauscursor hängen und dann die mittlere Maustaste drücken. Funktioniert glaube ich so bei SMDs. Hab gerade kein Eagle zur Hand ums selber zu probieren...
@ Matthias Das mit dem manuell Routen ist ein Klasse Tipp ... hätte ich soundso gemacht :) Wenn ich ein C parallel über den R3 hänge baue ich mir dann nicht einen Hochpass? Welchen Zweck soll das C erfüllen? @ Markus Das mit der mittleren Maustaste klappt, ich hoffe mal cadsoft hat irgendwo auch einen Menüeintrag dafür vorgesehen, von alleine kommt doch kein Mensch auf diese Idee ... Alex
>Wenn ich ein C parallel über den R3 hänge baue ich mir dann nicht einen >Hochpass? Welchen Zweck soll das C erfüllen? Richtig. Dafür sorgst du, dass der Transistor schneller zu/abschaltet. Kann aber bei sehr geringen Taktfrequenzen entfallen. Ich würde ihn auf der Platine vorsehen, und dann mittels Oszis nachsehen, ob nötig.
zur Platinenherstellung kann ich dir nur bilex-lp empfehlen, die machen das echt gut mit Lötstop und Durchkontaktierung und dann noch ein wenig billiger :P Hab da schon eine Platine bestellt, die nächste ist im Auftrag
So, nach nem Abend vorm PC habe ich mal meine erste Leiterplatte geroutet. Schematic und Board File habe ich mal im Anhang gezippt, vielleicht kann ja einer der Experten einen Blick drauf werfen und mir die groben Fehler nennen :-) Insbesondere bezüglich der Leiterbahnbreite sowie der Größe von Lötaugen (LEDs) bzw. der 4 Vias bin ich mir nicht sicher. Ich hoffe mal eine professionelle Leiterplattenfertigung kriegt so feine Strukturen hin und ich den Kram am Ende auch bestückt ... Alexander
Mach alle Leiterbahnen 0,3032mm breit. Das reicht hier bei den Stromstärken. Platinenhersteller kriegen das locker hin. So "eng" ist das ja nicht. Auf ne sinnvolle Leiterbahnführung musst noch achten: zB. JP3.Pin1. Die 12V Leitung sollte zuallererst den C2 erreichen, von hier kannst du das auf IC3 und die LEDs verteilen, wobei die Anode von LED1 wieder idealerweise nahe dem C2 liegt. genauso ist das mit dem Emitter von T4: de sollte nahe am C2 sein. ich würde über beiden noch einen 100nF legen, du willst ja mit ner PWM mit hoher Frequenz arbeiten.. Als GND kannst du ruhig ne Fläche nehmen.. Vielleicht route ich dann mal spasseshalber..
Ok, dann werd ich wohl noch etwas an der Wichtung meiner Optimierungskriterien arbeiten müssen. Bisher gab es nur eins und das war "Flächenminimierung". Um elektrische Aspekte hatte ich mir beim platzieren der Bauteile keinen Kopf mehr gemacht. Über die Sache mit der Groundplane habe ich heute schonmal irgendwo was gelesen, werde ich dann wohl beim finalen Design noch drüberlegen. Das Routen ist auf jeden Fall ein größeres Gemehre als ich mir das vorgestellt hatte, unglaublich wieviel Zeit ich für die paar Teilchen gebraucht habe. Über welche Bauteile müssen theoretisch noch Kapazitäten? - R3 hattest du ja bereits angemerkt, da ich jedoch nur Baudraten von max. wenigen kBaud plane habe ich der Flächenoptimierung Vorrang gegeben. - Meintest du zusätzlich R4?
Ok, offensichtlich kann man durch etwas exzessiven Einsatz von Vias die mittlere Leiterbahnlänge deutlich minimieren. Ich habe gesehen, dass du den 330n C am Spannungsregler entfernt hast. Ist das hauptsächlich durch Platzgründe motiviert oder braucht man das Ding einfach nicht (ich hatte die Angabe aus dem Datenblatt).
>Ok, offensichtlich kann man durch etwas exzessiven Einsatz von Vias die >mittlere Leiterbahnlänge deutlich minimieren. Ja, sobald du zweiseitig machst, spielt es (meist) keine Rolle ob du (oder besser der Automat) eins oder zehn Löcher bohren musst. Und das Durchkontaktieren erfolgt eh für alle (vorhandenen) Löcher zugleich. > den 330n C am Spannungsregler Ja, weil der 100n am Vcc-Eingang vom Atmel direkt daneben liegt. Somit passt das schon. Wichtig ist ja folgendes: Der 7805 braucht einen C. Der µC braucht einen Block-C am Eingang. Wenn beides nebeneinander liegt, dann kann ich auch nur Einen nehmen. Dafür hab ich der LED einen verpasst.
Hallo, ich habe mal noch ein Alternativboard mit RGB LEDs zusammengestellt. Da der Tiny 3 PWM-Ausgänge hat lässt das Raum für weitere Spielereien :) Es können natürlich auch einfach 3 gleichartige LEDs bestückt werden. Vielleicht kann es ja jemand brauchen. Das Format ist < 25x25mm. Eignet sich vielleicht ja auch für andere als Bastelplatine mit nem Tiny. Eine Stückliste mit den Reicheltpreisen habe ich mal angefügt. Man landet bei kleiner 5€ je Platine. Ich habe mir PCB-Pool mal näher angeschaut. Die fertigen 16 solcher Platinchen für < 50€ (schon fertig gefräst). Möchte man Lötstopplack sinds dann schon knapp 80€. Ich denke der würde das Bestücken einer solch kleinen Platine schon wesentlich vereinfachen, zumindest für jemanden der nicht die ruhigsten Hände und nicht das beste Werkzeug (Lötstation ...) hat. Akkumuliert sind es also 7,50 bzw. 10€ je Spielzeugplatine. Nochmal vielen Dank für eure Unterstützung, ich gebe auf jeden Fall laut, wenn der erste Prototyp am Rennen ist. Bis dahin werden aber sicherlich 2-3 Wochen vergehen. Alexander
Sieht schon passabel aus, aber solltest trotzdem noch bissel weiterüben beim Routen ;-) Tips: die GND-Airwires solltest du nciht mit der Hand routen, wenn du eine Massefläche verwendest. Signalleitungen solltest du immer so klein wie möglich machen, ich würde hier 0,3032mm (12mil) empfehlen. Versorgungsleitungen/Stromführende Leitungen je nach fließendem Strom, hier reichen wohl auch 12mil. Der Block-C (C1) sitzt viel zu weit weg vom µC. Der muss direkt an die Pins.
Zu den Masseflächen noch eine Frage: Bei jedem neuen Öffnen des Boards sind diese wieder verschwunden - "Rip Up" stellt sie dann wieder her. Kriegt ein Leiterplattenfertiger das dann trotzdem hin, dem schicke ich doch bspw. die board-Datei und er generiert sich daraus die benötigten Daten. Das sich Leiterplatten einfach routen lassen, wenn man am Anfang auf beide Seiten eine Massefläche legt, habe ich leider erst gelesen als das Ding komplett geroutet war und ich eben diese Flächen anlegen wollte ;-) Warum sollte ich die Leiterplatten dünner als nötig machen? Mögen Signale keinen geringen elektrischen Widerstand? :)
>Kriegt ein Leiterplattenfertiger das dann trotzdem hin, dem schicke ic Ja. es werden nur die Ränder gespeichert. Der "Rest" wird berechnet. Das weiß jeder Platinenhersteller. >Warum sollte ich die Leiterplatten dünner als nötig machen? Nicht die Platine, nur die gerouteten Verbindungen. >Mögen Signale keinen geringen elektrischen Widerstand? :) Richtig. Es sind nur Signale, keine (hohen) Ströme. Bei Signalen kommt es auf die Laufzeiten an (hier vielleicht nicht so tragisch, aber man kann sichs ja angewöhnen). Laufzeiten bedeutet, die Signale sollen möglichs kleine (Leitungs-)Kapazitäten (gegen Masse/anderes Signale) haben und möglichst kleine (Leitungs-)Induktivitäten haben. => geschlossene Stromkreise sollten möglichst kleine Flächen umschließen, das ergibt eine geringe Induktivität => hohes di/dt möglich Leitungen mit kleiner Kapazität lassen sich schneller umladen (0V=>5V=>0V) => hohes du/dt => große Flankensteilheit
Hallo, da nun endlich Wochenende ist konnte ich mal wieder etwas "eageln". Habe mal versucht die Hinweise bestmöglich umzusetzen. Eine Frage die sich mir noch stellt: Wenn man die *.brd Datei an einen Fertiger wie pcbpool schickt, führt dieser dann bereits die Durchkontaktierungen + Bohrungen per default durch? Die Option an sich habe ich nicht in der Oberfläche des Bestellformulars gefunden, so dass ich davon ausgehen würde. Gibt es eigentlich irgendwo im Netz eine Art Guideline (de oder en) die Hilfestellung beim Leiterplattendesign liefert. Ein paar gute Tipps sind ja hier schon gekommen. Gruß, Alex
@ Alexander (Gast) >Eine Frage die sich mir noch stellt: Wenn man die *.brd Datei an einen >Fertiger wie pcbpool schickt, führt dieser dann bereits die >Durchkontaktierungen + Bohrungen per default durch? Die Option an sich LOGISCH! Zum Schaltplan. Die drei Transistoren kannst du dir sparen. Einfach direkt per AVR und Vorwiderstand ansteuern. Die Leistungsbilanz ändert das nicht. Aber du sparst Platz und drei Bauteile. C2 ist reichlich dimensioniert, 20uF würden wahrscheinlich auch reichen. 100nF am Reset sollte man vorsehen, als EMV Schutz. Ich habe den Thread nur überflogen. Wie willst die Dinger nun ansteuern? RS232 artig? Ohne Quarz? Oder anders? FEHLER! Das Gehäuse für deinen Tiny ist zu schmal! Darauf bin ich auch gerade reingefallen! Die Tinys haben 8mm Pin-Pin Breite, dein Gehäuse im Layout nur 6,5mm! Die SO8 gibt es in min. 3 verschiedenen Breiten! Schau mal in die Microchip Bibliothek. >Gibt es eigentlich irgendwo im Netz eine Art Guideline (de oder en) die >Hilfestellung beim Leiterplattendesign liefert. Ein paar gute Tipps sind >ja hier schon gekommen. Mehr oder weniger. Hab aber keinen Link parat. MfG Falk
Hi, weiter oben hatte ich mal folgendes gepostet: <schnipp> Beim physischen Protokoll schwanke ich aktuell zwischen: a.) Manchester Codierung b.) Pulsbreitencodierung <schnapp> Daran hat sich bis jetzt nichts geändert. Der Master kriegt zwar einen Quarz, die Slaves bekommen aber definitiv keinen. Etwas tricky wird, die PWM Frequenz so zu wählen, dass ich den Timer parallel zur Auswertung der Kommunikation nehmen kann. Da werd ich morgen mal etwas rumrechnen. Den Bus-Eingangspin habe ich vorsichtshalber auf einen Tiny-Pin gelegt, der auch externe Interrupts triggern kann (INT0). Da bin ich mir aber noch nicht sicher, ob da vielleicht irgendwie noch ein Tiefpass davor muss. Ich habe etwas bammel mir auf diese Weise Störungen einzufangen, wäre ja nicht der erste, der seinen Controller durch Rauschen an einem Interrupt-Pin lahmlegt :) An der Transistorlösung mit den LEDs gefällt mir, dass ich nur 220 Ohm Widerstände brauche und als LED alles verbauen kann, was 20mA If hat, unabhängig von Uf (die Stromregelung wurde weiter oben schon einmal gut erklärt). Bist du dir bezüglich des Packages sicher? Ich vermute, du hast in meinem Schaltplan aus Versehen den Spannungsregler vermessen, der hat in der Tat ein schmaleres Gehäuse. Gruß, Alex
Hallo, Wie läuft die Kommunikation mit den Tinys? Ohne Quarz ist RS232 o.ä. sehr unzuverlässig. :) Was eventuell machbar wäre wenn man sich den Quarz unbedingt sparen will, daten im Manchestercode senden, der bringt den "Takt" gleich mit. Nachteil ist der große Datenoverhead. Alexey
@ Alexander (Gast) >a.) Manchester Codierung >b.) Pulsbreitencodierung OK, das passt auch mit RC-Oszillator. Aber wozu T1, R3 und R5? Einen Open Collector Ausgang kann der AVR auch allein bereitstellen. >An der Transistorlösung mit den LEDs gefällt mir, dass ich nur 220 Ohm >Widerstände brauche und als LED alles verbauen kann, was 20mA If hat, >unabhängig von Uf (die Stromregelung wurde weiter oben schon einmal gut >erklärt). OK. >Bist du dir bezüglich des Packages sicher? Ich vermute, du hast in >meinem Schaltplan aus Versehen den Spannungsregler vermessen, der hat in >der Tat ein schmaleres Gehäuse. Jain. Ja, ich hab erst den falschen erwischt. Aber jetzt nochmal IC1 auf der Unterseite gemessen, dein AVR. Der hat bei dir nur ca. 6,8mm "Spannweite". Im Datenblatt aber 8mm. Und ich hab vor ein paar Tagen welche bekommen (Tiny12), die sind wirklich so gross. MfG Falk
Hi, bei max. 64 Busteilnehmern müsste der Tiny 5V/10K * 64 = 32 mA gegen Masse schalten, das wird dann wohl doch zuviel. Ich weiß auch noch nicht, ob ich wegen der störsicherheit eventuell nur 4K7 als Pull-up verbaue. Bzgl. der Packages werde ich mich wohl noch mal schlau machen müssen, dann muss ich im Eagle halt die Lib anpassen. Ärgerlich ist sowas schon. Alex
edit: Außerdem wurde mir weiter oben gesagt, dass die internen Pull-ups zu groß sind, um bei langen Busleitungen halbwegs störsicher arbeiten zu können.
@ Alexander (Gast) >bei max. 64 Busteilnehmern müsste der Tiny 5V/10K * 64 = 32 mA gegen >Masse schalten, das wird dann wohl doch zuviel. Ich weiß auch noch ??? Nur mal als Tip. Bei I2C und ählichen Bussen gibt es EINEN Pull-up auf dem Bus, nicht N Mal. >Bzgl. der Packages werde ich mich wohl noch mal schlau machen müssen, >dann muss ich im Eagle halt die Lib anpassen. Ärgerlich ist sowas schon. In der Tat. Deshalb IMMER *GENAU* das Package anschauen. MfG Falk Alex
Hi, also sowohl bei I²C als auch bspw. bei LIN wird meines Wissens nach bei jedem Knoten (bei signifikanten Kabellängen dazwischen) terminiert. Gruß, Alex
Multi-Terminierung ist unsinnig. Einerseits: Wer soll das noch treiben können, wenn der Gesamtwiderstand durch Parallelschaltung immens runtergeht. Andererseits: Um Reflektionen auf einem Kabel zu minimieren, terminiert man immer einmal am Anfang und einmal am Ende des Kabels mit seinem Wellenwiderstand.
@ Winfried (Gast) >terminiert man immer einmal am Anfang und einmal am Ende des Kabels mit >seinem Wellenwiderstand. Alles richtig, aber der OP wird sicher NICHT so schnell arbeiten (wollen), das der Wellenwiderstand und die Terminierung eine Rolle spielen. Nicht bei dem geplanten Aufbau. MfG Falk
Angehängte Dateien:
-
einseitig.png
19 KB
Hmmm ... wird noch was am Board geändert? Ich hab mal geguckt wie weit man kommt wenn man es einseitig halten will. Braucht man beim Tiny die drei Tranistoren? Und wäre das übrehaupt noch lötbar? flo
@ flo (Gast) >Dateianhang: einseitig.png (1,7 MB, 4 Downloads) Du hast GEWONNEN ! Den Titel Bildformat-Ignorant des Monats! Siehe Bildformate Kann das noch jemand toppen? MfG Falk
Also das ist echt top, 1.7MB! Aber du solltest lieber niemanden herausfordern das noch zu schlagen :-)
Gemeine Frage: Warum sendest Du die Daten nicht über die Versorgungsleitung? Dann brauchst Du nur zwei Drähte. Die Versorgungsspannung unterbrichst Du im Takt der Daten beim Sender. Der Sender muss natürlich ausreichend Strom auf die Leitung geben können und schnell genug sein. Ich mach das mit einem low-RSon-Mosfet. Am Empfänger gibst Du die Daten über einen Widerstand direkt auf ein Pin. Die Versorgung pufferst Du über eine Schottky-Diode und den 100µ-Elko. Bei mir reicht das für eine 300mA-Luxeon-LED pro Empfänger. Die Versorgung kannst Du für den AVR noch mit Zenerdiode stabilisieren - der ist ja sehr genügsam - falls Deine Spannung auf der Leitung zu hoch ist. Die Daten werden binär codiert gesendet: Kurzer Puls - logisch Null, langer Puls - logisch Eins. Pakete mit erforderlicher Datenlänge, dazwischen immer schön Pausen, damit sich die Elkos wieder aufladen können. Vorzugsweise an einen Pin mit ExInt. Wenn fallende Flanke, Timer starten, nach Ablauf Timer gucken, ob noch low (Eins) oder schon wieder high (Null), ExInt wieder aktivieren und auf nächstes Bit warten. Timeout erzeugt Reset des Empfangs, wenn Daten zu lange ausbleiben. Sven
Juhuu... schon wieder gewonnen :) Was soll ich sagen? Ich habe den Preis aber auch verdient. Schließlich habe ich sogar so getan als ob ich es als png hätte anhängen wollen. Das es in wirklichkeit ein riesiges Bmp war kann natürlich nur einem Halbgott wie dir auffalen. Aber denk jetzt nich das ich mich auf meinen Lorbeeren ausruhen werde. Ich werde auch weiterhin an großen Bildern im Bmp-Format (was schließlich jeder Profi verwendet). @Sven: http://www.freebus.org/ aber ob man das auf einen tiny bekommt weiß ich nicht...
@Flo Leiterbahnen durch die Beine der SOIC-Packages zu ziehen habe ich mir mit Absicht verkniffen, damit wird es kaum mehr lötbar (Brückengefahr). Aus selbigem Grund habe ich auch Stiftleisten mit Rastermaß 2,54 mm genommen. Dort kriegt man auch noch ohne Verrenkung eine Leiterbahn zwischen den Beinchen durch. Die drei Transistoren senken denke ich zum einen die Störanfälligkeit, da ich die LEDs mit getrennten 12V versorge und der Tiny mit seinen 5V keine Leistung direkt schalten muss. Andererseits lässt es mehr Optionen für die Wahl der LEDs. Das Design bekomme ich mittlerweile auf eine 21 x 21 mm große Platine. Im DRC habe ich für "Different Signals" alles auf 12 mil gesetzt und für "Same Signals" auf 8 mil. Signale sind 16 mil breit und GND sowie VCC 24 mil. @Sven Über einen one-wire Bus mit parasite power hatte ich auch kurz nachgedacht. Das hätte die Datenrate aber denke ich sehr stark nach unten limitiert. Wieviel Bytes/s schaffst du mit deinem Aufbau? An der Schaltung wäre ich natürlich trotzdem interessiert, man lernt schließlich nie aus. Alexander
@ Alexander (Gast) >Über einen one-wire Bus mit parasite power hatte ich auch kurz >nachgedacht. Davon würde ich abraten. Die eine Ader frist keine Brot. Dagegen sind die Einschränkungen eher gross. MfG Falk
Hallo, hier mein nun hoffentlich finales "rundes" Design. Ein erster Anwendungsfall ist mir auch schon eingefallen: Warum die Platine nicht in Ostereier packen, die man dann RGB-technisch illuminieren kann?! Gehts trashiger? ;-) http://www.bastelbedarf-scholz.de/product_info.php/info/p2081_Kunststoffei,%20teilbar,%206%20cm.html Mit einem Platinendurchmesser von 3cm lande ich im oberen Viertel des Ostereies, sollte soweit also passen. Gut bei den Dinger ist, dass man sie ab Werk öffnen kann und nix dafür kaputt machen muss. Oben muss halt noch ein Loch für die Kabel ran, mal schauen ob Bohren oder Schmelzen dort einfacher ist. Hat einer ne Idee, wie ich so ein Ding matt bekomme, damit die Punktstrahlwirkung der LEDs etwas minimiert wird? Bei Angelika bekommt man ja bestenfalls welche (hell bzw. ultrahell), die 60° Abstrahlwinkel haben ... Gruß, Alexander
SMD LEDs probieren? die haben meist einen höheren abstrahlwinkel, aber kommt drauf an welche helligkeit gefragt ist.
SMD LEDs hab ich hier noch ein paar rumliegen, melde dich bei Interesse Alternativ könnte ich noch Superflux anbieten mit Abstrahlwinkel 140° glaub ich, bin mir aber nicht ganz sicher. Bei den SMD ist die Farbmischung natürlich besser, allerdings sind die Superflux heller. Von den Superflux hab ich aber nur noch wenige... allerdings bezweifle ich, dass du das Ei diffus hinbekommen wirst... hab das gleiche schonmal mit Plexiglas versucht und das hat nicht sehr gut funktioniert
Ich denke ich werde bei Reichelt ein paar SmartLED Typen im 0603er Gehäuse mitordern und mal schauen, ob ich die mit bestückt bekommen (160° Öffnungswinkel bei 56, 180, 112 mcd). Dazu habe ich auf der Platinenunterseite an den Bohrungen für die LEDs noch kurz Leiterstücke (quasi Pads) angebracht, so dass man sowohl bedrahtete als auch SMD bestücken kann. Dafür mussten ein paar Leiterzüge umverdrahtet werden, da man diese dann nicht mehr zwischen den LED-Beinchen durchzwängen kann. Bzgl. des diffus machens werde ich auch mal nach Chemikalien suchen, die Plastik angreifen und taub machen. Gibt es matte Lacke die farbdurchlässig sind? Flüssigkeiten zum Füllen der Eier scheiden leider aus Gewichtsgründen aus.
Ich habs mal mit Aceton versucht, keine Chance. Die LEDs sind nicht in Plastik, sondern in Epoxidharz eingegossen, das ist ziemlich resistent. Bei kleinen Mengen geht Abschmirgeln mit einem 80er bis 120er Schleifpapier ganz gut, bei größeren müßte man mal Sandstrahlen probieren. Wenn noch jemand eine Idee für Chemie zum Mattieren hat, ich probiers gern aus. Beste Grüße Sven
Es ging mir auch mehr darum das Plastik des Eies anzugreifen. Bei den LEDs werde ich auf jeden Fall mal meine Schleifkünste in die Wagschale werfen :)
Hi Alexander, ich baue an einer ähnlichen Sache (Lichterkette mit RGB-LEDs, jede LED soll einzeln ansteuerbar sein). Hast du schon an Software was fertig (ich will den ATTiny 25 nehmen und über Manchster-Code ansteuern - bei mir muss es noch kleiner werden d.h. nur ATTINY 25, RGB-LED, 100n C und 3 x R für LED (außer LED alles SMD)?? Viele Grüße, nurabsal
Nein, die Software ist noch nicht geschrieben. Habe heute erstmal Leiterplatte und Bauteile geordert. Ein Teil der SW wird sicherlich nächstes Wochenende entstehen (parallel zur HW), die kann ich ja dann hier posten. Jetzt wartet erstmal wieder eine Arbeitswoche ... Auch für die LEDs kannst du SMD verwenden, dort ist die Auswahl was Abstrahlwinkel angeht (klein, groß) größer.
Hi Alexander, die LEDs hab ich schon, außerdem sind normale LEDs für mich günstiger (z.B. am Weihnachtsbaum). Meine Platine soll hochkant an der LED sitzen, so das man das als ein Art Kerze in ein Röhrchen montieren kann. Ich schreibe gerade am Fading - willst du eine Farbraumkonvertierung machen oder arbeitest du mit rohen RGB-Werten (mit Linearisierung ?) ? Viele Grüße, nurabsal
um LEDs diffus zu machen kann ich folgendes empfehlen: Kopf abschneiden, Exopydharz anrühren und einen Tropfen weiße Farbe dazu (wirklich nur einen Tropfen) Dann immer einen Kleks auf die geköpfte LED
@Kai Danke für den Tipp, werde ich sicherlich mal testen. @nurabsal Ich denke mal ich werde direkt mit den RGB Werten arbeiten. Beachten muss man halt: - unterschiedliche Ausgangslichtstärke der LEDs bei gleicher Pulsweite - nichtlineares Verhalten des menschlichen Auges - ... Ich werde das einfach nach Gefühl machen, möchte ja keinen LCD-Monitor mit LED Backlight bauen sondern einfach nur ein Leuchtmittel das zwischen verschiedenen Farben faden kann.
bei der Dosierung bin ich mir leider nicht sicher, es ist eben wichtig, dass das Verhältnis von weißer Farbe zu Epoxidharz sehr groß ist. Du kannst es ja an einer LED mal testen und wenn dir die Streuung zu schwach ist, machst du eben mehr dazu. Je mehr Farbe, desto weniger Leuchtkraft ist ja klar
Hallo, da die Platinen nun da sind konnte ich mal eine erste bestücken. Vorweg, die SMD LEDs sind vom Abstrahlverhalten her wesentlich besser als die bedrahteten. Ein aufgeschnittener Tischtennisball sorgt für etwas Diffusität :) Ich hoffe das mit dem 0,7 MB Video im Anhang geht in Ordnung, ansonsten kann es ja einer der Moderatoren wieder entfernen - Bilder sind bei so etwas halt nicht so aussagefähig ... Nun werd ich mich wohl dem Master widmen müssen, der die Beleuchtungskommandos an die Slaves sendet. Geplant ist da sowohl USB als auch ein Ethernet Interface. Wird wohl so etwas wie ein ATMega128 werden, der eine am PC erstellte Schedule (bspw. über ein XML-File) bei sich speichert und diese dann zyklisch oder zeitgesteuert (RTC) abarbeitet. Falls jemand den Code möchte kann ich ihn natürlich posten, ist bis jetzt eh keine Hexerei, da es nur 3 PWMs sind. Die Buskommunikation ist zwar schon implementiert, es wird aber einen Master brauchen um dieses Codesegment zu verifizieren. Alexander
sieht doch schonmal schick aus :) Da du aber nur rot, grün und blau angesteuert hast, kann man leider nicht sehen wie gut deine LEDs die Farben mischen. Was für LEDs hast du denn jetzt in dem Video verbaut? Ich habe mit SMD RGBs auch gute Erfahrungen gemacht, für ein Moodlight sind sie mir allerdings etwas zu dunkel...
Hi, verbaut habe ich (Reichelt): LS L296 LT L29S LB L293 Ausleuchten kann man mit den Dingern logischerweise nichts, aber als Lichtpunkt sind sie schon zu gebrauchen. Der nächste Schaltungsentwurf wird je Platine 2 rote (sind am lichtstärksten), 2 grüne sowie 3 blaue enthalten, um den Lichtstrom etwas zu erhöhen. Platz nehmen sie ja dank ihrer Bauform nicht weg. Den Elko auf der Oberseite der Platine werde ich auch auf die Unterseite verbannen. Die Farbmischung habe ich für die Demo erstmal weggelassen, es ging mir erstmal nur darum, dass die PWM für alle 3 Kanäle arbeitet. Auf die schnelle ist mir kein kurzer Algorithmus eingefallen, um mich einmal durch den gesamten Farbkeil zu bewegen, ohne gleich ne halbe Seite Code durch Copy&Paste zu produzieren. Kann ich ja morgen noch nachlegen. Als bedrahtete Typen hatte ich SLH 56 RT, SLH 56 GN und SLH 56 BL, dort ist das Abstrahlverhalten aber schlechter als erwartet (praktisch nicht zu gebrauchen). Alex
als Farbverlauf bietet sich folgendes an: Anfang mit rot = max, grün = 0, blau = 0 grün++ bis rot = max, grün = max rot-- bis rot = 0 blau++ bis blau = max grün-- bis grün = 0 rot++ bis rot = max blau-- bis blau = 0 jetzt bist du wieder am Anfang Habe hier auch gerade eine Schaltung laufen, die auch diesen Farbübergang macht und es sieht recht gut aus. Ich habe zum Vergleich ein paar Superflux RGB und ein paar SMD RGBs angeschlossen (beide aus HK) Die Superflux sind zwar richtig hell, mischen allerdings längst nicht so gut wie SMDs. Auch haben die Superflux ein viel zu rotes weiß, was bei den SMD nicht der Fall ist.
Hi, nach etwas Recherche habe ich hier im Forum den Hinweis auf die RGB-HSV-Umrechnung gefunden. Damit kann man super einen Sweep durchs Farbspektrum machen. Habe mir ein PC-Applikation geschrieben, die ein look-up table mit den nötigen Werten erstellt. Die werde ich noch etwas ausbauen, so dass die PWM-Werte noch logarithmiert werden (passiert aktuell separat mit 5 Bit Genauigkeit) - so wirds für die Augen etwas gleichförmiger. An den Koeffizienten bei der Logarithmierung kann man dann noch etwas drehen, um den unterschiedlichen Ausgangshelligkeiten der LEDs Rechnung zu tragen. Im Forum wurde beschrieben, wie man die Widerstände alternativ tunen kann, davon halte ich jedoch nicht soviel (ginge bei meiner Schaltung auch so nicht) - dafür gibts Software :) Kostet wenn man S=V=1 wählt 3*360 = 1080 Byte Programmspeicher, davon hab ich aber genug (immer noch 50% frei). Im Anhang mal Version 2 des Projektes. Diese hat nun: - mehr LEDs ;-) - RS485 anstelle des vorherigen Eigenbau-Bus (und deshalb auch einen Quarz) Auf RS485 bin ich gewechselt, da nur so die Datenrate ausreicht, um eine Hand voll Slaves schön kontinuierlich kontrolliert faden zu lassen (geplant 250k wie bei DMX). Die Platine ist trotz des etwas höheren Bauteileinsatzes noch einen Tick kleiner geworden, etwas teurer macht sie nur der Einsatz der vielen LEDs, der Rest fällt wohl eher nicht ins Gewicht. Die muss man aber gegebenenfalls nicht bestücken, man kann sie auch teilweise durch Drahtbrücken ersetzen. Platztechnisch gehts nun etwas enger zu, aber PCB-Pool hatte offensichtlich auch bei Version 1 an den kritischen Stellen keine Probleme, so dass mir das vertretbar erscheint. Schwierig lötbar sind nur die popeligen LEDs ... Gruß, Alex
@ Alexander (Gast) >Dateianhang: EEP.zip (68,5 KB, 1 Downloads) Schaltplan und Layout sind nicht konsistent! >- RS485 anstelle des vorherigen Eigenbau-Bus (und deshalb auch einen >Quarz) Ach was. ;-) >Auf RS485 bin ich gewechselt, da nur so die Datenrate ausreicht, um eine >Hand voll Slaves schön kontinuierlich kontrolliert faden zu lassen >(geplant 250k wie bei DMX). Dann mach es gleich richtig und mach DMX. Dafür gibt es viel Hard- & Software. http://www.madrix.de MFG Falk
Noch was. Verwende lieber die +5V und GND Symbole, um Pins dort anzuschliessen, keine normalen netze mit Netznamen. Und ich bin mal gespannt wie du RS485 empfangen willst, wenn DE und RE\ auf Vcc liegen . . . ;-) MFG Falk
@ Falk Besten Dank für die Tipps, nach dem Lesen des Transceiverdatenblattes und eines kurzen Artikels zu DMX bin ich nun etwas schlauer und mein Board um ein paar Leiterzüge und Durchkontaktierungen reicher :) Die HP von madrix ist schon stylisch gemacht, zu verschenken haben die Jungs aber leider nix ... ;-) Wäre aber auf jeden Fall auch ein interessanter Job für einen Softwerker wie mich. Gruß, Alexander
Hallo, um auch mal ein etwas brauchbares an euch zurückzuliefern im Anhang mal ein Prog das look-up-Tabellen zum Dimmen erstellt. Ich habe mal ein wenig mit der exp-Funktion experimentiert und das Ergebnis war so schon ganz brauchbar. Allerdings hat sich gezeigt, dass wenn beim Faden bedingt durch die Nichtlinearitäten ein Pulsen aufgetreten ist. Das Programm normalisiert die RGB-Werte noch einmal, was das Pulsen auf Kosten der Endhelligkeit etwas unterdrückt. Eigentlich müsste man die Einzelkomponenten bei der Summation noch gewichten, was ich bei der Endversion sicher auch noch machen werde. Alexander
Dann möchte ich doch auch noch einen Link beisteuern: http://www.hoelscher-hi.de/hendrik/light/dmxled.htm Der ATmega8515-16 kann je nach Firmware ne ganze Menge: Dimmer mit 8-Kanälen, Schrittmotoren, Servos, 8x8-Matrix usw, und das alles mit DMX512 bzw DMX2000 (hab ich noch nie von gehört, ob es das ist was ich denke?)
Hi Wie siehts denn eigentlich mit dem Projekt aus? Das finale Layout, und der finale Programmcode? Ich finde die Idee genial und würde mir auch gerne soetwas bauen, da wären Praxiserfahreungen sehr hilfreich!
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.