Moin moin alle miteinander! Da ich kein großer Freund von Quecksilber bin, sehe ich nun den Punkt gekommen, an dem es Zeit wird, meine Zimmerbeleuchtung von Wolfram auf Halbleiter umzustellen, so sieht der Plan aus: 1500 RGB-LEDs, 1500 kaltweiße LEDs, 2000 warmweiße LEDs, alle auf flexiblen Leisten, jeweils in kleinere Gruppen unterteilt und mittels PWM (12 Bit) dimmbar. Als "Dimmer" möchte ich ca. 50 PIC12F1840 nehmen (hab hier noch ne Kiste voll von denen) und sie über I2C (400 kHz) ansprechen. Ich weiß, I2C war niemals als Feldbus konzipiert, aber da er ja auch schon offiziell als Verbindung zwischen TV und Videorekorder genutzt wurde.... Ich habe vor, SCL und SDA über 2 Koaxkabel laufen lassen, deren Kapazität bei 55 pF/m liegt und da als maximale Leitungslänge meine Zimmerhöhe (2,4 m) angenommen werden darf, bleibe ich garantiert innerhalb der spezifizierten 400 pF. Den Master (noch nicht konzipiert) dann ab in die Mitte und die Pullups jeweils an die beiden Enden. Die große gestrichelte Linie im Schaltplan steht für den Platz, an dem die restlichen Slaves sitzen/hinzugefügt werden können. Meine erste Frage betrifft den Schirm von SDA & SCL, wie beschalte ich ihn? Einseitig oder beidseitig, auf GND oder auf VDD oder mit Spannungsteiler auf VDD/2? Hab hier im Forum gegensätzliche Infos gefunden, deswegen... Außerdem bin ich noch etwas ratlos, ob und wenn ja, wie ich GND Slave und GND LEDs trenne ohne dabei große Masseschleifen zu basteln, hab die Sorge, dass der hohe pulsartige Strom der LEDs mir sonst das I2C versaut. Andererseits müssen die FETs natürlich noch irgendwie durchsteuern können ^^ Und wie siehts mit den Serienwiderständen vor jedem Slave aus, 330, 100 oder 0 Ohm? MfG, Quenz
Angehängte Dateien:
-
I2c2.png
12 KB
@ Quenz (Gast) >Da ich kein großer Freund von Quecksilber bin, sehe ich nun den Punkt >gekommen, an dem es Zeit wird, meine Zimmerbeleuchtung von Wolfram auf >Halbleiter umzustellen, so sieht der Plan aus: Den Teufel mit dem belzebub austreiben? >1500 RGB-LEDs, 1500 kaltweiße LEDs, 2000 warmweiße LEDs, alle auf >flexiblen Leisten, jeweils in kleinere Gruppen unterteilt und mittels >PWM (12 Bit) dimmbar. Wohnst du in las Vegas? Oder auf dem Rummel? >Ich habe vor, SCL und SDA über 2 Koaxkabel laufen lassen, deren >Kapazität bei 55 pF/m liegt und da als maximale Leitungslänge meine >Zimmerhöhe (2,4 m) angenommen werden darf, bleibe ich garantiert >innerhalb der spezifizierten 400 pF. Es geht auch mehr, dann eben halt langsamer. >Den Master (noch nicht konzipiert) dann ab in die Mitte und die Pullups >jeweils an die beiden Enden. Einmal irgendwo reicht. Das Thema Wellenwiderstand greift bei I2C nicht wirklich. >Meine erste Frage betrifft den Schirm von SDA & SCL, wie beschalte ich >ihn? Das ist deine Masse. >Außerdem bin ich noch etwas ratlos, ob und wenn ja, wie ich GND Slave >und GND LEDs trenne ohne dabei große Masseschleifen zu basteln, hab die >Sorge, dass der hohe pulsartige Strom der LEDs mir sonst das I2C >versaut. Muss man halt lokal mit Elkos puffern. >Und wie siehts mit den Serienwiderständen vor jedem Slave aus, 330, 100 >oder 0 Ohm? Gar nicht.
thx @ falk Du meinst, ich soll die Schirme als einzige Masseverbindung zwischen Netzteil, LEDs und Slaves nehmen? @ next Eigentlich keine schlechte Idee, das Ding ist nur, dass jeder Slave so klein (und so billig;) wie möglich bleiben muss, da ich sie (wie die LEDS) in eine Fräsnut in meinen Regalen einsetzen möchte. Mit jedem zusätzlichen Bauteil verbrauch ich mehr Basismaterial, hab mehr Lötarbeit und mehr "Hohlraum" in den Regalbrettern...
@ Quenz (Gast) >Du meinst, ich soll die Schirme als einzige Masseverbindung zwischen >Netzteil, LEDs und Slaves nehmen? Nein,denn du willst dort ja nicht Zig Ampere drüberschicken. Außerdem ist das mit den Koaxkabeln nicht sonderlich sinnvoll und praktikabel, selbst RG174 ist mal ganz fix ziemlich dick, von Steckverbindern ganz zu schweigen. Das Problem der Masseverschiebung löst man mit gescheiten Bustreibern, I2C ist dafür denkbar ungeeignet, geht nur in bestimmten Situationen. Nimm CAN oder RS485, die Kosten für den Tranceiver bringen dich nicht um.
Hast du schon gedacht wie man die i2c adressierung per platine unterschiedlicht einstellen kann ? Ueberlege mal om ein andere protocol zb DMX-512 zu benutzen.
@ Patrick Jeder Slave (ist ja ein µC) bekommt seine eigene Adresse bei der Programmierung. Ich hab mir stundenlang Gedanken übers Protokoll gemacht und hin und her überlegt, I2C kommt mir deshalb sehr entgegen, weils keine Außenbeschaltung braucht (insgesamt 2 Widerstände, nicht nennenswert) und nur 2 IO-Pins verbraucht (der 12F1840 hat nur 6 und 3 davon brauch ich schon für die RGB-Ansteuerung. Natürlich ist I2C nicht ganz ohne, aber da ich wiegesagt Koaxkabel mit 55 pF/m benutze und das auch nur 2,5 mm Durchmesser hat, scheint es mir bisher als die Lösung, die meinen Vorgaben (klein, simpel, billig) am nächsten kommt. Achja, Steckverbinder (einfache Stiftleisten) benutz ich nur für die Energieversorgung, die Koaxkabel werden alle 20 cm "leicht angeknabbert" und dann mit einem kleinen Stück Litze direkt an die Slaveplatine gelötet. HF-Steckverbinder wären nicht nur zu groß, sondern auch viel zu teuer. Sobald ich halt nen Transciver/Pegelwandler/sonstwas einsetze, wird die Slaveplatine (n>50) ebenfalls zu groß und zu teuer...
Ich finde es zumindest "ungeschickt", überschüssige Energie an Widerständen zu vernichten. Wenn das pro 3 LEDs 1 Widerstand ist, dann sind das immerhin 1667 Widerstände, und wenn jeder mit 1/4 Watt heizt, ist das die Abwärme eines Baustrahlers... Quenz schrieb: > 1500 RGB-LEDs, 1500 kaltweiße LEDs, 2000 warmweiße LEDs Weißt du, wie oft da eine kaputt ist? Wenn eine einzelne LED eine MTBF von 100000 Stunden hat, dann verreckt bei dir rechnerisch alle 100000/(3*1500+1500+2000) = 12,5 Stunden eine LED. Also sorg dafür, dass du die Dinger leicht tauschen kannst... :-o
@ Quenz Lese Dir mal den Absatz "Verwendung" unter http://de.wikipedia.org/wiki/I2c durch und lass ihn Dir auf der Zuge zergehen. Bist Du wirklich sicher, dass Deine Applikation diesen Anforderungen entspricht?
Lothar Miller schrieb: > dann verreckt > bei dir rechnerisch alle 100000/(3*1500+1500+2000) = 12,5 Stunden eine > LED. Was soll das bitte für eine Rechnung sein? Nach deiner Überlegung erreicht dann genau eine LED die MTBF.
I2C ist zwar nicht die beste Wahl, kann hier aber bedenkenlos benutzt werden. Ich nehme an, du willst keine super schnelle Blitzdings-Discobeleuchtung bauen, daher kannst du die Busfrequenz doch stark verringern und somit Probleme umschiffen. Bei 10kHz benötigst du grob geschätzt 1/3s für die Übertragung an alle Slaves. Wenn überall die gleiche Einstellung gemacht werden soll, so kannst du dies über eine globale Adresse machen, auf die alle Slaves reagieren. Das ACK musst du dann aber weglassen. Die Adresse würde ich dynamisch per SW jedes mal neu erzeugen. Ich hätte jedenfalls keine Lust die SW 50Mal neu zu kompilieren nur weil eine Zahl ändert... Ausserdem würde ich für die ganze Sache einen anderen Ansatz wählen. Warum nicht eine etwas grössere Leiterplatte erstellen, auf der LED Treiber sitzen, die von einem uC gesteuert werden. Ist doch dem Treiber wurscht wenn da noch 2m Kabel dazwischen sind. Ausserdem würde ich schauen, dass möglichst wenig unnötige Verlustleistung entsteht (Vorwiderstände usw.).
Hallo, 50 Slaves an 1 Master? Und dann noch ein paar Meter Koaxkabel? Na da wünsche ich mal viel Spaß! Gruß
@ Lothar Der Widerstand und die LEDs sind nur das Ersatzschaltbild für die flexiblen LED-Leisten, deren Design war nicht meine Idee ;) Die MTBF-Rechnung halte ich bei nicht überbelasteten LEDs für vernachlässigbar, zumal mir der Rechenweg ein wenig spanisch vorkommt. Wieso 3 mal die Gesamtanzahl aller LEDs? Die MTBF parallel zusammengesetzter Systeme wird doch ganz anders berechnet!? Außerdem darf man nicht vergessen, dass es eigentlich nie dazu kommen wird, dass alle LEDs (gleichzeitig) an sind, zum einen wegen der PWM, zum anderen weil die RGB-Beleuchtung sowieso nicht für den Alltag gedacht ist, sondern nur nach Bedarf verwendet wird. @ Jungster Ich weiß, dass die Idee hart an der Grenze ist, aber ich habe imho genügend Schutzmaßnahmen getroffen, als dass der Bus laufen sollte. Wie ganz zu Anfang erwähnt, es gab schon Videorecorder, die über ein I2C-Kabel mit dem Fernseher verbunden wurden.
Quenz schrieb: > Wie ganz zu Anfang erwähnt, es gab schon Videorecorder, die über ein > I2C-Kabel mit dem Fernseher verbunden wurden. 50 Videorecorder???
@ bestucki > I2C ist zwar nicht die beste Wahl, kann hier aber bedenkenlos benutzt > werden. Ich nehme an, du willst keine super schnelle > Blitzdings-Discobeleuchtung bauen, daher kannst du die Busfrequenz doch > stark verringern und somit Probleme umschiffen. Bei 10kHz benötigst du > grob geschätzt 1/3s für die Übertragung an alle Slaves. Wenn überall die > gleiche Einstellung gemacht werden soll, so kannst du dies über eine > globale Adresse machen, auf die alle Slaves reagieren. Das ACK musst du > dann aber weglassen. Sehr richtig, so hab ich auch gedacht :) Vll mach ich die I2C-Frequenz auch variabel, falls es doch mal einen Abend Blitzdingsdisko sein soll, muss dann halt schauen, bis zu welcher Geschwindigkeit der Bus mitmacht ^^ > Die Adresse würde ich dynamisch per SW jedes mal neu erzeugen. Ich hätte > jedenfalls keine Lust die SW 50Mal neu zu kompilieren nur weil eine Zahl > ändert... Das wäre eine große Arbeitserleichterung, gefällt mir sehr die Idee. Nur wie mach ich das bzw. woher weiß ich am Ende, welche Slave jetzt welche Addy hat? > Ausserdem würde ich für die ganze Sache einen anderen Ansatz wählen. > Warum nicht eine etwas grössere Leiterplatte erstellen, auf der LED > Treiber sitzen, die von einem uC gesteuert werden. Ist doch dem Treiber > wurscht wenn da noch 2m Kabel dazwischen sind. Ausserdem würde ich > schauen, dass möglichst wenig unnötige Verlustleistung entsteht > (Vorwiderstände usw.) 150 mal 12 Bit PWM mit unterschiedlichem DutyCycle? 151 mal ca. 2 Meter ungeschirmtes Kabel auf dem mit 5 - 10 kHz bis zu 1,5 A laufen? Ich glaube, da hab ich mit I2C weniger Stress ;)
@ Jungster > Quenz schrieb: >> Wie ganz zu Anfang erwähnt, es gab schon Videorecorder, die über ein >> I2C-Kabel mit dem Fernseher verbunden wurden. > > 50 Videorecorder??? Lustige Vorstellung. Ich denke mal, dass bei 50 Videorecordern die 400 pF-Marke überschritten worden wäre, weils das passende Kabel damals sicher nur in 0,5 Meter-Stückelungen gab.
@Falk Huhu, nur so als Idee, wenn's günstig sein soll: Schau Dir mal den L9637 bei ST an. Es gibt sowas steinstabiles wie LIN-Bus, da reicht dann für den ganzen Klump ein Dreidrahtsystem. Damit haben wir schonmal halbe Gebäude vernetzt, bei 24V, 19200 Bd und Konstantstromquellen für die LEDs. Nur ein Vorwiderstand dürfte doch etwas schlicht für gleichmäßige Beleuchtung werden. Wir haben das seinerzeit mit 90S4433, dem antiken Vorgänger des Mega8 aufgebaut, den LIN-Bus hatte ich ausgewählt, weil der kurzschlussfest und nahezu unzerstörbar ist. Beste Grüße Krempel
Hi Quenz, dass das Kabel keine 400pF hat mag ja noch hinkommen, aber jeder Slave und dessen Port + Leiterplatte + Stecker + Streukapazität hat schon mindestens 15pF. Macht bei 50 also schon 750pF + Kabelkapazität. Die spezifizierten 400pF kannst Du also knicken.
Nachschlag zum Thema Stringdefekt, Ausfall einzelner LEDs in der Kette. Littlefuse hat eine Bauteilserie PLED 5HT, die schaltet man parallel zu den LEDs und schon ist der Ausfall einer LED nicht mehr letal für die Kette.
@ Hans > Hi Quenz, > > dass das Kabel keine 400pF hat mag ja noch hinkommen, aber jeder Slave > und dessen Port + Leiterplatte + Stecker + Streukapazität hat schon > mindestens 15pF. Macht bei 50 also schon 750pF + Kabelkapazität. Die > spezifizierten 400pF kannst Du also knicken. Verdammt, nicht bedacht. Also die Slavekapazität plus Sicherheitsreserve ausrechnen und die 50 Slave mittels "Zwischenmaster" (Bus-Topo --> Baum-Topo) soweit aufteilen, dass jeder Strecke + Slaves wieder unter 400 pF liegen :/
Quenz schrieb: > Das wäre eine große Arbeitserleichterung, gefällt mir sehr die Idee. Nur > wie mach ich das bzw. woher weiß ich am Ende, welche Slave jetzt welche > Addy hat? Da du ausschliesslich uCs verwendest, die du selbst programmierst, hast du den Vorteil, dass du das "Protokoll" selbst definieren kannst. Du kannst die Adressen auch nur einmal dynamisch erzeugen lassen und dann im internen EEPROM speichern. Das erste Mal musst du dann einen "Konfigurationsmodus" aufrufen. Musst du ja so der so, entweder einmal dynamisch oder einmal statisch im Programmcode. Alternativ kannst du die Adresse auch einzeln "einbrennen". Dabei ist immer nur ein Slave mit einer Standardadresse (im Programmcode definiert) am Bus und der Master sendet diesem die neue Adresse, die dann im internen EEPROM abgelegt wird. z.B. über einen Taster kannst du dann den Master forcieren nach einem neuen Slave zu suchen.
Adresse eim eeprom is ne gute Idee. Beim flashen wird auch das eepromfile mit übertragen in dem immer mitm editor ne neue Zahl eintippen bevor man den nächsten PIC nimmt.
Och, wenn man mal auf der Site hier forscht: http://www.mikrocontroller.net/part/MCP201 zeigt doch ganz hübsch alles incl. CPU-Anbindung.
Falls du das von Hand löten willst: Ich habe mal ne Schaltung mit über 500 LEDs und entsprechend vielen Vorwiderständen gelötet. Das ist eine Heidenarbeit!
Martin Wende schrieb: > Adresse eim eeprom is ne gute Idee. > Beim flashen wird auch das eepromfile mit übertragen in dem immer mitm > editor ne neue Zahl eintippen bevor man den nächsten PIC nimmt. Danke für diesen großartigen Tip :)
Wie willst du eine drei-kanalige 12-bit PWM mit EINEM hardware 10-bit PWM Modul realisieren? In Software? Aber ich denke eine 8-bit Auflösung sollte für eine Beleuchtung auch ausreichen. Die ist dann einfach in Software zu machen und verringert auch den Datenverkehr auf dem Bus.
12 bit braucht man schon um die quadratisch verlaufende Helligkeitskurve auszugleichen. Das Auge nimmt Lichtintensität nicht linear war.
Angehängte Dateien:
-
I2C_unidirektional.png
4,8 KB
Hab mir mal das Datenblatt vom PIC12F1840 genauer angeguckt, 50 pF allein für den Slave-Pin, Mist... Aber mir ist eine Methode eingefallen, wie man das ganze retten kann ^^ Da die Slaves vom Bus sowieso nur Farb-, Dimm- und andere Steuerbefehle übernehmen sollen, spricht nichts dagegen, diesen unidirektional auszulegen; ich verzichte einfach aufs Acknowledge und puffer den Bus masterseitig! Außerdem vergrößere ich den Störabstand, indem ich die Bus-Spannung auf 24V erhöhe und diese mittels Spannungsteiler vor jedem Slave wieder auf TTL-Level bringe. 4 x 0603 Widerstände entspricht meinem Verständnis von klein, billig und simpel ^^ Irgendwer irgendwelche Einwände? > Wie willst du eine drei-kanalige 12-bit PWM mit EINEM hardware 10-bit > PWM Modul realisieren? In Software? Vergiss das PWM-Modul, die linearen 12 Bit vom I2C soll die SW per lookup table in einen 16-bit Wert umsetzen, welcher der bereits erwähnten Helligkeitskurve entspricht. Dieser 16-bit Wert wird dann als Compare für Timer1 benutzt. Nach jedem Interrupt wird des Compare mit gestoptem Timer auf die nächste Farbe geupdatet.
Dann nimm aber nicht mehr den I2C sondern einen (Software)UART. Dann brauchste sogar nur einen Datenpin. Außerdem kannste nen nrmalen Mosfettreiber nehemn, der hat auch schon genug Power um die Leitung zu treiben.
Martin Wende schrieb: > Dann nimm aber nicht mehr den I2C sondern einen (Software)UART. > Dann brauchste sogar nur einen Datenpin. Dann muss aber per Software die Taktfrequenz vom Master und der Slaves abgeglichen werden (ich nehme an, du benutzt den internen RC-Oszillator). Ausserdem würde ich auch einen Treiberbaustein verwenden. Bei deiner Lösung werden, wenn auch nur kurz, deine 24V kurzgeschlossen.
Schau Dir zu dem Thema auch mal noch folgendes an: http://ics.nxp.com/support/documents/interface/pdf/an97055.pdf
Ich werfe mal den WS2801 ins Rennen. - Ansteuerbar über eine CLK und DTA Leitung - Kaskadierbar und selbst adressierend - KSQ eingebaut - 3 8-Bit PWM Kanäle - Nur 3 Widerstände und ein Pufferkondensator als externe Beschaltung - Es sind fertige Strips mit RGB LEDs als Rollenware zu haben Beispiellinks: Datenblatt: http://shop.boxtec.ch/pub/sparkfun/WS2801.pdf Strip: http://shop.boxtec.ch/pixel-strip-ws2801-p-40601.html Beleuchtungsprojekt: http://pixelinvaders.ch/?page_id=396
Quenz schrieb: > Außerdem vergrößere ich den Störabstand, indem ich die > Bus-Spannung auf 24V erhöhe und diese mittels Spannungsteiler vor jedem > Slave wieder auf TTL-Level bringe. 4 x 0603 Widerstände entspricht > meinem Verständnis von klein, billig und simpel ^^ Hört sich für mich eher nach "Murks" und "Gebastel" an... :-/ > Irgendwer irgendwelche Einwände? I2C unidirektional? Wofür dann das ACKnowledge? Nimm RS485 oder besser RS422. Das ist z.B. in der kommerziellen Lichttechnik als DMX512 bekannt und kampferprobt, braucht auch nur 2 verdrillte Leitungen und hat wegen der symmetrischen Übertragung eine ausgezeichnete Störfestigkeit. Mit DMX512 könntest du z.B. auch Tests mit einem käuflichen Controller machen, oder dein System um eine kommerzielle Lampe erweitern... Und richtig: die Ausfallswahrscheinlichkeit ist niedriger, allerdings weiß ich einige LED-Strahler aus der Lichttechnik (Lichterketten, PAR56 und PAR64), wo ein LED-Defekt die Hauptausfallsursache ist. Ich würde also eine einfache Tauschmöglichkeit der LEDs einplanen...
Wenn du unbedingt bei I2C bleiben willst könnte dir noch ein P82B715 I2C Bus extender helfen... Ralf
Ralf schrieb: > Wenn du unbedingt bei I2C bleiben willst könnte dir noch ein P82B715 I2C > Bus extender helfen... > > Ralf Davon kann ich nur abraten. Wenn schon I2C dann wenigstens P82B96. Allerdings rate ich in diesem Zusammenhang immer noch von I2C insgesamt ab. Das ist für diese Applikation einfach zu empfindlich. Gruß
Moin moin, die Aufgabe ist sicher interessant, aber sonnvoll? Bei gut 400W Verlustleistung macht der Wolframdraht doch die bessere Figur. 6 60W-Lämpchen sind vermutlich gemütlicher und auch nicht verschwenderischer, und sie machen auch noch Licht dabei. ;-) Zumal unter ökologischem Gesichtspunkt 5000 LEDs + anderer Halbleiterkram gegen die 6 Glühlampen nicht sonderlich glorreich dastehen. VG Steffen
..ich nehme in dem Fall immer einen CAN Transceiver http://www.systronix.com/Resource/PCA82C250_3.pdf oder einen rs485 Transceiver: http://www.datasheetcatalog.org/datasheets/270/189806_DS.pdf oder dmx: http://www.sycelectronica.com.ar/semiconductores/75176.pdf und schalte Ihn direkt an den UART. Bei letzterem kann man sich auch protokolltechnisch alles wichtige abgucken da es sich um die Konstellation 1 Master X Slaves handelt. Ansosnten ist das hier wohl eher was für das Hausbus Unterforum. Gruß, M.
>>Gesichtspunkt 5000 LEDs + anderer Halbleiterkram gegen die 6 Glühlampen
ich verstehe nicht wie man das ins Verhältnis setzen kann, 5000 RGB
Leuchtdiodens und 6 Glühlampen, was haben die gemein außer das sie Licht
erzeugen?
MM
Hallo MM, meiner bescheidenen Meinung nach verursacht die Herstellung von 5000 LEDs mehr Sondermüll und Giftstoffe (Abprodukte der Halbleiterindustrie) als 6 Glühlampen. Aber wie so oft im Leben kann ich mich auch irren. Beweisen kann ich es eh nicht. ;-) VG Steffen
Achtung: Es geht hier nicht um 6 Glühlampen vs. 5000 LEDs Die Leistung von 400W war nur die Verlustleistung, die ich anhand der zuerst geposteten Schaltung bei 5000 LEDs maximal prophezeit habe. Bitte nicht jede dahingerotzte Zahl als Stand der Technik annehmen...
Ich weiss. Mir ging es darum auch darauf hinzuweisen, dass nicht alles sinnvoll ist, was machbar ist. Vor allem in Zeiten des ungebremsten "Wachstums" und der Verschwendung. Aber, ich will damit keinen Flamewar entfachen. ;-)
Und es geht natürlich nicht um 5000 LEDs - 6 Glühlampen, sondern um 5000 LEDs mit Vordiderstand - 6 Glühlampen. Wobei die 5000 LEDs auch eine Leistung benötigen. aber das kann ich natürlich hier so nicht abschätzen. VG
> Und es geht natürlich nicht um 5000 LEDs - 6 Glühlampen, sondern um 5000 > LEDs mit Vordiderstand - 6 Glühlampen. Flexible (RGB-)LED-Streifen (alle 5 cm teilbar) ohne Vorwiderstand? Wird sowas überhaupt hergestellt? Ich zerschredder doch nicht haufenweise Europlatinen, um mir daraus eigene (starre) Leisten mit KSQ statt Vorwiderstand zu basteln, wir reden hier von etlichen Metern... Achja, ich war zu Anfang bei der Mengenangabe der LEDs etwas unpräzise, es sollen nicht 1500 RGB-LEDs werden, es sollen 500 werden, ich hatte noch die Zahl der Dies im Kopf, deswegen... Die 2000 warmweißen LEDs werden die Hauptarbeit leisten, während RGB und kaltweiß für Sonderzwecke vorgesehen sind und somit für den tagtäglichen Energieverbrauch keine Rolle spielen.
@Quenz, das ist ein sehr schöner Beitrag von dir, klasse wie du auf Vorschläge eingehst. Offensichtlich hast du dich ja schon entschieden - ich bin weg - viel Erfolg. RGB LED und Glühlampen lassen sich nicht vergleichen da sie völlig unterschiedliche Möglichkeiten bieten. Man kann nicht schreiben "ob es sinnvoll wäre" da die Leuchtmittel völlig unterschiedliche Möglichkeiten bieten - mehr wollte ich nicht sagen. Das wäre so als würde ich schreiben, hmm ob es sinvoll wäre einen Ferrari gegen einen Polo zu tauschen wenn der kaputt gegangen ist. Es fehlen zu viele Angaben um das zu bewerten, auch von der Umweltbelastung her. Wenn der Ferrari von einer Wohngemeinschaft mit 20 Personen angeschafft wird um gemeinsam jeden Tag mit einem Anhänger voller Menschen zur Abreit zu fahren, und der Polo das von der Leistung her nie geschafft hätte.... Es hängt von den Randparametern und Gründen ab, die NICHT weiter genannt werden und um die es hier wirklich überhaupt nicht geht. MM
Maddin schrieb: > das ist ein sehr schöner Beitrag von dir, klasse wie du auf Vorschläge > eingehst. Offensichtlich hast du dich ja schon entschieden - ich bin weg > - viel Erfolg. Eher andersrum. Die Vorgabe ist, dass slaveseitig kein Pegelwandler eingesetzt wird, aber in den meisten Vorschläge wird das ignoriert. Stattdessen diskutieren wir über LED-Vorwiderstände...
Der PIC12F1840 kann ja schon mehr als die Standard 3mA an seinen IO Ports (und somit I²C) ziehen. Daher könntest du auch die I²C Pull-Ups kleiner machen (was den Kapazitätsproblemen entgegenwirkt).
Quenz schrieb: > Die Vorgabe ist, dass slaveseitig kein Pegelwandler > eingesetzt wird, aber in den meisten Vorschläge wird das ignoriert. Die Eigenschaften des Busses (siehe meinen Link im Beitrag oben) scheinen Dich nicht zu interessieren. Dieser Bus ist für die Signalübertragung zwischen Komponenten auf einer Platine konzipiert und nicht als Hausbus. Entweder wird Du bei Deiner Applikation einen sehr hohen Aufwand (= unnötig teuer) bei der Spannungsversorgung treiben müssen oder Du kannst sehr interessante Effekte erleben, die durch Potentialverschleppungen entstehen.
Quenz schrieb: > Die Vorgabe ist, dass slaveseitig kein Pegelwandler > eingesetzt wird, aber in den meisten Vorschläge wird das ignoriert. Ja, weil es einfach keinen Sinn macht, auf die 30 Cent für einen RS422-Wandler zu verzichten. Und auf einem Bus rumzuhocken, der für "Inter-Integrated-Circiut" Verbindungen (also auf Leiterplattenebene mit 50cm Länge) entwickelt wurde. > Stattdessen diskutieren wir über LED-Vorwiderstände... Es ist dein Thread (alternativ: deine Sitzung, deine Besprechung). Da bist du selber in der Moderatorenrolle und solltest sachlich dafür sorgen, dass das nicht ausufert! Oder sehe ich das falsch?
Wie immer, kaum wird ein I2C Bus über mehr als 5cm vorgeschlagen, schon machen sich alle in die Hose :) Halten wir mal fest: I2C über 2,5m ist absolut kein Problem. Zumindest wenn man ihn nicht mit 1MHz fahren will. Eine eigene Masse für den LED Strom hat er ja auch schon vorgesehen. Probleme dadurch sollten sich also auch in Grenzen halten.
Jörg S. schrieb: > Eine eigene Masse für den LED Strom Die Massen sind aber offensichtlich nicht potentialgetrennt. Damit kann sich der Strom (mit allen Störsignalen) aussuchen, über welche Masse er fließt. Wieso meinst Du, dass das gut funktionieren soll?
>Die Massen sind aber offensichtlich nicht potentialgetrennt. Soweit ich die Schaltung richtig interpretiere sind sie aber auf den LED Platinen getrennt.
Jörg S. schrieb: > Wie immer, kaum wird ein I2C Bus über mehr als 5cm vorgeschlagen, schon > machen sich alle in die Hose :) Das ist so nicht richtig. Ich verwende bei meiner Haussteuerung sehr viele Komponenten, die über I2C angeschlossen sind. Und auch ich bewege mich dabei weit außerhalb der Spezifikation. Mit den entsprechenden Folgen. Ich musste daher einigen Aufwand treiben, um noch eine zuverlässige Kommunikation zu gewährleisten. Obendrein wird hier durch die PWM-Steuerung der Module noch ein erhebliches Störpotenital vorhanden sein. Ich prophezeihe daher aus eigener Erfahrung, dass dies so einfach nicht dauerhaft funktionieren wird. Die Komponenten die ich über RS485 angeschlossen und übers ganze Haus verteilt habe, funktionieren dagegen absolut unauffällig. Gruß
Jörg S. schrieb: > Halten wir mal fest: I2C über 2,5m ist absolut kein Problem. > Zumindest wenn man ihn nicht mit 1MHz fahren will. Und wenn keine Störer unterwegs sind, und wenn die Masseverbindung passt, wenn keine Potentialverschiebungen durch die zwei "Massen" auftreten, und, und, und... Das wären mir einfach schon aus Prinzip zu viele Unwägbarkeiten. Und zumindest ich will ja nicht jedem Tag dem Zeug hinterherrennen, weil irgendwas wieder nicht tut wie es soll.
Lothar Miller schrieb: >> 1500 RGB-LEDs, 1500 kaltweiße LEDs, 2000 warmweiße LEDs > Weißt du, wie oft da eine kaputt ist? > Wenn eine einzelne LED eine MTBF von 100000 Stunden hat, dann verreckt > bei dir rechnerisch alle 100000/(3*1500+1500+2000) = 12,5 Stunden eine > LED. Also sorg dafür, dass du die Dinger leicht tauschen kannst... :-o Das ist schlechtweg falsch. Aber leicht tauschen sollte man sie schon könnnen...
Wahrscheinlich schrieb: > Das ist schlechtweg falsch. Das habe ich selber weiter oben schon angemerkt: Beitrag "Re: 5000 LEDs über I2C dimmen" Schön wärs jetzt gewesen, wenn du den richtigen Wert durchgegeben hättest...
Lothar Miller schrieb: > weil irgendwas wieder nicht tut wie es soll. Da geht dann der WAF dramatisch nach unten. Und das bei der Wohnzimmerbeleuchtung!!! Aber wer nicht hören will ... Gruß
Thread beobachten
Seitenaufteilung abschaltenBitte 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.