"Ambi Light" von Philips nachbauen - LOS GEHTS!!

Erster!

Die Schaltung ohne Regelung ist aufgebaut und funktioniert,
auch die Zusammenschaltung mit dem Plugin.

Optimierende Grüße, Samael

Beweise...

Bilder, Video wäre besser, Screenshots

hi,

ja genau, am besten noch Live-Präsentation mit ordendlich Verköstigung und Saufgelage! Wenn schon, denn schon!

cu,
BC

Zitat

Beweise...

Ja, kommt schon noch, wir waren gerade erstmal was futtern.
Foto kommt auf jeden Fall nachher.

Zitat

ja genau, am besten noch Live-Präsentation mit ordendlich Verköstigung und Saufgelage! Wenn schon, denn schon!

Komm rum, bring Bier mit!

Gruß, Samael

danke hulk,
ist nur der "vollständigkeit-halber"

Hier ein paar Bilder.

Wir sind gerade bei der AD-Wandlung und haben den Effekt, daß
die Spannung kleiner wird, je mehr eine Farbe angesteuert wird.

Ansonsten ist noch keine Regelung über die Helligkeit enthalten.

Gruß, Samael

@Hulk:
Ich habe gerade von _Frank_ erfahern das ihr hier auch mit USB-arbeitet. Sachen die mir augefallen sind:
Die Schaltung dürfte soweit passen......
Atmega8 hat 8kbFlash und der reicht dicke aus.... (Mehr wie atmega48)

In Sachen Software bin ich auch schon ein kleinwenig drinn. Also bei problememen PN, ICQ oder email

Mfg
Ulrich

Hier nun ein kleines Statement zum Thema wie belege ich meinen Atmega8 mit USB Signalen:

Beide Datenleitungen müssen auf den gleichen Port gehen. Ich benütze dafür gerne den PortD. Aber auch ein anderer Port wäre möglich. Hauptsache beide Signale auf einem Port.
Man muss bedenken dass nur 7 Takte zur Verfügung stehen um die Signale einzulesen und zu verarbeiten.....

Jetzt kommt der Trick und für Hulk warscheinlich Interessant.
Wenn man die Datenleitungen an PortD anschließt kann man auch über Pin PD6(INT0) Daten einlesen. D.h. man muss nicht 3Pins sondern nur noch 2Pins für USB-Opfern.

Zu Recht hat mich Frank nun angesprochen und gemeint ob das überhaupt funktionieren kann wenn man D- nicht auf Pin0 eines Portes legt. Das geht natürlich (bei mir zumindest).
Aber es ging bei mir nicht am Anfang. Nach kurzer Suche im Code fand ich den Fehler. Es gibt ein Define namens USBMASK. Es ist eine Masker mit 2 gesetzten Bits, welche dem Treiber sagen auf welchem Pin die Signale liegen. Ich änderte das Orginal:
#define USBMASK ((1<<USB_CFG_DPLUS_BIT) | 1 )) /* mask for USB I/O bits */

in Folgende und in meinen Augen richtige Version um:
#define USBMASK ((1<<USB_CFG_DPLUS_BIT) | (1<<USB_CFG_DMINUS_BIT)) /* mask for USB I/O bits */

Dieser Bugfix wurde obdev.at noch nicht mitgeteilt. Geschieht aber in wenigen Sekunden.

EDIT:
In der Antwort von Obdev steht sinnengemäss:
Das Signal D- muss auf Bit 0 liegen. Es wäre sonst nicht möglich innerhalb von wenigen Takten das Signal zu verarbeiten.....

Also war die angedachte Änderung von USBMASK falsch.
Bei mir ging es halt erst nachdem ich dies änderte. Aber das war nur ein Zufall. Das bedeutet das die einzigste mögliche Anschlussvariante so geht:
PD2 = D+
PD0 = D-
Jeder andere Anschluss benötigt 3 Pins.......

Alle Aussagen von mir basieren auf dem aktuellen Code der Referenzimplementation Powerswitch. Alle anderen Beispiele wie z.B. lcd2usb sind mit "pfuschanteil" unsauberere Trennung zwischen usb-Software und dem Rest.....

@Hulk:
Dir muss ich es ja eigenltich nicht sagen, aber Teil der USB-Lizenz ist es alles schön nach vorgegebenen System zu dokumentieren.
(Nicht der Sourcecode sondern das "Ausenrum", Schaltplan usw....).
Bei dir habe ich keine Bedenken das du dich an die Lizenz nicht hälst, aber es gibt sehr viele "schwarze Schafe" die sich leider nicht dran halten.....

Mfg
Ulrich

Samael,

wie weit bist Du mit Deiner FW?

Gruss

Eberhard

Die FW für den Atmel ist soweit erstmal fertig, genauso wie das Plugin
für den VDR. Wir haben hier bloß noch Probleme mit den Farben.
Das Atmolight stellt eine Farbe dar, die wir eigentlich nicht erwarten.
Da sind wir aber gerade im Moment zu Gange und wir erwarten,
daß sich vielleicht heute noch eine Lösung ergibt. Wenn wir mit
unserem ersten Wurf zufrieden sind, dann werden wir die Sourcen
fürs Plugin und auch für den Atmel veröffentlichen.

Gruß, Samael

P.S.: Heute ist "Vatertag" und ich hab noch kein Bier getrunken !?

Zitat

P.S.: Heute ist "Vatertag" und ich hab noch kein Bier getrunken !?

Geht mir genauso - bei uns ist aber auch ein Wetter, bei dem nicht mal das Bier schmeckt.

Deshalb hatte ich vor, mich mal etwas mit der AVR Programmierung auseinander zu setzen (Newbie).

Welche Entwickler-Umgebung benutzt Du eigentlich? Hab' mir mal WinAVR und AVR Studio 4 besorgt.

Also, wenn Du mal was an Sourcen "zum Einsteigen" in das Thema uebrig hast - nehm ich gerne.

Gruss

Eberhard

Das Wetter ist hier genauso. Ich glaub, ich fahr aber trotzdem gleich
mal zur Tanke :D.

Der Großteil der Programmierung des Atmel kommt von daniel_k.
Er hat sich, soweit ich weiß, irgendwo ein Entwicklungspaket freier SW
runtergeladen (Editor, Compiler, etc.).

Zum Einsteigen ist folgende Website bestimmt sehr gut:
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial

Gruß, Samael

Zitat

Welche Entwickler-Umgebung benutzt Du eigentlich? Hab' mir mal WinAVR und AVR Studio 4 besorgt.

Genau die benutzen wir auch. Zum "trocken" üben ist übrigens der Emulator im AVR-Studio gar nicht verkehrt.
Gruß,
Daniel

ich und ein paar andere die ich kenne arbeiten auch mit der Kombination aus "WINAVR" und "AVR Studio 4 SP2".
Mit diesen beiden Sachen habe ich eine IDE, Compiler, Software zum programmieren, Simulator usw....

daniel_k:
Nicht so wichtig, aber kennst du den Unterschid zwischen einem Simulator und einem Emulator?

BlackKing:
Ja, der Unterschied ist mir bekannt, ich komme da aber gerne mal durch den Tüddel

Hallo zusammen!
So, nachdem die ersten Gehversuche recht erfolgreich waren, ist aber
noch Optimierungsbedarf da. Offene Punkte sind bei uns noch folgende,
vielleicht hat da ja jemand kreative Vorschläge:

1. Dimensionierung der OP-Schaltung: Bei 0% Helligkeit liegen am Ausgang
des OP 5V an (was unter anderem auch die einstellbare Spannungsreferenz
am ATMega8 sinnfrei werden läßt...), bei 100% Helligkeit liegen
je nach Farbe der Röhre zwischen 3,3V und 4V an (bei der Dimensionierung
von Hulk). Ich habe provisorisch mit den Widerständen, die ich so da hatte
die Schaltung noch mal umskaliert, so daß ich bei Rot jetzt auf etwa 2,4V
und bei grün und blau auf ca. 3,3V komme. Ne Skalierung, die z.B. bis auf
ca. 1V runter geht, wäre mir allerdings noch lieber.
Die Unterschiede zwischen den Farben werden derzeit in der Firmware
abgefangen.

2. Nichtlinearität der Helligkeit: Wenn ich den Aussteuerbereich linear in
5bit aufteile (also 31 Schritte + 0 für schwarz) ist die Helligkeitsveränderung
im unteren Bereich riesig, im oberen Bereich eher minimal. Eine Look-up-
Table, die das Problem beseitigen soll, ist in der Firmware schon drin,
konnte aber noch nicht getestet werden. Bloß wie bekomme ich jetzt ne
vernünftige Kennlinie hin, damit die einzelnen Schritte jeweils die gleiche
Helligkeitsveränderung bringen?

Parallel dazu geht natürlich die Erkennung der anzusteuernden Farbe
innerhalb des Plugins weiter, obwohl der Algorithmus schon ganz gut
zu sein scheint. Vorhin war ich zufällig mal im Media-Markt und habe
mir da noch mal das "Original" im Betrieb angeschaut. Kann es sein,
daß die default-Farbe bei Philips immer weiß ist und dann in die
entsprechende Farbe überblendet wird?

Hey Jungs!

Bin gerade durch zufall auf euer Projekt gestoßen, und erstmal nen großes Lob. Wirklich "Geil" das Ding was ihr da gemacht habt.

Nun noch ne kleine Frage; Glaubt ihr, dass es auch von einem Laien wie mir nachzubauen ist?

mfg, dany

Hallo,

Wenn mal alles so läuft, wie die Entwickler und die Tester sich das vorstellen, kann ich gerne Platinen und Bausätze anbieten.

Gruß
Papsi

Najo gut- ich mein die bisher vorliegenden Schaltpläne von Hulk versteh ich einigermaßen, hab in der Schule selber Elektro-, Digital- und ansätze von Microcontroller-Technik--
allerdings bin ich jetz erst mitm ersten Jahr fertig und kann demensprechend keinesfalls behaupten, dass ich jetzt "kein Laie" mehr bin

Platinen find ich gut.. !

najo.. gruss dany

Zitat

Original von daniel_k
2. Nichtlinearität der Helligkeit: Wenn ich den Aussteuerbereich linear in
5bit aufteile (also 31 Schritte + 0 für schwarz) ist die Helligkeitsveränderung
im unteren Bereich riesig, im oberen Bereich eher minimal. Eine Look-up-
Table, die das Problem beseitigen soll, ist in der Firmware schon drin,
konnte aber noch nicht getestet werden. Bloß wie bekomme ich jetzt ne
vernünftige Kennlinie hin, damit die einzelnen Schritte jeweils die gleiche
Helligkeitsveränderung bringen?

Alles anzeigen

Ich hatte mal vor langer Zeit vorgeschlagen, dass man das AmbiLight automatisch einmal einmessen sollte (Idee war:bestimmte Farbstufen auf dem Fernseher erzeugen und mittels CCT die gleiche Farbstufe nachbilden). Das Ganze war damals nur ne theoretische Überlegung. Man wäre damit auch Problemen bzgl. Wandfarbe, Wellenlänge der CCTs, etc. aus dem Weg gegangen. Aber egal, nu ist es bisschen spät um die Einmessschaltung mit auf die Platine zu bauen. Soweit ich mich erinnern kann war die Aussage des Entwicklers bei dem das Teil schon lief, dass das alles nicht notwendig ist.
Bin mal gespannt wie es weiter geht, ich bin immernoch daran interessiert so ein AmbiLight mit ein paar LEDs aufzubauen. Zum Entwickeln von ner eigenen Schaltung fehlt mir dann aber doch das KnowHow. Es gibt ja auch noch den Thread für das LED-AmbiLight, in dem gehts aber schon seit Längerem nicht weiter.
Gruß
Jarny