Atmolight - Release 0.0.1

Zitat

"kytätä (ms)", // Is that correct?
"kohden killinki veres kaunistella",// Is that correct?

Oh! I love those finnish entries! The first one means kind of lurking, but the second one is really my favourite: beautify every coin with blood. Gotta have them all!

Zitat

Stark verallgemeinert für das Projekt, der Atmega 8 hat mehr Flash (8k), aber nur drei PWM Generatoren,
der Atmega 48 hat weniger Flash(4k), aber sechs PWM Generatoren ....

Ich habe ehe nur eine Monoversion in der Pipeline, deshalb ist es für mich erstmal wurst,
eher interessant ist, ob der Flash für die Firmware reicht.

Derzeit braucht meine Firmware 1526 bytes (18,6%) Program Space und 214 bytes (20,9%) Data Space auf dem bereits erwähnten Mega8.
Da da aber noch ein paar debug-Geschichten drin sind, denke ich, man sollte mit 4k Flash auch hinkommen.

Gruß,
Daniel

Hiho @ all

Zitat

Original von rofafor

Oh! I love those finnish entries! The first one means kind of lurking, but the second one is really my favourite: beautify every coin with blood. Gotta have them all!

Hehe, as i said, many of my translations sounds very funny... If you have the right translation, and tell us, we are very happy.

Original von Samael

Zitat

Crue: Danke für die Internationalisierung, aber das sind bei Weitem
nicht alle Texte, die übersetzt werden müssen.

Hmm, wo hatt sich denn der Rest versteckt ?(... ich hab noch Langeweile...

MfG

Crue

Hallo,

wie schon mal geschrieben:

Ich würde die Layouts für die Platinen erstellen, wenn einer einen passenden Schaltplan(Eagle) für die 6 Kanalversion hat.

Dann würde ich mir mal ein Angebot machen lassen, was die Platinen kosten würden, wenn wir die von einer Firma herstellen lassen.

Ich würde dann auch die Bauteile passend bestellen und Bausätze oder Fertiggeräte anbieten.
inkl. vorprogrammiertem Controllercip

Habe momentan aber leider nicht die Zeit die Schaltung selber zu testen.

Gruß
Papsi

Hallo,
ich hätte Atmolight auch gerne für mein neues 40"-Display (wenn es dann mal da ist :)).
Ich habe allerdings eine Client-Server VDR Architektur, heißt: ich streame über streamdev zu einem VDR Client mit DXR3-Karte (oder später vielleicht xine-Plugin).
Kann ich das Atmo-Plugin dann auch verwenden? Was ich aus dem Source-Code gesehen habe, verwendet es ja /dev/video0 um das aktuelle Bild einzulesen. Ich bräuchte also Zugang zu einem Framebuffer, aus dem ich das Bild auslesen kann, oder?
Gruß,
Matthias

Hiho

Zitat

Ich habe allerdings eine Client-Server VDR Architektur

Zitat

Kann ich das Atmo-Plugin dann auch verwenden?

...als Anregung...

CommandLineOptions :

// Return a string that describes all known command line options.
  return "  -n IP/PORT, --net=IP:PORT  send atmolight-data over network (e.g. 192.168.0.1:1234)\n"
         "  -s DEV,     --serial=DEV   send atmolight-data to serial device (e.g. /dev/ttyS1)\n";

MfG

Crue

HI,

was ist denn eigentlich aus der Igor USB Variante geworden?
Sollte man nicht vielleicht mit einer industriellen Platine warten, bis USB und 6 Kanal vollständig implementiert ist?

Ich denke bei einer Industriellen Platine lohnt es sich auch auf soviel wie möglich SMD umzusteigen, da das billiger wird. Oder liege ich da jetzt falsch?

Cu Trucki

Zitat

Was ich aus dem Source-Code gesehen habe, verwendet es ja /dev/video0 um das aktuelle Bild einzulesen. Ich bräuchte also Zugang zu einem Framebuffer, aus dem ich das Bild auslesen kann, oder?

Richtig, da ich sonst auf die Schnelle nicht wüßte, wie ich bei dem anderen VDR-Architekturen an die Bilddaten kommen sollte...
Aber falls da jemand kreative Vorschläge hat: Immer her damit.

Zitat

was ist denn eigentlich aus der Igor USB Variante geworden?

Da ich leider keine Ahnung von USB auf dem Atmel habe, müßte da jemand anderes ran.
Allerdings gibts für Leute ohne RS232 ja auch die Möglichkeit eines USB<->RS232-Wandlers
(den ich persönlich übrigens auch einsetze).

Gruß,
Daniel

Hi daniel_k,

ich hatte ja zwischenzeitlich auch schon an meiner FW ("atmega48") gebastelt und moechte mich nun wieder mit eurer Loesung synchronisieren, deshalb meine Bitte:

Wie sieht das Telegramm vom VDR zum Controller und umgekehrt aus?

Das 1.Byte ist das Startbyte 0x80. Den RAW Modes aktiviere ich mit Bit0, den Datenrequest mit Bit1. Richtig?

Wieviel Bit verwendet ihr beim Farbwert (8/10Bit)?

Ich Frage deshalb, weil ich nicht mit meinem VDR und dem Plugin arbeiten kann (da krieg' ich Stress mit der besseren Haelfte und mir zunaechst mal einen "Simulator" schreibe.

Ich hab' ja eine 6 Kanal Version ("atmega48") und werde die FW bzw. das Plugin entsprechend anpassen. Ins Telegramm werde ich nochmal 3 zusaetzliche Bytes fuer die 3 Farben des anderen Kanals einbauen. Beim Plugin habe ich vor, die Auswahl mono bzw. stereo ueber einen Commandline-Switch zu steuern.

Ansonsten: Klasse gemacht!

Hallo ke2705!
Den genauen Aufbau der Telegramme schicke ich Dir heute abend mal,
das liegt im Moment leider alles zu Hause. Aber vielleicht schon mal kurz ein
Abriss: Im Startbyte muß immer das höchste Bit (0x80) gesetzt sein,
damit es sich als Startbyte erkennen läßt (in den Datenbytes natürlich
dann auf 0). Damit kann ich sicherstellen, daß sich die Firmware auch
noch einer Unterbrechung des Transfers wieder aufsynchronisieren kann.
Weiterhin ist im Startbyte der Modus versteckt (ungeregelt/geregelt)
und ob die Firmware Meßwerte ans Plugin zurückschicken soll. Und die
3 MSB der Datenbytes stecken auch noch drin, damit ich sie in den
Datenbytes auf 0 setzen kann (wg. Startbyte, s.o.).
Wenn der RAW-Modus aktiv ist, wird in den Datenbytes einfach 0-255 pro
Farbe übertragen (mit dem MSB im Startbyte). Im geregelten Modus
wird der Index für die Lookup-Table der Farbe geschickt (0-31). Mit
Hilfe der Lookup-Table bläßt die Firmware die übertragenen 5 Bit (0-31)
dann wieder auf 10 Bit (0-1023) als AD-Sollwert auf, die dann durch die
Regelung "anzufahren" sind.
Ansonsten schicke ich Dir heute abend mal die genaue Beschreibung.

Gruß,
Daniel

Hi Daniel,

OK, ich glaub' ich hab's kapiert

Thanx

Eberhard

Hallo zusammen.
Anbei die angekündigte Beschreibung des Datentransfers vom Plugin
zur Firmware und zurück. Nicht wundern, wenn das nicht 100%ig zu den
sourcen der Version 0.0.1 paßt, da sind auch schon ein paar neue Ideen
drin, die dann in die 0.0.2 rein sollen...

Gruß,
Daniel

Hallo daniel_k,

auf der ersten Seite ist mir aufgefallen, dass Ihr für die Darstellung von
schwarz einen anderen Weg geht als Abstract.

Zitat

Original von daniel_k
...
[*]Darkness Limit: alles unter dieser Schwelle wird als schwarz dargestellt (Atmo aus)

Zu der Darstellung von schwarz schrieb Abstract im "alten" Thread:

Zitat

Original von abstract
...
1.) grundhelligkeit
wenn der bildinhalt schwarz oder sehr dunkel es, sollte eine gewisse grundhelligkeit bestehen - farbe natürlich weiss.
ich hab das als sehr angenehm empfunden und ausserdem erhöht es das kontrastempfinden da ja die wand hinterm fernseher etwas beleuchtet ist und das schwarz des tv dadurch besser wirkt!

Könntet Ihr mal bitte testen was besser wirkt?

Gruß Kail

Hallo Kail,
über die Darstellung von dunklen Farben haben Samael und ich auch
lange diskutiert und rumprobiert. Das Problem mit den Röhren ist
allerdings, daß man ein "dunkles" weiß nur sehr schwer hinbekommt,
da sich die Röhren im unteren Ansteuerungsbereich kaum regeln lassen.
Um die Röhre voll zu zünden und damit eine gleichmäßige Ausleuchtung
hinzubekommen, muß man die PWM schon relativ weit aufregeln. Nur
dann hat man aber auch schon eine Helligkeit, die ich kaum noch als
"Grundhelligkeit" bezeichnen würde.
Außerdem habe ich mit dem Wechsel nach weiß so ein Problem, vielleicht
mal an folgendem Beispiel dargestellt: Du hast eine Nachtszene, relativ
dunkel, mit dunkelblauem Himmel. Das Plugin "erwürfelt" daraufhin blau
als Hauptfarbe und stellt sie dar. Wenn nun die Szene noch dunkler wird,
habe ich ein Problem damit, daß dann auf einmal die Farbe nach weiß
wechselt (und damit eher als heller empfunden wird).
Ich hoffe, man versteht so einigermaßen, was ich meine

Gruß,
Daniel

Zitat

Anbei die angekündigte Beschreibung des Datentransfers vom Plugin
zur Firmware und zurück. Nicht wundern, wenn das nicht 100%ig zu den
sourcen der Version 0.0.1 paßt, da sind auch schon ein paar neue Ideen
drin, die dann in die 0.0.2 rein sollen...l

Ich werd' beklopt

Da wollte ich grad' den Vorschlag machen, eines der bis jetzt ungenutzten Bits im Startbyte zur Unterscheidung bei links und rechts zu benutzen (das Telegramm hatte ich zwischenzeitlich dank Daniels Hilfe endschluesselt) - da seh' ich diesen Post und siehe da: ist schon so vorgesehen

Jungs, ihr seit Spitze!!!

Gruss

Eberhard

Zitat

Da wollte ich grad' den Vorschlag machen, eines der bis jetzt ungenutzten Bits im Startbyte zur Unterscheidung bei links und rechts zu benutzen (das Telegramm hatte ich zwischenzeitlich dank Daniels Hilfe endschluesselt) - da seh' ich diesen Post und siehe da: ist schon so vorgesehen

Jupp, vorgesehen schon, nur noch nicht implementiert...
Also Eberhard, los gehts!

Gruß,
Daniel

P.S. Wie Du vielleicht auch gesehen hast, haben wir die Modus-Umschaltung
auch noch ein bischen erweitert. Dazu vielleicht auch noch mal kurz ein Paar
Worte:

Im Moment besteht in großes Manko der Firmware darin, daß man pro
Schaltung die Röhren vermessen muß (Toleranzen des OP/Widerstände,
Unterschiede in den Röhren und der Montage der Fotodioden, etc.), um
daraus zu Fuß die Lookup-Tables zu errechnen und in die Firmware zu
kodieren. Daher habe wir uns gedacht, wir gestallten einfach das Plugin
noch etwas intelligenter. Das Plugin steuert im (noch zu mplementierenden)
HW-Kalibrierungsmodus einfach die Röhren ungeregelt auf volle Helligkeit
(PWM=255) und wartet so ca. 1 Minute. Die dann von der Firmware
gemessenen Helligkeiten werden einfach ans Plugin zurückgesendet, und
das berechnet dann wie folgt die Einträge für die Lookuptable:
[list=1]
[*]als dunkelsten Wert immer 0 (um schwarz ansteuern zu können)
[*]als nächsten Wert ca. 5-10 (da haben die Röhren dann voll gezündet)
[*]30 Werte linear bis zum gerade gemessenen Maximum
[/list=1]
Die so pro Farbe ermittelten 32 Werte werden dann per "download"
einfach an die Firmware gesendet. Ob man die Werte dann noch im
EEPROM ablegt oder einfach jedes Mal beim Start vom Plugin aus
sendet, ist ne Geschmacksfrage. Bin ja eher fürs Plugin, dann hat
Samael mehr zu tun und ich weniger

Zitat

Also Eberhard, los gehts!

Eieiei, ich komm' ja be eurem Tempo gar nicht mehr mit! Und schliesslich gibt's nicht nur Atmolight

Hab's jetzt eure FW im atmega48 am Laufen und will's nun auf Stereo aufbohren. Nur ich will die Schnittstellenkompatibilitaet zu eurer Loesung erhalten und wollte deshalb den Vorschlag mit den Reservebits im Startbyte ja auch machen - aber ihr hattet es ja schon vorgesehen (Gedankenuebertragung?)

Bei meiner urspruenglichen FW hatte ich eine LUT im EEPROM - ist Geschmacksache - wenn's aber schon da ist

Auch meine LUT war im Prinzip genauso angelegt wie's ihr macht:

- Pro Farbe einen 0-Wert (man will die Dinger schliesslich auch mal ausmachen); - der 2. Wert war eine gerade sauber durchgehend leuchtende Roehre
- der Rest der LUT war linear verteilt bis zum Maximum.

Eine Feinjustierung pro Stufe auf ein gefuehlsmaessiges weiss hatte ich auch noch eingebaut.

Und ich denke auch, damit kann man leben.

Was mir zum Beispiel viel wichtiger waere: Schnelle Aenderungen des Helligkeits bzw Farbinhaltes des Bildes sollen "smooth" vom Ambilight dargestellt werden - ich (und besonders meine bessere Haelfte) wollen keine hektische Lichtorgel hinter dem Fernseher. Das heisst: Grosse Differenzen aus altem und neuen Sollwert werden verzoegert ausgesteuert.

Ich spiel auch mit dem Gedanken, wenn die LUT mal eingemessen ist, die Ist-/Sollwert Regelung zu deaktivieren - ich hab' da naemlich sporadisch das Problem, das der AD-Wandler eine Hausnummer liefert. Wenn dann die Regelung greift...

Kennt ihr dieses Problem nicht? Dann koennte es evtl. an der bei mir fehlenden Drossel in der Stromversorgung des atmega liegen. Evtl. kommt was ueber die Strimversorgung rein

So, nur mal noch etwas Brainstorming

Gruss

Eberhard

Zitat

Was mir zum Beispiel viel wichtiger waere: Schnelle Aenderungen des Helligkeits bzw Farbinhaltes des Bildes sollen "smooth" vom Ambilight dargestellt werden - ich (und besonders meine bessere Haelfte) wollen keine hektische Lichtorgel hinter dem Fernseher. Das heisst: Grosse Differenzen aus altem und neuen Sollwert werden verzoegert ausgesteuert.

Das kommt mir irgendwie bekannt vor, deshalb habe ich Samael dazu gezwungen, den parametrierbaren Filter miteinzubauen

Zitat

Ich spiel auch mit dem Gedanken, wenn die LUT mal eingemessen ist, die Ist-/Sollwert Regelung zu deaktivieren - ich hab' da naemlich sporadisch das Problem, das der AD-Wandler eine Hausnummer liefert. Wenn dann die Regelung greift...

Das habe ich noch nicht so ganz verstanden: Bei mir ist es so, daß es keine Beziehung zwischen Pulsbreite der PWM und Helligkeit gibt, das übernimmt komplett die Regelung. Das Plugin "kommandiert" also praktisch nur die gewünschten Helligkeitsstufen der einzelnen Farben.

Zitat

Kennt ihr dieses Problem nicht? Dann koennte es evtl. an der bei mir fehlenden Drossel in der Stromversorgung des atmega liegen. Evtl. kommt was ueber die Strimversorgung rein

Hmm, nein, also soetwas haben wir eher nicht beobachtet. Allerdings haben wir auch verdrillte Leitungen zu den Fotosensoren verwendet und die Spule für die Analogspannung mit drin, vielleicht bringt das ja wirklich was.

Gruß,
Daniel