DIY Oculus Rift - schematics, instructions and build pics!

Post by **adoral84** » Sat Dec 15, 2012 3:12 pm

Just got all my parts in to try to put together a 5.6" DIY to kill time until march, unfortunately it looks like the screen / driver board from vitrolight is doa... The LED just cycles at irregular intervals with the computer randomly picking up and dropping the device , and nothing shows up on the screen. Same thing happens over both HDMI and VGA too. Anyone seen this before? It's looking like a return unless someone's sorted this out before

Post by **ChrisP** » Sat Dec 15, 2012 3:37 pm

did you try a different power source?

Post by **tahustvedt** » Sat Dec 15, 2012 3:46 pm

I got my lenses and the 5,6" LCD with a DVI/VGA card. The VGA worked when I first tried it, but the DVI input didn't, as was mentioned here. I looked at the board, and on the back of the keyboard connector is some text describing the different pins. By shorting ground and K3 briefly it switched to DVI, and stays that way after being turned off. The screen is working very well with either input, but I haven't done much testing yet. I connected it to my gaming PC and my Android mini-PC, and both fired it right up. Pin K4 enters the menu, which I will explore once I make myself a jumper cable to click the buttons more effectively.

Has anyone tried dimming the backlight (which I assume is LED) with a variable resistor on one of the the power wires? It's hardly necessary to run with full brightness when the display is two inches from the eyes, in complete darkness. Dimming slightly would give better blacklevel.

BTW. Changing the language of the OSD is the top menu option on the second menu on my OSD.

I will design and CNC-mill the parts for my DIY Rift later.

Post by **adoral84** » Sat Dec 15, 2012 5:56 pm

ChrisP wrote:did you try a different power source?

Yeah I've tried a few. No luck so far...

Post by **Dycus** » Sat Dec 15, 2012 6:42 pm

tahustvedt wrote:Has anyone tried dimming the backlight (which I assume is LED) with a variable resistor on one of the the power wires? It's hardly necessary to run with full brightness when the display is two inches from the eyes, in complete darkness. Dimming slightly would give better blacklevel.

There are two pins for the backlight, one is 12v, and the other is the backlight brightness PWM signal. You can build a simple 555 PWM circuit to control it.

Post by **3dvison** » Sat Dec 15, 2012 8:46 pm

Hey Dycus,
Just sending a Thank You.
I got my 7 in 1 controler board cut down, and all is still well & working with it..
To be safe and since I only have caveman tools, I went a good 1/4 to 1/2 inch right of the orange line, just like you had suggested I do. I may be working with caveman tools, but when I plugged that controler back in, I did not want to discover fire...

Dycus, I still have most of the area the S-video socket was located in . Would it be safe to drill a mounting hole there ? I'm thinking Helz No, but thought I would ask anyway....It's a caveman man idea...I still want fire...LOL

Post by **Dycus** » Sat Dec 15, 2012 9:48 pm

Glad it still works!

If you rip off the s-video connector, you can drill a hole there for sure. Just cut the traces going to the port, and/or insulate the screw you put in. Don't wanna short anything.

Post by **3dvison** » Sat Dec 15, 2012 10:32 pm

Got It, Thanks Dycus.

adoral84...
What controler are you using ? As you can see from my post, I'm using the 7 in 1....
When I turned on my LCD/Controler I got no signal on the DVI port I was plugged into at the time. I then realized there was a button(AUTO) on the controler keypad, which I had to press in order to cycle through the different inputs (VGA/DVI/HDMI ect..).
You probably already did this, or it is not required with your controler, but thought I should post it just in case. No information comes with this stuff, so it is easy to over look things like that...I do all the time.

Post by **tmek** » Sun Dec 16, 2012 7:49 am

Hi guys, glad to see you are making progress with the 7" LCD builds!

I haven't had much time to work on my build lately and I may not be around much due to Christmas but I did finally make a bit of a breakthrough with headtracking.

I based all my hardware choices on trying to have a DIY Rift that was as close as possible to the E3 prototype Rifts. I really wanted to experience the demo that amazed so many people including members of the media and leaders of the game industry. This included the Hillcrest tracker even though its default fusion algorithm is too randomly jerky for headtracking as some users here have found. My hopes were that Carmack would release the entire demo source code but only the 3D/warping code was included with the D3BFG release. Since the tracker to be used in the Rift dev kit has been changed I'm not sure if the Hillcrest tracking code for the prototype Rifts will ever be released. However Carmack gave a lot of explanations of how he did things in the interviews. He got a custom 250hz firmware, read in the raw gyro and acceleration data and ran it through custom fusion code on the CPU instead of using the built-in sensor fusion. As a learning process I wanted to see if I could recreate smooth fast headtracking with the Hillcrest tracker by following the tidbits of information given by Carmack in the Rift demo interviews.

Hillcrest will give you the 250hz firmware, although they ask that you get it from them directly and not share it so they can track who is using it (Be aware you should only get it if you are going to be doing custom fusion with the raw IMU data). I was able to find a few blog articles, videos and some source code for doing IMU fusion. After a LOT of trial and error I finally got it working.. the result?

Smooth and responsive! I did my best to take a video but it really doesn't capture it very well. Any wobble or jerkiness you see is due to my own wrist movements, the camera movement or just bad video quality. In person it is actually amazingly smooth and responsive. It's not perfect (i'm not sure what the delay is but there is some) but it's MUCH better than the built in fusion.

[youtube]http://www.youtube.com/watch?v=-mmWsXYSkAI[/youtube]

For the noobs like me...
Along the way I gained a decent understanding of how IMUs work, it was an eye opening experience going from something I thought I would never understand to "woah, I think i'm getting it :O". When I first started learning about the Rift and head tracking I remember hearing statements about how accelerometers were not accurate enough for positional tracking. It also made me wonder what good an accelerometer could be for orientation anyway? I thought the gyro told the orientation. The problem with the gyro measurements is they are relative and over time you get drift. I knew this as well from the same discussions but still didn't see how an accelerometer could help since it just measured positional information. It turns out that the mass(es) in the accelerometer, while affected by positional movements, are also constantly being pulled on by gravity. So by measuring the accelerometer you can figure out the gravity vector. By knowing which way is down you can correct drift in pitch and roll. However, since yaw rotates perpendicular to the gravity vector it can't correct yaw drift. You either accept it or add a button to "realign" yaw in your application. Now this is where the magnetometer of the 9DOF IMU devices come in. It gives you a second vector pointing north. By combining, via fusion algorithms, the fast gyro data with the slower north and gravity vector data you get quick and responsive orientation that is also continuously being corrected for drift.

Post by **brantlew** » Sun Dec 16, 2012 11:17 am

Very, very nice work tmek. Can you post the links to the fusion code you started with just for reference?

Post by **TheLookingGlass** » Sun Dec 16, 2012 11:27 am

Great work & initiative Tmek! Very cool!

Post by **cybereality** » Sun Dec 16, 2012 11:58 am

Nice one, tmek!

Post by **tmek** » Sun Dec 16, 2012 12:28 pm

brantlew wrote:Very, very nice work tmek. Can you post the links to the fusion code you started with just for reference?

Sure thing.

This got me started, it has code that shows how to get up and running using the Hillcrest 6DOF sensor with Quake 2 (using the built in fusion).

That worked but as I would pan left or right the roll would violently twitch occasionally.

So I hacked that code in with the fusion code from here Open source IMU and AHRS algorithms. It's c# code but the algorithms (just math) were easily portable. But in order to make it work I had to get an understanding of what the raw body data actually represented. The libfreespace documentation and watching (only) the body data graphs as I moved the sensor in the "Freespace Motion Studio" app helped a lot with that.

http://www.starlino.com/dcm_tutorial.html discusses DCM fusion.

There is a minor isNewDevice bug in libfreespace that caused me some frustration.

There are a few fusion algorithms I've seen, Kalman filter seeming to be the most popular. I haven't tried it yet but plan too. I still don't understand them all that well. I imagine Carmack's was probably very simple/elegant but very fast. I'm also curious about this guy's ideas.

Post by **Fredz** » Sun Dec 16, 2012 7:01 pm

Very nice job tmek !

You can find a C implementation of the algorithm you are using in the original paper from Sebastian O.H. Madgwick :
http://sharenet-wii-motion-trac.googlec ... arrays.pdf

There are two versions, one for IMU and one for MARG, both optimized to minimize the required number of arithmetic operations. I didn't have a look at the C# implementation, but this one may be faster than your conversion from C# to C.

In the paper the author also said that he tried the algorithm with simulated sampling rates between 1Hz and 512 Hz by decimating the data, and that the filter achieved similar levels of performance at 50 Hz and 512 Hz. So the 250Hz custom firmware from Hillcrest may not be strictly necessary to achieve good sensor fusion.

It also gives me hope that cheaper MARG with lower update rates could be used, like the ones found in mobile phones or console game controllers (like the PS Move that I'm using in my project).

Post by **2EyeGuy** » Sun Dec 16, 2012 9:41 pm

The original Doom 3 BFG Edition EXE has features that aren't in the source code, including head-tracking stuff. I don't know if it can be made to work with your Hillcrest tracker or not (because I don't have one to test). And I don't know if the patch removed those features. But if you need a copy of the original North America release exe, I've got it.

Post by **3dvison** » Sun Dec 16, 2012 10:31 pm

Hi tmek,
Have you used your YEI 3-Space Sensor ?

Post by **MaterialDefender** » Mon Dec 17, 2012 3:15 am

tmek wrote:Hillcrest will give you the 250hz firmware...

Is there a special e-mail address for requesting that firmware or would the person who sent the order confirmation be the right contact for this? After some delays caused by customs and UPS (who seem to think it's a good idea to charge 25$ for storage due to delays caused by themselves...) I will finally get my sensor today, so this would come right in time.

Post by **tmek** » Mon Dec 17, 2012 3:33 pm

Fredz wrote:Very nice job tmek !

You can find a C implementation of the algorithm you are using in the original paper from Sebastian O.H. Madgwick :
http://sharenet-wii-motion-trac.googlec ... arrays.pdf

... In the paper the author also said that he tried the algorithm with simulated sampling rates between 1Hz and 512 Hz by decimating the data, and that the filter achieved similar levels of performance at 50 Hz and 512 Hz. So the 250Hz custom firmware from Hillcrest may not be strictly necessary to achieve good sensor fusion.

Thanks! I'll probably swap out my code for this c version, it looks nice and clean. I experimented a bit with putting the firmware back at 125hz. It seemed to work almost just as well. At first it was awful and but then I realized that I had forgotten to change the SampleRate variable in the code from 250hz back to 125hz.

2EyeGuy wrote:The original Doom 3 BFG Edition EXE has features that aren't in the source code, including head-tracking stuff.

I launched the Steam version of D3BFG and it did still have these. I enabled head tracking and it worked but it seemed a bit jittery. There are two console variables for the fusion algorithm so it may be that those defaults aren't very smooth (in favor of speed perhaps). Or maybe they coded it to work for 125hz firmware; I may have to go back and try with that.

3dvison wrote:Hi tmek,
Have you used your YEI 3-Space Sensor ?

I haven't yet

I have no soldering equiptment (or skills) and it requires some basic soldering before it can be used. The friend I was going to get to help me has been unavailable.

MaterialDefender wrote: Is there a special e-mail address for requesting that firmware ?

Email [Merrill dot Roller at Hillcrestlabs dot com] (hopefully that will prevent it from being picked up by spam bots) He said he'd be happy to help anyone else.

When I saw John Carmack handing the Rift prototypes to people in videos I was surprised by how he never seemed to have to set up the orientation or tell them that if your view gets off press some button to reset the orientation. He even gave an example in one video talking about drift in sensors by saying the world could look tilted (roll angle) by 20 degrees . I'm thinking he just did that because it is easier to express the problem with a 'roll' example. But in reality pitch and roll never get off. The one that does is yaw, but since you are constantly turning your character it makes yaw drift irrelevant. I've twirled it around like a lasso on the USB cable and pitch and roll are always dead on. Up in the real world always translates to up in the game world, which is great. You can just pick it up off the desk put it on your head and it's always 'calibrated' so to speak. I'm somewhat rambling about this but I was just really surprised by it.

I don't know if the current D3BFG tracking is written purely for speed or if I don't have some variables set right but I prefer the DCM version, it seems so incredibly smooth and precise. I wonder how I could quantify the timing differences.

Post by **brantlew** » Mon Dec 17, 2012 3:44 pm

MaterialDefender wrote: I've twirled it around like a lasso on the USB cable and pitch and roll are always dead on. Up in the real world always translates to up in the game world, which is great.

Assuming you are standing on level ground, the gravity vector can always be determined by the accelerometers so you always have a stable global reference for straight-down.

Post by **bobjwatts** » Mon Dec 17, 2012 5:04 pm

Awesome work happening here. nice tmec!

Question: I'm using my iPhone and can get the tracking data into freePie - can I then get that data to libfreespace to use a similar implementation to tmec's?

Post by **brantlew** » Mon Dec 17, 2012 5:26 pm

bobjwatts wrote:Awesome work happening here. nice tmec!

Question: I'm using my iPhone and can get the tracking data into freePie - can I then get that data to libfreespace to use a similar implementation to tmec's?

No. For one, there is no plugin to tie FreePIE output to libfreespace, and two - the FreePIE implementation is pretty basic and just routes "fused" Euler orientation values. These fusion algorithms need to work with raw IMU data. Now the raw data is also available via the Sensor Data app on the iPhone so you can get it very easily if you add a small bit of code to parse those values from the feed. But I just don't see any benefit to using raw data from the iPhone. Raw and fused data are both accessible via UDP socket and subject to identical latency and update rate (including the infamous iPhone network stutter). And Apple's fusion algorithm is stellar anyway - no drift at all. So you can't get any better results timing-wise or performance-wise by going down that route.

Post by **bobjwatts** » Mon Dec 17, 2012 5:36 pm

brantlew wrote:
bobjwatts wrote:Awesome work happening here. nice tmec!

Question: I'm using my iPhone and can get the tracking data into freePie - can I then get that data to libfreespace to use a similar implementation to tmec's?
No. For one, there is no plugin to tie FreePIE output to libfreespace, and two - the FreePIE implementation is pretty basic and just routes "fused" Euler orientation values. These fusion algorithms need to work with raw IMU data. Now the raw data is also available via the Sensor Data app on the iPhone so you can get it very easily if you add a small bit of code to parse those values from the feed. But I just don't see any benefit to using raw data from the iPhone. Raw and fused data are both accessible via UDP socket and subject to identical latency and update rate (including the infamous iPhone network stutter). And Apple's fusion algorithm is stellar - no drift at all. So you can't get any better results timing-wise or performance-wise by going down that route.

Thanks brantlew.

So you recommend using fused data via UDP into Doom 3 if i want rotation (currently I have mouse emu working via gizmo iPhone mouse app) Which is currently beyond my skill set

Post by **brantlew** » Mon Dec 17, 2012 5:51 pm

bobjwatts wrote:So you recommend using fused data via UDP into Doom 3 if i want rotation (currently I have mouse emu working via gizmo iPhone mouse app) Which is currently beyond my skill set

I have a hard time recommending the iPhone for a long term head tracking solution because of it's stutter and latency problems. It's great for a quick looksy though.

There is really no benefit of FreePIE mouse emulation over other mouse emulators except that it is scalable via script. And there is no easy way to force "roll" into games that don't have support via something like TrackIR. I guess Doom has native support for the Hillcrest and a sort of "conduit" for other trackers via the libfreespace DLL, but hacking that interface would probably be more effort than just modifying the game engine like tmek is doing and putting direct support.

So sorry, I don't see any "good" and "easy" general solutions right now. Hopefully the Oculus SDK will fix that.

Post by **bobjwatts** » Mon Dec 17, 2012 5:56 pm

brantlew wrote:
bobjwatts wrote:So you recommend using fused data via UDP into Doom 3 if i want rotation (currently I have mouse emu working via gizmo iPhone mouse app) Which is currently beyond my skill set
I have a hard time recommending the iPhone for a long term head tracking solution because of it's stutter and latency problems. It's great for a quick looksy though.

There is really no benefit of FreePIE mouse emulation over other mouse emulators except that it is scalable via script. And there is no easy way to force "roll" into games that don't have support via something like TrackIR. I guess Doom has a sort of "conduit" via the libfreespace DLL, but hacking that interface would probably be more effort than just modifying the game engine like tmek is doing and putting direct support.

Sorry, I don't see any "good" and "easy" solutions right now. Hopefully the Oculus SDK will fix that.

Great thanks Brantlew, that's the answer i was looking for. It's not ideal but I'm going to stick with my iPhone for DIY head tracking until I get my Rift.

Post by **3dvison** » Mon Dec 17, 2012 7:09 pm

I have the YEI 3-Space Sensor but maybe someone with a Hillcrest or other tracker can still help me.
I downloaded the old crysis single player demo, just to try out the tracker in mouse emulation mode, I had no other games to try.
Anyway, once I get the tracker up and running in mouse emulation mode, all is fine. I can navigate windows desktop and the games menu, all with the sensor acting as a mouse.
But the very second a game starts, all goes haywire, and the game world just spins in circles when I move the sensor ???
Any ideas ?

Post by **bobjwatts** » Mon Dec 17, 2012 7:18 pm

3dvison wrote:I have the YEI 3-Space Sensor but maybe someone with a Hillcrest or other tracker can still help me.
I downloaded the old crysis single player demo, just to try out the tracker in mouse emulation mode, I had no other games to try.
Anyway, once I get the tracker up and running in mouse emulation mode, all is fine. I can navigate windows desktop and the games menu, all with the sensor acting as a mouse.
But the very second a game starts, all goes haywire, and the game world just spins in circles when I move the sensor ???
Any ideas ?

No idea, do you have the 'Gravitron' setting turned on ;P

Post by **RoadKillGrill** » Mon Dec 17, 2012 7:22 pm

@3dvison
What mode is the mouse emulation in? If its in absolute it messes with some games, try it in relative mode.

Post by **3dvison** » Mon Dec 17, 2012 9:58 pm

RoadKillGrill wrote:@3dvison
What mode is the mouse emulation in? If its in absolute it messes with some games, try it in relative mode.

Eureka, It works now...Thanks RoadKillGrill
Relative to me, you are an absolute genius RoadKillGrill...LOL

Post by **braddas** » Tue Dec 18, 2012 7:57 am

My screen finally came! Luckily it works fine, and I had everything hot glued and taped up in about an hour. It's not pretty but you soon forget that once it's strapped to your face! Up until now I had just been attaching my phone to the case with rubber bands, so this made for a nice upgrade.

I've tried it with Crysis 2 and Skyrim so far. It's really very immersive, though admittedly I'm not quite getting the 'you are there' feeling I'd hoped for. The FOV is pretty good, but I'm glad Oculus is going for a 7" screen. I don't have any head tracking either, which I imagine is a pretty important piece of the puzzle. I'll probably be taking a similar route to bobjwatts and just use my android phone for now, I can't justify spending any more on this for the time being.

I need to add some foam padding, it gets a little uncomfortable after a while, and I think the lenses may need to moving a smidge further from the screen. I also need to get a much thinner HDMI cable, this one could rip the control board out completely if I move my head too quickly. Another thing, the board gets pretty hot after about 10 minutes. Is that normal? I've left the control board pretty open for ventilation, but the screen is hot glued straight onto the foam core, there's not really any space for ventilation behind it.

Thanks to everyone here, I would never have even known this was possible otherwise.

Post by **3dvison** » Tue Dec 18, 2012 8:39 am

Hi braddas,
You went with the 5.6"inch right ?
If it is the 5.6, did you also get the model without the mounting holes on the outer frame ? I take it thats why you used hot glue to mount it.
About the heat. I have the 7 in 1 controller but I think the place the heat comes from would be the same with all of them.
I am posting your picture and in it on the controller board you can see a copper looking oversized cheerio. That is the area on my board that most of the heat comes from. I have not had my screen running for large amounts of time, so I can't say how hot it gets.

Are you thinking of trying out the leep on the cheap optics ? I just might. It could give you more of that being there feeling.WickedAndy liked the cheap Leeps the best.

http://www.mtbs3d.com/phpBB/download/fi ... &mode=view

Post by **braddas** » Tue Dec 18, 2012 9:59 am

3dvison wrote:You went with the 5.6"inch right?

Yeah, it's the HV056WX1-100 from Vitrolight, I'm not sure about the contrast but I'm quite pleased with it. The heat does seem to come mainly from that cheerio thing you mentioned, it's actually not as bad now. I think it hot before because I had it on the desk for a while, I'll just have to keep an eye on it.

The Leep on the Cheap would be this right? Looks interesting, I'm not sure how easy it would be for me to get the right lenses in the UK, but I'll definitely consider it if/when I redo the case. This was really just meant to be a stopgap until I get my hands on the devkit, but I'm sure I'll get the itch to make improvements before April.

Post by **3dvison** » Tue Dec 18, 2012 12:46 pm

Hi braddas,
Yes that is the Leep optics I was talking about.
I didn't know you were in the UK, I may have used a term other than cheerio. It's an expression where you are, and a small piece of round food where I am (USA)...

I'm passing time till the Dev.Kit is out also...With my handyman skills, I should have taken a wood working class or a first aid class..or both, in reverse order....

Post by **bobjwatts** » Tue Dec 18, 2012 3:50 pm

Looks good braddas! I like how you have the board and screen in one backing plate.

I managed to get some space between the board and backing. Not sure it matters too much?

I think the headtracking will add a heap of immersion for you.

We have more visitors now so I'm moving at snail pace. Sometimes I consider becoming a hermit with a tricked out workshop

Post by **braddas** » Wed Dec 19, 2012 2:39 am

3dvison wrote:With my handyman skills, I should have taken a wood working class or a first aid class..or both, in reverse order....

Ha ha! Yeah, I don't think I'm particularly qualified to be doing any of this either. For all I know I could have electrocuted myself on multiple occasions while putting all this together! We actually have Cheerios in the UK, so I knew what you meant - it's actually dropped out of common use here, I don't think I've heard anyone say it in years.

bobjwatts wrote:Sometimes I consider becoming a hermit with a tricked out workshop

I'm sure you're not the only person to have considered that! I definitely seem to have less spare time as I get older, no idea what happens to it all.

Post by **3dvison** » Wed Dec 19, 2012 3:45 am

braddas wrote:We actually have Cheerios in the UK, so I knew what you meant - it's actually dropped out of common use here, I don't think I've heard anyone say it in years.

I think I had the expression on my brain, because it's in a Pop song over here (Karmin - Brokenhearted).
Only listen to it braddas, if you really want to hear someone from Nebraska saying Cheerio in a fake British accent...Let me apologize to you right now braddas , on behalf of the USA

Post by **tmek** » Wed Dec 19, 2012 4:16 am

If you guys have D3BFG try it with these console variables:

stereoRender_convergence 0
stereoRender_interOccularCentimeters 6.5 (or whatever your IPD is. The default for this is only 3, it is also represented by the "view offset" slider in the 3D options menu.
g_fov 90
g_showHud 0

The convergence description says "0 for head mounted displays otherwise distance to convergence plane".

You need the hud off because otherwise the hud elements will be drawn at convergence plane (now set to your where your LCD panel is) which is 5cm from your eyes. You can't converge your eyes on something that close (try it with your finger).

Using these values *really* make the 3D stand out. I imagine having steroRender_convergence to the default of 6 (for 3D monitors) is why CyberReality thought the 3D in my screenshots seemed weak. It does make a huge difference when both of these are set correctly.

Post by **Mel** » Wed Dec 19, 2012 9:26 am

tmek wrote:If you guys have D3BFG try it with these console variables:

stereoRender_convergence 0
stereoRender_interOccularCentimeters 6.5 (or whatever your IPD is. The default for this is only 3, it is also represented by the "view offset" slider in the 3D options menu.
g_fov 90
g_showHud 0

The convergence description says "0 for head mounted displays otherwise distance to convergence plane".

You need the hud off because otherwise the hud elements will be drawn at convergence plane (now set to your where your LCD panel is) which is 5cm from your eyes. You can't converge your eyes on something that close (try it with your finger).

Using these values *really* make the 3D stand out. I imagine having steroRender_convergence to the default of 6 (for 3D monitors) is why CyberReality thought the 3D in my screenshots seemed weak. It does make a huge difference when both of these are set correctly.

Could I trouble someone to do a screen capture with the IPD set to 5.5cm? I want to see if this helps my HMD experience at all. Thanks.

Post by **tmek** » Wed Dec 19, 2012 10:49 am

Mel wrote:Could I trouble someone to do a screen capture with the IPD set to 5.5cm? I want to see if this helps my HMD experience at all. Thanks.

Hi Mel, here i've made two screenshots. The first is 6.5cm IPD and the second is 5.5cm IPD. I tried to make them exactly the same otherwise.

If you have a browser that can do full screen (in Chrome press f11) you can alt-tab (or ctrl-tab if they're in the same browser window) between them.

I can actually feel my eye muscles changing as I switch between them. It's a weird feeling!

Post by **Postipate** » Wed Dec 19, 2012 10:51 am

Seems like I blown up my 5.6 monitor and control board... I finally got my foamcore and lenses and started to try if my monitor still works. But nothing happend and I noticed that monitor and control board were burning hot. I tried with another power supply but nothing happens. Only orange light when I power up my control board and no color when I plug my monitor.

Everything worked fine 2 weeks ago, I have no idea what happend while it was in the box.

http://www.ebay.com/itm/5-6inch-TFT-LCD ... 460786d0bf

Hopefully somebody has idea for fixing this. I allready spend too much money for this :/

Post by **tmek** » Wed Dec 19, 2012 11:07 am

Postipate wrote:Hopefully somebody has idea for fixing this.

Ouch

All I can offer is that mine seemed to do this once when I first got it. I unplugged it and let it sit for a while and plugged it in later and it worked. After you let it sit a while, disconnect the vga/hdmi cable and just see if you can just get the blue screen to come up.