Ambilight mit AtmoWin: Diskussionsthread

Das Projekt gefällt mir. Ist schon recht anspruchsvoll, denke ich. Und wenn man mal sieht, was da ein paar Leute im anderen Forum gerade versucht haben, ist das hier ein Ambilight, wie es sein muss. Machst Du die Vorstellung hier eigentlich "nachbaufähig"? Wäre eigentlich ein Projekt für die Lobby.

Ich muss sagen: Im cmbined Mode bin ich einfach begeistert! Wahnsinn!

Sehr geil. Was ein "Mittendrin"-Feeling. Ich will auch sowas!

Alle Daumen hoch!

Boah... Sowas will ich auch haben Dafür müsst ich mir aber erstmal nen LCD-TV kaufen, hab immernoch 'ne gute, alte Röhre hier rumstehen. Aber das Projekt ist einfach geil, vorallem der combined-Modus gefällt mir super gut!

Ich kann nicht verstehen, warum man sich sowas holt. Meineserachtens wird der Kontrast viom eigendlichen Bild deutlich verschwächt und ablenken tut es auch noch

Meine pers. Meinung.

Hochachtung vor dem Aufbau!

Hey!

Supersache, bin begeistert!

Bastel' für einen Freund (Heimkino, Beamer, etc...) gerade auch ein AtmoLight, aber auf die Idee das so eng zu segmentieren bin ich noch garnicht gekommen. Geschweige denn die decodierung des Datenstroms direkt vor Ort, und nicht zentral zu erledigen, so wie das Originalprojekt... Hut ab, das spart Unmengen an Kabeln...

Vielleicht kannst Du ja noch ein paar Details zu Schaltplan/Layout und der Firmware posten?
Könnte mir gut vorstellen, das in Dieser Form, oder eng daran angelehnt nachzubauen, und man muss das Rad ja nicht 2x erfinden
Ich sehe noch nciht ganz, wie Du die Daten zu den einzelnen Controllern schaufelst. Führst Du den TTL-Pegel über die Dritte Leitung durchgeschleift zu den Platinen?
Also PC -> Bluetooth, Bluetooth -> TTL, TTL -> Controller?

Edit: Oh, und nochwas: Wenn das Datensignal nur durchgeschleift ist, wie addressiert Du die Kollegen denn? In Software? Oder "Knabbert" jede Platine was von den Daten weg, und schickt den Rest weiter?
Und hast Du den Controller "fliegend" programmiert bzw. mit entsprechendem Adapter? Auf der Platine sehe ich keinen ISP-Header o.Ä. ?

Viele Grüße
Andre

Na, das ist doch mal ein Ambitioniertes Projekt, das wäre auf jeden Fall Lobby-würdig!

habe ich so auch noch nie gesehen, in der Auflösung, das ist schon echt ne Erweiterung des Bildes um die Glotze rum!

Ich bin generell auch eher ein Freund von "Rechenleistung verteilen" statt einem Riesencontroller und nem Berg Kabel... - Mich würde nur der überstehende Quarz stören, aber den könnte man ja auch noch durch einen in SMD ersetzen, dann wäre das ne schöne Pixelplatine, um die in ein Alu-U-Profil einzubauen...

Sieht mir so aus, als ob das der ISP-Anschluß wäre:

Gar nicht doof, da reicht wohl ne ordentlich draufgepresste Stiftleiste, oder hast Du da so nen Federnadel-Adapter...? - das ist ja generell immer das Problem, µC in SMD ist schön klein, und der ISP dann doppelt so groß - ich entwerfe gerade ne LED-Armbanduhr, da habe ich das Problem auch...

Auf dem Foto der Unterseite der Platine sieht man, dass die 3 Leitungen einfach durchgehen - Adressierung muss also in der SW fest eingebrannt sein... aber gut zu sehen, dass das auch mit TTL-Pegel über die Strecke und 32 Empfängern an der Leitung funktioniert, ohne besondere Maßnahmen (Treiber, abgeschirmte Kabel...)

Ich nehme an, Du benutzt die HW-PWM, deswegen 2x RGB..? - weil rein vom Controller her könnte man ja auch noch mehr LEDs auf eine Platine machen, gut, muss man halt schauen, dass es nicht zu viel Strom wird...(*)

Wie ist das mit diesem BTM-222 Modul, ist das speziell auf diese SW abgestimt, oder geht das einfach so, Bluetooth-Stick in den Rechner, dann virtueller Com-Port und aus dem Teil kommen serielle Daten raus..? - Da wäre das echt öfter zu überlegen für Lichtsteuerungen, oder z.B. auch Cube vom PC aus steuern etc., wenn das so einfach ginge...?

*EDIT: natürlich würde dann auch das Layout komplizierter...

Turi, hast Du Dir mal den im Startpost verlinkten Thread angesehen..? - Da ist die SW ja drin, in Bascom... bräuchte man nur noch das Layout als PDF, dann hätte man alles zum nachbauen (Schaltplan ist da ja wohl überflüssig.. ;))

Elite: Falls Du Dir mal Assembler "antun" willst, da könnte man auch ne 12-Bit-SW-BCM machen, dann wär das Auflösungsproblem in den dunklen Bereichen auch weg...

Nochmal EDIT: Inzwischen selbst gefunden: Im "SSP-Modus" kann man das Bluetooth-Teil einfach als serielle Schnittstellebenutzen, also im Endeffekt für den AVR genau so, wie wenn man ihn per RS-232-Kabel an den PC hängen würde - das ist ja mal genial! - Leider mit ca. 12-16 Euro nicht so günstig, dass man das in jede Spielerei mal schnell mit einbaut...

Ah, ok. Das mit dem verlinkten Thread hatte ich nicht so interpretiert. Allerdings wäre alles zusammen hier (in der Lobby?) schon nicht schlecht.

Wow, da will ich dir auch mal mein großes Lob aussprechen!
Manchmal kann so einfach so schön sein =)
Kann ich mein Ambi Projekt geradezu in die Tonne kippen.

Aber eine Frage bleibt mir, wie überträgst die Daten?
3 Adern haste ja, +, GND, eine bleibt.
Somit würde ich auf UART tippen?

Somit bekommt also jeder AT auch alle Daten und nimmt sich halt die Bits die er benötigt.

Was 2bl in eine Frage formuliert hat ist aber auch eine schöne Lösung, die dritte Ader auf der Platine trennen und RX rein und TX raus.
Jeder Stripe knabbert sich ein paar Bit ab und schickt den Rest weiter, somit könnte man sich die Adressierung sparen.

Greetz

Ja, das ist ja auch ne gängige Methode, machen der Biertrinker bei seiner Schattenfuge und ich bei meiner DMX-Lichterkette ja auch so...

Hat den zusätzlichen Vorteil, dass das serielle Signal immer neu erzeugt, und nur von Platine zu Platine weiter verbunden wird, man also auch deutlich mehr als 32 so Module über ne deutlich längere Strecke verbinden kann...

wäre direkt ne Überlegung wert, das dann bei ner Vorstellung hier im Forum (sofern überhaupt geplant...?) noch als Alternative reinzustellen, also zumindest das Layout, das ist ja nur ein klitzekleiner Umbau...

Gibts ne Passende Software auch für Linux ?

Plane gerade mein PVR durch und da könnte man das auch noch einpflegen

Mir ist gerade noch etwas aufgefallen was mich etwas verwundert.
Auf der Platine sind zwei 51Ohm Rs an den LEDs, ich vermute mal auf den roten Kanälen.
Die Frage die sich mir nun stellt, was ist mit Grün und Blau, die hängen über den AVR direkt am Saft,
sollte man denen nicht wenigstens nen 1Ohm R verpassen um den Strom zu begrenzen?

Selbst wenn die passenden 3,x Volt zur Versorgung eingesetzt werden so können die LEDs doch "unendlich" Strom ziehen, was weder dem AVR noch den LEDs gefallen dürfte?

Greetz

Hallo, ich beschäftige mich seit gestern auch mit demThema ambilight-nachbau, Um das Rad nicht neu erfinden zu müssen, würde ich mich auch sehr über Schaltpläne und eine kurze Anleitung wie ich die Software auf den Mikrokontroller bekomme freuen.
Beste Grüße
Arne

Elite

ich werde mich jetzt da mal durchwühlen.

MfG
faheus

hmm, funktioniert scheinbar nicht so pralle mit mythbuntu

Zitat von faheus

hmm, funktioniert scheinbar nicht so pralle mit mythbuntu

Sehr wertvoller Beitrag! - das ist auch so ein Grund, warum der Thread in der Lobby besser aufgehoben wäre...

Elite: Sehr ausführlich und gut gemachtes Tutorial! - eine Bitte: die Bilder bei abload.de sind garantiert irgendwann verschwunden, und dann ist der Thread nur noch halb so informativ - wäre also gut, wenn Du die "hier" (z.B. in der Galerie) hochlädst, und dann von da aus verlinkst...

Wegen dem sichtbaren Bildaufbau: das scheint daher zu rühren, dass die SW am PC die Daten relativ langsam berechnet - bei der Datenrate sollte eigentlich keine Verzögerung zu erkennen sein, bis die 192 Byte durch sind...

bei dem Weiterreichen kommt's natürlich auch drauf an, wie man das macht - wenn man erst alle 192 Byte puffert, und dann den Rest weiterschickt, dann dauert das natürlich zu lange - bei meiner DMX-Lichterkette z.B. wird das "direkt" weitergeschickt:

Die Empfangsroutine empfängt den "Break", dann erzeugt sie einen am Ausgang - inzwischen kommt das Startbyte, das wird dann auch gleich erzeugt - derweil kommen die ersten 3 Byte, die werden gespeichert - ab dem 4. Byte wird nicht mehr gespeichert, sondern dieses gleich weiter gesendet...

Die Verzögerung ist also pro Platine ca. "ein Byte", d.h. die Daten an der letzten Platine würden (bei 64 RGB-Nodes) "64 Byte später" ankommen, als wenn die letzte Platine direkt am DMX-Signal hängen würde, eigentlich so gut wie keine Verzögerung... dieses Prinzip lässt sich hier ja auch anwenden