RifTUP! FullHD Oculus DK1 upgrade kit

Post by **LaserEdge** » Sun Aug 11, 2013 12:10 pm

Keep in mind that that the HTC One Max is rumored to launch next month. See http://www.theverge.com/2013/8/5/458982 ... unch-rumor. I am almost certain it is using Sharp's 5.9" LS059T1SX01. Based on the spec the active area is 72.9mm X 129.6mm. Also the driver IC is the Renesas R63311, so the DCS write initialization sequence should be the same as JDI's ACX450AKN and Sharp's LS050T1SX01 (set_address_mode, set_pixel_format...). The dimensions of this panel is almost perfect for Rift based application.

@KBK No I don't work for Oculus or any other gaming related company. Just trying to be helpful here. Don't have an HDMI to MIPI board, but could make one.

Post by **KBK** » Sun Aug 11, 2013 1:44 pm

Some shots of the pertinent Gutty bits.

Looks more and more like MIPI. I don't see any 8 pairs of identical lines, here. (from my feeble knowledge of how this should look)

Post by **3dvison** » Sun Aug 11, 2013 1:45 pm

Flim wrote:Best bet is to get the 5.5 and mipi combination working... We can do it now.

I agree.

Post by **LaserEdge** » Sun Aug 11, 2013 2:18 pm

KBK wrote:Some shots of the pertinent Gutty bits.

Looks more and more like MIPI. I don't see any 8 pairs of identical lines, here. (from my feeble knowledge of how this should look)

Looks like MIPI-DSI to me too. You can clearly see the 5 pairs on the cable. Anything 1080P over MIPI-DSI requires 1 clock pair and 4 data pairs. You can clearly see those 5 pairs running together on the PCB. I assume they are heading towards the driver IC.

Post by **MSat** » Sun Aug 11, 2013 2:54 pm

The Nexus7 binaries for AOSP and factory images were completely useless. Besides being mostly shared object files (which I even looked through for telltale strings) there was absolutely nothing in any of the configuration files related to the display

So as far as I'm concerned, that's a dead end.

Interesting pics, KBK. There are indeed 5 identical pairs as well as 3 more, but a bit questionable. Can't really decipher anything from the circuit board pics.

Even 5 pairs wouldn't necessarily mean the panel is MIPI as I have come across an LVDS transmitter that could do F-HD over that. Not that it would make the situation much better, though.

@LaserEdge
Have you worked with MIPI before, or is your knowledge of it derived from the SSD2828 datasheet?

Post by **Inscothen** » Sun Aug 11, 2013 3:05 pm

The 5.5" panel solution is available pretty much right now, anyone that is doing that should probably light up the DIY thread so we can organize and get a group buy or something.

LaserEdge- if you did make a hdmi-MIPI board, how much would it cost? The cost to make and a reasonable buyer cost?

Post by **MSat** » Sun Aug 11, 2013 3:43 pm

Ok that LG panel is pretty damn cheap, and wouldn't require removal from glass like we would need to do if we used the Nexus7 unit. It would require other modifications to the Rift, though - replacement lenses and a bracket to center (and move it a bit closer towards the lenses?).

At any rate, we would still need the datasheet.

Post by **deiby3D** » Sun Aug 11, 2013 3:59 pm

Hello guys,
This is getting interesting
ready for any collective buying

I have the LG 5.5 panel at home waiting for a board

My dev kit came with problems of pixels on the screen

I have good excuse to break the soul.

Excuse my inglish
deiby3D

Post by **deiby3D** » Sun Aug 11, 2013 4:12 pm

MSat wrote:Ok that LG panel is pretty damn cheap, and wouldn't require removal from glass like we would need to do if we used the Nexus7 unit. It would require other modifications to the Rift, though - replacement lenses and a bracket to center (and move it a bit closer towards the lenses?).

At any rate, we would still need the datasheet.

It would require other modifications to the Rift: Not necessarily this solves that little problem http://sugru.com/

Post by **3dvison** » Sun Aug 11, 2013 5:29 pm

maxOh wrote:I did get a feedback about the HDMI/DVI->MIPI board. Sounds quite promising. Here the facts:
HBTM5(MIPI Bridge)_1.pdf
- the board will cost 150 USD
- Minimum quantity seams to be 100(http://www.alibaba.com/product-free/144 ... HBTM5.html), on buykorea it was 10, so let's see how to get a board

OK, isn't that it ? That board and the 5.5 inch LG screen and off we go into 1080p ?
Is it group buy time ?

I don't think it would be that hard to get it into the Rift....I will cut and glue my way to the finish line if I could just get a 1080p screen and board in my hands.

It does look like that other site has a low 10 min order number like posted above.
http://www.buykorea.org/s/GOODS_SN/3007660

Post by **goodl** » Sun Aug 11, 2013 6:13 pm

Count me in on that group buy if its a goer

Post by **Flim** » Sun Aug 11, 2013 6:41 pm

Ya, me as well...

I will cad up a new housing so folks can have them 3d printed.

Post by **3dvison** » Sun Aug 11, 2013 6:58 pm

Whats the best way to do a group buy ? Just pick a senior member we all know and send them the payments for the bulk buy ?
Will we do both the controller board and the 5.5 LG screen as a group buy or is the 5.5 screen easy to buy as a single unit and no need to do a group buy for it ?

Does the LG 5.5 screen listed in those older post, come with a backlight ? Seems to read like it does not ?

Post by **LaserEdge** » Sun Aug 11, 2013 7:41 pm

Parts cost for a HDMI to MIPI-DSI board if only 10 boards are made would be around $60 each. If 100 boards are made parts cost goes down to around ~$50. I would say around $100 is a fair cost for such a board. $150 is too much.

I haven't made any boards around MIPI, but I have read the MIPI-DSI spec. To me it is just another packetized protocol with it commands and structure. I have worked with all kinds of micro protocols over the course of my engineering career. I have worked with much higher frequency and more complicated protocols than MIPI-DSI. To me it is just a protocol aimed at creating a low powered display interface. The circuit design for a HDMI to MIPI-DSI board is straight forward.

Also that Korean board is crap for HDMI application. For HDMI board you want light, small, input voltage of 5V (ie USB input) with peak current of 500mA max. Anything more than 500mA will interfere with the USB communication of the data tracker. If it is designed correctly you should have a board around 5cm X 5cm with HDMI and micro or mini USB inputs, an output header for the USB to tracker board, and a FPC connector specific to the panel that will pair with the board. Sustained current draw for a well designed board should be around 300mA. Then you can run the HMD off a laptop on the go no problem. I believe the extra expense for a low power design is important to meet the goal of portable applications.

Post by **MSat** » Sun Aug 11, 2013 8:48 pm

LaserEdge wrote:Parts cost for a HDMI to MIPI-DSI board if only 10 boards are made would be around $60 each. If 100 boards are made parts cost goes down to around ~$50. I would say around $100 is a fair cost for such a board. $150 is too much.

I haven't made any boards around MIPI, but I have read the MIPI-DSI spec. To me it is just another packetized protocol with it commands and structure. I have worked with all kinds of micro protocols over the course of my engineering career. I have worked with much higher frequency and more complicated protocols than MIPI-DSI. To me it is just a protocol aimed at creating a low powered display interface. The circuit design for a HDMI to MIPI-DSI board is straight forward.

Also that Korean board is crap for HDMI application. For HDMI board you want light, small, input voltage of 5V (ie USB input) with peak current of 500mA max. Anything more than 500mA will interfere with the USB communication of the data tracker. If it is designed correctly you should have a board around 5cm X 5cm with HDMI and micro or mini USB inputs, an output header for the USB to tracker board, and a FPC connector specific to the panel that will pair with the board. Sustained current draw for a well designed board should be around 300mA. Then you can run the HMD off a laptop on the go no problem. I believe the extra expense for a low power design is important to meet the goal of portable applications.

This sounds pretty good. Do you think it would be possible to get the panel working without a datasheet, say, if you had a phone that utilizes the panel by probing it? Is it correct to assume the most important diff pairs to find would be the the clock and data0, then the remaining data line orders could be found by trial and error? I understand that MIPI-DSI allows vendor-specific commands, but should the standardized commands be sufficient to get it up and running?

Post by **Shannonb1** » Sun Aug 11, 2013 8:58 pm

Im in if we do a group buy, just email me and let me know.

Post by **LaserEdge** » Sun Aug 11, 2013 9:09 pm

MSat wrote: This sounds pretty good. Do you think it would be possible to get the panel working without a datasheet, say, if you had a phone that utilizes the panel by probing it? Is it correct to assume the most important diff pairs to find would be the the clock and data0, then the remaining data line orders could be found by trial and error? I understand that MIPI-DSI allows vendor-specific commands, but should the standardized commands be sufficient to get it up and running?

With a decent logic analyzer that has differential pair support you could identify the MIPI lanes. Yes. Clk and Data0 are the easy ones. Data 1, Data 2 and Data 3 are more tricky. You have too look for long packets whose byte count isn't even multiple of 4. With 2 remaining bytes Data0 and Data1 are used, but Data2 and Data3 not. With 3 remaining bytes Data0, Data1 and Data2 are used, but Data3 not.

The rest of the connections can be figured out using a typical multimeter.

Post by **3dvison** » Sun Aug 11, 2013 9:13 pm

Beggars can't be choosers...as the days and months just slip away.

It just seems that the 5.5 LG with that controller board would not be any worse than the DIy Rift I made with the 5.6 screen and controller board. I had the controller board cable extended and that took the controller board off the HMD Head mount and all was great.

Post by **LaserEdge** » Sun Aug 11, 2013 9:31 pm

@MSat Forgot to mention that you will need a logic analyzer anyway to see the DCS write sequence used to initialize the LCD panel.

Post by **MSat** » Sun Aug 11, 2013 10:20 pm

Do you really need to probe both lines of a pair? The data is the same, just inverted, so one should be good enough, no?

I can't comment on the DSI protocol other than the bits an pieces I've come across scouring the web. From my understanding, data0 is the only bi-directional channel in the protocol, so it absolutely necessary to get right (or risk possible damage to the components). I don't know much about clock other than the fact that it also carries sync information. The rest of the data pairs should be able to be connected arbitrarily with no physically ill effects. At best, you get them correct and the image shows up as it should. At worst, the image is incorrect (if it even shows up at all). Your chances of getting the 3 data pairs correct is 1 in 6, so it wouldn't take long to find the right order with a bit of experimentation.

What do the standardized commands cover? My understanding is that vendor-specific ones may cover things such as contrast etc. That's why I was curious if the standard commands tend to be sufficient enough to get a panel up and running at least in its default mode.

I really wish more manufacturers would make their datasheets readily available. It's almost as bad as not even displaying your products at all (I'm looking at you, JDI).

Post by **em4mars** » Sun Aug 11, 2013 10:43 pm

Hi guys,

First off thanks for doing all of this work! I have been following this thread very closely and am REALLY EXCITED about a 1080p Rift. I created a mtbs3d account just so I could respond to this thread - although there is a lot of great info here otherwise.

Count me in on a group buy!

I want to use the Rift to race in iRacing and find the res too low to see things in the distance. I have decent breakdown and mod skills and am ready to give this a try!

Thanks and I look forward to hi-def Rifting!

Marshall

Post by **LaserEdge** » Sun Aug 11, 2013 11:30 pm

MSat wrote:Do you really need to probe both lines of a pair? The data is the same, just inverted, so one should be good enough, no?

I can't comment on the DSI protocol other than the bits an pieces I've come across scouring the web. From my understanding, data0 is the only bi-directional channel in the protocol, so it absolutely necessary to get right (or risk possible damage to the components). I don't know much about clock other than the fact that it also carries sync information. The rest of the data pairs should be able to be connected arbitrarily with no physically ill effects. At best, you get them correct and the image shows up as it should. At worst, the image is incorrect (if it even shows up at all). Your chances of getting the 3 data pairs correct is 1 in 6, so it wouldn't take long to find the right order with a bit of experimentation.

What do the standardized commands cover? My understanding is that vendor-specific ones may cover things such as contrast etc. That's why I was curious if the standard commands tend to be sufficient enough to get a panel up and running at least in its default mode.

I really wish more manufacturers would make their datasheets readily available. It's almost as bad as not even displaying your products at all (I'm looking at you, JDI).

Assuming the master to slave communication stays in low power mode you could probably get by with just probing the positive data lane. The voltage for a high bit on the positive lane will reach around 1 volt. You will of course be seeing only half the bits in low power mode as the negative pair carries the other bits. For high speed mode transmission the voltage swing is only 0.2 volts so it might not register at all with the logic analyzer. In short it is gamble if this short cut will work.

Yes. Data0 is the only data lane that can be used for BTA transfers.

All the panels I have seen want to used sync events during the blanking period rather than sync pulses. That means the master should use short packets with commands 0x01 for V Sync and 0x21 H Sync. So the clock lane should only carry the clock.

Just the standard DCS command set should be sufficient to get the panel up and running. So far it seems the DCS commands should be mostly the same since all the 1080P panels I have seen are using the Renesas R63311 driver IC. I have attached the MIPI DCS specification if you want to read up on the standardized slave commands in detail.

Post by **Raptor5150** » Mon Aug 12, 2013 1:28 am

What so were all abandoning the direct 7 inch replacement to the dev kit??

Why do we need 5.5 inches .... We have a housing already and lenses that work fine.. Im trying to make this more cost effective than hey lets make my own HMD and slap a 1080p 5.5 screen instead of using what I already have.

not what we set out to do guys...

Post by **Endemo** » Mon Aug 12, 2013 1:56 am

Guys this is really interesting to read. Even if i am just a graphics guy and barely understand all the technical chinese you folks are talking.
What i do know is that i would really apprechiate if i could join a possible groupbuy for that controller (and the screen?). Also i got a friend at hand that could print out custom plasticparts for me if i provide the stls. I am a simmer at heart and being able to experience all the gorgeous sims in full HD is everything i just dreamt about. So please. Count me in!

Endemo

Post by **Mattijs** » Mon Aug 12, 2013 2:38 am

count me in for a group buy too...

Post by **Mattijs** » Mon Aug 12, 2013 2:44 am

it would actually be funny if somebody decided to do a kickstarter for a rift upgrade kit

.
Seems very doable no?

Post by **Endemo** » Mon Aug 12, 2013 2:51 am

Mattijs wrote:it would actually be funny if somebody decided to do a kickstarter for a rift upgrade kit .
Seems very doable no?

And receive instant message from Oculus VR lawyers:)

Post by **Mattijs** » Mon Aug 12, 2013 3:29 am

Endemo wrote:
Mattijs wrote:it would actually be funny if somebody decided to do a kickstarter for a rift upgrade kit .
Seems very doable no?
And receive instant message from Oculus VR lawyers:)

you think that would happen? They could just name it HMD upgrade without mentioning OR or something...or DIY 7 inch HD HMD screen (provide own tracking solution).

Post by **yunti** » Mon Aug 12, 2013 3:41 am

I'm definitely in for a group buy.

I appreciate that the nexus 7" would potentially be more drop in with the existing Rift HMD, but with a lack of datasheet and the issues of the bonded glass, not least the fact that Oculus have also gone with the LG5.5" display I would much rather go that route. If it means I potentially having an uglier HMD became it has to be hacked together a bit more. I think that's a fair compromise for 1080p.

Post by **Freakling** » Mon Aug 12, 2013 5:29 am

Raptor5150 wrote:What so were all abandoning the direct 7 inch replacement to the dev kit??

Why do we need 5.5 inches .... We have a housing already and lenses that work fine.. Im trying to make this more cost effective than hey lets make my own HMD and slap a 1080p 5.5 screen instead of using what I already have.

not what we set out to do guys...

Agree... I'd rather see a 7" screen upgrade so the current lenses and housing can be re-used.

Post by **remosito** » Mon Aug 12, 2013 7:03 am

Freakling wrote:
Raptor5150 wrote:What so were all abandoning the direct 7 inch replacement to the dev kit??

Why do we need 5.5 inches .... We have a housing already and lenses that work fine.. Im trying to make this more cost effective than hey lets make my own HMD and slap a 1080p 5.5 screen instead of using what I already have.

not what we set out to do guys...
Agree... I'd rather see a 7" screen upgrade so the current lenses and housing can be re-used.

Priorities differ!
7" results in a lot of wasted pixels and less pixels visible!
5.5" has a lot more visible pixels! At the cost of seeing borders if your IPD is big (or wasting center pixels by increasing lens magnification/screen coverage)

Increased pixel density via smaller screen is one of the reasons the Rift HD prototype looks SOO much better than the standard DK... (others are better contrast/saturation and maybe pixelfill ratio)

Post by **geekmaster** » Mon Aug 12, 2013 7:29 am

With custom optics, screen size does not really matter. Optics can magnify and shift the image. A smaller screen requires more magnification, which may cause a smaller "sweet spot". To require less careful optical adjustments, a larger screen with smaller magnification may be preferred, but tangential distortion correction may be required (depending on optics used). You can test this with a 7-inch screen using the 2-inch 5x aspheric lenses from the "DIY Rift" thread.

Post by **remosito** » Mon Aug 12, 2013 7:42 am

geekmaster wrote:With custom optics, screen size does not really matter. Optics can magnify and shift the image. A smaller screen requires more magnification, which may cause a smaller "sweet spot". To require less careful optical adjustments, a larger screen with smaller magnification may be preferred, but tangential distortion correction may be required (depending on optics used). You can test this with a 7-inch screen using the 2-inch 5x aspheric lenses from the "DIY Rift" thread.

Very true indeed. Though custom optics that do specifically what you want is anything but trivial!

Which is why THE item in the Oculus Lab I am most curious about are the "our next gen optics are a lot better." palmer mentioned on reddit! Are those already in the HD Prototype? What screen size are they tailored for? What's their FoV?

If they are in the HD prototype, then they are not tailored for the 5.5" HD screen as ppl noted being able to see screen borders...

Post by **KBK** » Mon Aug 12, 2013 9:40 am

MSat wrote:The Nexus7 binaries for AOSP and factory images were completely useless. Besides being mostly shared object files (which I even looked through for telltale strings) there was absolutely nothing in any of the configuration files related to the display
So as far as I'm concerned, that's a dead end.

Interesting pics, KBK. There are indeed 5 identical pairs as well as 3 more, but a bit questionable. Can't really decipher anything from the circuit board pics.

Even 5 pairs wouldn't necessarily mean the panel is MIPI as I have come across an LVDS transmitter that could do F-HD over that. Not that it would make the situation much better, though.

@LaserEdge
Have you worked with MIPI before, or is your knowledge of it derived from the SSD2828 datasheet?

I would expect that eight differential pairs of signals would require 8 pairs of perfectly spaced and terminated copper traces on these cables, in order to perfectly control impedance loading of said specific signals.

It is a matter of using a different cable and different termination, at either end, if it was LVDS. since Asus has large experience in running dual LVDS, I would suspect that they would have no problems in building such a system. There would be no need or reason whatsoever to try and 'fudge a fix' when they can simply do it right for zero extra dollars or expense, and pull a working scenario from their extensive database of direct functional experience, and drop that in. To do it with 5 being right and three being off, is a 'chance' & a risk, and is dice rolling...which...at this level of expertize and manufacturing, that sort of chance is not taken.

Therefore, with no perfectly physically identical runs of 8 differential pairs on the cable, but only 5.... we end up at a MIPI interface being incredibly likely, in this case. The MIPI impedance loading being identical for it's required 5 differential runs. That is what this cable says to me, when I look at the fairly clear image of the panel termination end of the cable.

My next issue is that I have no idea HOW MIPI works on the fundamental level of panel matrix addressing. If it is encoded, I would think that I need to see a break out of some sort, via some form of IC, but it's been a VERY long time since I looked at how modern LCD panels are addressed concerning the actual load presented to actual pixels. I'm guessing it is a cross between native impedance design at the actual LCD pixel level and then it holds steady 'long enough' until the next level change comes along. I'm a bit fuzzy on the addressing of the matrix, is what I'm saying. When I peeled back the shielding I found no matrix addressing chip, and I THINK all I saw was power and filtering, other than what you saw. (feeling the remaining covered up bits with a fingertip and comparing to the exposed bits, I find no other chips, just power filtering, etc)

I'm guessing that it is a good ole logic flip system that is built into the panel itself. (I like to guess ahead of time. Helps keeps the mind sharp, for those times when you really don't have jack poop for data. Now I'll go and read about it)

Post by **deiby3D** » Mon Aug 12, 2013 10:54 am

maxOh@ We already have more than 10 willing to buy the board collectively

My eyes do not support more so poor Res.
It is regrettable that OR does not want to collaborate with this update, even with the information

avoided this whole letter soup... and many diseases.

deiby3D

Post by **Flim** » Mon Aug 12, 2013 11:03 am

Unless laser is willing to build a custom board...?

Post by **KBK** » Mon Aug 12, 2013 11:16 am

Flim wrote:Unless laser is willing to build a custom board...?

The custom board is not required if a HDMI/DVI to MIPI-HD board exists. Which the Korean example says it does.

At that point, the next problem...it is the addressing of the panel itself, what it needs to see on each pin and how that is sequenced.

most makers of these boards (LVDS, for example) expect you to specify which panel you want the board to work with, so they can flash the board's chip with the required details, so the board and the LCD panel can talk to one another.

In this case, we have a custom panel with no advertized specs or data published for addressing the panel. It is highly likely that the panel uses standard addressing protocols which are industry standards, but there may be some things that need to be known ahead of time and are not capable of being guessed at.

I have a unit and I'm capable of doing some simple tests, like identifying pin usage on the cable in the general sense. i can get to the point where i can label most of the cable and connector pins through the process of elimination.

In this case, most of this 'problem' would go away with a FULL snapdragon 400 implementation PDF, as the pin outs would be identified. It is also possible to interrupt the data flow to the panel, the data flow that is sent out by the snapdragon, and probably gain most of what we need to know, from that.

Depending on the number of DVI/HDMI>MIPI boards the company might be able to sell to the individual, they might be willing to do that for the buyer of said boards. It also depends on how the board manufacturer feels about doing such a thing (working with a panel that has yet to reach 'general release').

Post by **Flim** » Mon Aug 12, 2013 11:46 am

Well,

we saw a pic of the 5.5 working, so it looks that they already did the hard work...

Post by **LaserEdge** » Mon Aug 12, 2013 12:42 pm

@KBK There is already a standardized command in MIPI for controlling how address mapping of pixels is done to the LCD matrix. Read the MIPI DCS Specification. I posted it in page 6 of this thread. Look at the set_address_mode command. Also having the datasheet would be great, but if you have the right tools in the lab you could reverse engineer the panel interface. I don't have the proper logic analyzer for it.

@Film I am in the middle of making my own HDMI to MIPI PCB. Currently waiting for the PCB to be delivered from the fab. Haven't been planning on selling it. Even if I did have plans to sell it I would want to have a nice working prototype before talking about selling it.

My goal here is to help you guys get to 1080P. The quickest way to get there is to have someone reverse engineer the 2nd gen Nexus 7 panel interface and have someone with a working HDMI -> MIPI board do a quickturn PCB to interface to it. I am in agreement with Geekmaster that going the 5.5" route requires new optics and likely a new housing due to focal distances being different. Possible even all the Rift software might be incompatible.

Post by **Flim** » Mon Aug 12, 2013 1:07 pm

Well, I'm not quite sure about the lenses, because in all the proto 1080 pics I see the same lenses... I doubt they changed anything except some possible software tweaks.

Also, the nexus screen is not available nor the data sheet... so it will take another 6 months to get the info you need to maybe make it work, while it looks you can buy the MIPI converter board now with the 1080p 5.5.

Might as well wait for Oculus to come through...