Hi! Ich habe mir überlegt man könnte sich ja ein Ambilight nachbasteln :-) Habe da im Internet schon verschiedene Lösungsansätze gesehen aber nichts wirklich ausgereiftes. Das was mich am meisten stört ist dass sich noch niemand gedanken drüber gemacht hat wie man das bild in verschiedene bereiche aufteilen könnte. Ich bin kein Spezialist in dem Bereich aber afaik kommt aus dem VGA ein analoges signal raus, und das für jede Farbe. Zeilenweise. Das heißt um an einen bestimmten Bildbereich zu kommen müsste man nun jede Zeile auf verschieden aufteilen. Das kann ja ein µC übernehmen, vorrausgesetzt der ist schnell genug dazu, weiß ja nich wie schnell VGA so arbeitet.. Man hat nun zum beispiel 4 bereiche und jedem Bereich ist eine nachliegende Schaltung zugeteilt. Das gibt für jeden Farbkanal also 4 Schaltungen. Um nun den Durchschnittswert eines Kanals in einem Bereich zu bekommen schaltet man hinter einen widerstand einen kondensator. Der Widerstand wird so gewählt dass wenn der ganze bereich weiß sei der Kondi sich beim durchlaufen des bereichs von oben nach unten voll aufläd. Am ende des Durchlaufs misst man dann nur noch die Spannung des Kondensators um herauszufinden wie hell der kanal durchschnittlich in diesem bereich angesteuert wurde. Danach wertet ein weiter µC eben die spannungen aus und erzeugt eine PWM für 12 LED-leisten die hinter dem Bildschirm kleben und das ambilight erzeugen :-) Was haltet ihr davon? Ist so ein Ansatz realistisch bzw einen Versuch wert? mfg PoWl
VGA...das soll für nen PC-Monitor werden, ja? Das is ja mal cool :-) So schnell kommen die Signale meines Wissens nach nicht, also mit einem AVR sollte das schaffbar sein. Ich würde die drei Farbwerte über nen ADC direkt in den AVR einlesen. Da ja immer 3 AD-Umwandlungen erforderlich sind könnte das mit dem AVR vielleicht auch knapp werden, aber man kann ja notfalls auch 3 externe ADCs nehmen. Und wenn du 8-bit Genauigkeit wählst (was voll ausreicht) hast du schöne Werte 0...255. Bei VGA gibts dann noch zwei Signale, die die aktuelle Position angeben - ok die müsste man auch digitalisieren, also schon sehr knapp. Ich würde den Bildbereich so unterteilen: ## ## ## 1 ## ## ## 4 ### 2 ## ## ## 3 ## ## ## Du kannst dann anhand der Position immer berechnen, zu welchem Bereich der Farbwert gehört, und alle Farbwerte eines Bereiches addieren und damit den Mittelwert berechnen. Und das würde ich dann direkt am PWM-Ausgang ausgeben. Weiß nicht ob es µC mit 12 PWM-Ausgängen gibt, ansonsten eben paar per Software emulieren. Ansonsten finde ich das realistisch, ja.
Wenn das für einen PC ist (VGA), dann wäre es erheblich einfacher und sinnvoller, einen DirectShow-Filter zu schreiben und der Ambilight-Hardware das Ergebnis zu übergeben. Die Hardware würde sich dann nur noch um die LEDs kümmern.
@Dietmar E: Stimmt auch wieder. Allerdings funktioniert das dann nur bei Filmen, nicht beim normalen Windows-Desktop. Das wäre ja (besonders wenn mans hinter dem Arbeits-Monitor anbringt) das Interessante.
VGA ist schon recht schnell - nehmen wir mal 1024x768 @ 80 Hz (overscan und ähnliche feinheiten vernachlässige ich jetzt hier bewusst!), was ja jetzt noch nichts weltbewegendes ist. Da werden dann also 768 Zeilen mit 1024 Spalten 80 Mal pro Sekunde angezeigt. Ergibt also eine Zeilenfrequenz (H-Sync) von 768*80=62880 Hz. Damit ist die Pixelfrequenz rund 64MHz. Wollte man jedes Pixel auswerten bräuchte es also einen entsprechend schnellen ADC. Die gängigen Mikrocontroller dürften da auch nichts mehr bringen. Da wir das Bild nun aber nicht anzeigen sondern nur in ein paar Bereichen auf seine Farbe hin analysiren wollen, teilen wir es nun horizontal in sagen wir mal 8 Bereiche auf. Die Mitte interessiert uns dabei weniger. Wir wollen nun aber auch gleich Nägel mit Köpfen haben und nehmen deshalb an, dass das Ding bis 1600x1200 @ 80 Hz laufen soll. as wären dann also 96kHz Zeilenfrequenz. Wegen der 8 Bereiche müssen wir dann auch 8 mal samplen (wir nehmen da jetzt mal ein schönes Tiefpassfilter vornedran und so weiter als gegeben und ideal an) Dann müssen wir also 768000 mal pro sekunde samplen - irgendwie immer noch erträglichm, wenn auch schon etwas schwerer mit einem avr. Daher jetzt mal mit richtig schöner analogtechnik: Sagen wir mal, 4x4 Felder reichen uns, dann könnte man folgendes machen: Mit dem HSync füttern wir eine PLL, die eine Phasensynchrone, 4 mal so hohe frequenz erzeugt. Mit dem VSync machen wir das gleiche. Zusätzlich nehmen wir das originale HSync, um damit zwei zähler zu resetten, immer wenn der Elektronenstrahl von oben neu startet. Wir haben nun mit den beiden Zählern ein insgesamt 4 bit breites adresswort. Das geben wir jetzt auf drei 16:1 Multiplexer, die wir mit den jeweils gepufferten RGB-Werten versorgen. Hintendran kommt dann ein RC-Tiefpass mit einer Grenzfrequenz von sagen wir mal 0,25-0,5 Hz. Wenn man den ganzen Kram jetzt am laufen hat, hat man die durchschnittliche Farbe in den 16 Feldern analog vorliegen. Jetzt kann man da z.B. die äußeren 12 nehmen und die Werte in diesen mittels AVR o.ä. messen. (wären dann 36 Analogwerte, also nochmal 3 16:1 Muxes). Der AVR hat dann nichts weiteres zu tun, als das ganze in eine hübsche PWM umzuformen. GGf. kann man das dann noch vereinfachen, indem man die 4 Randdbereiche gleich hinter dem Mux zusammenrührt. Dann hat man nur noch 12 Analogwerte zu messen. Vorteil der Analogvariante ist, dass man, sobald man die PLLs am laufen hat, praktisch beliebige Auflösungen fahren kann, solange die entstehenden Frequenzen noch im Syncrange der PLLs liegen. Die VSync PLL müsste folglich auf Eingangsfrequenzen von 50-100 Hz einrasten (entspricht Frequenzbereich 200-400 Hz, noch sehr gut machbar), die HSync PLL muss dann von 12-120 kHz einrasten können (=48-480 kHz) um einen Auflösungsbereich von 320x240@50Hz bis 1600x1200@100Hz nutzen zu können. All diese Angaben sind jetzt zunächst mal nur rein spekulativ und ohne berücksichtigung der Randbereiche, die ebenfalls im VGA Signal enthalten sind, sowie des Strahlrücklaufs, während dem irgendwie ein integrieren des Signals zu verhindern ist. Am besten nimmt man wohl den Syncrange eines CRTs als Vorlage. Die Frequenzen müsste eigentlich allesamt mit billigen PLL-Bausteinen (der 4046 wäre da evtl interessant) machbar sein. Die Theorie zu PLL sollte man sich vorher irgendwo mal nachgelesen haben.
> VGA ist schon recht schnell
Ach stimmt, ist ja jetzt VGA. Bin irgendwie von der TV-Auflösung
ausgegangen, weil ich mich vor kurzem damit beschäftigt hatte - und das
ist noch schaffbar. Ok stimmt.
Wenns natürlich für ein LCD Panel ist, dann reicht VSync von 50-60 Hz aus - supereasy. Und HSync wäre dann wohl bei 12-62kHz, was schon wesentlich angenehmer ist, da der Frequenzbereich kleiner ist, in dem die PLL funktionieren muss. Sollte wohl mit einer Portion Hühnerfutter nebst etwas CMOS Garnitur zu schaffen sein. Dürfte wohl noch auf eine Europlatte passen, wenn man geschickt routet. Muss mir mal die Signalformen vom VGA näheransehen - wäre mal ein lustiges Projekt für zwischendurch
so rund 6 CMOS ICs, etwas Krams mit OPs für die Signalaufbereitung, evtl 2 Flipflops mit etwas Gemüse garniert und der AVR dazu. Das sollte es sein. Denke mal, Kosten sollten unter 20 Euro zzgl. LEDs liegen.
Im Anhang mal ne Idee, wie man aus den Sync-Impulsen die Position (in 4/8/16/64 Feldern) ermitteln kann (muss man aber wohl erst noch genau testen), sollte allerdings vom Prinzip her klappen. Die 4046 PLLs gehen von 0Hz bis etwas über 1MHz. Das sollte wohl reichen. Die Position kann man dann aus den COunterwerten ablesen. Die Flipflops im Eingang sorgen für 50% Dutyfactor bei den Syncs, damit die PLLs schön einrasten können. Die Exors mit den Schmitt Triggern bereiten die Syncsignale auf und wandeln evtl. negative Sync-Polarität in positive um. Die Resets der Counter müsste man dann noch an den aufbereiteten H-Sync (pre flip-flop) anhängen, damit die Zähler immer mit 0 beginnen, wenn ein neuer frame kommt. Das ganze passt übrigens bis jetzt auf eine einseitige Leiterplatte (derzeit 100x80). Mit den 15pol-HD Steckern wirds dann amber etwas eng mit einseitig, wenn man das Signal durchleiten will. Hier muss also evtl. eine Kabelpeitsche gelötet werden. MfG Andreas
Die Frage ist nur, sieht das dann auch nach was aus? Wenn in einem der ausgewerteten Felder z. B. ein irgendwie geartetes Pixelgemisch ist, dann sieht die langsame Auswerteschaltung dort graue Soße. Das Auge sieht sort aber unter Umständen Strukturen (das Pixelgemisch) und dominate Farbflächen. Eine intelligente Signal-Aufbereitung könnte mit wenig Rechenaufwand solche dominanten Flächen erkenne, müssste das Signal aber Pixel für Pixel (oder jedenfalls mit höherer Auflösung als nur 8 Abtastungen pro Zeile) auswerten. Es wäre vielleicht doch hilfreich zu wissen, wie und mit welcher Abtastrate die Auswertung denn bei der kommerziellen Lösung erfolgt. Frage: weiß das jemand, oder hat schon mal jemand in die Patente geschaut?
ihr habt noch garnix zu meiner kondensatormethode gesagt :-D
Das kommerzielle Ambilight von Philips dürfte auf digitaler Signalverarbeitung basieren, da ein LCD/Plasmagerät sowieso alles digitalisieren muss. Ein VGA Signal direkt zu digitalisieren halte ich allerdings für einen Overkill. Das originale Ambilight analysiert afaik nur den linken, den rechten und den oberen rand. Wenn man sich jetzt etwas mehr arbeit machen will, kann man ja hergehen und den Bildbereich in z.B. 8x8=64 Flächen unterteilen. Damit man jetzt hier nicht 64 Tiefpaääse nebst der zugehörigen Analogschalter braucht, nimmt man einen 1:16 Mux un einen schnellen ADC (12kSamples min.), so dass man immer während die nächste Zeile aus 8Blöcken gemittelt wird, die letzte auslesen kann. man kann sich ja dan auch schön die randbereiche raussuchen. Das Signal komplett zu digitalisieren halte ich allerdings für mit "Hausmitteln" (also ohne DSP oder richtig schnellen µC, sowie die passenden ADCs für nur sehr bedingt durchführbar (ich sag jetzt nicht, dass das nicht geht, aber die knapp 3 mal 80 Megapixel die bei 1280x1024@60Hz RGB pro Sekunde übers Kabel kommen direkt zu messen wird echt haarig)). Wenn man denn wirklich mit 8x8 Feldern arbeitet, dann hat man schon ganz gute chancen, unterschiedliche Farbflächen zu erkennen. Wenn es halt keine dominante Farbe gibt, dann ists halt nur Hintergrundlicht mit angepasster Helligkeit. Und wer sagt eigentlich was von langsam? Bei 60 Hertz Bildfrequenz müssen die Tiefpässe schon recht schnell sein. Wenn man jetzt auch noch mehrere Ledmodule links, rechts un oben verwendet (z.B. jeweils 4), dann wirds schon ziemlich cool und geht über das normale Ambilight sogar noch hinaus. Ich werde die PLL/Kondensatorvariante wohl mal bauen (vermutlich aber erst mal nur 4x4), da die Kosten für die ICs (abgesehen von LED-Treibern, AVR und soweiter, die sowieso vorhanden sind) wohl kleiner als 10 Euro sein werden und es somit nicht zu tragisch ist, wenn es dann doch nicht so cool war. Wenn man die ICs sockelt, hat man beim Scheitern des Projekts nur ein paas Rs und Cs verschwendet. Das ist grad noch zu verschmerzen. MfG Andreas
Wenn man einen Tiefpass nimmt, dann sieht's wirklich bäh aus. Wenn man stat dessen integriert, kommt schon was schöneres bei raus. GGf müsste man dann wohl noch in Software die Sättigung etwas verstärken.
Wenn man dann noch mehrere LED-Module pro Rand nimmt, sollte das System dem Original durchaus etwas entgegenzusetzen haben.
@ Andreas, ich scheine eine Lawine in dir in Gang gesetzt zu haben, wäre schön wenn du sowas sogar umsetzt :-) Dennoch würde ich gerne noch wissen was ihr von meiner superanalogen Kondensatormethode haltet? Die wäre noch einfacher als die Geschichte mit deinen Digitalbausteinchen :-) mfg PoWl
Das muss ja nicht mit 60-100Hz laufen sondern würde auch mit 1/5 davon oder weniger reichen. d.h. der µC oder was auch immer könnte immer abwechselnd die signale sammeln, dann auswerten und danach "ausgeben". also massig freie zeit
Zumindest eine PLL wäre eigentlich schon nötig, um den Bildbereich aufzuteilen. Damit muss das Programm dann auch keine exakten timings mehr einhalten. Nur Kondensator habe ich auch mal simuliert, allerdings sind die Pixel dann halt nicht gleichgewichtet, so dass man wohl um einen OP als Integrierer nicht rumkommt.
Zumindest eine PLL wäre eigentlich schon nötig, um den Bildbereich aufzuteilen. Damit muss das Programm dann auch keine exakten timings mehr einhalten. Nur Kondensator habe ich auch mal simuliert, allerdings sind die Pixel dann halt nicht gleichgewichtet, so dass man wohl um einen OP als Integrierer nicht rumkommt. Man kommt übrigens mit einem Integrator pro Farbkanal aus, es werden nur die Kondensatoren umgeschaltet. Hat den Vorteil, dass man nicht 3x16 Integratoren aus je OP, Widerstand und Kondensator braucht, sondern "nur" 48 Kondensatoren, 3 OPs und 3 Rs. Um den Integrierer in einen definierten Zustand zu bingen, kann man den C nach dem Samplen dann auch einfach per AVR-Portpin entladen.
> Wenn man dann noch mehrere LED-Module pro Rand nimmt, sollte das System > dem Original durchaus etwas entgegenzusetzen haben. Auf die Idee kam Philips mit "Ambilight Full Surround" auch schon :-) http://www.computerbase.de/news/consumer_electronics/beamer_fernseher/2006/september/ifa_philips_flat-tv_100_zoll/ Wies aussieht sind das oben und unten je 4, und an den Seiten je 2 LED-Module, wobei die Farben dort nicht wirklich wie der Durchschnitt von denen aus dem Bild aussehen. Oben rechts: woher kommt das Orange und Grün? Irgendwie scheint da noch mehr miteinbezogen zu werden - z.B. die Frau dort.
Hmm, im gegensatz zum Ursprünglichen Ambilight scheint hier ganz ordentlich Bildverarbeitung dahinter zu stecken. Ganz so doll wird homebrew dann wohl nicht, aber man kann ja mal sehen, was man mit einem AVR draus machen kann...
Hi, schaut mal bei vdr-portal.de vorbei und sucht dort mal nach "atmolight". Ich hoffe man kann das hier lesen. Hab mit PIE geschrieben. Gruss
diese neue philipslösung sieht meines erachtens nach auch nich grad so toll aus. dann hätten sie schon mal die ganze leiste durchgehend fein aufgelöst mit LEDs bestücken können. Ist ja kein problem für die. Ich find es besser wenn man für jede seite ein Modul hat. Oder wie wärs für jede Ecke? Also für jeweils 2 halbe Seiten in der Ecke? Wäre vielleicht sogar sinnvoller was Filme betrifft. Naja die Ideale Lösung wird man nicht finden :-) mfg PoWl
Ich werde wohl doch die Variante mit 64 Feldern versuchen. Gegenüber der 16er ist nämlich praktisch nur die Software aufwändiger. Die Elektronik is fast gleich. Allerdings muss man irgendwie einbauen, dass man die Integratoren in bezug auf ihren skalierungsfaktor programmieren kann (ist zumindest mal wegen der verschiedenen Wiederholraten nötig). Soweit ich mich jetzt nicht irre, müsste die gesamtzeit, in der ein Segment während eines Frames adressiert wird ja bei gleicher wiederholrate unabhängig von der auflösung sein. Das macht die Sache deutlich leichter. Man braucht dann nämlich nur ein paar Presets berechnen und kann die dann mittels Mux umschalten (jaja, ich weiß ja, dass das ein CMOS Massengrab wird). Den rest kann man dann auch noch per Software kompensieren, indem man ggf. die gesamthelligkeit eines Frames irgendwie mittelt oder den Peak ermittelt, wodurch das Umgebungslicht dann bei dunklen Szenen auch schön dunkel ist. Bei der Werbung von Philips hab ich irgendwie immer das Gefühl, dass das Licht auch bei dunklen Szenen immer noch recht hell ist. Kann mich da jetzt aber auch gewaltig irren, da ich keinen Plasma von Philips, sondern gar keinen Fernseher hab. Daher ja auch mein Interesse an der VGA Version. Fernsehtauglich sollte man das aber doch bekommen können, wenn man das Composite FBAS mit einem PAL-Dekoder in RGB+Sync umwandelt. Man muss dann nur die Sync separieren und gut ist der Kuchen. Dank der PLLs stellt sich die Schaltung dann innerhalb kurzer Zeit auf das PAL-Bild ein. Das mit dem interlaced sollte eigentlich egal sein, weil ja eh große Mengen Pixel zusammengefasst werden. Was da auf jeden Fall auch eine Zeit brauchen wird, ist das Berechnen Sinnvoller Zeitkonstanten und anderer Bauteilparameter. Ich hätte jetzt halt gerne, dass wenn z.B. im Film eine Nachtszene gezeigt wird und irgendwas explodiert, dass das Licht dann auch schnell reagiert, andererseits sollte es nicht zu nerös rumzappeln. Da ich aber sowieso Blockweise arbeiten werde muss der ganze Kram ja dann ohnehin in Software passieren. Das wird wohl doch aufwändiger als gedacht, aber ich denke mal, dass für die Steuerelektronik immer noch sehr moderate Bauteilokosten rauskommen. Würde mal sagen, ohne AVR und LEDs und Co. sollte es nicht wirklich mehr als 10€ werden. Logikgatter sind billig und der Rest auch. Jedenfalls wird das mehr als eine halbe Eurokarte ausfüllen. Hoffe jetzt nur, dass die Platine einseitig bleiben kann. Wäre dann echt cool als Selbstbaulösung, da halbwegs einfach aufzubauen und auch nicht teuer. MfG Andreas
Hier mal ein Schnappschuss vom noch nicht fertigen Board. Das links sind die beiden PLLs, rechts sind zwei von drei benötigten umschaltbaren Kondensatorbänken. Durch den jeweils zweiten 4067 kann man mit nur drei ADC-Ports alle Spannungswerte auslesen. Über das DDRx des AVR kann man dan auch gleich noch den Kondensator entladen, wenn man fertig gemessen hat. Die Kondensatoren werden wohl sowas um die 100nF sein. Könnte sogar wirklich einseitig klappen. Allerdings werden's wohl zwei Platinen, da ich zumindest mal die LED-Endstufen nicht mehr da drauf bekomm, wenn ich kleiner gleich 160x100 mm bleiben will, aber es gibt ja auch noch größere Standardmaße, die man noch mit ner A4 Folie belichten kann. Mal sehen, was draus wird.
gibt es was neues bei dir Andreas? Ich würde es gerne für den TV bauen, aber ich habe auch so eine TV->VGA BOX hier rumlieren die ich eh nicht benutze. Damit wäre ich mit deiner Methode sogar variabel und könnte es sowohl für PC als auch TV benutzen. Dein Fachliches Wissen scheint mir auf dem Gebiet enorm zu sein, da kann ich nicht viel beisteuern. Ich fänd (um einfacher zu bleiben) die 4x4 Methode sehr Interessant, würde aber mehr Lichtquellen verwenden als oben,unten,links,rechts. Und zwar würde ich zusätzliche LEDs für die Ecken einsetzen und für links/rechts und oben/unten jeweils die Mittleren Felder zusammenfassen. Ich hab mal versuch das in einem Bild zu verdeutlichen. Wenn du sagst mit FBAS bzw. RGB ist es "einfach", dann könntest du auch einfach den TV Ausgang, den viele Grafikkarten haben nehmen, oder so nen billigen VGA->TV Adapter an den zweiten Ausgang hängen. Die Qualität ist ja ziemlich wurscht. Damit hättest du dann ausserdem die Lösung für TV gleich mitgeliefert. Ich hoffe du arbeitest weiter an diesem Projekt und wirst bald Schaltpläne veröffentlichen :P.
Hallo andi84, bist Du mit deinem Projekt schon weitergekommen? Ich suche nach sowas für Veranstaltungen mit DMX Ausgabe Skalierbar bis von 1 bis auf max 16 Scheinwerfer. Mir fehlen aber die Grundlagen im Bezug auf Signalverarbeitung, wie bekommen ich das RGB Signal in den Controller DMX ist kein Thema RGB LED Scheinwerfer pro Seite.
hmm, bin noch dabei, aber habe leider weniger zeit als ich dachte. Läuft halt alles nach dem schema "rechnen, kaufen, löten, fluchen, erröten - und dann wieder von vorn...", wobei ich irgendwo beim Rechnen stehen geblieben bin. Falls ich demnächst mal etwas zeit finde versuche ich mich mal an den PLLs, dann ist schon recht viel getan. Wenn jemand in dem Thema drinsteckt, kann er ggf. ja auch den kram weiter oben als denkanstoß nutzen. Die Kondensator und Widerstandswerte für die PLLs kann ich mal berechnen. Hab halt nur grad meinen Bastelkram nicht greifbar. MfG Andreas
Hallo, im Rahmen eines Projektes an der Uni sind wir dabei, genau das zu entwickeln. Wir sind "kurz vor fertig" und werden in den nächsten Tagen testen und optimieren. Unser Ansatz: Der Bildschirm wird in seine vier Quadranten aufgeteilt. Es gibt einen Integrator und vier Sample&Hold-Glieder (pro Farbe, also x3). Es wird immer über einen Quadranten integriert, dann gesampelt, entladen und dann der nächste Quadrant beim nächsten Bild... Nach fünf Bildern hat man die Daten für alle Quadranten (ein Bild wird zwecks Kondensatorentladung zwischen 4. und 1. Quadrant ausgelassen). Integrator an/aus, Addressierung der S&H-Glieder, Resetten der Integratoren und Auswerten der H- und VSycns übernimmt ein ATmega16 mit min. 16MHz. PWM der Dioden haben wir hingegen analog mit Dreieckgenerator und Comperator gelöst. Ferner übernimmt der uC die Aufgabe, die Gesamthelligkeit der LEDs zu regeln, da die Integrierzeit von der Bildwiederholfrequenz abhängig ist. Im obigen Bild sieht man (nach einer 20-stündigen Programmiersession das noch nicht optimierte) Integratorsteuersignal. Man erkennt, daß der rechte untere Quadrant integriert wird. Grün: Vsync, Gelb: HSync und Blau Integratorsteuersignal (High: Integrieren). Obigen Ansatz mit der Frequenzverdoppelung per PLL hatten wir auch im Auge, nur muß man aufpassen, da die unsymmetrischen Synchronisationssignale je nach Auflösung negiert werden (high-low). Unsere Projektseite: http://ele12.wikidot.com/
Falls es interessiert: Wir sind fertig. Es folgen nur noch kosmetische Korrekturen. Wir mußten uns zwar noch ganz schön quälen, einige Probleme konnten wir per Software patchen an anderen Stellen mußten wir nochmal zum Lötkolben greifen, aber das Ergebnis kann sich sehen lassen... Grüße von Andreas
Hey Andreas, super geniales Projekt! Ist noch ein Scarteingang angedacht? Bzw. wir der Quellcode oder HEX-File veröffentlicht zum nachbau? Gruß aus Dortmund Patrick
Ist es möglich eine Bauanleitung von diesem Projekt zu bekommen? Ich suche schon ewig nach sowas und euer Ergebnis finde ich echt super! Respekt!!! Gruß Siggi!
Hallo, http://www.vdr-wiki.de/wiki/index.php/Atmo-plugin lässt sich auch über Windows ansteuern... Gruß Papsi
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.