P+ driving a recycled junked laptop LCD


Recommended Posts

I had a broken laptop that was given to me and after it sat there gathering dust for a long time I decided to take the LCD apart since I had nothing to lose if nothing came of it. Once I exposed the LCD panel, I was pleasantly surprised to find a datasheet online with electrical, timing specs, even a pinout for the LCD panel, a QD15TL02 type which is a 15" panel with 1280x800 pixel native resolution.

The panel requires about 10V (5W) for the CCFL inverter and 3.3V (1.4W) for the logic, you can see below a 3.3V linear regulator I found in my junkbox bolted to a heatsink which I'm using currently do bring up the LCD panel. Additionally the panel is driven with four LVDS differential pairs, three for data and one for clock.


Currently I have all the signals soldered to a small perfboard with a header that plugs into wing slots BH and AL. The reason I chose these slots is because I need differential signal pins and no single wing alone provides these.

Eventually I plan to make a small circuit board with a switch mode regulator that will fit in the corner seen in the picture above (the three screw holes). The PCB will have a barrel connector for power, a small pot for adjusting the brightness and a HDMI connector for the signals. Below is an eagle board I submitted to Batchpcb the other day. The LCD panel is not HDMI capable but the HDMI connector is ubiquitous and ideally suited for passing the high frequency data signals required.


On the right hand side above is a Pap wing with an HDMI connector which I plan to use to connect to the LCD panel but by reprogramming the FPGA to talk TMDS, that wing should be able to be used with any proper HDMI sink. I can't wait to use that wing to try out Mike's Dvid_test on my HDMI monitor.

The ground planes in the picture above have not been rendered for clarity. I've already received the components from Digikey (in less than 2 days no less) but Batchpcb has been having issues for the last few days and I only just today managed to buy my design, now a few weeks waiting for boards to turn up :(


This post has been promoted to an article

Link to comment
Share on other sites

I had the 32Mhz input clock run through a DCM with a 14x multiplier but although it synthesized to a bit file and seemed to run, I was getting a few failed timing warnings. I believe the -2 stepping of the FPGA has a max DCM clock of about 350 to 380 MHz, can't quite remember, someone correct me if I'm wrong, so that would explain the failed timings. I since dropped it down to 10x and they went away.

The LCD panel datasheet recommends a 67 to 72 Mhz pixel clock (with data at 7x that rate) in order to avoid noticeable flicker. Since the panel has a 1408x816 resolution (including blank space, 1280x800 visible) a 67Mhz clock works out to 67M/(1408x816)=58.3Hz refresh, or 62.6Hz at 72Mhz.

With my 32Mhz x10 = 320Mhz data clock I get 320/7 = 45.7Mhz pixel clock or 39.7Hz refresh.

Link to comment
Share on other sites

Yes, I'm familiar with dvid_test and the ODDR2 trick. It works well when you have an even number of bits to shift as the ODDR2 element essentially shifts out 2 bits per clock cycle. Your TMDS 10 bit encoding works well with that:

databit: 0123456789
clock_p: _-__
clock_n: __-_

In my case however I have a 7 bit stream which is not very ODDR2 friendly:

databit: 0123456 <-not enough data bits to shift on last clock cycle
clock_p: _-_-_
clock_n: __-_-

If I was to run off the "sedate" half clock and implement a kind of pipeline where I concatenate two 7 bit values into 14 bits so I can shift it out 2 bits at a time, I'd have new data coming at me every 3.5 "sedate" clock cycles, or in other words I'd have to have a synchronized clock, call it ck_load, that is 3.5 time slower still than my "sedate" clock like so:

databit: 0123456789abcd
clock_p: _-__-_-_
clock_n: __-__-_-
ck_load: ---____---____

This means my pipeline needs to be accessed in two clock domains (with clocks that are non integer multiples of each other), ie read at "sedate" clock and loaded at ("sedate" / 3.5) ck_load clock.

It's not completely impossible, but I don't see how I'd implement this without making it a candidate for the next "what the heck does this do?" puzzle.

Link to comment
Share on other sites

OK nevermind, sorted it, below is a shot of my solution driving the panel using DDR as you suggested. Clocking is 32Mhz x 7 = 224Mhz into DDRs, giving an effective 448MHz data rate or 64Mhz pixel clock.

The reason the video image is so misaligned is because the video signal produced by the game does not meet the panel required sync and front/back porch timing.

Normally when feeding that signal into a monitor, the monitor does some auto sync to center the image, but the panel does not have these kind of smarts and expects the correct timings to be met.

I attached the source code for my LVDS parallel to serial shifter as a text file as this forum does not seem to allow .vhd extensions! Bonus puzzle: understand the logic and explain how it works...



Link to comment
Share on other sites

Nope, you reckon it should have?

Number of ILOGIC2/ISERDES2s: 0 out of 200 0%
Number of IODELAY2/IODRP2/IODRP2_MCBs: 0 out of 200 0%
Number of OLOGIC2/OSERDES2s: 4 out of 200 2%
Number used as OLOGIC2s: 4
Number used as OSERDES2s: 0

Well, yes.

see http://www.xilinx.com/support/documentation/user_guides/ug381.pdf and



Link to comment
Share on other sites

If you first make something with hdmi input, think about adding an hdmi output at the same time also, maybe we could use it for overlaying video.. (if that is ever possible of course)

This has already been done and I have one of those in my toy box :)



Given the NeTV architecture is based on a Spartan 6 LX9 it will 100% be possible to do that with the Papy with the right wing. Also given the HDMI connects to a FPGA, the distinction between "input" and "output" is configurable.

Link to comment
Share on other sites

Yes, I was thinking multiple HDMI connectors, that way a HDMI switch would be possible too.

Oh, cool, bunnie's device. When that came out I was already looking at the Xilinx TMDS app notes and thinking about a set top device. HDCP was my biggest concern, I was stoked when I saw that bunnie was working on it. :) Looks like a code base to build on might be available.

I've been thinking along the lines of a Media Controller type of device, it seems to me that where a lot of home theater automation solutions fall apart is with all the wildly different IR commands to do things and the difficulty in tracking state. Do you need to press input 3 time or 5 times to get to your XBOX? It seems like a smart audio/video selector that would make a standard control scheme might be the right direction for a good home theater automation solution.


Link to comment
Share on other sites

  • 3 weeks later...

Finally! PCB goodness in them mails. Feels like xmas.


First off I assembled the super easy Papilio HDMI wing, You can see different views of it in the insets as well as how it fits on the Pap board. It is technically not an 8 bit wing nor a standard 16 bit wing but a kind of modified 16 bit wing as it straddles two 8 bit wing slots due to the requirement for differential pins. The row of 4 pins with the missing pin connects to power and ground, the next row of 8 pins connects to the standard 8 bit wing and finally the last row of 4 pins connects to the adjacent 8 bit wing's pins to get to the differential pair's other pins which are not available on any 8 bit wing alone.


Next filing the PCB corner to make it fit in the oddly shaped space and line up with the screw holes.


Finally (for today) assembled the PCB with the tiny 3.3V switch mode power supply regulator, the pot for adjusting the LCD brightness and the HDMI connector where the LCD differential pins will connect to.


The only testing was to apply power to the board above and check that I get 3.3V which initially I wasn't. This is what happens when it takes a month from designing it until the PCBs arrive. Going back to the schematic I quickly realized I had made a decision to only enable the switch mode supply when the input voltage exceeds 9V (this can be easily changed as it's only a resistor divider) and I was only supplying 8.5V. Quick turn of the knob on the lab PSU to bring the input voltage above that threshold solved the problem :) and I could measure 3.3V on the output.

Next, I have to start cutting into the LCD plastic enclosure to open up spaces for the connectors and the pot which will protrude out the front of the LCD panel. Not really looking forward to that, cutting into plastic and making precisely aligned openings is not my favourite activity.

This post has been promoted to an article

Link to comment
Share on other sites

Maybe but I didn't think it necessary as I designed this as a standalone HDMI wing. There is already a MicroSD Wing you can buy which will give you the functionality you ask for. The idea with the wings is that you can mix and match as you require, having them combined into one removes that ability. This is where mega wings come in and I'd rather see HDMI on a mega wing than trying to squeeze more stuff into the HDMI wing.

Also IIRC it should be possible to plug a second HDMI wing side by side with the current one for an input/output combo and then that entire side of the board with the 32 I/Os is gone :(

PS did you get my email from Tuesday?

Link to comment
Share on other sites

OK it's nearly 2am and I'm off to bed... satisfied I have accomplished the task I set out to complete :)

After much cutting the plastic case with a box cutter and a metal nibbler and drilling holes I finally had the mechanical side sorted. Finished soldering the wires to the board and hooked it all up to the Papilio then run a quick LVDS test and... nothing. No picture at all. I immediately thought, oh crap, SI issues (signal integrity). How can this be, after all it used to work with just loose wires flying about. Is it the the HDMI wing, is it the trace width, is it the trace spacing, impedance issues? All these thoughts and more run through my head, but as always, one must approach a seemingly unsolvable problem one step at a time.

I checked the power in and out of the switch mode supply, all good, checked the noise on the output, not all that great, about 100mv of a square looking ripple at about 6.6Mhz. Hmmm... whatever.

Checked the trace continuity from the Papilio HDMI wing all the way through the HDMI cable to the panel pins. This is where I uncovered a problem. One of my signal pairs was not coming though. This turned out to be because I had a soldering issue with two of the pins on the HDMI connector on the panel side, they were not making contact with the PCB traces. A quick touch up with the soldering iron fixed that, so after rechecking all signals for continuity I was all cocky thinking I had my issue licked. But alas, on testing, still no picture on the panel. On with the troubleshooting.

Next it was time to check the HDMI wing so off to synthesize Mike's DVID test, but first I must adapt it to the Papilio by creating a suitable ucf file. With ucf done and project flashed on the Papilio I hooked up the HDMI wing to a HDMI monitor and two things became immediately apparent. I had a picture which was great. The quality was not perfect which was not so great. There were a few visible artefacts and I guess that is to be expected since the signal path from FPGA to HDMI connector was not really designed with high speed signals in mind or even matched traces.

At least the HDMI wing was tested to be OK. It was about at this stage when it hit me that while creating the ucf file before, I had a niggling feeling that some signals to the LVDS panel were in a different order. I double checked my LVDS driver project and sure enough that was the case. Initially, a month ago, I had tested the panel with wires soldered directly to a header that plugged into the Papilio expansion header but when I designed the HDMI wing I followed the HDMI pinout. Because of that, some of the differential signals had been swapped around, eg my panel clock now connected to one of the signals... so after fixing up the ucf to match the correct pins, I finally had a picture on my panel.


With the cover screwed in, it looks like this. I should mention at this point that the pot intended to control the brightness, doesn't. I had honestly thought after checking the datasheet for the CCFL driver that the brightness would be controlled by an analog voltage, but it seems that chip has a few different modes, depending on how three of its pins are wired. Two of the modes are analog brightness control (on different pins) and the third mode is PWM brightness control. It would appear this is the case here. So the pot when turned all the way to one side turns off the backlight, then as it is wound up, when the analog control voltage reaches 1.5V it turns the backlight fully on. Oh well, I can live with that :) If I was bored, I'd attempt some circuit surgery on the CCFL driver board to rewire the pins and change the mode to analog but that's not a huge priority for me right now.


Final picture of the complete project. I should really remind you again that just because the panel has been fitted with an HDMI connector, it DOES NOT have the smarts to recognize TMDS encoded HDMI signals, it needs to be driven with LVDS.


Link to comment
Share on other sites

I'll have to take back what I said earlier regarding the artefacts with the HDMI wing, I traced them to some incorrect timing where the pixel clock was nowhere near in sync or at the correct rate relative to the TMDS clock. Below is a picture of the HDMI wing output on my HDMI monitor, after I fixed the issues, clocking is 32Mhz into DCM x10 = 320Mhz (just scrapes in under the 333Mhz max limit for the DCM) into ODDRs generating 640Mhz. The Video clock is 320Mhz/5 = 64Mhz.

The gory details of my generic VGA module producing the video for those that understand these is:

generic map ( hFront => 24, hSync => 136, hBack => 160, hRes => 1024, hActive => '0', vFront => 3, vSync => 6, vBack => 29, vRes => 768, vActive => '0') -- 1024x768 60Hz - 65.000 MHz

So the timing is 64Mhz / (24+136+160+1024) = 47.619 Khz horizontal and 47619 / (3+6+29+768) = 59 Hz vertical which is what the monitor OSD confirms below so the HDMI wing is perfectly useable for generating nice HDMI signals :)


Link to comment
Share on other sites

How do you rate the picture now? It is looking 10 out of 10 in the screenshot!

I was thinking that it sounded a little bit odd, giving the way TMDS works - the highest frequencies look to be in the code words used during the hblank/vblank interval, so a cruddy signal is more likely to loose sync than corrupt pixels...

Link to comment
Share on other sites

  • 9 months later...


This topic is now archived and is closed to further replies.