DIY Ambilight howto?

Moet volgens mij prima kunnen. Snel zat ook, sneller waarschijnlijk dan je met de meeste PICs kunt lezen. En snelle ADCs kosten nou eenmaal veel geld, 40MHz is niet niks.

Ik heb er trouwens wat onderdelen bij, zoals de eerder genoemde THS10064 ADC, een tripple video buffer (LMH6739) en een YPbPr -> RGBHV converter / 2:1 video switch (LMH1251). En natuurlijk de nodige AVRs. Heb voorlopig alleen andere dingen te doen dus zal wel even duren voordat ik er mee kan werken maar de spullen voor een prototype zijn er in ieder geval.

[ Voor 78% gewijzigd door madwizard op 07-03-2006 00:01 ]

Er werd gevraagd of we Ambilight 2 gaan verslaan. Ik zou zeggen van wel. Het kost mischien meer, maar om hoeveel meer praten we hier dan?

Of het beter wordt weet ik niet, die TVs hebben natuurlijk het voordeel dat ze alles digitaal kunnen verwerken, wij zullen het moeten doen met simpelere spullen. Goedkoper denk ik wel, maar hoe vergelijk je dat? Want je kan niet ambilight los kopen ofzoiets. Ik schat dat je met 50 euro voor een zelfbouw iets wel een eind komt, hangt ook een beetje af van de LEDs (of buizen) die je gebruikt.

Ik vraag me alleen af of de twee verschillende kleuren van ambilight 2 een verbetering zijn. Als ik zo naar het bovenste plaatje daar kijk lijkt het me persoonlijk eerder storend. Een kleur lijkt me rustiger, maar goed ik heb het niet werkend gezien. En om te maken moet het niet veel moeilijker zijn dan met 1 lamp.

madwizard schreef op dinsdag 07 maart 2006 @ 10:33:
Of het beter wordt weet ik niet, die TVs hebben natuurlijk het voordeel dat ze alles digitaal kunnen verwerken, wij zullen het moeten doen met simpelere spullen. Goedkoper denk ik wel, maar hoe vergelijk je dat? Want je kan niet ambilight los kopen ofzoiets. Ik schat dat je met 50 euro voor een zelfbouw iets wel een eind komt, hangt ook een beetje af van de LEDs (of buizen) die je gebruikt.

Vergelijk een Ambilight plasma met een plasma met dezelfde specs, zonder ambilight. Natuurlijk vragen ze voor deze optie Xmaal meer dan bouwprijs, en daarnaast nog een leuk bedrag daarop omdat het zo'n unieke gadget is...

Ik vraag me alleen af of de twee verschillende kleuren van ambilight 2 een verbetering zijn. Als ik zo naar het bovenste plaatje daar kijk lijkt het me persoonlijk eerder storend. Een kleur lijkt me rustiger, maar goed ik heb het niet werkend gezien. En om te maken moet het niet veel moeilijker zijn dan met 1 lamp.

Daarnaast kan het ook mogelijk zijn dat er dan 2 kleuren worden gegenereerd die verschrikkelijk met elkaar lopen te vloeken denk k.

Zullen we dan met z'n allen voor ambilight 1 gaan?

eXistenZ_NL schreef op dinsdag 07 maart 2006 @ 23:50:
Zullen we dan met z'n allen voor ambilight 1 gaan?

Dat lijkt me zowiezo een eerste stap, eenmaal dat werkt is Ambilight 2 puur een software issue.

Inderdaad, ik heb wat verder geexperimenteerd met software (op de PC nog dan) en heb al een redelijk idee voor de hardware, maar zoals gezegd zal het nog even moeten wachten.

Ik heb zelf de Philips 42PF9966/10, een 42" plasma scherm met Ambilight. Een aantal dingen vallen me op:

- Hoe dichter een minderheidskleur bij de rand is, hoe meer voorrang deze krijgt op de "algemene" kleur. Dit lijkt op het oog een linear verloop te hebben. Bijvoorbeeld een grote gele bal op een blauwe achtergrond zal (met de bal gecentreerd) een blauwe gloed geven. Zodra de bal richting de zijkant verplaatst zal de intensiteit steeds meer geel worden. De maximale factor waarop de zijkanten invloed hebben op de kleur schat ik op zo'n 75%, d.w.z. de dominerende kleur zal nooit voor 100% overruled worden door een vlak met een afwijkende kleur aan de zijkant.

- Sommige combinatiekleuren mengen veel minder sterk naar een mengkleur dan andere combinaties. Het lijkt erop alsof bij sommige kleurcombinaties een bepaalde kleur voorrang krijgt. Wellicht heeft dit met het algoritme te maken en met complementerende of aanhangende kleuren. Het lijkt erop alsof het algoritme de "vloekende" kleuren eruit probeert te filteren

- Er is geen linear verloop en/of relatie van "algemene" helderheid en ambilight helderheid. Het ene donkere beeld geeft een grotere ambilight intensiteit dan de andere (bij dezelfde ambilight instelling). Dit heeft waarschijnlijk te maken met de beelden direct voorafgaand aan de donkere scene.

- Vlakken met een grote kleurscheiding krijgen voorrang boven vakken met een kleine kleurscheiding. (Veel/weinig onderscheid tussen de onderliggende R-G-B waarden). Als het hele scherm grijs is met een klein blauw vlakje, dan zal ambilight dermate veel blauw produceren dat ik niet de indruk heb dat het een gemiddelde is van alle kleuren van het scherm, maar dat het kleine blauwe vlakje voorrang krijgt op het massale grijze vlak.

Over de lampen zelf, deze zitten achter een plastic melktransparante kap die geribbeld is en een licht bochtje maakt. Het doet me een heel klein beetje denken aan een sterk uitvergroot verticale fresnel lens. Dit hebben ze vast gedaan om het TL licht zo optimaal mogelijk te projecteren op de achterwand. De beste positie is trouwens ook 10-12 cm van de muur volgens de handleiding.

Al met al denk ik dat het algoritme dermate moeilijk is dat dit met analoge techniek (bijna) niet op te lossen is. Natuurlijk kun je gaan voor een simpelere oplossing, maar het effectieve effect zal hoogstwaarschijnlijk minder zijn.

Ik wil de eerste filmpjes wel eens zien van de zelfbouw ambilight van de doorgewinterde tweaker in dit topic

DexterDee schreef op woensdag 08 maart 2006 @ 16:52:
....

Al met al denk ik dat het algoritme dermate moeilijk is dat dit met analoge techniek (bijna) niet op te lossen is. Natuurlijk kun je gaan voor een simpelere oplossing, maar het effectieve effect zal hoogstwaarschijnlijk minder zijn.

Ik wil de eerste filmpjes wel eens zien van de zelfbouw ambilight van de doorgewinterde tweaker in dit topic

Het algoritme zal digitaal uitgevoerd worden (met een microcontroller), dus we kunnen wel zo'n filtering maken (gezien de verlopen relatief traag zijn, mogen het gerust relatief zware berekeningen zijn). En bedankt voor de info over specifieke gevallen, erg interessant.

Ja analoog had ik meteen al opgegeven. Digitaal zal evengoed wel z'n beperkingen hebben vanwege de hoge snelheid van videobeelden, maar 64 gemiddelden uit elk frame halen moet naar mijn idee lukken, het algoritme wilde ik eigenlijk ook in 1 frame doen, misschien 2. Wel handig inderdaad om te weten hoe ambilight er mee om gaat, al is het soms ook goed gewoon zelf een beetje te proberen omdat dat vaak makkelijker is dan een bestaand iets namaken (ookal gaat het hele topic juist daarover ).

Die trage verlopen, is dat in het echt ook zo dat het ambilight duidelijk een vertraging (~1 seconde) heeft ten opzichte van het beeld? Natuurlijk wel makkelijk om beter de kleur te bepalen maar het lijkt mij irritant dat het licht steeds net even te laat is.

madwizard schreef op woensdag 08 maart 2006 @ 19:59:...Die trage verlopen, is dat in het echt ook zo dat het ambilight duidelijk een vertraging (~1 seconde) heeft ten opzichte van het beeld? Natuurlijk wel makkelijk om beter de kleur te bepalen maar het lijkt mij irritant dat het licht steeds net even te laat is.

Ik kan met 100% zekerheid bevestigen dat er geen vertraging optreedt bij de reactiesnelheid van ambilight t.o.v. het beeld. De vertraging zit al in de voorbewerking op het beeld, die is zo ongeveer 1 seconde ten opzichte van een analoge TV. De ambilight reageert instant of vrijwel instant (vertraging niet merkbaar) op wijzigingen in het beeld. Het lijkt ook wel alsof het algoritme zo is ingesteld dat de kleurenfade veel sneller gaat als het beeld plosteling van overwegend blauw (bijv. onderwater) naar groen (bijv. voetbalwedstrijd) switcht. Overgangen waarbij het beeld gradueel verandert gaan merkbaar langzamer. Het ligt ook natuurlijk aan de instelling van Ambilight.

Aha dat is handig om te weten. Het algoritme wat ik nu heb werkt ook direct, maar dat betekent ook dat je de kleur alleen aan de hand van het huidige beeld en vorige beelden kunt bepalen. Je hebt niet de luxe het beeld een seconde te cachen zoals de philips TV. Overspringen bij verschillende kleuren is ook vrij eenvoudig, ik had al een simpele sceneverandering-detectie zodat de kleur direct overspringt bij veel verandering. Flitsen en dergelijk werken ook zonder problemen.

Het originele idee van dit topic is veel te moeilijk voor mij.
Daarom ben ik soortgelijk projectje begonnen, volledig in software.

Ik ben begonnen met een directshow filter te schrijven die de gemiddelde RGB waarden berekent.
Deze RGB waarden worden via de seriële poort naar een microprocessor gestuurd die op zijn beurt het PWM sturen van rode, groene en blauwe LED voor zijn rekening neemt.
Voorlopig is het het zuiver rekenkundig gemiddelde. Ik weet wel dat ik er beter een algoritme achtersteek, maar het gaat hier voorlopig om een prototype.
Mijn bedoleing is om dit eerst uit te breiden naar 3 kleuren (links, rechts en boven).
Ik neem aan dat dan het algoritme minder belangrijk wordt.

Het prototype in werking ziet eruit als volgt :

(het vierkant linksonder geeft de gemiddelde kleur weer. Ik gebruik 3 afzonderlijke LEDS voor rood, groen en blauw. Ik geef toe dat ze nog wat beter op mekaar moeten afgesteld worden).

Je kan het prototype ook in werking zien in volgende filmpjes, maar deze zijn van zeer slechte kwaliteit (ze zijn gemaakt met een digitaal fototoestel). Op de achtergrond is er een irritant geluid dus zorg ervoor dat je geluid niet te hard staat

Een RGB kleurentest (1,3Mb) :
http://users.skynet.be/Ra.../MoMoLight/colourtest.mpg

Een film intro (5Mb) :
http://users.skynet.be/RafkeP/tutorials/MoMoLight/movie.mpg

Rafke P.

Heel gaaf Ik zal deze thread eens aan mijn huisgenoot pasen, die heeft deze week toch niets te doen Wordt de source van je directshow filter ook beschikbaar?

[ Voor 22% gewijzigd door BCC op 09-03-2006 21:31 ]

Je kan toch ook heel simpel een tweede monitor aansluiten (oude CRT 19" bak) en deze softwarematig aansturen? Of is lichtopbrengst van zo'n monitor te laag? (splitter -> 2 19" bakken )

[ Voor 14% gewijzigd door BCC op 10-03-2006 09:22 ]

BCC schreef op vrijdag 10 maart 2006 @ 09:22:
Je kan toch ook heel simpel een tweede monitor aansluiten (oude CRT 19" bak) en deze softwarematig aansturen? Of is lichtopbrengst van zo'n monitor te laag? (splitter -> 2 19" bakken )

Dat lijkt me een vrij dure en lompe manier om een RGB gloed ergens te projecteren . En die 19" schermen zijn zo lastig weg te werken achter een platte monitor/TV

@RafkeP, Zou je misschien de source en het schema online kunnen zetten zodat we hiermee verder kunnen klussen, ik heb namelijk wel intresse in computer gestuurd systeem.

Zou het ook mogelijk zijn om de gemiddelde kleur van de buitenste randen te berekenen?

madwizard schreef op donderdag 09 maart 2006 @ 21:43:
Uhm ligt het aan mij of is er iets gigantisch mis met skynet.be?
....
en hij is weer stuk...

HAHAHA, lol... vooral die vent met die baard

@ BCC & Mr GAmba : of ik de source beschikbaar ga stellen weet ik nog niet: ik ben namelijk niet zo trots op de troep die ik bij mekaar heb gecodeerd en ik heb zoveel SDKs en dergelijke geïnstalleerd dat ik er zelf niet meer wijs uit geraak hoe ik de filter op een andere PC kan compileren

Zodra ik een iet of wat deftige setup bij mekaar heb, zorg ik er zeker voor dat op zijn minst de binaries online komen met een mooie how-to.
Ik hoop tegen het einde van volgende week de "3-weg" versie in orde te hebben.
Verder wacht ik nog op RGB leds (waarvan ik hoop dat ze beter mengen).

Aangezien het de eerste keer is dat ik met een PIC werk, ben ik vertrokken van William's Site (URL terug te vinden in het moodlight topic van Ferry). Mijn schema is bijgevolg ook identiek aan dat van de RGB led van William. Die site is trouwens een must voor iedereen die met PICs wil beginnen.
Het programma dat in de PIC zit, is een samenraapsel van code die ik links en rechts heb gevonden, aangevuld met wat eigen creativiteit.

@madwizard: ik heb die intro maar genomen omdat hij vrij goed aantoont hoe goed de leds het beeld volgen. Aangezien ik voorlopig het zuiver rekenkundig gemiddelde gebruik, neem ik aan dat tijdens een normale film de leds voornamelijk wit/grijs gaan schijnen. Mijn prototype setup is ondertussen ontmanteld dus ik kan even geen filmpjes meer maken.

Ik heb verder nog klachten gehad van vrienden die ook verkeerde foto's op hun scherm kregen
en die net als ik aangesloten zijn bij Skynet. Ik neem dus aan dat de fout helemaal bij Skynet ligt.

http://www.a-r-e.nl/index.php?page=info

Hmmm?

Lampie1979 schreef op dinsdag 21 maart 2006 @ 04:16:
http://www.a-r-e.nl/index.php?page=info

Hmmm?

Die werd hier ook al genoemd, was geloof ik rond de 200 euro. Wat vrij veel geld is aangezien het gewoon op software werkt. Als je de handleiding leest zie je zelfs een FTDI usb-serieel driver voorbij komen, en moet je software installeren (overlay werkt niet). Het kastje is dan alleen nog maar een LED driver, eigenlijk wat RafkeP precies zo heeft gemaakt. En ze hebben RJ-45 connectors gebruikt om de LED strips aan te sluiten .

Of het een beetje werkt weet ik niet, er staan wel twee filmpjes maar die zijn beiden van gerenderde of getekende films, wat echt het simpelste is om goed te laten werken.

Lampie1979 schreef op dinsdag 21 maart 2006 @ 04:16:
http://www.a-r-e.nl/index.php?page=info

Hmmm?

Wat misschien een makkelijkere manier is, is dit te doen via een FPGA. samen met een video decoder (philips SAA....) kun je heel gemakkelijk video bewerken en dingen uit berekenen. Daar sluit je een AVR-etje op aan, of een softcore voor de liefhebbers. en je hebt ambilight zoals ook philips het doet.

En als je het helemaal goed wil doen, kun je zelfs je video bufferen, maar dan moet je wel een andere tuner gebruiken dan van de TV (VCR of DVR bv.) Dan sluit je het ambilight aan tussen de tuner en de Tv, en buffer je zelf gewoon een deel.

'k denk dat ik binnenkort wel een klein voorbeeldje zal maken (als ik er aan toe kom)

Verwijderd schreef op vrijdag 24 maart 2006 @ 11:06:
Wat misschien een makkelijkere manier is, is dit te doen via een FPGA. samen met een video decoder (philips SAA....) kun je heel gemakkelijk video bewerken en dingen uit berekenen. Daar sluit je een AVR-etje op aan, of een softcore voor de liefhebbers. en je hebt ambilight zoals ook philips het doet.

Die SAA decoders hebben zeker een digitaal signaal als uitgang? Met FPGA is dat waarschijnlijk wel te doen. Nadeel daarvan is dat maar weinig mensen ervaring hebben met FPGA's (ik zelf ook niet), maar wel met microcontrollers. Ook zijn ze lastiger te krijgen, al zijn de video ICs en ADCs die ik laast heb gekocht ook niet bij de elektroboer om de hoek te halen. FPGA lijkt me evengoed een prima idee maar ik ga toch voor AVRs omdat ik daar meer wel ervaring mee heb en het ook makkelijker aan te passen valt door anderen mocht er wel een werkend iets uit voorkomen.

En als je het helemaal goed wil doen, kun je zelfs je video bufferen, maar dan moet je wel een andere tuner gebruiken dan van de TV (VCR of DVR bv.) Dan sluit je het ambilight aan tussen de tuner en de Tv, en buffer je zelf gewoon een deel.

Dan wordt het allemaal wel heel ingewikkeld

Dan wordt het allemaal wel heel ingewikkeld

Mooi toch. 'k ben nu nog aan het verhuizen. maar binnenkort ga ik weer aan de hobby.
Dit zal een van de eerste projecten worden.

FPGA's zijn wat moeilijker aan te komen zijn, maar wil je het echt goed doen is dit toch echt de enige oplossing. Digitaal video is geklokt op 27 Mhz. Dat krijg je niet zo maar in een AVR binnen, als je ook nog berekeningen wil doen. Je zit dan al snel op 100 tot 200 Mhz klok voor je uC.
Een pipelined DSP zou daarintegen wel weer kunnen, maar dan is een FGPA net zo makkelijk aan te komen.

Er zijn wel goedkope development borden aan te komen voor FGPA's en op de meeste ModChips voor PS2 etc. zitten ook FPGA's. 'k ben nu aan het kijken of deze ook direct bruikbaar zijn.
Dan kun je ze best goedkoop aankomen.

Verwijderd schreef op dinsdag 28 maart 2006 @ 10:06:
FPGA's zijn wat moeilijker aan te komen zijn, maar wil je het echt goed doen is dit toch echt de enige oplossing. Digitaal video is geklokt op 27 Mhz. Dat krijg je niet zo maar in een AVR binnen, als je ook nog berekeningen wil doen. Je zit dan al snel op 100 tot 200 Mhz klok voor je uC.
Een pipelined DSP zou daarintegen wel weer kunnen, maar dan is een FGPA net zo makkelijk aan te komen.

Digitaal video is inderdaad niet te doen met een AVR. Mijn idee is het analoge RGB signaal (of YPbPr geconverteerd naar RGB) te samplen met een snelle ADC (2 megasamples met 3 channels tegelijk) om een serie gemiddelden van het beeld te krijgen. Je hoeft niet per se elke pixel te samplen, omdat het toch gemiddeld wordt. Dan is het wel snel genoeg. Nadeel daarvan is dat je wel RGB moet hebben, composite is wel om te zetten maar er zijn alleen maar ICs die dat naar zo'n digitaal signaal converteren waar je dus niets mee kan met een AVR. Met een FPGA heb je dat wel weer als voordeel. Composite zou wel mooi zijn want dat heb je toch vaak als extra output. Anders wordt het aftappen van de SCART of component connectors, wat wel kan maar weet niet wat dat met het signaal doet (aan reflecties e.d., want je kan ze niet dubbel termineren).

Ik was jullie nog een kleine update verschuldigd ...

Vorige week heb ik soft- en hardware kunnen uitbreiden naar 3 RGB leds (links, rechts en boven).
Het enige wat mij nu nog rest is ervoor zorgen dat er wat meer licht is, maar voorlopig ontbreekt mij de elektronica kennis om dat te realiseren.

Om te beginnen zou ik willen kijken of 3 LEDs langs elke kant voldoende licht geven voor (of beter gezegd achter) een 14" scherm, maar ik heb geen flauw idee hoe ik 3 RGB LEDs "in serie" kan zetten.
Nadien zou ik willen overschakelen op CCFLs, maar daar heb ik helemaal geen verstand van

Binnen dit en 2 weken zal ik ervoor zorgen dat de software geschikt is voor het grote publiek en dat het ergens online komt te staan.
Voor diegenen die zelf al hardware in mekaar willen steken kan ik al zeggen dat je hardware in staat moet zijn om aan 19200 bps RGB waarden tussen 0 en 256 te ontvangen in volgorde : Rood_Links, Rood_Boven, Rood_Rechts, Gr_L, Gr_B, Gr_R, Bl_L, Bl_B,Bl_R.
Voor de anderen zal ik een schemaatje met PIC software online zetten.

@iedereen > Ga ik hier te zeer off-topic ? Is het beter een apart topic te maken ?
Of mag ik jullie hier gewoon verder op de hoogte houden van mijn progress?

[b]RafkeP schreef op vrijdag 31 maart 2006 @ 20:27:
Om te beginnen zou ik willen kijken of 3 LEDs langs elke kant voldoende licht geven voor (of beter gezegd achter) een 14" scherm, maar ik heb geen flauw idee hoe ik 3 RGB LEDs "in serie" kan zetten.

Als je RGB LEDs als compleet element hebt (dus 4 aansluitingen, niet 6 of losse kleuren) kan je ze niet in serie zetten, simpelweg omdat de pootjes (intern) aan een kant dan verbonden zijn en je ze los moet hebben. Wel kunnen ze parallel (met eigen weerstanden uiteraard). Ik weet niet hoe je ze nu aanstuurt maar je hebt met meerdere LEDs al snel dat je ze met een MOSFET (of desnoods normale transistor) moet aansturen omdat microcontrollers maar weinig stroom kunnen leveren.

Of ze voldoende licht geven hangt natuurlijk helemaal van de LEDs af. Ik denk dat drie gewone 5mm RGB LEDs vrij weinig licht geven, je moet dan ze dan vrij dicht op de achtergrond zetten. Ik heb zelf voor m'n nog te maken prototype een 3W RGB Luxeon, daar komt wel een flinke berg licht uit.

Nadien zou ik willen overschakelen op CCFLs, maar daar heb ik helemaal geen verstand van

Daar kun je de inverter wel PWMen, alleen kunnen CCFLs niet echt lekker dimmen, ze gaan langzaam uit in het midden en moeten volgens mij altijd een beetje aan blijven staan. Het geeft wel een mooie berg diffuus licht natuurlijk en philips doet het ook dus zeker de moeite waard om eens mee te experimenteren.

@iedereen > Ga ik hier te zeer off-topic ? Is het beter een apart topic te maken ?
Of mag ik jullie hier gewoon verder op de hoogte houden van mijn progress?

Ik zou het gewoon hier neer zetten, misschien zodra je een volledige werkende set hebt dat het handig is een apart topic te maken (soort handleiding zeg maar).

En ? zijn er nog ontwikkelingen ? ben erg benieuwd maar inees zo stil hier

Het wordt mijn volgende project maar de EL democompo gaat eerst even voor .

Ik heb vorige week heel wat veranderingen aangebracht aan mijn software, maar bij gebrek aan een deftige LED setup heb ik deze nieuwe versie nog niet kunnen testen.

Ondertussen ben ik begonnen aan een soort van constructie om achter mijn laptop schermpje te plaatsen, maar net zoals directshow filters en PICs is dit weer iets waar ik geen ervaring mee heb
Het zal bij mij dan ook nog een paar weekjes duren.

Morgen waarschijnlijk eindelijk de beschikking over een cam om fotos te maken

Ik heb nog een vraagje voor jullie : Wat voor een effect geven RGB CCFLs ?

Ik zie net dat er een inkoopactie loopt met (volgens mij) goedkope CCFLs.
Daar worden RGB CCFLs aangeboden aan dezelfde prijs als normale.
Volgens het plaatje wordt zo'n buis opgedeeld in drie stukken.

Ben ik juist als ik veronderstel dat deze stukken op een afstand mengen tot 1 kleur, net zoals 3 afzonderlijke CCFLs of moet ik echt gaan voor 3 afzonderlijke buizen ?

RafkeP schreef op woensdag 19 april 2006 @ 09:07:
Ik heb nog een vraagje voor jullie : Wat voor een effect geven RGB CCFLs ?

Ik zie net dat er een inkoopactie loopt met (volgens mij) goedkope CCFLs.
Daar worden RGB CCFLs aangeboden aan dezelfde prijs als normale.
Volgens het plaatje wordt zo'n buis opgedeeld in drie stukken.

Ben ik juist als ik veronderstel dat deze stukken op een afstand mengen tot 1 kleur, net zoals 3 afzonderlijke CCFLs of moet ik echt gaan voor 3 afzonderlijke buizen ?

* DarthPlastic schopt topic
RGB CCFL's hebben gewoon 3 kleurtjes erin gemaakt.
Normaal zit er aan de binnenkant een soort poederlaagje (bepaalt de kleur, zoek maar eens op werking tl-buis naar fosforen (/me heeft profielwerkstuk daarover gedaan)) maar bij deze ccfl's hebben ze gewoon meerdere kleuren erin gesmeerd.
Omdat je altijd rood-groen-blauw oid. zal zien kun je hier géén losse kleuren mee maken.
Ook zijn de kleuren niet je-van-het, en zal het van ver weg niet op wit lijken.

[ Voor 3% gewijzigd door DarthPlastic op 21-04-2006 12:18 ]

Sorry voor het omhoogbumpen van dit topic, maar ik ben zeer geintresseert in ambilight...

Nu kwam ik dit tegen op het internet : http://forum.electronicwe...&start=15&zeige=ambilight

Dit gebeurt heel simpel zonder buffers, ed. Vind ik zelf ook niet erg nodig... Vind het belangrijker dat ik een leuke achtergrondverlichting heb, in het gemiddelde van het scherm... Als het ook nog gaat werken vanuit Composite video zou het helemaal tof zijn.. Maar dat is van latere zorg...

Gemiddelden lijkt me toch echt niet goed werken hoor, als je er dan toch tijd in steekt om zoiets te maken kan je het beter goed doen in plaats van dat je iets maakt en dan toch teleurstellend werkt.

Composite is echt een drama om iets mee te doen, de kleur zit daar gemoduleerd als UV in een signaal van 4.3 (?) MHz. Niet met een simpel schakelingetje eruit te halen dus en moet ook nog naar RGB omgezet. Alle analoge ICs die dat doen zijn voor zover ik weet hopeloos verouderd en niet te krijgen, alle recente zijn een digitaal front-end met enorme bandbreedtes.

Ik heb niet alle comments gelezen maar kun je niet (softwarematig) het midden uit je beeld knippen en een rand van 2-10cm gebruiken. Dan moet je gewoon het gemiddelde van elke zijde van de rand (boven, beneden, links en rechts) uitrekenen om een kleurtje te krijgen. Als je het goed doet en de belichting in het midden plaats zullen de 4 hoeken van je beeld automatisch goed komen door het mengen van de kleuren op de muur.

Ik ben natuurlijk niet direct op de hoogte indien dit eenvoudig mogelijk is, maar ik denk dat Philips ook zoiets simpel doet. Doordat ze LCD gebruiken en het is hun eigen hardware is moeten ze misschien zelfs niet veel berekeningen doen en past het in een simpele DSP omdat ze gewoon een reeks waarden uit de sturing van de rijen en kolommen moeten nemen aan de buitenzijden van het scherm en daaruit de gemiddelde kleur nemen.

Dit is natuurlijk wel low-level, je moet direct uit de sturing kunnen lezen maar waarschijnlijk is het ook softwarematig mogelijk. Als je natuurlijk reeds op voorhand moet weten naar welke kleur het moet gaan, vb. om een rustige transitie naar een ander shot moet je misschien een vertraging inbouwen. Daarnaast is het ook mogelijk dat je hardware te traag is. Dan moet je het in een specifieke DSP steken (wat Philips waarschijnlijk doet) of opnieuw je beeld bufferen (wat redelijk duur is)

Eindelijk kan ik jullie mijn eindresultaat voorstellen :

Het "brain" van de hele setup :

De aandachtige kijker zal zien dat dit schema identiek is aan dat van de RGB-led van William, met uitzondering van de USB connector en jumper links bovenaan.
Deze laatsten dienen zuiver voor voeding: wanneer ik een kleine demo wil geven, doe ik dat met 3 RGB LEDs. Die stroom kan ik halen uit de USB poort en dat bespaart mij de moeite om met een externe voeding rond te lopen.
De jumper staat parrallel over de voeding van de USB voor het geval ik toch met een externe voeding wil werken. (zie verder). Uiteraard gebruik ik ze nooit tesamen.
Aan de rechterkant heb ik een gerecycleerde connector gezet waar een flatcable in past.

De achterkant van dit printje ziet er zo uit :

Zoals je kan zien, kan ik het nog een stuk compacter maken, maar voorlopig houd ik het zo; dan kan ik er nog wat gaatjes in maken om ergens op of in te monteren.

Om met hogere stromen te werken werd mij hier aangeraden te werken met FETs.
Dit "power" gedeelte heb ik op een aparte print gezet. (kwestie van het brain gedeelte zo multifunctioneel mogelijk te houden).
Ook dit power deel is heel simpel opgebouwd :

Enkel een connector voor de flatcable, FETs en kabels die naar de CCFLs gaan.
(gebruik van kabels kom ik zodadelijk op terug)

Langs de onderkant:


Dit dient allemaal om de CCFLs te sturen :

De drie CCFLs zijn met de bijhorende velcro op een stukje plexi gezet. Voor de rest was het mijn bedoeling om de CCFLs volledig intact te laten. Dit leidt zoals je kan zien tot een chaos aan kabeltjes. Aangezien de kabeltjes van van de CCFLs daarenboven ook nog eens kort zijn was ik genoodzaakt om van het power gedeelte met langere kabels te vertrekken.
In totaal zijn er 3 sets van bovenstaande foto.

Alles wordt gevoed met een oude AT-voeding.

Hoe ziet het er nu uit ?
Wel, spijtig genoeg heb ik geen plasma, LCD noch breedbeeld TV.
Ik ben dus maar een constructie beginnen bouwen rond mijn laptop met behulp van CD-doosjes

Eerst even een kleurentest met mijn testprogramma :


Daarna opnieuw een screenshot uit de film "The Cube":

Let op het verschil tussen links en rechts

En zoals steeds een filmpje in zeer slechte kwaliteit :
http://users.skynet.be/Ra...MoMoLight/movie_intro.mpg (5Mb)

Zodra ik wat meer tijd heb maak ik een volledige tutorial met schema's en software,
maar ik vond dat ik jullie nu toch wel een kleine update verschuldigd was

Rafke P. also known as the Justified Ancient of MoMo

TOP!!! Ik ga zeker experimenteren als er schemas en tutorials komen!

Een beetje vel maar wel erg mooi

Heel mooi gemaakt!! Was zelf hetzelfe aan het doen met Rode, Groene en Blauwe LED's.
De software heb ik in Delphi gemaakt. Die "test" gewoon randon wat pixels in het scherm en berekend dan de gemiddelde waarde, of je kan het zo instellen als jou met aparte kleuren. Wat ik nog niet heb kunnen testen is of ik ook pixels kan testen in een video (werkt toch met overlay en dat soort zaken ) En welke methode gebruik jij als "invoer"? Ook gewoon wat pixels of een andere manier?

Leuk gedaan hoor Jammer dat het filmpje zo slecht is, zowieso is het altijd lastig dit soort dingen mooi op film te zetten. Die rood ziet er nog goed uit voor CCFLs, meestal is dat meer roze.

Echt geweldig, als die Tutorial er komt, wil ik hem erg graag nabouwen!

Dit ziet er echt geweldig uit, je gebruikt hiervoor echt een stuk software he? Is dit ook zo te maken dat de input komt van een tv ? zonder tussenkomst van de pc...

@atmoz & Koenzie :
Als invoer gebruik ik inderdaad een stuk software: mijn eigen directshow filter.
Voorlopig heb ik hem enkel nog maar aan de praat gekregen met BSplayer.
Dit betekent ook dat je met MoMoLight niet kan gamen of websites bezoeken zoals met a-r-e.
(vandaar dus ook de naam Movie Mood Light)

Misschien kan ik ooit mijn programmeerskills verbeteren zodanig dat er meer mogelijk wordt,
maar om eerlijk te zijn vrees ik daar een beetje voor

Verder hoop ik dat dit topic zijn origineel doel ooit zal bereiken : ambilight zonder PC.
(maar ik vrees dat het dan iets te ingewikkeld gaat voor een doorsnee elektronica hobbyist als ik)

Heel mooi gedaan.

Ziet er heel mooi uit!

Heel knap. Ik wil ook al een tijdje zo eentje bouwen maar de onderdelen komen maar niet binnen! Welke FETs heb je gebruikt? Ik had oorspronkelijk de IRF510 besteld (volgens een schema dat ik vond online) maar die hebben ze blijkbaar niet binnen en het duurt even voor ze die kunnen hebben.

Nu nog iemand die een print maakt om een scart kabel afteluisteren en te analyseren en in combo met de print van RafkeP is GoT Ambilight geboren

Evinyatar schreef op woensdag 31 mei 2006 @ 14:17:
Welke FETs heb je gebruikt? .

Het is de eerste keer dat ik met FETs werk, dus heb ik raad gevraagd aan de enige persoon,waarvan ik weet ,dat hij ze ooit heeft gebruikt ... Ferry
Hij raadde mij de IRFZ34n aan, maar mijn elektronicaboer had enkel IRFZ44n dus heb ik die maar genomen.Waarschijnlijk dikke overkill, maar better safe than sorry. (en het moest natuurlijk vooruit gaan). Aangzien er een FET per CCFL is, moeten ze 300mA aankunnen.

Wat misschien belangrijker is om in het oog te houden is de power supply : die moet 9x300mA aankunnen.

Hoi,

'k ben ook geinteresseerd in de schema's e.d.
Ik heb een begin gemaakt met het ambilight filter in een FPGA te maken. En dit begint ook al op te schieten. 'k hoop hier binnenkort het een en ander van te kunnen laten zien.

grtz,
Vincent

Verwijderd schreef op donderdag 01 juni 2006 @ 10:51:
Hoi,

'k ben ook geinteresseerd in de schema's e.d.
Ik heb een begin gemaakt met het ambilight filter in een FPGA te maken. En dit begint ook al op te schieten. 'k hoop hier binnenkort het een en ander van te kunnen laten zien.

grtz,
Vincent

wat gebruik je als input?
Composite? Want ik meen dat de meeste TV's het beeld wat er op TV is ook op de video-out-poort zetten. En dat is in veel gevallen gewoon composite...

RafkeP schreef op dinsdag 30 mei 2006 @ 20:48:
@atmoz & Koenzie :
Als invoer gebruik ik inderdaad een stuk software: mijn eigen directshow filter.
Voorlopig heb ik hem enkel nog maar aan de praat gekregen met BSplayer.
Dit betekent ook dat je met MoMoLight niet kan gamen of websites bezoeken zoals met a-r-e.
(vandaar dus ook de naam Movie Mood Light)

Misschien kan ik ooit mijn programmeerskills verbeteren zodanig dat er meer mogelijk wordt,
maar om eerlijk te zijn vrees ik daar een beetje voor

Verder hoop ik dat dit topic zijn origineel doel ooit zal bereiken : ambilight zonder PC.
(maar ik vrees dat het dan iets te ingewikkeld gaat voor een doorsnee elektronica hobbyist als ik)

Als je een tv kaart hebt of iets anders met video in zou je daar de tv-out van je videokaart op aan kunnen sluiten en in graphedit de directshow filters aan elkaar kunnen knopen.

bobo1on1 schreef op donderdag 01 juni 2006 @ 16:19:
[...]


Als je een tv kaart hebt of iets anders met video in zou je daar de tv-out van je videokaart op aan kunnen sluiten en in graphedit de directshow filters aan elkaar kunnen knopen.

Dat klopt volledig, maar zo blijf je natuurlijk een PC nodig hebben.
Normaal gezien zou het ook mogelijk moeten zijn om de filter een hogere merrit te geven zodanig dat hij ook met andere players gebruikt kan worden, maar om een of andere rede (die mij nog onbekend is) laadt de filter zich dan 3 maal en dan crasht natuurlijk alles
Uiteraard ga ik dat proberen op te lossen

RafkeP, ik zou je eeuwig dankbaar zijn als je de software (hex, test programma en DS filter) al ergens online zou kunnen plaatsen
Vandaag alle onderdelen gaan halen, behalve de CCFL's, die komen volgende week ergens binnen. Ik kan amper wachten om het af te hebben

Weet iemand nog een goed algoritme om de lampen aan te sturen? Ik zit eraan te denken om de dominante kleur van het scherm te nemen en daar de lampen op te zetten.

atmoz schreef op donderdag 01 juni 2006 @ 10:55:
[...]


wat gebruik je als input?
Composite? Want ik meen dat de meeste TV's het beeld wat er op TV is ook op de video-out-poort zetten. En dat is in veel gevallen gewoon composite...

Ja, composite, wat ik door een SAA7111 haal om er IBU 656 van te maken (10 bits digitaal video)
Daar kan ik alle lijnen van uitlezen en vertalen naar RGB.

Goed ik heb even een programmaatje in elkaar gedraait wat de video van me tv kaart uitleest en daar de gemiddelde kleur van uitrekent voor links en rechts, dat werkt prima moet ik zeggen.

Nu nog de lampen, ik zit aan ccfl´s te denken maar geven die wel lekker veel licht? Anders kan ik beter gloeilampen ofzo nemen, al zijn die wel langzamer.

Voor de aansturing maakt het mij niet uit.

bobo1on1 schreef op dinsdag 06 juni 2006 @ 02:09:
ik zit aan ccfl's te denken maar geven die wel lekker veel licht?

CCFLs geven zeker genoeg licht voor een ambilight. Nog meer licht gaat volgens mij enorm storend worden. Het enige probleem met de CCFLs die ik gebruik is dat ze beginnen te flikkeren wanneer ze niet volledig worden opengestuurd.
Ik zou dringend eens een volledige film moeten bekijken met mijn MoMoLight om te zien of die flikkeringen storend zijn (maar eerst wil ik natuurlijk die how-to afkrijgen )

Misschien moet iemand het eens keer met ledstrips proberen (/me kijkt naar madwizard )

RafkeP schreef op dinsdag 06 juni 2006 @ 17:06:
[...]

CCFLs geven zeker genoeg licht voor een ambilight. Nog meer licht gaat volgens mij enorm storend worden. Het enige probleem met de CCFLs die ik gebruik is dat ze beginnen te flikkeren wanneer ze niet volledig worden opengestuurd.
Ik zou dringend eens een volledige film moeten bekijken met mijn MoMoLight om te zien of die flikkeringen storend zijn (maar eerst wil ik natuurlijk die how-to afkrijgen )

Misschien moet iemand het eens keer met ledstrips proberen (/me kijkt naar madwizard )

Ja CCFL's zijn daarvoor geschikt. Maar met een PWM sturing flikkeren ze niet. Ik zie allesinds geen probleem daarin.

Ow crap, ik heb me slecht uitgedrukt...
Ik bedoel wanneer ik ze PWM flikkeren ze. Enkel wanneer ik de PWM op 255 zet (dus volledig open) zijn ze stabiel.
Doe ik dan iets verkeerd ?

Bij mij doen ze dat niet...
Misschien PWM frequentie verhogen

Wat trouwens een goed algoritme is om de lampen aan te sturen, is de gemiddelde kleur berekenen, en daarvan de rgb waardes zo te vermenigvuldigen dat tenminste 1 rgb waarde op zijn maximum zit, zo brandt er altijd 1 lamp voluit, zodat je hem goed ziet.

Ik heb namelijk het idee dat als de lampen op bijvoorbeeld 30% vermogen branden je er al weinig meer van ziet.

lol dit is wel leuk man. Echt knap werk maat!

RafkeP schreef op dinsdag 06 juni 2006 @ 20:43:Ik bedoel wanneer ik ze PWM flikkeren ze. Enkel wanneer ik de PWM op 255 zet (dus volledig open) zijn ze stabiel.

Je kan misschien dit PWM algoritme proberen: http://www.mosaic-industr...56optimalpwmalgorithm.pdf

Je zou ze ook linear kunnen regelen vanuit de microcontroller, al is dat wel wat lastiger.

Of anders een klein elco'tje van 100 µF ofzo parallel aan de inverter.

[ Voor 30% gewijzigd door bobo1on1 op 07-06-2006 15:19 ]

@evinyatar: dat lijkt mij een interessant artikel, maar ik weet niet of ik dat ooit ga kunnen vertalen naar assembler code. 'k heb je ook een paar dagen geleden een mail gestuurd, ik hoop dat je die gevonden hebt

@bobo1on1: dat van die elco had ik precies bij _Ferry_ ook een keer gelezen. Ik ga het alleszinds ooit een keer proberen. Ik zeg "ooit" omdat ik voorlopig mijn buik eventjes vol heb van Ambilight.
(even tijd voor een nieuw project zou ik zeggen)

@all: de how-to komt vanavond online, bijna gelijk met de release van BSplayer 2.
Ik zal de link hier straks posten.

RafkeP, mooooooooooi gedaan man
Ik ben geen programmeur maar ik ga het toch ook maar proberen op basis van jou how-to

Ik ontwikkel het gewoon zelf

Het is nog wachten tot de 12 ccfl's binnenkomen, een enkele ccfl was 5 euro en een dubbele 6,50, dus heb ik maar 6 dubbele genomen.

Hoe stuur je eigenlijk die lampen aan via rs232? Dan kan ik me microcontroller zo programmeren dat ik het ook met die directshow filter kan proberen.

[ Voor 33% gewijzigd door bobo1on1 op 07-06-2006 21:27 ]

bobo1on1 schreef op woensdag 07 juni 2006 @ 21:24:
Ik ontwikkel het gewoon zelf

Het is nog wachten tot de 12 ccfl's binnenkomen, een enkele ccfl was 5 euro en een dubbele 6,50, dus heb ik maar 6 dubbele genomen.

Hoe stuur je eigenlijk die lampen aan via rs232? Dan kan ik me microcontroller zo programmeren dat ik het ook met die directshow filter kan proberen.

PC zend via RS232 6 bytes, "R" en een byte voor zijn helderheid, "G" en een byte voor zijn helderheid, "B" en een byte voor zijn helderheid. Je microcontroller stuurt dan 3 PWM kanalen volgens de ontvangen waarde.

We are go for launch !

> Klik hier voor de volledige how-to <

Voor vragen/opmerkingen en aanvullingen mogen jullie mij dus altijd contacteren
Enjoy....

@bobo1on1: ik stuur 9 bytes over RS232 @ 19200kbs. In volgorde R1,R2,R3,G1,G2,G3,B1,B2,B3.
De volgorde is zo gekozen omdat het efficienter is voor de filter.
Verder ben ik erg benieuwd naar jouw software want die kan natuurlijk veel meer aan dan enkel BSPlayer.

En voor de rest natuurlijk hoge hoop voor de creatie van niceboy1981.
(en alle andere creaties die uit deze thread voorvloeien )

Leuke howto, heb em alleen even snel doorgelezen. Geen source van de directshow filter of kijk ik verkeerd?

Heb trouwens nog wat met de ledstrips geprobeerd maar ik denk dat ze toch wat weinig licht geven. Vergeleken met 2 CCFLs per kleur geven die laatste echt veel meer licht. Ook krijg ik de kleuren niet helemaal goed van die LED strips, de rood is erg zwak vergeleken met blauw.

Ik wilde ook nog wat proberen met m'n eigen algoritme en CCFLs (plus AVR rgb controller) maar dat wil niet erg lukken omdat m'n usb naar serieel converter kabel 'crasht' zodra de CCFLs aangaan. Dat ligt aan die converter wat echt een onding is, ook als je het licht aandoet in je kamer stopt ie er al mee .

Ow... je mailtje nu pas gezien (Zat ergens bij de junk mail )
Ik krijg het nog niet helemaal aan de praat. BSPlayer wilt de DS filter niet laden ondanks de juiste instellingen in de filter management. Het werkt wel als ik in GraphEdit de filter er zelf tussen zet (tussen de Out van ffdshow Video Decoder en de Input van Video Renderer). Wel zie ik dat er dan een filter "Color Space Converter" filter bij komt.

Gaaf dit, heb het topic eigenlijk helemaal niet zo gevolgd, maar het resultaat is erg mooi!

RafkeP schreef op woensdag 07 juni 2006 @ 22:08:
We are go for launch !

> Klik hier voor de volledige how-to <

Voor vragen/opmerkingen en aanvullingen mogen jullie mij dus altijd contacteren
Enjoy....

@bobo1on1: ik stuur 9 bytes over RS232 @ 19200kbs. In volgorde R1,R2,R3,G1,G2,G3,B1,B2,B3.
De volgorde is zo gekozen omdat het efficienter is voor de filter.
Verder ben ik erg benieuwd naar jouw software want die kan natuurlijk veel meer aan dan enkel BSPlayer.

En voor de rest natuurlijk hoge hoop voor de creatie van niceboy1981.
(en alle andere creaties die uit deze thread voorvloeien )

Wat gebeurd er nou als er ergens een bitje verloren gaat?
Volgens mij klopt de aansturing dan niet meer.

Evinyatar schreef op woensdag 07 juni 2006 @ 22:39:
BSPlayer wilt de DS filter niet laden ondanks de juiste instellingen in de filter management.

Woei, dat begint goed : bij de eerste die iets probeert loopt het al gelijk mis
Laat ons dit via mail proberen op te lossen.

@bobo1on1: het is best mogelijk dat het dan in de war geraakt, maar zolang het probleem zich niet voordoet ben ik niet van plan het aan te pakken.
Je moet rekenen dat ik per frame 9 waarden naar buiten moet sturen. Frames komen a rato 24 fps.
De PIC moet op die tijd de waarden binnenpakken en 9 PWM uitgangen sturen.
Ik heb geen zin om dit alles dan nog eens gaan te belasten met handshaking of iets dergelijks.
(rijkt mijn kennis waarschijnlijk ook niet ver genoeg voor)

Ik heb een beetje geëxperimenteerd met m'n eigen algoritme en CCFLs via serieel en een AVR. Het dimmen van de CCFLs geeft wel een flinke storing op m'n boxen, maar goed die willen ook nog wel eens radio oppikken. Het dimmen flikkert bij mij ook soms een beetje maar niet heel veel, wel merk je dat bij een lage duty cycle de buis maar aan een kant brandt. Omdat ik een extra inverter had (van kapotte CCFLs) heb ik die opengemaakt een zoals verwacht bleek daar een 100uF condensator aan de ingang te zitten. Omdat deze moet laden en ontladen duurt het een korte tijd voordat de CCFL de volle 12V krijgt en voordat deze weer op 0V staat. Bij lage duty cycles (< 10% ongeveer) is er te weinig tijd om op 12V te komen en brandt het ding maar half. Ik heb de 100uF vervangen door een 100nF en dat werkt een stuk beter, bij een paar procent duty cycle (op 600Hz) brandt het ding al volledig, maar wel heel zwak zoals ook de bedoeling is. Ook het flikkeren is zo minder volgens mij. Ik heb verder niet gekeken wat het effect op de inverter kan zijn van de vervangen condensator, het zou kunnen dat je wat spanningspieken terugkrijgt (vanwege de spoelen) dus misschien is het handig een diode parallel te zetten. De PWM frequentie is vrij laag met 600Hz en goed hoorbaar ook uit de CCFLs, hoger krijg je wel weer sneller het effect van de condensator, die dan nog lager moet worden.

Eindelijk heel de zooi ineen gekregen vandaag. De Sunbeam CCFLs hebben geen last van gedeeltelijk oplichten, wat ik ook had verwacht daar Sunbeam zelf een lightbus en zelfs sound module verkoopt voor hun CCFLs. Wel is het flikkeren van de CCFL's matig irritant. Hopelijk kan ik dat verhelpen met dat andere PWM algoritme, maar dat zal blijkbaar toch niet voor deze week zijn.

Voor de voeding heb ik een goedkoop dingetje gebruikt; 13.8VDC / 6A voor rond de 25 euro. Het voltage heb ik kunnen verlagen tot 12.7V. Die wordt omgezet naar 5V voor de PIC, dmv een LM317 schakeling. De invertors lijken geen last te hebben van de extra 0.7V.

Jammer genoeg heb ik door een kortsluiting drie van de negen FETs opgeblazen. Nu kan ik enkel de bovenste set lampen volledig laten branden.

Wij zijn ook bezig, en wij werken met een PIC met 3 PWM aansluitingen, maar weet iemand hoe je in MikroC (of een andere uC compiler) een andere PWM aanstuurt, kort na elkaar?

edit: het is een PIC16F767 die 3 hardwarematige PWM uitgangen heeft

En wij zaten met het probleem dat we geen trafo's konden vinden. En volgens een projectlid van mij hadden we die nodig om die CCFL's aan te krijgen, maar jij gebruikt een FET en dan een inverter (die standaard bij de CCFL zat?) Onze projectleider zei dat hij niet de CCFL's kon dimmen/aansturen met die standaard inverters (waarom weet ik eigenlijk ook niet)

[ Voor 56% gewijzigd door Barryvdh op 11-06-2006 21:14 ]

Niet alle invertors zijn geschikt om te dimmen (lees daarvoor madwizard's post). Merk wel op dat je CCFL's enkel kan dimmen met PWM; er een potentiometer tussen zetten zal vrijwel zeker nooit werken.

Ja weet ik, maar ik heb een standaardfunctie in MikroC om PWM aan te sturen, maar daar kan je niet kiezen welke PWM output je wil gebruiken (van de 3 die op mijn PIC zitten)
Wordt daar een selectie bit voor gebruikt, en weten jullie zo welke?
Of zou ik het dan met de hand aan moeten sturen

Barrytje schreef op maandag 12 juni 2006 @ 11:03:
Ja weet ik, maar ik heb een standaardfunctie in MikroC om PWM aan te sturen, maar daar kan je niet kiezen welke PWM output je wil gebruiken (van de 3 die op mijn PIC zitten)
Wordt daar een selectie bit voor gebruikt, en weten jullie zo welke?
Of zou ik het dan met de hand aan moeten sturen

F1 in mikroC zal je waarschijnlijk vertellen (ik gebruik mikroBasic) dat enhanced PWM's niet ondersteund worden, maar dat er in de example's een voorbeeld zit (in mikrobasis is het "dual pwm" van jpc). Je moet dus idd ff de datasheet lezen, en et zelf aansturen. Maar het zou me erg verbazen als op het forum van mikroelektronica al geen voorbeeldprogramma te vinden is.

Is het niet gewoon mogelijk om de stroom die van de inverter naar de CCFL gaat te schakelen?

Verwijderd schreef op maandag 12 juni 2006 @ 18:20:
Is het niet gewoon mogelijk om de stroom die van de inverter naar de CCFL gaat te schakelen?

De CCFL is hoogspanning (precies weet ik niet maar geloof honderden of duizenden volts), en volgens mij ook wisselspanning. Zowieso is het lastig zulke hoge spanningen te schakelen, FETs slaan bij enkele tientallen volt al door bijvoorbeeld. Verder raak je bij de meeste schakelmethoden de galvanische scheiding kwijt waardoor je schakeling onder hoogspanning komt te staan bij een foutje. Als laatste moet de inverter wel tegen zo'n PWM load kunnen, al moet dat volgens mij een niet al te groot probleem zijn.

Een CCFL'etje daait op zo'n 800V, 600Hz (net als TL's met elektronische ballast, dat eten ze het liefst ). In de primaire PWM'men lijkt me dan ook de allerbeste oplossing.
Let ook op de frequentie van je PWM'en, volgens mij is 100Hz ideaal, lager kan je zien knipperen, hoger heeft de inverter niet genoeg tijd om op gang te geraken, en is het dimgedrag niet ideaal (dan kan je die halve oplichting nog hebben).

Ik had het allemaal veel eenvoudiger gevonden als jullie gewoon bevestigd hadden dat het flikkeren van mijn goedkope CCFLs kwam. Nu kan ik mij weer suf piekeren over een oplossing

Kan er iemand de volgende berekening bevestigen ?
-Ik ben vertrokken van de PWM code van the master himself : naftebakje en heb hier liggen mee sjoemelen tot ik op 9 PWM uitgangen kwam.
-Dit resulteert volgens mij in een interrupt om de 69 instructies.
-Om een volledige PWM af te werken heb ik 256 IRQs nodig.
=> 256x69x1 microseconde = 0,017664 seconden of 56 Hz

In minder dan 69 instructies kan ik het volgens mij niet doen, dus ben ik volgens mij de sigaar.

Zou het inschakelen van een externe oscillator niet helpen? De interne van de 16f628 is 4MHz. Als we daar nu een 8MHz aanhangen lijkt me dat dat voldoende moet zijn. Of we halveren gewoon de resolutie van de PWM

naftebakje schreef op maandag 12 juni 2006 @ 20:43:
Een CCFL'etje daait op zo'n 800V, 600Hz (net als TL's met elektronische ballast, dat eten ze het liefst ).

Heb m'n scope eens in de buurt van het ding maar het signaal wat je dan oppikt zit toch meer rond de 30kHz. Spanning meten waag ik me niet aan.

RafkeP schreef op maandag 12 juni 2006 @ 21:20:
Ik had het allemaal veel eenvoudiger gevonden als jullie gewoon bevestigd hadden dat het flikkeren van mijn goedkope CCFLs kwam. Nu kan ik mij weer suf piekeren over een oplossing

Volgens mij hoeven de CCFLs zelf niet echt 'op te starten', en anders waarschijnlijk niet lang. De inverters zijn denk ik het probleem. Zoals gezegd helpt vervangen van de ingangscondensator al wel. Je wilt dat de CCFLs zelf ook echt afwisselend aan en uit gaan, niet dat ze een halve spanning krijgen of dat ze langzaam aan en uitgaan tijdens het PWMen. Spoelen en condensators in de inverter gaan dat juist tegen.

Kan er iemand de volgende berekening bevestigen ?
-Ik ben vertrokken van de PWM code van the master himself : naftebakje en heb hier liggen mee sjoemelen tot ik op 9 PWM uitgangen kwam.
-Dit resulteert volgens mij in een interrupt om de 69 instructies.
-Om een volledige PWM af te werken heb ik 256 IRQs nodig.
=> 256x69x1 microseconde = 0,017664 seconden of 56 Hz

Lijkt me wel wat ingewikkelde code voor PWMen. PWM zelf kun je simpel doen door een lijstje PWM waarden te hebben, herhaaldelijk van 0 tot 255 tellen en zodra het getal gelijk is aan een van de waarden die uitgang hoog zetten. bij 0 zet je alles weer laag. Volgens mij hoeft dat niet heel veel tijd te kosten, je hebt alleen het UART gebeuren waar je nog mee zit.

Ja ik heb al gekeken in de manual, in de examples en in het forum. Maar een echt duidelijke oplossing kon ik niet vinden.
Ik kan trouwens geen pwm frequentie instellen van 100Hz, alleen hoger dan ongeveer 1500Hz, anders zegt ie dat het argument out of range is. Onze PIC draait trouwens wel op 20 Mhz

madwizard schreef op maandag 12 juni 2006 @ 22:03:
[...]

Heb m'n scope eens in de buurt van het ding maar het signaal wat je dan oppikt zit toch meer rond de 30kHz. Spanning meten waag ik me niet aan.

Die 600Hz is niet zo kritisch, en het kan gerust zijn dat hogere frequentie's evengoed werken, dus je gemeten 30kHz zal wel kloppen. Spanning zou je kunnen meten met een (erg) hoogohmige spanningsdeler, je moet wel ff kijken hoeveel de dooslagspanning is van een weestandje. Ik ga me binnenkort eens bezighouden met een ionisator (rookafzuiging repareren), dus ik ga straks ff op zoek daarvoor. Een standaard 1/4W weerstandje kan maximaal 200V aan (350V volgens een andere bron), 1/2W 300V, en een 1W weerstand 400V. Je kan dus gewoon een spanningsdelertje maken, zorg dat over elke weerstand niet meer dan de maximale spanning komt, en hou rekening met de ingangsimpedantie van je meettoestel (10MOhm ofzo). Voor de zekerheid kan je trouwens een neonlampje parallel over de ingang van je mettoestel plaatsen, bij een 60V slaat die door, dus bereken je deler dat de spanning daaronder blijft. Bij teveel ingangsspanning, licht het neonlampje op en voorkomt het dat je meettoestel kapot gaat.

[...]
Lijkt me wel wat ingewikkelde code voor PWMen. PWM zelf kun je simpel doen door een lijstje PWM waarden te hebben, herhaaldelijk van 0 tot 255 tellen en zodra het getal gelijk is aan een van de waarden die uitgang hoog zetten. bij 0 zet je alles weer laag. Volgens mij hoeft dat niet heel veel tijd te kosten, je hebt alleen het UART gebeuren waar je nog mee zit.

Dat is de manier die ik gebruik, ik heb wel die code snel ff geschreven dus mss kan je nog hier en daar wat optimaliseren.
De interrupt routine is 27 instruktie's lang voor 4 kanalen, en in 4 instructie's heb je een kanaal erbij gevoegd, dus kom je op 47 instructie's. Daar komt dan nog bij dat je om de 256 cycli (PWM cyclus) elk van de kanalen eens aangelegd hebt en eens uitgeschakelt hebt, reken dus wat reserve in (ruim gerekend 15 voor het uitschakelen, inschakelen is een paar instructie's en valt in het niets). Je wil dus naast je 47 instructie's van de interrupt nog 15 instructie's voor de rest (een keer het uitschakelen van de uitgangen per PWM cyclus, de 255 andere keren kan je dan telkens 15 instructie's besteden aan je andere code), reken dus op 62 instructie's tussen elke interrupt.
RafkeP: proficiat, berekening is in orde, op 4MHz klok kom ik net op 63Hz uit. Beetje nipt, maar ws werkt het wel (TV flikkert aan 50Hz, dat merk je ook niet/nauwelijks). En "master himself" ben ik niet, der zitten hier gasten die beter zijn in elektronica dan ik (wow, hij is dan nog bescheiden ook ).

Barrytje schreef op dinsdag 13 juni 2006 @ 10:44:
Ja ik heb al gekeken in de manual, in de examples en in het forum. Maar een echt duidelijke oplossing kon ik niet vinden.
Ik kan trouwens geen pwm frequentie instellen van 100Hz, alleen hoger dan ongeveer 1500Hz, anders zegt ie dat het argument out of range is. Onze PIC draait trouwens wel op 20 Mhz

Zoek eens op mijn naam en PWM, ik heb een progje in ASM (met bergen massaal veel uitleg) gepost om zelf je PWM aan te maken, en op 20MHz zal je PIC 4/5 van de tijd uit zijn neus zitten eten (dus voldoende tijd over voor ander dingen die gelijktijdig moeten gebeuren). Ik dacht dat ik em hier ook al eens in Basic had gepost, als je dat liever hebt (kijk dan wel goed na of je basic compiler optimaal mijn code kan compilen, ik heb em in mikroBasic geschreven en het scheelde bijna geen code met ASM). Als je de ingebouwde module voor PWM gebruikt kan je idd geen lage frequentie's gebruiken, maar als je een RC netwerkje aan de uitgang hangt om een regelbare DC te bekomen, met een NE555 een zaagtand genereert (0-5V) van de gewenste PWM frequentie (100Hz), en die met een comparator vergelijkt met de regelbare DC die je hebt gemaakt, dan heb je een PWM op een frequentie die volledig onafhankelijk is van je PIC, kan je zelfs testen met een potmeter enzo, en als je de frequentie regelbaar maakt kan je gemakkelijk testen welke frequentie je de beste resultaten geeft.

[ Voor 36% gewijzigd door naftebakje op 13-06-2006 14:09 ]

http://gathering.tweakers.net/forum/view_message/24960953
De Basic versie heb ik gevonden, alleen niet zobveel comments?

Edit: ASM ook gevonden:
http://gathering.tweakers.net/forum/view_message/24675173

[ Voor 27% gewijzigd door Ricvdp op 13-06-2006 15:04 ]

Waarom CCFL en geen RGB leds?? En is het gelukt om dit spul aan de composiet uitgang van een tv te sleutelen?

naftebakje schreef op dinsdag 13 juni 2006 @ 13:17:
De interrupt routine is 27 instruktie's lang voor 4 kanalen, en in 4 instructie's heb je een kanaal erbij gevoegd, dus kom je op 47 instructie's. Daar komt dan nog bij dat je om de 256 cycli (PWM cyclus) elk van de kanalen eens aangelegd hebt en eens uitgeschakelt hebt, reken dus wat reserve in (ruim gerekend 15 voor het uitschakelen, inschakelen is een paar instructie's en valt in het niets). Je wil dus naast je 47 instructie's van de interrupt nog 15 instructie's voor de rest (een keer het uitschakelen van de uitgangen per PWM cyclus, de 255 andere keren kan je dan telkens 15 instructie's besteden aan je andere code), reken dus op 62 instructie's tussen elke interrupt.

Hmm inderdaad dan heb je niet heel veel tijd meer over op 4MHz, 4 instructies per extra kanaal is best goed lijkt me.

Verwijderd schreef op dinsdag 13 juni 2006 @ 17:01:
Waarom CCFL en geen RGB leds?? En is het gelukt om dit spul aan de composiet uitgang van een tv te sleutelen?

CCFLs zijn denk ik veel makkelijker om snel een berg licht te maken. Die LED strips bijvoorbeeld geven al veel minder licht, je zou dus nog meer LEDjes nodig hebben. Daarnaast spreiden die CCFLs het licht mooier, al krijg je wel wat kleurschaduwen aan de randen als je er niets diffuus opplakt (wat kalkpapier ofzo).

En composiet is niet erg makkelijk. Een manier om het via de PC te doen is het via een TV kaart te lezen en te verwerken, maar dan moet je ook TV kijken op je PC waarschijnlijk want meestal hebben die kaarten wat vertraging. Voor het hardware ambilight is het veel lastiger, de enige mogelijkheid is eigenlijk composiet te digitaliseren, maar dan krijg je data die te snel is voor de gemiddelde micocontroller, en zul je met FPGAs aan de gang moeten. Wat best kan (iemand hier is er al mee bezig) maar persoonlijk heb ik daar te weinig ervaring mee, net als wel meer mensen waarschijnlijk.

Hoe stel je eigenlijk in welke com poort je wilt gebruiken in die directshow filter?

@madwizzard & naftebakje : dan zijn we het eens over de ASM code. Misschien dat ik dit weekend eens probeer met een externe klok. Wat de condensator betreft kan ik melden dat bij mij aan de ingang al een 100nF zit. Dus vervangen is ook uitgesloten.

@bobo : je gelooft het nooit ... ik erger mij op mijn werk al meer dan een jaar over een bepaald stukje software dat je daar slechts 2 COM poorten kan kiezen. Nu schrijf ik zelf iets en wat doe ik ?
COM1 hardcoded erin zetten . Nooit aan gedacht om het variabel te maken.
Zal het zo snel mogelijk proberen te fixen.

@Felony : aan MoMoLight kan je net zo goed RGB leds hangen, maar je zal er wel een heleboel nodig hebben. Verder kan ik melden dat je via BSplayer Pro (de betaalversie dus (waar ik overigens zelf niet over beschik)) de mogelijkheid hebt om via een TV-in te kijken met MoMoLight.

[ Voor 21% gewijzigd door RafkeP op 14-06-2006 22:32 ]

*schop* en *update*

@bobo: de versie waarin je de com poort kan kiezen staat nu online. (zelfde link).
Ik moet alleen de tutorial nog aanpassen, maar ik neem aan dat dit veldje voorlopig
voor zich spreekt.

@all :
Ik heb alles een keer aan een scoop gehangen en die meet een frequentie van 50Hz.
Mijn bedoeling was dan om snel even de interne klok te disablen en een RC oscillator te gebruiken maar ik krijg het niet aan de praat.

Wat heb ik gedaan ?
- in de __config INTRC_OSC_NOCLKOUT vervangen door _ER_OSC_NOCLKOUT
- de pwm die op poort RA7 zat, verhuisd naar RB3
-RA7 mbv trisa op input gezet
- verder heb ik ook nog geëxperimenteerd met b'00001000' naar PCON te schrijven
- weerstand van 1k gezet tussen RA7/OSC1 en GND

Dit heeft allemaal geen effect: de PWM uitgangen blijven allemaal op 0 hangen.

Iemand enig idee wat ik vergeten ben?

Hoe heb je je kristal aangesloten?

Typo van mij : ik bedoel ER Oscillator.

Geen kristal dus, enkel een weerstand.
Dit om voorlopig de impact op het bestaande design zo klein mogelijk te houden.