3
\$\begingroup\$

Here's my conundrum - I'd like a portable display that can be driven at both variable and high refresh rates > 80 Hz (for some visual perception experiments). Does anyone know if this tech exists / if it's possible with OLEDs?

A lot of datasheets don't seem to be clear about this, and - truthfully, I'm not very well versed in how this stuff works / what the bottlenecks are. I know there are displays, display-driver ICs, and that the refresh rate is typically dictated by the number of rows (I think?).

All of the ones I've seen that have been clear about this have been <= 60Hz, and I'm not sure if that's just due to the clockspeed, or the physical properties OLEDs themselves. I would buy some displays to play around with, but it seems like this could quickly become an expensive mistake (on my budget).

\$\endgroup\$
2
\$\begingroup\$

First of all, I do not know of any displays available that support what you want.

This article implies that OLED displays should be able to deliver refresh rates > 80Hz. It claims 1000 times current displays which would put it in the 60kHz range. That may be true for an individual pixel, but I think they're confusing the response time of a pixel with the ability to give a pixel a new value. The former is how fast the pixel gets to a new value, the latter is the refresh rate (i.e. how often you can refresh the whole display).

It does seem that OLEDs could do what you want, but I doubt there is a display that will allow you to select an arbitrary refresh rate.

The reason I doubt is that the way video works is that you have an image that is refreshed at a particular rate to produce the video. Electronically this is done by sending pixels out one at a time to the display at a well-defined pixel clock.

Example:
Assuming a resolution of 1920x1080 and a refresh rate of 60Hz, your pixel clock would be a minimum of 1920*1080*60 = 12.4416MHz. In practice, you clock out extra pixels at the end of each line (horizontal blanking) and after the last line (vertical blanking). This is done to allow for a more reasonable clock (12.4416MHz isn't an easy frequency to generate from standard oscillators). Blanking time is also used to send other data and/or allow the receiving end (a display in your case) to process the received data. To continue the 1080p60 example, the pixel rate for that resolution and frame rate is defined as 148.5MHz. This is a more "rounded" frequency and allows for 2200x1125 pixels to be clocked out at 60Hz. When transmitted over HDMI, the blanking periods are used to send audio and control data.

So you see that both the video source and the video receiver (in your case a graphics chip and a display) have to both know about the exact format of the data being sent in order to work together. This is why I doubt there are displays like you desire. The graphics chip manufacturer would have to support a highly variable pixel clock which basically means they'd have to put an FPGA on-board to clock out the data in addition to their graphics chip. The display controller manufacturer would have to do the same on their end. Though depending on the display the display controller manufacturer might be able to just use the input clock from the graphics card without knowing the exact timings (within the limits of the display and controller).

You could conceivably support what you want, but you'd basically be implementing a graphics card in an FPGA. You'd take whatever the original video was and then convert it to the frame rate you want inside the FPGA. You'd be limited in the maximum pixel clock that the display controller can use and you'd have to select a few discrete frame rates (i.e. maybe 80, 85, 90, 95, etc) to output based on how much logic and how many PLLs your FPGA has. So you couldn't vary the frame rate in real time, but you could support more frame rates than a typical display driver supports.

\$\endgroup\$
  • 3
    \$\begingroup\$ Most LCD/LED displays do not inherently enforce particular ranges of refresh rate the way that mangetically scanned CRTs did. A controller which resamples the data may of course enforce it's own limitations, but a simpler interface where your external circuitry provides the data more directly to the display elements will generally accept arbitrary rates within a wide allowed range. It's not unheard of for that range to extend well outside of the datasheet specification (or for manufacturer's demo modules to successfully drive them with out of spec timing) \$\endgroup\$ – Chris Stratton Aug 16 '12 at 18:48
  • \$\begingroup\$ @Chris I thought that was the case, but couldn't find a source so I just waffled in my answer. Do you have an example data sheet or other source I could add to my answer and get that ambiguity out? \$\endgroup\$ – Littleman Aug 16 '12 at 22:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.