DLP4710: Max 8-bit (grayscale) framerates achievable with DLP4710 and DLP470TP

Sure.

blogs.valvesoftware.com/.../
blogs.valvesoftware.com/.../

1. The problem to solve is minimization of rainbow artifact and judder to an acceptable level for DLP head mounted displays with high FOV when user moves his eyes from one point to the next relatively fast (eg. media.steampowered.com/.../blog11fig7.jpg).
For regular projection screens this is not as much of a problem as the viewing distance creates a relatively smaller FOV than a head mounted display.
2. Yes, I understand
3. Of course, but first would like to know if is even possible
4. Yes, www.statista.com/.../
Majority of the VR market is OLEDs which have a refresh rate of  <=1ms.

Admittedly, I, nor anyone else have tried yet building and testing 120Hz or 240Hz for head mounted displays with a FOV of over 90 degrees horizontally. So the rainbow artifact and judder may or may not be as noticeable as with 60Hz. Only way to know is to build and test one. But if it fails to meet the expectations, we need a backup plan to secure the investment in the research and development. One option is to go with 2 more DMDs each running in grayscale to get the refresh rate down all the way to 1.39ms, and target the developed product for the prosumer market instead of consumer.

Please follow me through this.

1) From what I know the colors in DLP are color-sequential. For each frame there are 3 subframes and each subframe is for each color channel. Each subframe the corresponding LED is modulated 8 times (is on or off), or more but that is irrelevant for the reason mentioned below. All the LEDs together are modulated 24 times only each frame, so total modulation each second for a 60Hz/fps system is 1440Hz or 480Hz for each color channel. I think this is the values you meant. This causes, like wth LCoS displays, "color fringing" in virtual reality. It may not be as noticeable in pico projectors where the viewing distance makes it comparably lower to a VR headset's field of view and the screen is fixed therefore head rarely rotates and eye rotations are relatively small and slow, but for a relatively high FOV where there are head movements this color separation is more noticeable: 

Please check the white dot in the middle starting from 0:11 that is separated into its color channels when the user's head moves. This is because when the user rotates or moves his head, at one angle the projector only has time to show him one color channel subframe and in another angle after few milliseconds the other color channel(s) subframes. Hololens uses a 60Hz color sequential LCoS and 240Hz will definitely help, but hopefully you get the problem.

Issue is not how fast or how much LEDs are modulated each subframe, issue is each subframe takes 1.43 ms even at 240Hz and if the user rotates his head just a little the one or more color channels will appear not where the other one(s) appeared to the eye.

This likely woulnd't be a problem if instead of color sequential subframes for each frame the LEDs were modulated as such: R, G, B, R, G, B, R, G, B, R, G, B, R, G, B, R, G, B, R, G, B, R, G, B where each (R, G, B) was the subframe instead of having LED modulation per subframe in this order: R,R,R,R,R,R,R,R, (or G,G,G,G,G,G,G,G, or B,B,B,B,B,B,B,B depending on current subframe).

2) But even then, this would solve the color fringing issue, but not judder, which is smearing of pixels (motion blur) due to relatively high persistence of DLP which needs time to create pixel intensity via modulation VS OLEDs which have analog pixels and can have extremely low persistence by showing the pixel for 2ms, then inserting blank frame for the rest of the time of the frame. Again if your head is pointing in one direction for 1.43ms and slightly different angle after, the other color channels will appear, due to persistence of vision, offset from that color channel.

To solve judder, also known as motion blur, without going over 240Hz DMD would need to be able to module 24 times in only 2.1 ms or less vs 4.3, then do nothing for the rest of the time left for the particular frame.

LCD solves this by strobing the LED backlight at fast 200Hz+ speeds and that is referred to as "black frame insertion"

With VR motion blur is not only about reduced visual clarity but also motion sickness for some users because it happens at a much higher field of view compared to projection screens at typical viewing distances.

Now again, 240Hz is much different than 60Hz and 4.3 ms is much imrovement from 16.6 ms refresh time at 60Hz and is much closer to OLED's (Oculus Rift) 2ms, but I do not know if it is still acceptable and researching and developing a headset just to check is risky.

It seems like I underestimated what DLP is capable of and have been fed false information by people in the AR/VR business who have the wrong idea themselves and / or lump DLP and LCoS together and falsely explain how both work the exact same way when it comes to modulation and persistence time of each frame. I'll be sure to notify them of the actual workings of the pico DMDs.

Thank you for the clarification.

To be clear, is this how pico DLP DMDs work VS standard size single chip DMDs with lamp illumination and color wheels, thanks to the modulation speeds LEDs/lasers allow? (the "color biplanes") or is this also how the older color wheel systems worked?

This other question may be inapropriate to ask here as it's related to a competing product and if so feel free to ignore it but if you have permission to answer it do you know if LCoS modulates similarly or there's an inherent speed limit with LCoS? Because of all the pico projetors I've tested LCoS always seems to have worse rainbow artifact at the same claimed refresh rate.

When you say "10x -20X color refresh", what does color refresh mean here? I assume whatever it means it is repeated 10-20 times? And per frame or per 60 frames?

When you say "actual LED color switching", do you mean the DLP controller can be set to use the modulation speeds the specific LED is capable of and the faster the better? What's the theoretical, suggested and practical upper limit?

When you say at 60 fps 50% of the frame time can be used to display the image and do nothing the other 50%, does this come in cost of lowering the bitrate of each color channel? I assume no based on what you described above on color biplanes but I want to be certain.
Second question regarding this, how much of the frame time can you use for darks this way and how is the limit determined?
For example at 240Hz for DLP470TP how much of each frame can be used to display nothing?

For VR the optimum time to have each frame shown (frame persistence) to reduce motion blur and motion sickness appears to be 1.9-2ms. At 240Hz 4.17ms is close but not as close as I would wish. If we could halve that it would be perfect.

Thank you very much.

"These dark time & color cycle information is based on simple estimation and we have not implemented it."
What do you mean? Not implemented on DLPC6421 & DLP470TP, yet?

"For DLPC6421 & DLP470TP chip-set @ 240 Hz frame rate , 25% dark can be supported . We can also do 8 color cycles in every frame with 25% dark time."
I don't understand this part as well. In the first sentence you say 25% dark can be supported but on the second you say you can "also" do 8 color cycles in "every" frame at 25% dark. What's the difference in these two sentences? Isn't dark inserted after every frame? How many color cycles can you do with @ 240 Hz frame rate , 25% dark as you stated in the first sentence?

Power consumption is no problem but I don't understand where the FPGA comes from here.

That FPGA costs more than the DMD + all the ICs and in my case even the illumination engine. No way that can be a practical solution for anything mass produced. Please provide an alternative, a full FPGA just to drive your DMD at a fixed 240fps is overkill. Adds nearly 80% to the production cost.

I just checked the reference design again and its not actually suited for many use cases where you need 240Hz/fps video. It takes 4K video frame and chops it into 4 1080p frames. That means the 4th frame displayed will need to be pre-rendered and delayed frame_timex3 milliseconds. For things such as gaming the high framerate/refresh rate is there to display frames rendered in realtime immediately.

I will instead need a 240Hz 1080p HDMI 2.1 or DisplayPort video frontend chip, so there will be no need for the FPGA to do some of the work.
I will only need to do the 1920x1080 to two (960+32)x1080@240Hz and I think there may be much cheaper options for doing that.

Can you suggest anything? Perhaps your frontend chip partners have solutions? Seems like many other DMDs require such vertically cropped signal for two DLPControllers as well.

I was referring to what the video frontend chip expects to receive, not the controllers. If the frontend chip expects only 4K and splits that frame vertically and horizontally into 4 1080p frames to be displayed in sequence then the last frame from those will be delayed 3 240Hz frames.

Also can you please explain what the 32 from the (960+32)x1080@240Hz value comes from? (same diagram on page 33 of the datasheet)

If each DLPController simply takes 960x1080 frames (one side of full frame) then maybe I can have two identical video frontend chips each cropping one side instead of one and doing the cropping with an additional FPGA. While sounds unnecessary may be the cheaper option here. Some frontend chips can do keystone correction, scaling and cropping so may be able to do this. What do you think?
And what companies would you suggest to contact for video frontend chips supporting DLP?

Understood. That means using just two video frontent chips being fed the same video and each cropping one horizontal side of the source frame won't work.

However, since I don't need to support 4k@60fps and only 1080p@240fps I believe my FPGA needs to do less work anyway. And I have a suspicion the FPGA in the reference design is overspec'd anyway, since this is just a reference design and it doesn't have to use the most affordable parts in the reference design, just show a way to implement the PCB design.

If you agree I can get a firm to do some consulting work by synthesizing the reference design of the FPGA code (if you can provide it) with the recommended FPGA targeted, and see the utilization to determine if and which cheaper FPGA can fit my specific task. What do you think?

Also I'm not aware of such a firm that can perform this job for me so if you have recommendations that will be much appreciated.

So to recap, the 2 ports per DLPC, only one will have the overlap region, right?

And do you have the FPGA code I could get modified and synthesized by 3rd party to determine which cheaper FPGA I could use for my specific use case?


And getting back to the OP, if I want to tell the DLPC that I want it to run at 240Hz @ 1080p (with two controllers) with 25% black per frame, how can I get such a firmware generated for the controller? Is there a dedicated program for that?

Thank you.

>>i think it would be easier if we provide the timing and resolution information on how it should be split then it should work for you; but it is going to take while because we are yet to plan on this part.

I guess. I assumed there may be something more going on other than timing and splitting but if that's all I guess that is all I need to pass to a FPGA programmer.

At this point I am again not 100% sure we really need an FPGA for this, video splitting sounds something a ready IC might be able to do. At the very least if 4 1080p video frontend chips are wired to the same HDMI or DisplayPort port but set to crop the incoming signal differently they will probably remain in sync if synced on startup and still be a more economical solution over the listed FPGA. But other than this there's probably a dedicated IC that can do the same alone.
But in any case please provide the data when you can. Is there an estimated date when it will be available?

>>Now, with 25% black per frame, you meant to say @ 240Hz 4.16ms time window, you want to display content for 75% of the time i.e., 3.125ms?

Yes. If I understood Vivek correctly that's as much black as can be inserted at 240fps/Hz while maintaining bit depth. I wouldn't mind more (50%) otherwise, to achieve the same frame persistence as eg. the HTC Vive head mounted display.

>> After we release DLPC6421 datasheet i am guessing 1 - 2 quarters from there.

Well when will that happen?
And what is the point of releasing DLP470TP datasheet and labeling the product as "ACTIVE" if the chipset is not complete? Or have a BUY button suggesting to contact distributors on the page if the chipset is not ready? This does cause unnecessary confusion.

>>the current offering with DLPC6421 is 100% usage of frame-time, 25% dark time is something needs to be newly created.

This contradicts what your colleague Vivek said in this very topic. That is where I got the 25% number, it's not a value I pulled out.

>> we have to re-generate the display sequences

You mean you have to generate a different firmware for the DLPC? If that is the case it doesn't seem like a big deal. As a suggestions a GUI program that takes requirements such as resolution, frame rate and possible dark time (possible with the previous input) and generates a firmware file would save us all time in the long run. Maybe even a universal program that also lets you choose the chipset first.


How about this confusion?
You say the DLPC6421 will be released soon yet you say it may take up to 6 months from then to decide what data it's going to receive from the FPGA? That doesn't make much sense.

So a product is going to be released but it will not be usable? This makes as much sense as releasing DLP470TP before its controller.

And when do you anticipate the release of DLPC6421? It's been mentioned for quite some time now.

Okay.

But I really don't understand one of your previous posts where , correct me if I'm wrong, you say you can provide "timing and resolution information" needed for DLPC6421 up to 6 months after releasing the datasheet for DLPC6421. Isn't that part of the datasheet? How can we have one without the other, what it expects as input.


And can you get any info on the relrease of the actual DLPC6421 IC?

I understand now. While that is also helpful and needed, what I rather want is

info on what the FPGA needs to do, so I may find a more economical FPGA and get a programmer to write the needed code for that FPGA instead. Since I don't need to do 4K to 4x1080p frame splitting that is one reason I don't need FPGA with much power/memory, for instance. Also Xilinx FPGAs are by default slightly more expensive than the competition.
Since you do not provide the code for the FPGA, we need to know at least what the code does so we can write and use our own FPGA code with our own FPGA and skip the 4K to 4x1080p conversion step.

That is the info I was asking for, not the info to run the DLPC without an FPGA and this is why I was puzzled why you may need extra 1-2 quarters to provide that info, since you already have it because you wrote the code/firmware for the FPGA.

Is that info something you can provide now or with the release of the DLPC6421 datasheet?