Is low persistence possible on dk1?

[wileythecoyote]

Is it possible to implement black frame insertion or backlight strobing on dk1?
I'm talking about software fix on a hardware problem...
At least the backlight on dk1 is plenty bright to give out sufficient light levels even while strobing.

[GeraldT]

I do think that while you might be able to do the software magic behind it there is little to gain since the LCD display lacks the pixel switching time to remove the visual garbage. From what I understand you need a very fast display first and then you apply the low persistence to only show visual data while the data is correct.

[MSat]

The pixel switching time is crap, which in some cases probably exceeds the frame duration. However, at least low persistence backlight strobing won't make the image any worse. At 60hz, the flicker would probably be annoying though. I think people experimented with theirs running over 70hz, which would be at least a little better.

I'm not sure how you could properly strobe the backlight in a non hack-ish way. The only way I can think of -- and I don't know how practical it would even be on the rift's panel -- would be to intercept the address data for the last row driver IC, and when you detect the last row being addressed, you have a trigger to pulse the backlight. It doesn't actually have to be the last row; it could be the first, but the method would be the same. Perhaps there's a way to make the Realtek interface IC control the backlight like that, but I wouldn't know it.

[zalo]

If anyone here has the technical know-how to strobe the backlight by intercepting the driver signals, that person would be a community hero.

I'd try it with a more hacky method (strobing the backlight's power with an arduino using a photosensor on the main monitor (obv that wouldn't work, but something like that)), but I'm kinda foggy on the specifics of hardware hacking.

I imagine it involves measuring the voltages going to the backlight, and then cutting those traces and soldering my own device there...

[geekmaster]

The simplest way to tap the VSYNC pulse may be to use a cheap HDMI to VGA adapter, which has VSYNC out on a VGA pin:
http://www.amazon.co.uk/Neewer-Black-Ad ... B007KEIRNG

But you still need to hijack the internal backlight LEDs.

Because your eyes dark adapt, it mignt not be necessary to overdrive the LEDs during their one msec on time. A user-adjustable brightness control would probably be needed, which controls LED drive current.

It should be obvious, but any solution that requires opening the Rift or its controller box voids the warranty, but it is a DEVELOPMENT KIT (from a Kickstarter campaign) after all, and we are lucky to even HAVE a warranty.

Alternatively, it might be possible to control the backlight over USB (perhaps with a custom Rift firmware hack). But that would have complexities from interaction between USB and HDMI timing and variable relative latency.

EDIT: By "simplest", I mean least invasive, and simplest to get working with the least effort. From a manufacturing POV, it makes more sense to tap into an existing internal signal, if available, or perhaps add a cheap HDMI decoder IC to extract timing information if needed.

[MSat]

Interesting idea on using the VSYNC signal, geekmaster. It's unfortunate than Oculus didn't implement VGA support in the Rift (and shame on them for using the wrong DVI connector ).

If you look at this pic from the iFixit teardown http://d3nevzfk7ii3be.cloudfront.net/ig ... bsmEA.huge on the bottom left corner is a 2 conductor ribbon cable which is likely what runs to the backlight LEDs

Another method (though not ideal) would be to have a circuit that strobes the backlight at whatever your refresh rate is, and the ability to tune the phase of the strobing. This would require you to manually tweak the phase until it "looks right", though it will probably slowly go out of phase so you would need to tweak it every once in a while.

[zalo]

I'm thinking about routing the backlight power into a digispark w/ MOSFET and controlling the phase of the strobe via USB. This way I can still adjust the brightness via the control box while using a custom serial app for initial phase correction.

Interestingly, I think Palmer has the most experience screwing with backlights since he added them to several handheld devices...

[MSat]

I'm thinking about routing the backlight power into a digispark w/ MOSFET and controlling the phase of the strobe via USB. This way I can still adjust the brightness via the control box while using a custom serial app for initial phase correction.

Interestingly, I think Palmer has the most experience screwing with backlights since he added them to several handheld devices...

I think an app would require manual tweaking as well, so it might just be easier to have a potentiometer on the board to tweak the phase.

[MSat]

One more thought.. While I don't have the datasheet for the Realtek RTD2483 used in the dev kit, I have one for the 2662 which appears to have a very similar pinout. According to the datasheet, pin 97 is "Display V Sync". While that isn't used for LVDS displays, I can't help but wonder if it's active anyhow (probably not, but who knows?). I don't have an O-scope, but maybe I could use the frequency/duty cycle counter on my multimeter. I think I'll give it a shot tomorrow. If it is active, then we're golden

[zalo]

Please let us know what you find!

A reddit thread shows that the Crystal Cove prototype was running around 76 FPS, so 71hz sounds like a very reasonable frequency for good strobing.

Especially because we have no idea when DK2 is coming out!

[cgp44]

Check out the latest interview video. Palmer said low persist was only possible
When they had pixel switching next to nothing.

[virror]

If we could just grab the v-sync, the backlight strobing would be pretty trivial to add, would be cool if that pin was active, then it might be possible to use that directly to drive a MOSFET or similar to strobe the backlight.

[MSat]

So I opened up the controller box with the expectation to probe the V-Sync pin just to be greeted by the Realtek chip with painfully small pin pitch (I couldn't "appreciate" how small it was when I had the iFixit images blown up on my monitor). There's no way I can get my DMM probe on it without touching adjacent pins. Even if I could verify that it was active, soldering a wire to it would be practically impossible.

[android78]

I can't find the datasheet for the Himax HX8851, however it is likely to be similar to:
http://lcd-screen.com.ua/data/pdf/HIMAX ... HX8801.pdf
It would seem that the DVS pin is what you'd want. It would be really nice if one of the test pads on the lcd controller board.
@MSat - Since you're pulling yours apart, do you have a scope that you could just test each of the test pads on the controller board and see if any of them have a fairly consistent 60Hz pulse? Checking the pins is fine, but likely to end up shorting something.

[MSat]

I can't find the datasheet for the Himax HX8851, however it is likely to be similar to:
http://lcd-screen.com.ua/data/pdf/HIMAX ... HX8801.pdf
It would seem that the DVS pin is what you'd want. It would be really nice if one of the test pads on the lcd controller board.
@MSat - Since you're pulling yours apart, do you have a scope that you could just test each of the test pads on the controller board and see if any of them have a fairly consistent 60Hz pulse? Checking the pins is fine, but likely to end up shorting something.

The 8801 appears to be a timing controller with an NTSC/PAL composite input rather than LVDS. Interesting, but substantially different from what's in the Rift.

I closed the interface box back up already. The pin that I was curious about is unconnected, and there's nothing else that should be providing a V-sync signal. I doubt there would be such a signal on the panel itself either.

[MSat]

So I gave it a shot anyway. Since adjacent pins are GPIO and likely in a HI-Z state, I probed them as a pair (or whatever my DMM probe would land on). Sadly, I have no good news to report.

[Fredz]

So the only solution would be sending a signal via software on the DDC pin of the DVI connector or to a USB interface then ?

[MSat]

So the only solution would be sending a signal via software on the DDC pin of the DVI connector or to a USB interface then ?

I'm not familiar at all with the computer side of things. Is there a way to actually know in real time when a frame is getting sent down the wire? I suppose there must be something if you can lock to V-sync.

[virror]

To bad : /

[wileythecoyote]

My opinion is that this should be implemented by locking the backlight strobing to v-sync. On the engineering side, I unfortunately don't have any clue how this could be done.
(has anyone tried to tap into v-sync from the display driver board on the headset itself?)

Black Screen Insertion was a bad idea to begin with on my part You'd need at least 120 hz panel for that to be usable.

But I'm glad I left this topic here for future use. Maybe when we get our upgrade kits ready, we'd might be able to introduce some form of low persistence to our devkits

Otherwise they'll be in the bin or a desktop ornament when the dk2 or ck1 comes out.

(I actually made a IR point model for my rift to experiment with positional tracking, but my freetrack setup ain't cutting it in vr. I have order some lenses for ps3 eye cam and try with that and perhaps find another software to handle optical tracking. Freetrack doesn't have decent camera calibration so field of view causes translation errors.)
http://djsa.pp.fi/riftpointmodel.JPG

[geekmaster]

Like I said, get VSYNC from a cheap HDMI-to-VGA adapter, with a cheap HDMI splitter of course. No soldering to tiny pins that way.

[virror]

Should work i guess, would make it less intrusive as well.

[geekmaster]

Should work i guess, would make it less intrusive as well.

At least until you polish your skills at soldering to tiny pins.

Regarding soldering to tiny pins, I would start with a TINY wire, and let solder bridge multiple pins while soldering it in place, then use solder wick to remove excess solder. Attach the wire to the PCB with tape for strain relief, then solder larger wire to the other end of the wire. Use adequate magnification while soldering.

The reason for using external VSYNC extraction is for proof-of-concept, to see how well it CAN work, before commiting to hacking the internal circuitry.

[Fredz]

I'm not familiar at all with the computer side of things. Is there a way to actually know in real time when a frame is getting sent down the wire? I suppose there must be something if you can lock to V-sync.

I did it for Linux some years ago, sending DDC signals over VGA/DVI for 3D glasses via interception of the IRQ on NVIDIA GPUs (ie. at each vertical retrace). I guess it can be done on Windows as well, you may have a look at WinSGL for this. I've tried refactoring the code for a recent kernel without success yesterday but I'll have another try at it.

[MSat]

I'm not familiar at all with the computer side of things. Is there a way to actually know in real time when a frame is getting sent down the wire? I suppose there must be something if you can lock to V-sync.

I did it for Linux some years ago, sending DDC signals over VGA/DVI for 3D glasses via interception of the IRQ on NVIDIA GPUs (ie. at each vertical retrace). I guess it can be done on Windows as well, you may have a look at WinSGL for this. I've tried refactoring the code for a recent kernel without success yesterday but I'll have another try at it.

How does this work given that DDC uses an I2C physical protocol that seems tied to an eeprom in the display?

DDC1[edit]
DDC1 is a simple, low-speed, unidirectional serial link protocol. Pin 12, ID1 functions as a data line that continuously transmits the 128-byte EDID block, and the data clock is synchronised with vertical sync, providing typical clock rates of 60 to 100 Hz.

Very few display devices implemented this protocol.

too bad

[Fredz]

How does this work given that DDC uses an I2C physical protocol that seems tied to an eeprom in the display?

Have a look here : http://www.mtbs3d.com/phpbb/viewtopic.php?f=16&t=7691

Very few display devices implemented this protocol.

too bad

There were also several DVI sync extractors that were used to drive shutter glasses with a VESA connector but they seem quite expensive (3DTV DVI Vesa Sync Splitter, Moome EXT-FULLHD V3 3D, 3D VESA DVI Sync Dongle, VesaDong).

Some years ago Petrus designed a DVI sync extractor, could be an interesting alternative : http://www.mtbs3d.com/phpbb/viewtopic.p ... 474#p49474

[MSat]

Good stuff, Fredz!

First off, does anyone know if games recognize the Rift without having the DDC bus connected? I'd prefer it if we could abuse the bus without potential interference, and it might actually be necessary in case we can't bit bang the I2C bus (I'm looking at you, windows), and are forced to send a "proper" packet.

In the event that we can't arbitrarily set the SDA line the way we want, I'm thinking of a circuit that triggers on a hight to low transition of the SDA line (since SDA is normally high) and settles back to its wait state after a couple ms (to ignore any additional transitions of the SDA line).

[Fredz]

With the DVI sync extractor from Petrus you wouldn't need to send DDC signals by software at each vsync. From what he said it shouldn't interfere with the signal if the display does respect the DVI specification (was the case with his LCD monitor but not with his projector).

I didn't remember this thread at first, nice to know that the blue link is also used for the digital sync. It's even mentioned on the DVI article on Wikipedia but I didn't remark that before either.

[MSat]

With the DVI sync extractor from Petrus you wouldn't need to send DDC signals by software at each vsync. From what he said it shouldn't interfere with the signal if the display does respect the DVI specification (was the case with his LCD monitor but not with his projector).

I didn't remember this thread at first, nice to know that the blue link is also used for the digital sync. It's even mentioned on the DVI article on Wikipedia but I didn't remark that before either.

Wow.. total brain fart.. I completely ignored your link to the sync extractor. This is a wonderfully simple circuit! I'm not gonna pretend I fully understand how it works just yet, but as long as it does, this is definitely our best bet.

Now to go read up on the DVI protocol....

[Fredz]

Wow.. total brain fart.. I completely ignored your link to the sync extractor.

Yay that's what I figured and why I posted a follow-up, since that's basically what you were looking for.

Btw I got an idea while reading a thread about shutter glasses at the Oculus forums :

You could use them to simulate strobed backlighting, by keeping both eyes shut for most of the time and opening them only for a short amount of time (1-2ms) when the pixels are ready (after 15ms from the specs of the panel in the Rift DK1 at panelook).

You'd need to invert the cabling of the glasses for one eye to have both eyes synchronized. You'd also need to design a circuit to activate the glasses after a defined time after vsync and for a defined duration (with potentiometers). I think Petrus posted the schematics for a signal retarder for 3D glasses somewhere that could be helpful.

The biggest problem would be to find glasses big enough that can fit on the Rift lenses or behind them, but the general idea seems a little bit more feasible than a backlighting mod to me.

[MSat]

The use of shutter glasses is an interesting idea, which as you stated, wouldn't require any hardware mods to the Rift itself, thus making it more accessible.

I don't think you would need or want any delay, otherwise when you strobe, you'll catch it while a new frame is getting drawn. There's just not really any way to avoid the pixel switching, unfortunately.

Fitting the shutter glasses behind the lenses is an interesting idea, but I finally opened up the headset to take a peek (long overdue, I know ), and it would be a bit tricky - the problem is you're unlikely to find the right size so they would either be too big to fit, or not big enough to block out the entire screen. Sitting them above the lenses is probably the best bet.

[cybereality]

Wearing shutter-glasses with the Rift? Hmm...

[MSat]

^ Well not all of us get to play with Crystal Cove

[Fredz]

I don't think you would need or want any delay, otherwise when you strobe, you'll catch it while a new frame is getting drawn. There's just not really any way to avoid the pixel switching, unfortunately.

I meant using a delay before opening the shutter because the pixels are only correctly lit after the Tr response time of the panel has been attained (15ms according to the specs). That leaves 1.66ms for the opening of the shutter for a 60Hz refresh rate, it'll be a bit problematic for higher frequency like the 90Hz Oculus talked about (11.11 ms for a frame).

Fitting the shutter glasses behind the lenses is an interesting idea, but I finally opened up the headset to take a peek (long overdue, I know ), and it would be a bit tricky - the problem is you're unlikely to find the right size so they would either be too big to fit, or not big enough to block out the entire screen. Sitting them above the lenses is probably the best bet.

Yes it's going to be a bit complicated. Maybe LC shutters can be found in different form factors than the ones found in 3D shutter glasses, something like the ZScreen used for DLP projection or older CRT monitors :

[MSat]

I don't think you would need or want any delay, otherwise when you strobe, you'll catch it while a new frame is getting drawn. There's just not really any way to avoid the pixel switching, unfortunately.

I meant using a delay before opening the shutter because the pixels are only correctly lit after the Tr response time of the panel has been attained (15ms according to the specs). That leaves 1.66ms for the opening of the shutter for a 60Hz refresh rate, it'll be a bit problematic for higher frequency like the 90Hz Oculus talked about (11.11 ms for a frame).

But remember that pixels are addressed sequentially, so the last pixel wouldn't be ready until ~15ms after the first one is - basically 30ms after the frame starts, or 15ms into the next frame....

[Fredz]

Ah yes I didn't think about that, I feel stupid now. :/

Still, since Tr response time is for the worst case I suppose a lower value than 15ms could be used before opening the shutter, but that'll still give a big latency as you said (16.7 to 31.7ms for a 60Hz refresh rate). The Rift can be driven at 71Hz without artifacts, so that would give a latency between 14ms and 29ms, probably with a lot of ghosting from previous frames though.

[MSat]

is it 15ms from white to black, or grey to grey? My understanding is that the latter usually takes longer.

One thought that's been brewing in my head for a little while is to start the new frame a little later in the refresh cycle in an attempt to at least have the mid section of the the image ready by the time the display is strobed.

Essentially the top 1/3rd of the old frame and bottom 2/3rds of the new frame is moved to the display buffer, and the backlight (or shutter glasses) are strobed 1/3rd frame duration after V-sync. This is constantly repeated so that in essence you're starting a new frame a 1/3rd of the way into the scan, so therefore the center section of pixels should finish switching first giving a crisper image in that area, while the top 1/3rd finishes last.

Granted, this is a bit silly and has no real use outside of the Rift, or other LCD-based HMDs that don't have the benefit of "overdriving".

[Fredz]

is it 15ms from white to black, or grey to grey? My understanding is that the latter usually takes longer.

I think it's the opposite actually, I've read that several times on different sites and Wikipedia seems to confirm it :

"For an LCD display, typical response times are 8 to 16 ms for black-white-black, or 2 to 6ms for grey-to-grey"

From : https://en.wikipedia.org/wiki/Response_time_(technology)#Display_technologies

This makes sense to me also because intuitively it should be faster to go from say a 128 to 132 gray level than from a 0 to 255 gray level.

If the firmware in the controller board could be modified to give more voltage for pixel illumination, I suppose the pixel switching times could be reduced in the same way overdrive works on fast panels (see : http://www.bit-tech.net/hardware/monito ... verdrive/1).

But at this point it looks a lot more easier to simply go for OLED panels.

[MSat]

From that wiki link:

For an LCD display, typical response times are 8 to 16 ms for black-white-black, or 2 to 6ms for grey-to-grey. The response time was traditionally recorded at the full black > white transition, which became the ISO standard for this specification on LCDs. Grey transitions are far more common in practice but in terms of pixel latency, they remained significantly behind the ISO transition. In recent years there have been a wide range of Response Time Compensation (RTC) / overdrive technologies introduced which have allowed panel manufacturers to significantly reduce grey transitions.

that reduction in grey-to-grey pixel switching time is due to overdriving, whereas it used to take longer than black to white. The reason is because the pixel switching speed is proportional to the applied voltage to the liquid crystal; the higher the voltage, the faster the liquid crystal moves to its correct position. Since black to white is achieved by supplying maximum voltage to the liquid crystal, it would move at the fastest velocity possible. Greys require lower voltages, so they switch slower. Since overdriving works by applying the maximum voltage to a subpixel during its transition, it has no effect on black to white since that normally requires max voltage anyway. Basically, overdrive tries to achieve maximum liquid crystal velocity for transitions, so the ones that would benefit most are the ones with small delta values, i.e. grey to grey.


But yeah, OLEDs are the way to go, though I thought we were still talking about the DK1

[Fredz]

Ah good catch I should have read this article and others better, so GTG is only good because of overdrive technology. Confirmed by this article at TFT Central also.

So without overdrive the 15ms response time is a best case, to me that rules out any experiment with non-overdrive LCD panels.

For the ZScreen-like shutters, in an older thread on MTBS3D the ZScreen sold by DepthQ was quoted at $2,500, another module from Tyrell Innovations at $400 and the PolaRotator at $850, so that's probably a no-go as well.

Too bad because the PolaRotator size looked like a good fit when placed inside the Rift (74x74"), two of them could probably be put slanted inside the HMD.



I fail to understand why it's so expensive when shutter glasses can be found for less than $50 though.