DIY Ambilight howto?

Pimmetje, kan je mij mailen? Dan regelen we wat.

PM/mail gestuurd

quote:

LED-Maniak schreef op zondag 07 december 2008 @ 22:18:
Pimmetje, kan je mij mailen? Dan regelen we wat.

Ik ondervind problemen met het programmeren van de PIC16F628.
Ik heb de programmer gebouwd zoals hij staat vermeld op circuits-online, en nog werkt hij niet.
Eerst heb ik de simpele programmer gebouwd, maar toen die niet werkte ben ik opnieuw begonnen met de volledige programmer.

Icprog blijft hangen bij het 'Inlezen code', PonyProg geeft mij een 'Device missing or unknown device (-24)' error.
Zou het kunnen liggen aan mijn COM-poort? De COM-poort instellingen in de Device Manager staan gewoon op default. Mijn moederbord is trouwens een Asus K8U-X.

Heeft iemand nog een printje over?
Of gewoon zo'n gaatjes print. Kan het niet meer krijgen bij mijn vaste winkel en heb mijn laatste printje verpest

nog héél even geduld en de usb versie ligt in de "winkel"

Met kerst onder de kerstboom?

Ik heb alle onderdelen al, dubbel zelfs moet alleen nog een printje.

Je kunt toch wel ergens op internet een gaatjesprint bestellen?

Ik heb nog wel wat liggen, je mag ze op komen halen (als je in de buurt van Rotterdam bent).

Ik ben laatst nog aan de gang geweest met een wrapper voor d3d9.dll, ik heb hem zo aangepast dat hij linksboven een blokje tekende met de gemiddelde kleur, dat werkte best goed, het was iig stukken sneller dan getpixel.

Ik ben dit ook al sinds tijden op verschillende sites in de gaten aan het houden.
Zou het erg graag willen gebruikenin combinatie met de projector.
Ben erg benieuwd. Als iemand iets heeft waar ik al dingen mee kan testen laat het maar horen!

is wel heeeeel stil hier , nog nieuwe ontwikkelingen ?

Ik heb wel een klein nieuwtje, ik ben er achter gekomen dat windows standaard geen file descriptors maakt voor stdin, stdout en stderr en dat de file descriptors beginnen bij 0.
Open je dan eerst een config file en daarna een seriele poort, dan komen alle printf's daar uit

bobo1on1 wijzigde dit bericht 05-01-2009 18:13 (3%)

kijk daar ben ik blij mee om te lezen

quote:

bobo1on1 schreef op maandag 05 januari 2009 @ 18:13:
Ik heb wel een klein nieuwtje, ik ben er achter gekomen dat windows standaard geen file descriptors maakt voor stdin, stdout en stderr en dat de file descriptors beginnen bij 0.
Open je dan eerst een config file en daarna een seriele poort, dan komen alle printf's daar uit

Dit hele topic ziet er erg interessant uit! Het begint alleen een beetje te dateren. Ik ben ook een tijdje op zoek geweest, maar geen zin om er bijvoorbeeld 200 euro aan uit te geven. Eigenlijk zou een puur hardware oplossing natuurlijk het mooiste zijn. Geen pixels grabben, geen progjes die je moet draaien en instellen, die evt proc kracht vragen of niet 100% van de tijd werken. Zoals ik lees moet je bijvoorbeeld onder Vista Aero uitschakelen, en da's natuurlijk geen optie meer tegenwoordig. Gewoon een DVI signaal destilleren is natuurlijk het mooist, maar waarschijnlijk dus ook het duurst.

Is er ondertussen al iemand die iets meer weet over zo'n oplossing? Ik het het andere topic wat geopend is ook doorgelezen, er waren daadwerkelijk erg mooie plannen met goede oplossingen, het is alleen een beetje langzaam doodgegaan, omdat de uiteindelijke ontwerpers er niet de tijd voor konden vinden en verder weinig andere mensen de inspiratie hadden om een mooi totaalpakketje te ontwerpen.

Ik ga btw volgend jaar verder met HBO elektrotechniek, misschien dat ik er dan wel een project van kan maken, in dat geval zal ik iedereen hier op de hoogte houden!

quote:

trueKAMi schreef op woensdag 21 januari 2009 @ 10:53:
Dit hele topic ziet er erg interessant uit! Het begint alleen een beetje te dateren. Ik ben ook een tijdje op zoek geweest, maar geen zin om er bijvoorbeeld 200 euro aan uit te geven. Eigenlijk zou een puur hardware oplossing natuurlijk het mooiste zijn. Geen pixels grabben, geen progjes die je moet draaien en instellen, die evt proc kracht vragen of niet 100% van de tijd werken. Zoals ik lees moet je bijvoorbeeld onder Vista Aero uitschakelen, en da's natuurlijk geen optie meer tegenwoordig. Gewoon een DVI signaal destilleren is natuurlijk het mooist, maar waarschijnlijk dus ook het duurst.

Is er ondertussen al iemand die iets meer weet over zo'n oplossing? Ik het het andere topic wat geopend is ook doorgelezen, er waren daadwerkelijk erg mooie plannen met goede oplossingen, het is alleen een beetje langzaam doodgegaan, omdat de uiteindelijke ontwerpers er niet de tijd voor konden vinden en verder weinig andere mensen de inspiratie hadden om een mooi totaalpakketje te ontwerpen.

Ik ga btw volgend jaar verder met HBO elektrotechniek, misschien dat ik er dan wel een project van kan maken, in dat geval zal ik iedereen hier op de hoogte houden!

wij hebben op het hbo zo'n ding gemaakt.
een ARM processor die naar de vga-poort luisterde, dus geen programmaatjes op pc geinstalleerd.
werkt goed, maar is veel werk om na te bouwen. Je moet zo'n arm programmeren, en dan nog aansluiten

Ik heb op dit moment wat RGB led strips die worden aangestuurd d.m.v wat potmeters. De volgende stap zou dus zijn om hem aan te sturen via pc.
Nu is het verhaal van een VGA connector ook erg mooi. Tegenwoordig hebben veel systemen VGA + DVI.
Je zou een kopie van DVI over VGA kunnen laten gaan, uitlezen, analyseren en daarmee het controll board aansturen. Nu gaat di me allemaal ver boven mijn pet, maar het is wel een ontzettend leuk idee.
Ik ga eerst maar beginnen om gewoon de RGB Strips aan te sturen via PC (comport oid.).

Mooi id, alleen vervalt de optie dan om 2 beeldschermen aan je PC te hangen, zoals ik heb

Gewoon DVI uitlezen (is digitaal, moet gewoon kunnen) met een blokje ertussen, maar het signaal ook door naar je beeldscherm laten gaan moet mogelijk zijn. Dat zou m.i. de ideale oplossing zijn, zo ben je geen extra stekker kwijt, en steeds minder kaarten en beelschermen gaan op VGA werken, uiteindelijk gaat het toch naar DVI of HDMI (Maar daar zit ook het DVI signaal in, dus is nog steeds uit te lezen)

DVI zou tof zijn, alleen zit je met de hoge bandbreedte van dit signaal (tot 165 MHz voor een single link, zie wiki)

In dat geval zou je dus een FPGA kunnen toepassen, alleen zit je misschien met het probleem dat daar te weinig "brains" inzitten om netjes verschillende ambilights aan te sturen.

quote:

3V3RT schreef op woensdag 21 januari 2009 @ 15:46:
DVI zou tof zijn, alleen zit je met de hoge bandbreedte van dit signaal (tot 165 MHz voor een single link, zie wiki)

In dat geval zou je dus een FPGA kunnen toepassen, alleen zit je misschien met het probleem dat daar te weinig "brains" inzitten om netjes verschillende ambilights aan te sturen.

Het zou betekenen dat je met een FPGA 3.96 Gbit/s aan data moet verwerken. Dat is op z'n zachts gezecht vrij veel. Wat echter niet wil zeggen dat je in het in een beetje mid/high-end FPGA niet geprogrammeerd krijgt...

Edit:
Je kan dan bijv. een AD9380 pakken, deze slikt VGA en HDMI (en misschien ook nog wel RGB over SCART). Deze decode het video signaal naar RGB met HSYNC en VSYNC. Het probleem is echter dat je met 300MHz signalen zit en dat PCB ontwerpen dan niet zo straightforward is...

simplendi wijzigde dit bericht 21-01-2009 16:44 (16%)

Heb net vorige week mijn eigen versie van ambilight afgewerkt.

Scherm verdeeld in 6 blokken (2 links, 2 boven en 2 rechts), aangesloten via MCHP USB, werkt met een PIC18f2550 en doet 6 x 25cm RGB strip van dealExtreme branden (3 strips in 2 stukken gesneden)


Mijn software was oorspronkelijk gebaseerd op boblight, maar dan aangepast om met usb te werken en met 6 vlakken.
De GDI is echter ondertussen ook al veranderd naar een DirectX capture en ondertussen blijft er nog maar weinig over van de originele boblight
Met een resolutie van 1920*1200 haal ik momenteel ongeveer 30 à 40 "fps" met directX capture (in game mode)

Ga nog even blijven zoeken om het misschien nog iets sneller te krijgen.


Via DVI/HDMI/VGA zou het misschien nog iets beter gaan, maar dat lijkt mij voorlopig iets te veel moeite om dat werkend te krijgen.

houd direct x capture in dat we van het schokken in games af zijn die de get pixel routine veroorzaakt?

Dat lijkt me wel ja, bij opengl is glReadPixels iig wel stukken sneller.

Ik heb niet echt een idee wat je met "schokken in games die de get pixel routine veroorzaakt" bedoeld aangezien die GDI gewoonweg niet werkte bij mij in games (eigenlijk enkel met moderne games getest).

Kan enkel zeggen dat ik geen schokken heb.
Spel blijft vloeiend spelen (met uitzondering van GTA IV, maar dat ligt aan het spel zelf).

Heb de code ondertussen ook nog verder aangepast dat het nog sneller gaat. (code om dx capture uit te voeren nam vroeger +- 40 msec in beslag en nu nog maar +-2 msec.) => Geeft alweer ongeveer 10 fps meer.
Ook de timer is eruit gehaald. Als ik mijn timer instel op bvb 1 msec, dan geeft ie nog steeds pas om de 100 msec een tick. (maw: of ik mijn timer nu op 10 of op 100 instel, dat blijft gelijk. max aantal fps is dan ook ongeveer 10). => gebruik er nu een apparte thread voor, gaat véél sneller!

Mijn divide is ook aangepast. Voor movie mode: 64, voor gaming mode 128. Ook een berekening om de randen van het scherm belangrijker te maken dan het midden van het scherm zit erin.


Als ik zelf tevreden ben met de code dan zal ik het wel een keertje ergens uploaden. Iemand zal het dan wel weer terug moeten aanpassen om met com poort en 3 vlakken te werken. Voorlopig is er nog wel werk aan. Zou de pixel herkenning nog anders willen doen.

Je kunt het beste een multimedia timer gebruiken: http://msdn.microsoft.com/en-us/library/ms712704(VS.85).aspx
Die is stukken nauwkeuriger dan een waitable timer of settimer.