DIY Ambilight howto?

[vennox]

zijn er toevallig nog geen plannen om ambilight software te porten naar osx?

[Kr3Kr]

RafkeP schreef op zaterdag 22 december 2007 @ 14:17:
Ik vermoed dat er slechts 2 protocollen "standaard" zijn : atmolight en bob/momolight.

Dat laatste zit als volgt in mekaar 9 bytes aan 9600bps in volgorde : R1R2R3G1G2G3B1B2B3.
Ik heb hier al gelezen dat dit niet het meest robuuste protocol is, maar met mijn beperkte elektronicakennis wist ik niet beter.

Als je graag een ander protocol gebruikt, dan wil ik gerust een andere build maken van de MoMoLight filter.

Dat zou mij erg goed uitkomen voor het gebruik van Benadski's bordje van deze inkoopactie. Misschien is het handiger als e.e.a. in te stellen is in het filter, als dat niet te veel programmeren is? Sowieso zou het wel handig zijn als de COM-poortinstellingen in te stellen zijn.
Overigens wordt bij Media Player Classic de filter niet ingeladen nadat ik hem geregisteerd en geactiveerd heb. Ideeen?

vennox schreef op zaterdag 05 januari 2008 @ 17:03:
zijn er toevallig nog geen plannen om ambilight software te porten naar osx?

Ook daar zou ik interesse in hebben.

[ Voor 16% gewijzigd door Kr3Kr op 10-01-2008 14:45 ]

[RafkeP]

Kr3Kr schreef op donderdag 10 januari 2008 @ 14:40:
[...]Sowieso zou het wel handig zijn als de COM-poortinstellingen in te stellen zijn.[...]

Dat kan je instellen in het properties window van de filter.
In BSPlayer en Zoomplayer kan je dat window openenen wanneer een film gestart is.
Met graphedit kan je er ook aan en ik neem aan dat er nog wel een hele reeks tools zijn die toegang geven tot DS filters.

[...]Overigens wordt bij Media Player Classic de filter niet ingeladen nadat ik hem geregisteerd en geactiveerd heb. Ideeen?[...]

Bijna juist : hij wordt wel ingeladen (dit zie je aan de verlichting die helemaal blauw kleurt), maar de data van de fim wordt niet verwerkt. Ik heb nog geen tijd gehad om dit verder uit te zoeken, maar ik vermoed dat dit komt omdat MPC een niet gesupporteerde colour space gebruikt.

[peakaboo]

Hallo allemaal, ik heb een vraagje: Ik wil graag een soort van ambilight achterop mijn HP W2408 LCD monitor plakken, hangen, bouwen. Maar: Het hoeft niet te veranderen van kleur en ik wil niet gaan solderen enzo, want dat kan ik niet! Kortom, ik wil gewoon een beetje sfeer verlichting achterop de monitor krijgen zodat het beeld in het donker niet zo fel is. Het liefst 1 of 2 buizen van 30 cm ofzo die ik dan achterop de monitor plak met zelf klevende vierkantjes (net als van die blue cathode 30cm, maar die zijn molex enz.) Ik zoek er dus eigenlijk 1 die je via usb kan aansluiten, omdat ik 4 USB ingangen heb op mijn monitor, kan ik dat mooi wegwerken.

Zijn deze dingen er? Of moet het anders... Ik kan ook zo'n Philips living colours lamp kopen maarja goeiemoggel die zijn alweer 100eu bij coolsound bijv. Vind ik toch een duur grapje... Eigenlijk kan het heel simpel door zo'n led buis te kopen maar dan zit je met de aansluiting...

Kan iemand mij helpen of heeft iemand een idee? Je mag ook direcht mailen naar mijn adres, staat in de tweaker gallery pagina.

[Verwijderd]

Meeste ccfl's zijn allemaal 12v, de ledstrips die gebruik worden ook. In jouw geval zou ik toch gaan voor de livings colors lamp, of natuurlijk gewoon leren solderen.

[peakaboo]

Verwijderd schreef op dinsdag 15 januari 2008 @ 15:03:
Meeste ccfl's zijn allemaal 12v, de ledstrips die gebruik worden ook. In jouw geval zou ik toch gaan voor de livings colors lamp, of natuurlijk gewoon leren solderen.

Zijn er dan echt geen neon buizen met een USB aansluiting ofzo? Ik vind 100eu nogal wat voor zo'n lamp... Kep ook al zo'n wake up light, die werkt wel fijn alleen vind ik ook 100eu daarvoor al duur... Dus als ik dan nog zo'n duur philips ding erbij moet aanschaffen

[madwizard]

De strips van dealextreme heb ik ondertussen ook binnen, zijn erg mooi en alle LEDs aan is ook echt wit, maar ze zijn wel flink lang. Te lang voor de meeste TVs waarschijnlijk (met name verticaal dan).

Op circuitsonline heb ik een vergelijking van de dealextreme en LEDsee strips gezet, ik zal die ook hier neerzetten:

---

Hier zijn de strips van dealextreme en van LEDsee. Dealextreme is de grote (links), LEDSee de kleine.

Naast elkaar, alle LEDs aan
De dealextreme strips geven naar mijn idee over het geheel meer licht, maar per stuk zijn de LEDs minder fel. Er zitten dan ook 54 leds op in plaats van 27, en ze zijn een stuk langer. De strips van LEDsee hebben een meer geconcentreerd licht. Op de dealextreme strips lijken eens oort 5mm LEDs ter zitten, het is wat lastig te zien wat voor LEDS precies gezien alles ingegoten is in een doorzichtig iets (epoxy ofzo?)


Een voor een, alle LEDs aan
Dealextreme heeft mooi wit licht, de deur lijkt nog iets blauw maar in werkelijkheid is het witter, je kunt ook goed de echte kleur van de houten vloer zien. De rood van LEDsee is te zwak waardoor er een cyaantint ontstaat, de vloer ziet er gewoon blauwig uit.


Rood en groen aan (geel)
(sorry strips zitten hier andersom, LEDsee links en Dealextreme rechts). Hier zie je goed dat groen het rood overheerst (links bij LEDsee). De spreiding lijkt hier ook minder goed bij LEDsee maar dat komt grotendeels doordat de strip wat gekanteld is, de LEDs zitten bij beide strips op ongeveer gelijke afstanden.


Nog wat andere info:
De strips van LEDsee zijn per 9 LEDs te breken in kleinere stukken. Daar zit ook steeds een boorgat. Aan beide kanten van een strip zit een connector. Dealextreme heeft geen connector maar gewoon 4 draden eraan hangen, de gesoldeerde kant is ook in het plastic ingegoten en zit op zich goed vast (niet alleen met tin dus), maar als de draden breken kan je de boel niet meer aansluiten. Dat zal waarschijnlijk niet zo gauw gebeuren. De dealextreme strips zitten in een (aluminium profiel) en voelen stevig aan, aan beide kanten zit een stukje uitstekend metaal met een boorgat en aan de zijkanten zitten groeven waarmee je eventueel ook nog de boel kunt bevestigen.

edit: nog een closeup:

[Phalox]

Ik ben van plan om mijn plafond te gaan verlichten ik heb nu 5 strips van Niels.. misschien toch maar die van Dealextreme bestellen ?

Heb jij last gehad van douane ? (hier in belgie zijn ze daar iets sneller meer ) en hoelang duurde het voordat je pakket bij je thuis was ?

Zitten er langs de andere kant ook van die draadjes ? altijd handig om weten he.. grtz!

ps: het zijn toch deze strips: http://www.dealextreme.com/details.dx/sku.10061

Wel een stukje duurder dan bij Niels

[ Voor 14% gewijzigd door Phalox op 16-01-2008 11:47 ]

[madwizard]

tokesnugerd schreef op woensdag 16 januari 2008 @ 11:42:
Heb jij last gehad van douane ? (hier in belgie zijn ze daar iets sneller meer )

Nee geen BTW betaald, op het pakket staat 45HKD (~ 4 euro) en gift. Maar ja dat staat tegenwoordig op elk pakket uit china ongeacht de inhoud dus ik weet niet hoe dat in Belgie gaat.

en hoelang duurde het voordat je pakket bij je thuis was ?

Ongeveer 2 weken.

Zitten er langs de andere kant ook van die draadjes ?

Nee, er zitten wel aansluitingen maar die zijn ingegoten aan die kant, daar kun je niets mee.

Wel een stukje duurder dan bij Niels

You get what you pay for

En ja die strips zijn het inderdaad.

[ Voor 8% gewijzigd door madwizard op 16-01-2008 11:50 ]

[Perceptor]

madwizard schreef op woensdag 16 januari 2008 @ 11:49:
[...]
Nee geen BTW betaald, op het pakket staat 45HKD (~ 4 euro) en gift. Maar ja dat staat tegenwoordig op elk pakket uit china ongeacht de inhoud dus ik weet niet hoe dat in Belgie gaat.
[...]

Ongeveer 2 weken.

You get what you pay for

En ja die strips zijn het inderdaad.

Ik had er ook 4 besteld, bij mij waren ze na precies één week binnen en heb ook geen douane hoeven te betalen. Ik vind ze er wel robuust uitzien. Moet ze nog aansluiten.

[Kr3Kr]

BobLight aangepast zodat hij werkt met Benadski's bord (255-R1G1B1-R2G2B2-R3G3B3-R4G4B4 - protocol)

edit: BobLight is door Bob (bobo1on1) geschreven, niet door mij. Ik heb alleen die kleine aanpassing gemaakt.

[ Voor 30% gewijzigd door Kr3Kr op 20-01-2008 14:52 . Reden: discl ]

[Verwijderd]

@madwizard: Bedankt voor het vergelijk. Zie dat je strips hebt ontvangen met een witte ondergrond die van mij zijn zwart. Als ik het goed heb gezien kun je deze strips wel door midden zagen en aan de andere kant de epoxy weghalen en op nieuw aansluiten. Zal eens kijken of ik 1 strip kan opofferen.

[Verwijderd]

Met een stanley mes kan ik de epoxy wel weghalen. Dit moet je dan wel zeer voorzichtig doen en laagje voor laagje zodat je de printsporen niet beschadigd. Doormidden zagen is de volgende aktie. Wie?

[madwizard]

Als je goed kijkt zie je in de witte achtergrond printbanen lopen, als je die weer verbind zou je ze misschien wel weer kunnen splitsen. Maar solderen aan printbanen onder de epoxy is niet echt makkelijk en ook geen goede stevige verbinding natuurlijk. Of je moet het weer opnieuw ingieten ofzo.

[MikeyMan]

Is het geen idee om die strip van LEDsee licht op te schuren voor een wat meer diffuus licht? Of eventueel achter een melkglaasje...?

Verder nog vorderingen trouwens, madwizard?

[madwizard]

Op een beetje afstand mengen die LEDsee strips vrij goed hoor, het is alleen jammer dat de rood zwak is. Verder helaas nog weinig vorderingen, ben er nog niet aan toegekomen.

[MikeyMan]

Zou een beetje opschuren dat niet oplossen dan? Als finishing touch zegmaar?

Haal daar vaak wel aardige resultaten mee, en het zou -lijkt me- de menging ook wel ten goede komen...

[Verwijderd]

ik zat zelf te denken aan transparante buisjes en deze met fijn schuurpapier mat te maken en daar dan die led stips in. Aan de andere kant mixen ze best heel aardig. Dat rood minder is heb na het compenseren totaal geen last van.

Ik ben even de draad kwijt wie nu exact bob light geschreven heeft, maar is het mogelijk een 5 tal presets in te bouwen? Gamen met bob light aan stoort me nogal vanwegen de hakkeling die het opleverd in het beeld. Maar ja zonder bob is het buro opeens wel heel kaal dus zet ik bob uit en met het ambilight test programma van Raf zet ik dan een kleur aan.

Het zou echt super zijn als je gewoon in bob light even snel een preset zou kunnen selecteren.

[Kr3Kr]

Verwijderd schreef op donderdag 17 januari 2008 @ 01:33:
ik zat zelf te denken aan transparante buisjes en deze met fijn schuurpapier mat te maken en daar dan die led stips in. Aan de andere kant mixen ze best heel aardig. Dat rood minder is heb na het compenseren totaal geen last van.

Ik ben even de draad kwijt wie nu exact bob light geschreven heeft, maar is het mogelijk een 5 tal presets in te bouwen? Gamen met bob light aan stoort me nogal vanwegen de hakkeling die het opleverd in het beeld. Maar ja zonder bob is het buro opeens wel heel kaal dus zet ik bob uit en met het ambilight test programma van Raf zet ik dan een kleur aan.

Het zou echt super zijn als je gewoon in bob light even snel een preset zou kunnen selecteren.

BobLight is door Bob geschreven! (ik ben zelf ook z'n nick kwijt ) Bedankt Bob!
Je bedoelt dat je beeldscherm gaat "hakkelen"? probeer BobLight na het selecteren van de preset eens een lagere prioriteit te geven (in taakbeheer), ik zag namelijk ook pas tijdens het lezen van de code dat hij hem in de gamingmode meer prio geeft. Misschien gaan de leds dan wel hakkelen/achter lopen oid...
Over die aanpassing: ik denk dat zelfs dat teveel voor mij is

[madwizard]

Net de elektuur binnen gekregen, staan 2 ambilight projecten in, beide zo te zien op VGA danwel RGB scart. Een analoog, een digitaal (met een of andere PIC). Heb nu geen tijd om het stuk te lezen verder maar dan weten jullie dit alvast

[Oyster]

madwizard schreef op donderdag 17 januari 2008 @ 12:42:
Net de elektuur binnen gekregen, staan 2 ambilight projecten in, beide zo te zien op VGA danwel RGB scart. Een analoog, een digitaal (met een of andere PIC). Heb nu geen tijd om het stuk te lezen verder maar dan weten jullie dit alvast

Scan eens.

[madwizard]

Je hebt nog iets met copyright he Bovendien is het flink wat pagina's, koop het maar gewoon

[Oyster]

madwizard schreef op donderdag 17 januari 2008 @ 13:11:
Je hebt nog iets met copyright he Bovendien is het flink wat pagina's, koop het maar gewoon

Ik wil hem graag kopen, alleen heb ik tot op heden nog geen verkoop punt gevonden in de buurt. Mischien neem ik wel gewoon een abbo.

[madwizard]

Ik heb een proefabbo genomen (speciaal voor dit ), kost 12 euro en krijg je drie nummers zonder verdere verplichtingen. Je krijgt ook nog deze maand als je het in deze maand aanvraagt. Ik zie ze altijd bij de ako liggen trouwens mocht die misschien in de buurt zijn.

[ Voor 18% gewijzigd door madwizard op 17-01-2008 13:38 ]

[Oyster]

madwizard schreef op donderdag 17 januari 2008 @ 13:35:
Ik heb een proefabbo genomen (speciaal voor dit ), kost 12 euro en krijg je drie nummers zonder verdere verplichtingen. Je krijgt ook nog deze maand als je het in deze maand aanvraagt. Ik zie ze altijd bij de ako liggen trouwens mocht die misschien in de buurt zijn.

Ik heb ook maar een proefabbo genomen. In die zin ben ik wel van mening dat dergelijk blad moet blijven bestaan. Dus dan vraag ik liever een proefabbo aan.

[etimm]

Helaas heb ik het februari nummer van elektuur nog niet in de winkel zien liggen.
Nog ff geduld hebben dus...

Staat er toevallig nog in wat de voor/nadelen zijn van de analoge/digitale versie?

Zonde dat het alleen met vga of rgb werkt. (ergens wel logisch) Mij leek het juist geweldig tijdens het gamen op m'n xbox 360. Ik heb m via component aangesloten en ben niet van plan om de vga aansluiting hiervoor te gaan gebruiken...

bestaat een yuv (component) naar rgb converter?

[ Voor 50% gewijzigd door etimm op 18-01-2008 15:32 ]

[bobo1on1]

Kr3Kr schreef op donderdag 17 januari 2008 @ 08:55:
[...]

BobLight is door Bob geschreven! (ik ben zelf ook z'n nick kwijt ) Bedankt Bob!
Je bedoelt dat je beeldscherm gaat "hakkelen"? probeer BobLight na het selecteren van de preset eens een lagere prioriteit te geven (in taakbeheer), ik zag namelijk ook pas tijdens het lezen van de code dat hij hem in de gamingmode meer prio geeft. Misschien gaan de leds dan wel hakkelen/achter lopen oid...
Over die aanpassing: ik denk dat zelfs dat teveel voor mij is

Ik heb boblight geschreven en ik zou het op prijs stellen als mijn achternaam niet open en bloot op een forum staat.

Ik ben nu bezig met de linux software die nu al een stuk beter is dan de windows software, je kunt instellen hoeveel lampen je hebt en op welk deel van het scherm ze moeten reageren, je kunt een momo type controller gebruiken met een willekeurig aantal kanalen, je kunt lampen aansturen via een geluidskaart, en je kunt rgb waarden naar een programma schrijven met popen() als je zelf een controller hebt gemaakt die je met een eigen programma aan wilt sturen.
Je kunt ook verschillende controllers door elkaar gebruiken, dus 4 momo controllers en 2 geluidskaartcontrollers is geen probleem (maximaal 64 controllers en 64 lampen).

De software werkt met een soort client/server model, er wordt een stuk shared memory gecreëerd wat verdeeld is in 32 slots waar clients naar kunnen schrijven, de server leest dit uit en pakt de waarden van het slot met de hoogste prioriteit, als er twee slots open zijn met dezelfde prioriteit pakt hij degene die het langst open is.

Een client mag ook schrijven op elke gewenste snelheid, de server interpoleert de waarden automatisch, als je dus een X11 grabber gebruikt die elke halve seconde de desktop uitleest dan zorgt de server ervoor dat je toch vloeiende overgangen hebt.

Hier vast een voorproefje met een tv kaart:

[madwizard]

etimm schreef op vrijdag 18 januari 2008 @ 11:14:
bestaat een yuv (component) naar rgb converter?

De LMH1251, heb er zelfs een liggen volgens mij. http://www.national.com/pf/LM/LMH1251.html

[kippy]

etimm schreef op vrijdag 18 januari 2008 @ 11:14:
Helaas heb ik het februari nummer van elektuur nog niet in de winkel zien liggen.
Nog ff geduld hebben dus...

Staat er toevallig nog in wat de voor/nadelen zijn van de analoge/digitale versie?

Zonde dat het alleen met vga of rgb werkt. (ergens wel logisch) Mij leek het juist geweldig tijdens het gamen op m'n xbox 360. Ik heb m via component aangesloten en ben niet van plan om de vga aansluiting hiervoor te gaan gebruiken...

Mensen zijn ook nooit tevreden, is er een vga verzie moet er weer een component verzie komen
Maar je vroeg naar het verschil tussen de analoge en digitale verzie.
De analoge heeft maar 1 led, en houd dus geen rekening met links rechts boven en onder. De digitale verzie werkt met drie led strips aangestuurd door een microcontroller, deze houd wel rekening met links, rechts en boven.

[Kr3Kr]

bobo1on1 schreef op zaterdag 19 januari 2008 @ 17:12:
[...]


Ik heb boblight geschreven en ik zou het op prijs stellen als mijn achternaam niet open en bloot op een forum staat.

Ik ben nu bezig met de linux software die nu al een stuk beter is dan de windows software, je kunt instellen hoeveel lampen je hebt en op welk deel van het scherm ze moeten reageren, je kunt een momo type controller gebruiken met een willekeurig aantal kanalen, je kunt lampen aansturen via een geluidskaart, en je kunt rgb waarden naar een programma schrijven met popen() als je zelf een controller hebt gemaakt die je met een eigen programma aan wilt sturen.
...

Excuses voor de achternaam. Aangezien die in de source van het programma staat dacht ik dat je er geen problemen mee zou hebben. Ik heb het aangepast.

Die linuxversie klinkt erg interessant. Zou die ook te porten zijn naar OS X?
Zo'n client-servermodel lijkt me voor de windowsversie ook een goede toekomst, zodat e.e.a. wat modulairder wordt. Ik zat nu al te denken hoe ik dat moest gaan doen als ik een deel van de lampen ambilight wil laten doen, en de anderen een random colorfade...

[ Voor 26% gewijzigd door Kr3Kr op 20-01-2008 14:58 ]

[bobo1on1]

De server is wel te porten naar osx en ook wel naar windows.

De clients moeten bijna helemaal opnieuw geschreven worden, maar die zitten zo simpel in elkaar dat dat weinig uitmaakt.

[StapelPanda]

Vandaag toch maar weer is met DirectX 3d gespeeld, en ja hoor, na een half uurtje werk kan ik een screenshot maken van een film . Ik zal het binnenkort in een Ambilight project te zetten.

[ Voor 4% gewijzigd door StapelPanda op 20-01-2008 16:33 ]

[Verwijderd]

Betekent dit nu dat de weg vrij is voor een momolight directx aan stuur geneuzel? Hoerayy :-)

[Verwijderd]

Sweet! BobLight op linux...

Wat zou dat fijn zijn, dan kan ik straks helemaal af van Windows MCE en kan ik me helemaal focussen op m'n bestelde Tribbox (open source top-set-box). Het draait Fedora dus een linux versie van Boblight maakt me helemaal blij!

/me vond het al zo jammer dat boblight en Vista niet goed samen gaan

[ Voor 0% gewijzigd door Verwijderd op 21-01-2008 14:11 . Reden: damn... alleen USB aansluitingen op de Tribbox. Zucht, even mailen of er geen RS232 header op het mobo zit ;-) ]

[StapelPanda]

Verwijderd schreef op maandag 21 januari 2008 @ 14:09:
Sweet! BobLight op linux...

Wat zou dat fijn zijn, dan kan ik straks helemaal af van Windows MCE en kan ik me helemaal focussen op m'n bestelde Tribbox (open source top-set-box). Het draait Fedora dus een linux versie van Boblight maakt me helemaal blij!

/me vond het al zo jammer dat boblight en Vista niet goed samen gaan

Rs2332 is handig, maar anders kan je misschien met een usb naar RS232 kabeltje het een en ander aansluiten.

[Verwijderd]

Staat er nog iets in de planning om Boblight Vista compatible te maken?

[Verwijderd]

Het werkt met vista alleen niet met aero. Wat ik gelezen heb in dit topic heeft dat te maken met de Get pixel routine welke in vista op de schop is gegaan. Je zou dus een hele andere aanpak moeten hebben bij vista.

[BasilFX]

Verwijderd schreef op maandag 21 januari 2008 @ 15:31:
Staat er nog iets in de planning om Boblight Vista compatible te maken?

Boblight werkt gewoon in vista. Je moet alleen Aero uit zetten. Dat is het enige punt. Voor de rest zou het gaan werken als je het 3D gedeelte van Aero kunt benaderen.

[Verwijderd]

Rs2332 is handig, maar anders kan je misschien met een usb naar RS232 kabeltje het een en ander aansluiten.

Net even gebeld, er zit een RS232 header op het mobo. Anders is een USB->RS232 ook een optie (draait immers linux)

Boblight werkt gewoon in vista. Je moet alleen Aero uit zetten. Dat is het enige punt. Voor de rest zou het gaan werken als je het 3D gedeelte van Aero kunt benaderen.

Aargh, dan maar snel even proberen!

[etimm]

Ik heb nu eindelijk een exemplaar van elektuur thuis
Ik ben alleen bang dat led strips (die gebruikt worden bij de digitale versie) wel erg kort zijn voor m'n 42" plasma Volgens mij kunnen er ook maar 3 op aangesloten worden of heb ik dat mis?
De TV hangt hier op een witte muur en er is ook plek voor een ledstrip aan de onderkant van de tv.

Heeft iemand enig idee wat de stand alone versie uit de elektuur moet kosten (alle onderdelen etc) ?

[bobo1on1]

Verwijderd schreef op maandag 21 januari 2008 @ 16:43:
[...]

Net even gebeld, er zit een RS232 header op het mobo. Anders is een USB->RS232 ook een optie (draait immers linux)

Ik heb het aangesloten op een usb naar rs232 converter met een pl2303 chip, dat werkt zowel in linux als in windows perfect.

Het enige waar je op moet letten is dat er niet te veel stroom door de gnd aansluiting van de converter loopt want dan loopt de converter vast, dat kan gebeuren als je de momo controller aangesloten hebt op de voeding van de pc.

Ik heb dat opgelost door een 10 ohm weerstand in serie te zetten met de gnd aansluiting van de seriele kabel.

[Verwijderd]

Bij mij blijft boblight om de paar minuten crashen onder vista (met aero uit). Misschien dat het licht aan dat ik 64 bit draai dan?

[kippy]

etimm schreef op maandag 21 januari 2008 @ 16:45:
Ik heb nu eindelijk een exemplaar van elektuur thuis
Ik ben alleen bang dat led strips (die gebruikt worden bij de digitale versie) wel erg kort zijn voor m'n 42" plasma Volgens mij kunnen er ook maar 3 op aangesloten worden of heb ik dat mis?
De TV hangt hier op een witte muur en er is ook plek voor een ledstrip aan de onderkant van de tv.

Heeft iemand enig idee wat de stand alone versie uit de elektuur moet kosten (alle onderdelen etc) ?

De ledstrips kun je zo lang maken als je zelf wilt. Je kan dus gewoon de ledstips van niels gebruiken of een ander type dat hier als wel eens voorbij is gekomen.
De kosten... ja heb er ook naar zitten kijken, en het zijn niet de goedkoopste componenten die er zijn. Het grootste probleem zijn de ADC's die zijn vrij lastig verkrijgbaar, waarom ze die gebruiken is voor mij ook een grote vraag.
Maar ik denk dat je totaal met print zonder led stips zo'n 50~60 euro kwijt bent.

[etimm]

Dat is nog wel te doen, helaas is solderen niet echt mijn sterkste kant
Is er toevallig iemand die het printje van elektuur gaat maken?

[madwizard]

Er is ook het een en ander te koop in de elektuur shop,

[kippy]

madwizard schreef op dinsdag 22 januari 2008 @ 19:22:
Er is ook het een en ander te koop in de elektuur shop,

Print, zonder onderdelen 29 euro...
3 lamp verzie

Serround light met smd voorgesoldeerd (1 lamp verzie) 129 euro.... dat is echt niet normaal. Daar koop je met gemak een am-Bix van philips voor...

[Hermanvh]

Wellicht dat we er een aantal kunnen laten maken in China ofzo? Designs zitten erbij, dus een stuk of 20 of 50 laten maken in China zou best te doen moeten zijn

Dan nog de onderdelen op de kop tikken (wellicht dat we kant en klare boardjes in China kunnen bestellen?).

Het zou mooi zijn als iemand het zou kunnen testen op een development boardje ofzo en dan de resultaten zou kunnen posten, zodat we weten of het de moeite waard is.

Helaas heb ik weinig electro-meuk thuis liggen, dus kan zelf niet echt testen....

De PIC's (18F4550 en 16F628) zijn redelijk aan de prijs, ik vraag me af wat een compleet boardje zou moeten kosten. Ik denk dat je al gauw op € 60/70,- uitkomt (is natuurlijk nog steeds een stuk goedkoper dan die van Elektuur )

[mabarto]

Veel gelezen de laatste maanden over dit onderwerp (deze topic en op SK), maar ik wij eigenlijk zo'n systeem in mijn verlaagd plafond. Probleem dat ik nu even zie is dat de producten die hier gemaakt worden de ambilight surround nabootsen en niet de full surround (4 kanten).
Komt hier verandering in of zijn hier oplossingen voor? (let wel: de 4 zijden moeten niet kopien van elkaar zijn ofzo... bijv links en rechts die beide dubbel uitgevoerd zijn)

[Verwijderd]

ambi light zoals het nu is heeft 9 kanalen verdeeld in 3 boven 3 links en 3 rechts. Voor zover ik nu weet is er geen hardware voor 12 kanalen en vermoedelijk ook geen software. Dat neemt niet weg dat het mogelijk is een 12 kanaals versie te bouwen de vraag is of mensen er op zitten te wachten. Persoonlijk zou ik hem niet eens kwijt kunnen ivm de monitor voet.

Surround ambi light? Je snapt wel dat het niets met geluid doet he....

In het systeem plavon, aha, dus links op het scherm word links plavon boven recht etc, boven blijft boven maar de onder kant van je scherm word dan opeens achter je?

[_Brake_]

Als je nou niet dynamisch licht wilt achter je LCD / Plasma, maar gewoon die 4 LED bars van de IKEA. Voor welke kleur zouden jullie dan gaan? Want het is jammer om 20 euro extra uit te geven, als je alleen maar wit licht achter je TV op de (in mijn geval overigens witte) muur projecteert!

[bobo1on1]

mabarto schreef op donderdag 31 januari 2008 @ 13:11:
Veel gelezen de laatste maanden over dit onderwerp (deze topic en op SK), maar ik wij eigenlijk zo'n systeem in mijn verlaagd plafond. Probleem dat ik nu even zie is dat de producten die hier gemaakt worden de ambilight surround nabootsen en niet de full surround (4 kanten).
Komt hier verandering in of zijn hier oplossingen voor? (let wel: de 4 zijden moeten niet kopien van elkaar zijn ofzo... bijv links en rechts die beide dubbel uitgevoerd zijn)

Met mijn linux software kun je zelfs 64 lampen aansturen

Op een momolight controller kun je er maar 3 aansluiten, maar je kunt zonder problemen twee momo controllers gebruiken.

Hier is de eerste linux versie:

Dit is de lib die je eerst moet installeren met ./configure && make && make install
http://www.xs4all.nl/~loo...t/boblight-lib-0.1.tar.gz

Dit is het pakket met de server, constant client, video4linux client, jack client, X11 client en de lirc client.
Installeren met ./configure && make && make install.
http://www.xs4all.nl/~loosen/boblight/boblight-0.1.tar.gz
Dependencies:
libboblight
libasound (comes with alsa)
libX11 (comes with xorg)
libXext (comes with xorg)
liblirc_client (comes with lirc)
libjack (comes with jack)

Dit is de plugin voor xine, installeren met ./configure && make && make install en vervolgens een symlink maken zoals in de readme staat.
http://www.xs4all.nl/~loo.../boblight-xine-0.1.tar.gz
Dependencies:
libboblight
libxine

Hier staat een voorbeeld boblight.conf met een momo controller: http://www.xs4all.nl/~loosen/boblight/boblight.conf

Een heleboel informatie staat in de files README, INSTALL en USING, documentatie schrijven is een heleboel werk dus het is nog niet af, als er iemand vragen heeft dan zie ik het wel.

Als je wilt weten hoe je met een geluidskaart een lamp aanstuurt dan kun je beginnen met dit schema:

[ Voor 46% gewijzigd door bobo1on1 op 31-01-2008 19:49 ]

[mabarto]

Verwijderd schreef op donderdag 31 januari 2008 @ 15:23:
Surround ambi light? Je snapt wel dat het niets met geluid doet he....

Yep, maar hiervoor moet je bij de marketing afdeling van Philips zijn. Ambilight Surround = 3 kanten, Ambilight Full Surround = 4 kanten (aurea bijv).

In het systeem plavon, aha, dus links op het scherm word links plavon boven recht etc, boven blijft boven maar de onder kant van je scherm word dan opeens achter je?

Ik heb een koof rondom in mijn woonkamer aan de kant van de muren. In het middenstuk is het iets verlaagd, maar hier wil ik dus nog een plaat plaatsen om te verlagen, zodat ik aan de binnenkant van de iets minder grotere plaat (dan het gedeelte verlaagd in het midden), leds kan plaatsen. Als ik dus tv kijk en ik kijk omhoog dan zie ik het middenstuk.

[_Brake_]

Een beetje nep, maar ik heb zojuist de DIODER van IKEA gehaald.

Het ziet er leuk uit, zal vanavond de foto's posten (zijn nu nog 5MP)!

[Pinjataaa]

_Brake_ schreef op maandag 04 februari 2008 @ 17:17:
Een beetje nep, maar ik heb zojuist de DIODER van IKEA gehaald.

Het ziet er leuk uit, zal vanavond de foto's posten (zijn nu nog 5MP)!

Die heb ik ook, werkt mooi Ik moet alleen die 12V naar 10 volt zien te krijgen, anders blijft rood branden wanneer ie uit moet zijn... Heb het al met een diode geprobeerd maar dan knipperd het teveel.

[ Voor 23% gewijzigd door Pinjataaa op 04-02-2008 17:24 ]

[Sprite_tm]

* Sprite_tm is bezig met de draadloze en asociaal-dure-tis-dat-ik-m-gekregen-heb-variant ervan:

En jah, te veel latency en geen leuk algo; tis ook nog maar een proto:

[Pinjataaa]

Atmel powerrr

Ik ben bezig met een moodlight optie in boblight, nja, meer een beetje aan het uitproberen met C#..
Echter snap ik er geen pepernoot van, ik heb alle waardes van rood tot aan rood, maar als ik de waardes uitstuur reageert mijn kitje er heel raar op.. het is toch gewoon RL RB RR GL GB GR BL BB BR?
Dan kan ik toch gewoon 1271270 uitsturen om oranje te krijgen? Of ben ik nu dom bezig
Moet het in hex? 7F7F00? Moeten er enters achter oid.

Alvast bedankt..

[ Voor 93% gewijzigd door Pinjataaa op 05-02-2008 16:39 ]

[Eiland]

Mischien een domme vraag maar; Wat is het verschil tussen Momolight & boblight

[Sprite_tm]

Even tussendoor: Is het niet een idee om een universeel licht-besturings-protocol te schrijven? Voor zover ik kan zien is alleen Momolight iets wat de meeste mensen wel implementeren, en to be honest, da's vrij waardeloos. Geen synchronisatie, alleen ondersteuning voor drie kanalen, geen ondersteuning voor out-of-band-data...

Ik stel voor dat we een nieuw 'standaard'-protocol bedenken. We hoeven niet meteen naar DMX over, dat is imo te kostbaar om in zo'n simpele setup te schuiven, maar het zou grappig zijn als een apparaat plug-and-play in een serieele poort te steken is en een programma meteen snapt hoe en wat, en dat ook meer of minder dan drie kanalen herkend kunnen worden.

What about een packet-based aanpak zoals dit?
Kanaaldata:
Byte 0-1: 0x55 0xAA : Synchronisatie-bytes, pakketjes beginnen altijd hiermee.
Byte 2: Startkanaal, 0>kanaal>127. Hierna aan te duiden met K
Byte 3: Hoeveelheid kanalen aan data volgen.
Byte 4: Kanaal K, rood
Byte 5: Kanaal K, groen
Byte 6: Kanaal K, blauw
Byte 7: Kanaal K+1, rood
Byte 8: Kanaal K,+1 groen
(etc)

Commando's:
Byte 0-1: 0x55 0xAA : Sunchronisatie-bytes, pakketjes beginnen altijd hiermee.
Byte 2: Commando, 127>commando>255. Hierna aan te duiden met C
Byte 3: Hoeveelheid bytes aan data in het commando volgen. Kan 0 zijn.
Byte 4-...: commando-data

Commando's:
127 : request number of channels. Apparaat geeft hoeveelheid kanalen terug, als 1 byte.
128-191: reserved for future use
192-255: Vendor-specific. Als je hardware speciale functies heeft (om mijn unit als voorbeeld te pakken: het aanmelden van extra ambilights) kan je die hier implementeren. Niet gestandaardiseerd.

In principe is dit protocol stream-based, dus het maakt niet uit of het over USB, RS232 of desnoods een TCP/IP-socket gaat. Ik stel wel voor dat we voor RS232 een standaard baudrate etc instellen waar elk apparaat op zou moeten werken.

Als we zoiets als standaard pakken, weten we iig zeker dat alle alternatieve moodlight-devices compatible blijven met de aanwezige software, hoeveel kanalen of wat voor configuratie het ook heeft.

Anyway, als je op/aanmerkingen hebt, giltumaar

[0fbe]

Waarom zo moeilijk doen? Zo kostbaar is DMX/RS485 nu ook weer niet. Een RS485 converter (75176) kost je nog geen euro. FPS is hoog genoeg (44.1Hz voor 512 kanalen van 8 bit) Verder is het vrij standaard en kan je dus ook gemakkelijk het combineren met andere verlichting. Pak iig RS485 want dat is redelijk failsafe ook op grote afstanden. Verder is je talkback idee wel goed. Alleen moet je dan wel even kijken hoe je dat doet met overspraak etc...

Zelf heb ik (professionele) ervaring met DMX en het protocol is ook niet alles (het is een beetje verleden tijd het stamt ook al 1986) Waarop DMX op het moment hangt is het volgende:
-Te weinig kanalen (je zult dus van die 250kbaud af moeten, waarmee je signaal kwaliteit/zekerheid gaat verliezen en dus lengte)
-Geen talk-back (wat RS485 wel ondersteund)
-De mogelijkheid voor fabrikant specifieke aansturing en programmering/adressering op afstand

[ Voor 59% gewijzigd door 0fbe op 06-02-2008 22:35 ]

[Sprite_tm]

Ik heb eraan gedacht, maar ik heb er een aantal zaken tegen, onder andere deze:
* DMX is niet retourgeschikt, plug'n'play is dus niet as is mogelijk.
* Een RS485-converter is misschien niet zo duur, maar vaak wel compleet overbodig hier: de lichtjes zullen bij de meeste mensen achter de monitor of TV terechtkomen: max 5 meter ofzo.
* DMX-data moet continue verstuurd worden (op een vrij vreemde baudrate iirc) in vaststaande blokken. Dat kan een PC as is niet, dus er zal altijd een uC bij moeten komen om spul vanaf de PC als DMX te encoderen
* Als je zo'n verlichting dmv USB wilt aansluiten... moet ik nog verder gaan?
* Ik zie niet echt iemand die 'voor de leuk' voor een paar tientjes zelf een ambilight samenstelt, verder gaan door er duur DMX-spul aan te hangen. Inter-operability is leuk, maar dit zijn 2 verschillende doelgebieden imo.

[ Voor 5% gewijzigd door Sprite_tm op 06-02-2008 22:32 ]

[0fbe]

Zie ook mijn edit...
Dat je geen DMX wilt gebruiken geef ik je 100% gelijk in (zie redenen in vorige post)

Alleen zou ik wel RS485 gebruiken gezien de betrouwbaarheid (differentieel dus niet zo vatbaar voor storingen) en de "juistheid" (RS232 is een 1:1 protocol officieel, RS485 is multi-node, multi-master)

Edit:
Ik keek vandaag nog even over je protocol heen en hoe wil je het doen qua adressering? Worden alle pakketten naar iedereen gebroadcast?

[ Voor 23% gewijzigd door 0fbe op 07-02-2008 10:32 ]

[bobo1on1]

Sprite_tm schreef op woensdag 06 februari 2008 @ 22:12:
Even tussendoor: Is het niet een idee om een universeel licht-besturings-protocol te schrijven? Voor zover ik kan zien is alleen Momolight iets wat de meeste mensen wel implementeren, en to be honest, da's vrij waardeloos. Geen synchronisatie, alleen ondersteuning voor drie kanalen, geen ondersteuning voor out-of-band-data...

Ik zou niet gaan voor een bepaald kanaal waar dan 3 kleuren aan hangen, dan verplicht je mensen om een controller te maken met een aantal kanalen wat een veelvoud van 3 is, naar mijn mening is het het beste dat de controller zegt hoeveel kanalen hij heeft.

Ik zou ook graag 2 bytes per kanaal gebruiken zodat je eventueel met een 16 bits dac kunt werken, 8 bits is soms net te weinig, vooral bij lage waarden.

De controller moet zelf aangeven hoeveel lampen hij heeft en op welke kanalen de kleuren van de lampen zitten aangesloten, ook moet hij aangeven op welk deel van het beeld een lamp moet reageren.

Wat ook een mogelijkheid moet zijn is dat je meerdere controllers aansluit op een elke rs232 poort, zo zou je losse lampen kunnen maken die je dan aan elkaar kunt daisy-chainen.

Een TCP of UDP socket is niet erg geschikt voor ambilight, ik heb het voor mijn linux app uitgeprobeerd maar ik kreeg nogal veel jitter.

offtopic:
Zie ik daar een Tulip toetsenbord met een heerlijke aanslag?

[ Voor 49% gewijzigd door bobo1on1 op 07-02-2008 23:54 ]

[Sprite_tm]

Timkooijmans: Ik wilde de fysieke layer eigenlijk ongedefinieerd laten, zodat je zelf met ethernet->usb->rs232->rs458-converters in de weer kan gaan als dat moet. Misschien zijn ideeen voor de implementatie op de verschillende fysieke lagen wel een idee, maar ik wilde eigenlijk niets verplicht stellen.

Bobo1on1: Fair nuf, misschien is meteen een optie te maken dat bij elk kanaal uit te lezen is welke kleur 'ie geeft. Zo zou je bijvoorbeeld ook je (gele/roze/paarse) kerstlampjes in het geheel kunnen opnemen. 16bit is idd ook wel een optie.

offtopic:
Nope, tis zo'n ouderwetsch IBM Model M sla-iemand-ermee-dood-en-het-keyboard-heeft-geen-schrammetje klikklik keyboard.

[0fbe]

Sprite_tm schreef op vrijdag 08 februari 2008 @ 01:37:
Timkooijmans: Ik wilde de fysieke layer eigenlijk ongedefinieerd laten, zodat je zelf met ethernet->usb->rs232->rs458-converters in de weer kan gaan als dat moet. Misschien zijn ideeen voor de implementatie op de verschillende fysieke lagen wel een idee, maar ik wilde eigenlijk niets verplicht stellen.

Bobo1on1: Fair nuf, misschien is meteen een optie te maken dat bij elk kanaal uit te lezen is welke kleur 'ie geeft. Zo zou je bijvoorbeeld ook je (gele/roze/paarse) kerstlampjes in het geheel kunnen opnemen. 16bit is idd ook wel een optie.

offtopic:
Nope, tis zo'n ouderwetsch IBM Model M sla-iemand-ermee-dood-en-het-keyboard-heeft-geen-schrammetje klikklik keyboard.

Qua kleur: gebruik een 3 of 4 lettercode daarvoor, daar word nu met DMX ook al mee gewerk. Als je het slim in elkaar steekt zou je het zelfs semi-backwardscompatible met DMX producten kunnen maken (de meeste chips die DMX uitlezen zijn programmeerbaar en dus ook om te bouwen naar een andere standaard over RS485)

Verder is het vrijlaten van de fysieke layer een goed idee denk ik, misschien is het verstandig om een keer rond de virtuele tafel te gaan zitten en een echte standaard vast te stellen, er is namelijk nogal vraag naar in de proffesionele licht wereld...

[Sprite_tm]

Hoewel het maken van een nieuwe standaard in de lichtwereld misschien ook wel een goed idee is, was ik eigenlijk niet van plan om het zover te laten komen. Ik denk namelijk niet dat er heel veel gevallen zijn van de profi lichtwereld en de ambilight-kloon die in een bepaald project mixen, en in dat geval is het denk ik beter om een goedkoop en makkelijk te implementeren protocol in elkaar te zetten dan meteen te gaan beginnen aan een allesomvattende lichtstandaard die bij elke profi situatie moet kunnen worden ingezet. Geintjes als RS485 enzo zijn dan, as said, gewoon compleet overkill: de meeste mensen zullen toch wel niet meer willen dan een kabeltje in een serieele- of USB-poort willen steken. Als je het zo bekijkt is bijvoorbeeld de mogelijkheid om meerdere devices via 1 'bus' aan te sturen ook niet echt nuttig: mensen prikken wel een extra USB-plugje in.

Anyway, aangepast voorstel. Hierin zitten de sub-kleuren als aparte kanalen, zijn de kanalen te groeperen en word er 16-bit data ipv 8-bit data overgestuurd.
Kanaaldata:
Byte 0-1: 0x55 0xAA : Synchronisatie-bytes, pakketjes beginnen altijd hiermee.
Byte 2: Startkanaal, 0>kanaal>127. Hierna aan te duiden met K
Byte 3: Hoeveelheid kanalen aan data volgen. Minimaal 1.
Byte 4: Intensiteit kanaal K, MSB
Byte 5: Intensiteit kanaal K, LSB
Byte 6: Intensiteit kanaal K+1, MSB
Byte 7: Intensiteit kanaal K+1, LSB
(etc)

Commando's:
Byte 0-1: 0x55 0xAA : Synchronisatie-bytes, pakketjes beginnen altijd hiermee.
Byte 2: Commando, 127>commando>255. Hierna aan te duiden met C
Byte 3: Hoeveelheid bytes aan data in het commando volgen. Kan 0 zijn.
Byte 4-...: commando-data

Commando's:
127: request number of channels. Apparaat geeft hoeveelheid kanalen terug, als 1 byte.
128: request channel configuration: 1 databyte die het kanaal aangeeft. Response:
byte 1,2,3: RGB-waarde van de kleur van het kanaal. Indien alleen RGB in het aansturende programma is geimplementeerd pakt deze als 'kleur' van het licht de hoogste waarde: RGB 255,128,0 word dan aangestuurd als een rode lamp.
Byte 4: Pool-ID. Kanalen die in dezelfde lichtbron zitten (e.g. rgb-strip) hebben hetzelfde pool-ID.
129-191: reserved for future use
192-255: Vendor-specific. Als je hardware speciale functies heeft (om mijn unit als voorbeeld te pakken: het aanmelden van extra ambilights) kan je die hier implementeren. Niet gestandaardiseerd.

[teun-v]

Klein vraagje, ik snap wel dat er een standaard veel handiger is, maar is dit niet een beetje heel erg veel overkill? Ik bedoel 2 bytes om te synchroniseren met wat? voor mijn gevoel is dat namelijk zonde van je tijd in uC, voor synchronisaties als je baudrate niet klopt heeft het ook niet echt zin, behalve dat je instaat bent om de rest te negeren om het onzin is, maar daar heb je geen 2 bytes nodig. Voor een TCP/IP heb je het ook niet nodig buiten dat je eventueel andere dat kan negeren wat waarschijnlijk toch niet op de gekozen poort aankomt. Een stopbit zou hier handiger zijn omdat je dan de data kan opslaan en in een keer kan verwerken zodra het stopbit binnen is. Verder 2 bytes voor 1 kleur, is dat ook niet erg veel overkill? Als je 1 byte (dus 8 bit) per kleur hebt heb je al keuze uit meer dan 16,7 miljoen kleurtjes(ingeval van RGB). Lijkt mij niet erg nodig om dat nog verder te vergroten zeker omdat je het verschil toch niet kan zien.

Ik kan me verder wel vinden in het protocol wat je noemt alleen niet in 2 bytes voor synchroniseren, als het nodig is dan lijkt mij 1 voldoende maar zonder kan het ook. Eventueel zou voor TCP/IP een stopbit handiger zijn. En 2 bytes voor de kleuren vind ik eigenlijk zonde van je uC cycles terwijl het geen zichtbare verbetering geeft.

[bobo1on1]

teun-v schreef op vrijdag 08 februari 2008 @ 12:57:
Klein vraagje, ik snap wel dat er een standaard veel handiger is, maar is dit niet een beetje heel erg veel overkill? Ik bedoel 2 bytes om te synchroniseren met wat? voor mijn gevoel is dat namelijk zonde van je tijd in uC, voor synchronisaties als je baudrate niet klopt heeft het ook niet echt zin, behalve dat je instaat bent om de rest te negeren om het onzin is, maar daar heb je geen 2 bytes nodig.

Mja met het momo protocol ben ik eigenlijk nog nooit de synchronisatie kwijtgeraakt, dus 2 bytes gebruiken is misschien wat overbodig.

Verder 2 bytes voor 1 kleur, is dat ook niet erg veel overkill? Als je 1 byte (dus 8 bit) per kleur hebt heb je al keuze uit meer dan 16,7 miljoen kleurtjes(ingeval van RGB). Lijkt mij niet erg nodig om dat nog verder te vergroten zeker omdat je het verschil toch niet kan zien.

Daar vergis je je toch even flink in, als ik op een monitor de kleur #101010 laat zien dan is dat praktisch zwart, zet je het naast #090909 dan zie je het verschil niet.

Zet ik een lamp op #101010 dan is dat wit, ook al komt er niet veel licht uit, zet je de lamp nou op #090909 dan heb je ineens een verschil van 10%! Wat dus duidelijk is te zien.

[teun-v]

bobo1on1 schreef op vrijdag 08 februari 2008 @ 15:19:
[...]

Daar vergis je je toch even flink in, als ik op een monitor de kleur #101010 laat zien dan is dat praktisch zwart, zet je het naast #090909 dan zie je het verschil niet.

Zet ik een lamp op #101010 dan is dat wit, ook al komt er niet veel licht uit, zet je de lamp nou op #090909 dan heb je ineens een verschil van 10%! Wat dus duidelijk is te zien.

Dat zou dan een fout zijn in de kleur weergave van de lamp, niet linear? Daar zou dan nog iets hardware of software matig moeten worden opgelost en is niet een probleem wat in een protocol opgelost zou moeten worden. Neemt overigens niet weg dat ondanks deze afwijking er toch nog altijd meer dan 16,7 miljoen kleurtjes zijn.

[Sprite_tm]

Hmmm, het probleem is niet zozeer de non-lineariteit van de LEDs (die worden namelijk per PWM aangestuurd en zijn dus bijna per definitie compleet lineair) maar de non-lineariteit van het oog. De vraag is dan waar dat opgelost moet worden: in de software of in de hardware? Ik stem voor, if any, in de software: in de hardware ben je namelijk vaak druk genoeg zonder er floating point operations voor het logaritmisch maken van de lichtinitensiteit tegenaan te gooien.

En over het synchronisatie kwijtraken: het is me al een paar keer voorgekomen. Nou zit ik hier dan ook niet met de meest standaard hardware (AVR die softwarematig een USB serieele poort nadoet, met een 2.4GHz zender eraan) maar het is dus niet een non-issue. Het grootste probleem vind ik nog wel dat er bij momolight geen enkele manier is om het te detecteren of te corrigeren. (Ok, misschien iets timing-based, maar mooi is anders.) Waarschijnlijk is 1 byte wel genoeg, tho', ik zal het in de volgende revisie veranderen naar enkel 0x55.

Bedenk verder even om hoeveel data het gaat: we lopen hier at max 50 keer per seconde data te versturen. Bij, zeg, 10 lampen, gaat het om 63 byte. Met een baudrate van 33600 is dat nog makkelijk te halen, en dan moet je je bedenken dat 10 lampen aan 1 board aan een trage serieele verbinding in de praktijk niet echt vaak voor zal komen.

TeunV: Een stopbit is niet nodig: de uC kan ergens in het begin de lengte van het pakket al bepalen, en kan dus zelf uitvogelen wanneer de laatste byte binnen is.

[madwizard]

Sprite_tm schreef op vrijdag 08 februari 2008 @ 17:32:
Hmmm, het probleem is niet zozeer de non-lineariteit van de LEDs (die worden namelijk per PWM aangestuurd en zijn dus bijna per definitie compleet lineair) maar de non-lineariteit van het oog. De vraag is dan waar dat opgelost moet worden: in de software of in de hardware? Ik stem voor, if any, in de software: in de hardware ben je namelijk vaak druk genoeg zonder er floating point operations voor het logaritmisch maken van de lichtinitensiteit tegenaan te gooien.

Met hardware bedoel je waarschijnlijk microcontroller-software Er is wel een punt om er via hardware toch rekening mee te houden, als je namelijk een 8-bits PWM resolutie hebt merk je vaak al dat in het lage gebied de non-lineariteit (zal dan wel van het oog zijn inderdaad, heb nooit echt begrepen waarom dit bij PWM anders zo is) al vrij goed te merken is en de stappen tussen de waarden (1-bit) eigenlijk te groot zijn. Je zou de PWM resolutie kunnen ophogen natuurlijk maar misschien is er een beter oplossing voor. In ieder geval kan je een te lage PWM resolutie in het lage gebied nooit met software oplossen.

[teun-v]

Met software bedoelde ik eigenlijk software voor op de computer of op de uC en met hardware alles anders dan dat, dus wat aan de uC hangt Maargoed your getting my point.

@Sprite_tm: Over de stopbit, dit is omdat ik soms er lui ben Vooral bij TCP of UDP je kan dan kijken bij het uitlezen van je buffer kijken of de stop byte voorbijgekomen is zo ja zijn we compleet en kunnen we met de data aan de gang, zo nee laat je alles nog even links liggen. Vandaar, maar je hebt gelijk, het is eigenlijk niet nodig zeker voor een uC niet.

[Sprite_tm]

Madwizard: Hardware = uC + firmware inderdaad Je zou inderdaad wel het een en ander in firmware kunnen oplossen; je timersnelheid afhankelijk maken van je timerpositie ofzo, maar ik vraag me af of je dan niet sneller en beter af bent met alsnog wat meer bits als resolutie te pakken: kans is groot dat je hack evenveel klokcycli gaat innemen als het toevoegen van een paar bits.

[Oyster]

In de elektuur print worden adc's van 50MSPS gebruikt. Is dat niet een beetje overkill?

[kippy]

Xander2000 schreef op zondag 10 februari 2008 @ 22:26:
In de elektuur print worden adc's van 50MSPS gebruikt. Is dat niet een beetje overkill?

Als je alle beeldputen wil sampelen is dat niet overkill. Maar dan is de vraag wil je dat, en kan je micro controller dat wel aan?

[Oyster]

kippy schreef op maandag 11 februari 2008 @ 10:22:
[...]

Als je alle beeldputen wil sampelen is dat niet overkill. Maar dan is de vraag wil je dat, en kan je micro controller dat wel aan?

Dat weet ik nu zo net niet. Pal heeft immers geen horizontale beeldpunten, maar is een analoog signaal in de tijd. De interleaved verticale resolutie van PAL is ~625 oid. De effectieve progressieve resolutie zal rond de 380 lijnen zitten. Met een afmeting van 4:3 of 16:9 wordt de horizontale lijn dus behoorlijk vaak gesampled. 1200 keer per lijn oid volgens de elektuur spec. Ik vind dat erg vaak.

Maar dan is de vraag wil je dat, en kan je micro controller dat wel aan?

Dat zou niet de eerste vraag moeten zijn. De vraag is of het nuttig is zoveel punten te samplen. Als het niet nodig is is het overkill.

[ Voor 5% gewijzigd door Oyster op 11-02-2008 12:21 ]

[Verwijderd]

Pinjataaa schreef op donderdag 22 november 2007 @ 22:22:
[...]


Ik ben nog een beetje aan het fine-tunen, bijvoorbeeld wanneer het beeld zwart was, gingen de lampjes wit branden. Dit is nu wel opgelost, maar toch zijn er nog een paar dingen die beter kunnen. Zodra alles op print is en de led balken klaar zijn zal ik filmpjes/foto's maken
Ik zit ook nog te denken om er een USB aansluiting op te maken, com-poort is een beetje onhandig.

Ik kan het nog goedkoper maken, ik heb een winkel gevonden die voor 3 euro de microcontroller (Atmega 8515) verkoopt en waar de MAX232 maar 1,50 kost.
Op ebay staan de ledjes á 50 stuks nu voor 10 dollar, hier komt nog 15 dollar verzendkosten bij, dus dat kost nu €16.95, maar ik gebruik er maar 18, dus €6,-

Totaal exclusief printje en ander grut €10,50

Ik ben erg benieuwd waar je die goedkope microller enzo hebt gekocht.
Heb jij zo een layout van het printje wat je hebt gemaakt? heb je een atmolight gemaakt?
Ik heb zowat alle posts in deze thread gelezen maar niet veel kunnen vinden...

[Milmoor]

Ik wil graag ambilight bij mijn PC. Na wat zoekwerk een kort samenvatting van mijn bevindingen:
Zoals eerder vermeldt biedt de Elektor een analoog en een digitaal schema om er zelf een in elkaar te zetten. Je kan het nummer kopen waar beide versies in staan voor 6 euro 95, of de pdf's kopen voor 1 euro 20 per stuk. In Maart kan je de analoge versie semi-compleet kopen voor 169 euro.
Philips biedt Ambilight voor PC's plus nog wat gadgets. Ik ga de lampenset daarvan proberen uit te breiden zodat ik meer licht rondom mijn beeld heb. Dat lijkt me een stuk makkelijker te regelen dan de hele electronica qua aansturing en software zelf te moeten bouwen/programmeren/uitzoeken, en vergeleken de kant en klare versie van de Elektor is het financiele plaatje interessant. De Starters Kit heeft alleen de lampen en heb ik vanaf 114 euro gevonden, de Premiumkit met echt alles erin vanaf 199 euro. Daarom heb ik net de Premium Kit besteld (waar ik de 2.1 speakerset niet van ga gebruiken, ik heb al 5.1)

[ Voor 7% gewijzigd door Milmoor op 23-02-2008 21:37 . Reden: Iets leesbaarder gemaakt qua volgorde ]

[bobo1on1]

Ik heb het protocol van Sprite_tm in een 18F4550 gebouwd met wat aanpassingen zodat je de lampen ook aan kunt hebben zonder pc.


• toch 0x55 0xAA als prefix
• commando 131 om de aansturing te openen
• commando 132 om de aansturing te sluiten, de lamp pakt dan de rgb waarden die in de eeprom opgeslagen zijn
• commando 129 om de huidige rgb waarden uit te lezen
• commando 130 om de huidige rgb waarden naar de eeprom te schrijven


Nu moet er alleen nog een naam worden verzonnen voor het nieuwe protocol.

[ Voor 7% gewijzigd door bobo1on1 op 26-02-2008 19:48 ]

[etimm]

bobo1on1 schreef op dinsdag 26 februari 2008 @ 19:45:
Ik heb het protocol van Sprite_tm in een 18F4550 gebouwd met wat aanpassingen zodat je de lampen ook aan kunt hebben zonder pc.


• toch 0x55 0xAA als prefix
• commando 131 om de aansturing te openen
• commando 132 om de aansturing te sluiten, de lamp pakt dan de rgb waarden die in de eeprom opgeslagen zijn
• commando 129 om de huidige rgb waarden uit te lezen
• commando 130 om de huidige rgb waarden naar de eeprom te schrijven


Nu moet er alleen nog een naam worden verzonnen voor het nieuwe protocol.

Zonder pc

met "surround" ambilight?

[MikeyMan]

Klinkt erg interessant...

[bobo1on1]

etimm schreef op woensdag 27 februari 2008 @ 15:03:
[...]


Zonder pc

met "surround" ambilight?

Zonder pc hebben de lampen gewoon een vaste kleur, eventueel instelbaar met knopjes.

[MikeVM]

het zou handig zijn moest iemand een nieuw topicje openen met alle info mooi in de topicstart. want zo kan ik er helemaal niet uit.

wie brengt me up to speed.

wat is het beste momo of bobo.
en welke artikels kan ik best eens lezen, tutorials printjes..
welke microcontrollers zijn allemaal bruikbaar.?


"ben junior progammer en zou het project willen doen om beter de kunnen programeren en ambilight zelf"

[bobo1on1]

Ik heb het nieuwe protocol LTBL genoemd, van Let There Be Light.

Wie heeft er zin om een controller te ontwerpen met dit protocol?

De eisen zijn:


• Minimaal 12 kanalen
• Kan aangestuurd worden met een frequentie van minimaal 50 hertz
• Pwm resolutie zo hoog mogelijk
• Moet makkelijk te bouwen zijn, dus geen smd of moeilijk verkrijgbare componenten
• Kleur instelbaar met knopjes als de lampen niet extern aangestuurd worden


Als er geen animo is zal ik het zelf moeten doen maar ik geloof dat er mensen zijn die het een stuk mooier kunnen dan ik.

Het protocol op een rijtje van hoe ik het heb geimplementeerd:

Kanaaldata:
Byte 0-1: 0x55 0xAA : Synchronisatie-bytes, pakketjes beginnen altijd hiermee.
Byte 2: Startkanaal, 0>kanaal>127. Hierna aan te duiden met K
Byte 3: Hoeveelheid kanalen aan data volgen. Minimaal 1.
Byte 4: Intensiteit kanaal K, MSB
Byte 5: Intensiteit kanaal K, LSB
Byte 6: Intensiteit kanaal K+1, MSB
Byte 7: Intensiteit kanaal K+1, LSB
(etc)

Commando's:
Byte 0-1: 0x55 0xAA : Synchronisatie-bytes, pakketjes beginnen altijd hiermee.
Byte 2: Commando, 127>commando>255. Hierna aan te duiden met C
Byte 3: Hoeveelheid bytes aan data in het commando volgen. Kan 0 zijn.
Byte 4-...: commando-data

Commando's:
127: request number of channels. Apparaat geeft hoeveelheid kanalen terug, als 1 byte.
128: request channel configuration: 1 databyte die het kanaal aangeeft. Response:
byte 1,2,3: RGB-waarde van de kleur van het kanaal. Indien alleen RGB in het aansturende programma is geimplementeerd pakt deze als 'kleur' van het licht de hoogste waarde: RGB 255,128,0 word dan aangestuurd als een rode lamp.
Byte 4: Pool-ID. Kanalen die in dezelfde lichtbron zitten (e.g. rgb-strip) hebben hetzelfde pool-ID.
129: Request current values. Computer stuurt startkanaal en hoeveel kanalen, apparaat geeft startkanaal en hoeveel kanalen terug, daarachter 2 bytes voor elk kanaal.
130: Write current values to eeprom. Computer stuurt startkanaal en hoeveel kanalen, apparaat schrijft de huidige waarden van de kanalen naar de eeprom, het apparaat wacht dan ongeveer 250 ms om de eeprom te beschermen, de computer zal 500 ms wachten.
131: Open light. Dit opent de aansturing via de computer, het apparaat is niet meer aanstuurbaar met knopjes, de lampen blijven wel op dezelfde waarden staan.
132: Close light. Dit sluit de aansturing via de computer, het apparaat zal de waarden uit de eeprom lezen en is nu weer aanstuurbaar met knopjes.
133-191: reserved for future use
192-255: Vendor-specific. Als je hardware speciale functies heeft (om mijn unit als voorbeeld te pakken: het aanmelden van extra ambilights) kan je die hier implementeren. Niet gestandaardiseerd.

[MikeVM]

ik wil gerust helpen, ik ben student professionele bachelor, ik hoop men bijdrage te leveren..

laten we een nieuw topicje te openen met alle info die we nu hebben erin, en de eisen van het nieuwe project?

[MikeVM]

Kleur instelbaar met knopjes als de lampen niet extern aangestuurd wordendit kan je doen met een Potentio meter aansluiten op een AD
hiermee kan je met een AD van 10bits tot 1024 kanalen selecteren..

Pwm resolutie zo hoog mogelijk
bedoel je niet de frequentie...
resolutie zal je meer contrast geven..
frequentie zorgt voor minder flikkering.


Minimaal 12 kanalen
mag geen probleem zijn

Moet makkelijk te bouwen zijn, dus geen smd of moeilijk verkrijgbare componenten
als er genoeg animo is, kan ik een pcb ontwerpen, deze dan ergens laten maken of door een medetweaker, en die opsturen.. dan hoef je alleen nog maar solderen en klaar is kees,
ook zou je tegen een prijsje gesoldeerde ontwerpen kunnen laten maken door mij bv
voor 5 euro wilk ik best een printje solderen hoor...


Vragen:
vraag1Moet het een pic zijn, of mag het ook met een avr controller.?
Met een avr, heb je Timers die speciaal gemaakt zijn om PWM uit te sturen.. dit vraagt geen/weinig rekenkracht van de cpu

vraag2: ook denk ik dat je protocol beter kan.. je kan sync byte sturen. daarnaa gewoon 12bytes en een 13de crc byte ofzo
(hierdoor zal je minder verkeer hebben)

hierna laat je de controller zelf zien wat voor info er door gestuurd is..

vraag 2:wanneer zou je het project af willen hebben...

vraag3: zouden we geen USB product maken

[ Voor 5% gewijzigd door MikeVM op 02-03-2008 00:27 ]

[bobo1on1]

MikeVM schreef op zaterdag 01 maart 2008 @ 23:25:
Kleur instelbaar met knopjes als de lampen niet extern aangestuurd wordendit kan je doen met een Potentio meter aansluiten op een AD
hiermee kan je met een AD van 10bits tot 1024 kanalen selecteren..

Ik zat te denken aan een rotary encoder, maar alles is mogelijk.

Pwm resolutie zo hoog mogelijk
bedoel je niet de frequentie...
resolutie zal je meer contrast geven..
frequentie zorgt voor minder flikkering.

In het protocol worden 2 bytes gebruikt per kanaal maar de pic18f4550 die ik gebruikte was maar snel genoeg voor 10 bits pwm, nou heb ik het in C geprogrammeerd en misschien dat het effcienter kan in asm.

Vragen:
vraag1Moet het een pic zijn, of mag het ook met een avr controller.?

Zolang het goed verkrijgbaar is maakt het mij niet uit

vraag2: ook denk ik dat je protocol beter kan.. je kan sync byte sturen. daarnaa gewoon 12bytes en een 13de crc byte ofzo
(hierdoor zal je minder verkeer hebben)

Het protocol is zo ontworpen dat een controller met een willekeurig aantal kanalen aangestuurd kan worden, de hoeveelheid data maakt eigenlijk niets uit, rs232 is snel genoeg.

vraag 2:wanneer zou je het project af willen hebben...

Het is maar voor de hobby dus dat maakt mij niet uit.

vraag3: zouden we geen USB product maken

Als dat makkelijk te doen is, waarom niet? Wat wel belangrijk is is dat het apparaat gezien wordt als usb>rs232 converter, zo hoef je niet voor elk OS een driver te schrijven.

Wat ik ook graag zou willen is dat de broncode van de software voor de microcontroller beschikbaar wordt maar dat is geen eis.

[Seesar]

en je blijft dus bouwen op software die dus op de achtergrond moet draaien? Met als gevolg incompabiliteit met de minder voorkomende os-en en eventuele bugs?

ALs je toch van scratch af aan begint, probeer het toegankelijk te maken door het aan te sluiten op een splitbox (vga/dvi) of een extended port van je laptop/pc. Daarnaast kamp je dan niet met maximale doorvoersnelheden van je RS232 (die destijds te traag was voor mijn DIY).

Overigens is het wel makkelijker en goedkoper omdat je geen hardware hoeft te kopen om de analyse op je DVI/VGA poort uit te voeren.

[LauPro]

Ik heb nog even een verzoekje om alvast rekening mee te houden, ik ben bezig met het implementeren van andere systemen die ook met dit soort dimmers werken en heb deze opmerkingen:

• Toevoegen van 'fade-to' commando. Als er gebruikt wordt gemaakt van sliders via een GUI om bijvoorbeeld het licht te dimmen en/of van kleurstelling te wijzigen en je gaat dit op 10bits (1024 waarden) doen dan genereert dit nogal wat verkeer. Natuurlijk kan je dit ook in een lagere resolutie doen maar dan zal het licht in schokjes aan gaan. Tevens als je bijvoorbeeld de lichten aan wil laten faden dan is het onzinnig om dit vanaf de PC helemaal te regelen (je zal de gehele periode berichten moeten sturen), het zou mooier zijn als je een commando kan sturen als:

code:

133: Fade in, parameter 1: value, parameter 2: time in ms, parameter 3: curve coëfficiënt
134: Fade out, parameter 1: value, parameter 2: time in ms, parameter 3: curve coëfficiënt

Op het moment dat de gebruiker dan de lamp aan wil hebben, kan de software een fade instarten, deze moeten natuurlijk worden onderbroken zodra er een ander commando binnen komt.

Met dit commando kan je dus zeggen: "kanaal x moet in 0,5 seconden 100% aan zijn."

De coëfficiënt moet je zien als een afwijking in de 'dimlijn', hiermee kan je bijvoorbeeld een lamp rustiger op laten komen of wat feller, ik zal nog proberen om dit met wat grafiekjes en voorbeeldformules toe te lichten.

• Zorg ervoor dat de events van knopjes ook kunnen worden doorgegeven aan de PC, hiermee zou een softwarepakket de controle van deze knopjes over kunnen nemen en kan je zelf ingestelde acties uitvoeren.

[MikeVM]

Ik zat te denken aan een rotary encoder, maar alles is mogelijk.
[i]ja, je kent er blijkbaar ook veel vanaf...
maar misschien is een potmetertje veel goedkoper, en het is nauwkeurig genoeg denk ik.[/i][...]

In het protocol worden 2 bytes gebruikt per kanaal maar de pic18f4550 die ik gebruikte was maar snel genoeg voor 10 bits pwm, nou heb ik het in C geprogrammeerd en misschien dat het effcienter kan in asm.
ik kan ook alleen maar in C programmeren..

[...]


Zolang het goed verkrijgbaar is maakt het mij niet uit
uiteraard

[...]


Het protocol is zo ontworpen dat een controller met een willekeurig aantal kanalen aangestuurd kan worden, de hoeveelheid data maakt eigenlijk niets uit, rs232 is snel genoeg.
okido

[...]

Het is maar voor de hobby dus dat maakt mij niet uit.


[...]

Als dat makkelijk te doen is, waarom niet? Wat wel belangrijk is is dat het apparaat gezien wordt als usb>rs232 converter, zo hoef je niet voor elk OS een driver te schrijven.
tegen een kleine kostprijs zou dit te doen moeten zijn.. een kleine chip die dit doet in plaats van een MAX232

Wat ik ook graag zou willen is dat de broncode van de software voor de microcontroller beschikbaar wordt maar dat is geen eis.
als ik hem maak, is hij open source

__________________________________________________________________

Seesar schreef op zondag 02 maart 2008 @ 04:39:
en je blijft dus bouwen op software die dus op de achtergrond moet draaien? Met als gevolg incompabiliteit met de minder voorkomende os-en en eventuele bugs?

ALs je toch van scratch af aan begint, probeer het toegankelijk te maken door het aan te sluiten op een splitbox (vga/dvi) of een extended port van je laptop/pc. Daarnaast kamp je dan niet met maximale doorvoersnelheden van je RS232 (die destijds te traag was voor mijn DIY).

Overigens is het wel makkelijker en goedkoper omdat je geen hardware hoeft te kopen om de analyse op je DVI/VGA poort uit te voeren.

ja, maar dan moeten we het protocol van DVI volledig ontleden.. (het zou zonde zijn, nu nog met VGA te beginnen.. als je DVI neemt, zou je het op een TV(HDTV) kunnen hangen...

ik zal morgens eens kijken of dit haalbaar is voor mij..
______________________________________________________________

hoeveel animo is er. want ik denk dat het beter is als we de printjes samen aankopen en laten etsen, zo is je printje kleiner, beter, en makkelijker te solderen.. ook kan er wat van de prijs van componenten als je samen koopt.

nog maals de vraag.. is het niet beter als we een nieuw topicje openden om de animo te controleren..

[ Voor 38% gewijzigd door MikeVM op 02-03-2008 13:09 ]

[naftebakje]

Ik weet niet hoe het zit met verkrijgbaarheid, en in hoeverre iedereen SMD kan/wil solderen, maar met een DVI receiver en transmitter aan elkaar geknoopt zou het relatief eenvoudig moeten zijn om het beeld in te lezen.
Tussen beiden heb je dan 2*8 bits (even en oneven) data voor elke kleur, horizontale en verticale sync, en klok. Met een µC kan je dan de digitale kleurwaarde gemakkelijk uitlezen, en je hebt "geen kennis" van DVI nodig (knoop een SiI1161 aan een SiI1160, geef ze allebei 3.3V voeding, en je kan die zo tussen een DVI verbinding plaatsen zonder invloed op het beeld).

[Verwijderd]

Animo.. wat gaat het dan exact worden? een momolicht welke op de vga poort werkt? of weer een software gedreven ambilight?

[bobo1on1]

Seesar schreef op zondag 02 maart 2008 @ 04:39:
en je blijft dus bouwen op software die dus op de achtergrond moet draaien? Met als gevolg incompabiliteit met de minder voorkomende os-en en eventuele bugs?

ALs je toch van scratch af aan begint, probeer het toegankelijk te maken door het aan te sluiten op een splitbox (vga/dvi) of een extended port van je laptop/pc. Daarnaast kamp je dan niet met maximale doorvoersnelheden van je RS232 (die destijds te traag was voor mijn DIY).

Overigens is het wel makkelijker en goedkoper omdat je geen hardware hoeft te kopen om de analyse op je DVI/VGA poort uit te voeren.

Ik heb al software geschreven voor windows en linux, met wat kleine aanpassingen kun je die software ook draaien op osx en bsd, eventuele bugs kun je gewoon verhelpen.

Als je het volledige in hardware wilt doen krijg je weer het probleem dat je een stuk of 5 standaarden moet gaan ondersteunen, dat is ook niet handig.

LauPro schreef op zondag 02 maart 2008 @ 06:18:
Ik heb nog even een verzoekje om alvast rekening mee te houden, ik ben bezig met het implementeren van andere systemen die ook met dit soort dimmers werken en heb deze opmerkingen:

• Toevoegen van 'fade-to' commando. Als er gebruikt wordt gemaakt van sliders via een GUI om bijvoorbeeld het licht te dimmen en/of van kleurstelling te wijzigen en je gaat dit op 10bits (1024 waarden) doen dan genereert dit nogal wat verkeer. Natuurlijk kan je dit ook in een lagere resolutie doen maar dan zal het licht in schokjes aan gaan. Tevens als je bijvoorbeeld de lichten aan wil laten faden dan is het onzinnig om dit vanaf de PC helemaal te regelen (je zal de gehele periode berichten moeten sturen), het zou mooier zijn als je een commando kan sturen als:

code:

133: Fade in, parameter 1: value, parameter 2: time in ms, parameter 3: curve coëfficiënt
134: Fade out, parameter 1: value, parameter 2: time in ms, parameter 3: curve coëfficiënt

Op het moment dat de gebruiker dan de lamp aan wil hebben, kan de software een fade instarten, deze moeten natuurlijk worden onderbroken zodra er een ander commando binnen komt.

Met dit commando kan je dus zeggen: "kanaal x moet in 0,5 seconden 100% aan zijn."

De coëfficiënt moet je zien als een afwijking in de 'dimlijn', hiermee kan je bijvoorbeeld een lamp rustiger op laten komen of wat feller, ik zal nog proberen om dit met wat grafiekjes en voorbeeldformules toe te lichten.

• Zorg ervoor dat de events van knopjes ook kunnen worden doorgegeven aan de PC, hiermee zou een softwarepakket de controle van deze knopjes over kunnen nemen en kan je zelf ingestelde acties uitvoeren.

Als je de lampen als ambilight gebruikt dan krijg je evenveel verkeer, de boel is daar op ontworpen dus dat maakt weinig uit.

[Verwijderd]

Zoals ik het nu begrijp word het dus een soort geavanceerdere versie van het bestaande ambi licht project en ook weer software gedreven waar natuurlijk niets mis mee is, however er valt nog genoeg te verbeteren aan het bestaande project, aero support in vista, direct x support etc. Ik bedoel loop je zometeen niet tegen exact de zelfde beperkingen aan?

[DJF5]

*blijft dromen over een ambilight laptop-mod :D*

(heeft ook wel een leuk effect... in de trein een film kijken en je film ervaring word er beter op omdat je medepassagiers opgloeien in de kleuren van je film )

[LauPro]

bobo1on1 schreef op zondag 02 maart 2008 @ 16:40:
Als je de lampen als ambilight gebruikt dan krijg je evenveel verkeer, de boel is daar op ontworpen dus dat maakt weinig uit.

Klopt, maar op het moment dat je het als sfeerverlichting wil gebruiken lijkt het me toch handiger om ipv 'dure' CPU-tijd op je PC de 'goedkope' CPU-tijd op de microcontroller te gebruiken.

[bobo1on1]

Op een amd X2 4000+ valt het cpu gebruik niet eens te meten zo laag is het, dan heb je het over 9 kanalen op 50 fps met aardig wat floating point berekeningen.

Punt blijft dat het moelijk is op een redelijke snelheid gamma correctie te doen in een microcontroller.

[LauPro]

Het kan best zijn dat je die sfeerverlichting vanuit een embedded systeempje aan wil sturen die maar 200 Mhz heeft, dan praat je al over andere ratio's.

Ik ben het met je eens dat het op een PC niet uit maakt, daar het vertonen van de film zelf per definitie al meer CPU-tijd kost.

Natuurlijk is het lastig, maar zie het als een uitdaging . Plus er zijn microcontrollers die hier speciale instructies voor hebben, iig ik heb niet alle details maar lijkt me zeker niet onmogelijk.

[MikeVM]

ja, maar die wattage voor je lampen schud je echt niet uit een batterij hoor.. 1 laptop batterij zou dan geen halfuur uithouden hoor...

_________________________________________________________________________

naftebakje schreef op zondag 02 maart 2008 @ 14:27:
Ik weet niet hoe het zit met verkrijgbaarheid, en in hoeverre iedereen SMD kan/wil solderen, maar met een DVI receiver en transmitter aan elkaar geknoopt zou het relatief eenvoudig moeten zijn om het beeld in te lezen.
Tussen beiden heb je dan 2*8 bits (even en oneven) data voor elke kleur, horizontale en verticale sync, en klok. Met een µC kan je dan de digitale kleurwaarde gemakkelijk uitlezen, en je hebt "geen kennis" van DVI nodig (knoop een SiI1161 aan een SiI1160, geef ze allebei 3.3V voeding, en je kan die zo tussen een DVI verbinding plaatsen zonder invloed op het beeld).

als ik het zo hoor zou dat wel schitterend zijn.. en eens ik met het project begin stop ik toch niet..
maar ik heb geen zin om met VGA te beginnen..

maar SMD is vrij makkelijk te solderen hoor, je moet er geen schrik van hebben, je moet alleen een deftige soldeerbout hebben (40-80 euro), dun soldeer tin (kzal de maat wel opzoeken die je nodig hebt) en een desoldereer pompje of van dat litzedraad voor de overtollige tin te verwijderen..

verder zie ik nog altijd wel iets in een voorgebouwd printplaatje maken.. en deze versturen over heel nederland.

ik ga nu een topicje openen met een Question..
AMBILIGHT.
Software of hardware
voor gemaakt of zelf solderen.
DVI en of VGA
HDMI ontleding voor TV (zal wel 100% hetzelfde zijn als DVI) al weet ik dit niet zeker...

__________________________________________________________________________

Milmoor schreef op zaterdag 23 februari 2008 @ 21:33:
Ik wil graag ambilight bij mijn PC. Na wat zoekwerk een kort samenvatting van mijn bevindingen:
Zoals eerder vermeldt biedt de Elektor een analoog en een digitaal schema om er zelf een in elkaar te zetten. Je kan het nummer kopen waar beide versies in staan voor 6 euro 95, of de pdf's kopen voor 1 euro 20 per stuk. In Maart kan je de analoge versie semi-compleet kopen voor 169 euro.
Philips biedt Ambilight voor PC's plus nog wat gadgets. Ik ga de lampenset daarvan proberen uit te breiden zodat ik meer licht rondom mijn beeld heb. Dat lijkt me een stuk makkelijker te regelen dan de hele electronica qua aansturing en software zelf te moeten bouwen/programmeren/uitzoeken, en vergeleken de kant en klare versie van de Elektor is het financiele plaatje interessant. De Starters Kit heeft alleen de lampen en heb ik vanaf 114 euro gevonden, de Premiumkit met echt alles erin vanaf 199 euro. Daarom heb ik net de Premium Kit besteld (waar ik de 2.1 speakerset niet van ga gebruiken, ik heb al 5.1)

heeft iemand dit al nader bekeken, en is dit een oplossing,
wat kan dit, en wat kan dit niet.

[ Voor 118% gewijzigd door MikeVM op 02-03-2008 23:56 ]

[MikeVM]

Hier een nieuw Topicje voor de geïntereseerden in een nieuwe Ambilight..
en het oude topic hoeft voor mijn part niet dicht hoor

Let There Be Light

oh, bobo, ik heb even je naampie gestolen, laat me weten als je wil dat ik verander..

[Seesar]

kort maar krachtig; vga zuigt. Ik heb mijn ambi destijds gemaakt en je adc zijn gewoon de grootste bottleneck in kwaliteit en snelheid tesamen met betrouwbaarheid en behoud van signaal (zonde rdure duplicator).

Ik heb nog geen tijd gehad om DVI uit te pluizen, maar ik durf te stellen dat 95% van de tweakers die bereid is DIY ambi te nemen ook DVI hebben; drop je vga; tis oud en gedateerd, elke vga kaart heeft DVI en zeker als je behoud/opsplitten van 1 uitgang kan gebruiken dan zou ik hardware matig prefereren boven software.

Ik wil best helpen als ik terugben hardwarematig; ben net afgestudeerd elektrotechniek en heb zoals gezegd al via VGA ambilight gemaakt (4 zijden onafhankelijk, met verschillende modi; zoals gemiddelde kleur; afgebakend gesamplede kleur), alleen de mC was te traag voor echt mooie resultaten op hogere res.

Ik zou mijn geld 100% op dvi inzetten