Project Logs

Collapse

• Working Prototype

  Jared Sanson • 03/16/2015 at 08:56 • 0 comments

  I've pretty much got my R500 LCD panel working how I want it at this stage, so I probably won't look at any more panels for now. I've definitely learned a lot about how LCD panels work though!

  Continuing on from my last post, I managed to solve all the issues I had:

  • Messed up colours
  • RIoTBoard & EDID
  • Configuring the RIoTBoard's output resolution
  • Backlight Driver

  Firstly, the messed up colours was a pretty easy fix - I had two of the LVDS channels mixed up because the wire colours were very faint and hard to distinguish. After swapping them the display worked beautifully!

  Secondly I wanted to know whether the RIoTBoard could make use of the display's built-in EDID chip, which contains information to tell the host computer exactly how to drive it at the correct resolution. Unfortunately it seems my build doesn't implement EDID (at least not within U-Boot), so I was forced to hard-code the resolution into U-Boot env. This isn't really an issue since I intend to only use this display with the board. Interestingly I can indeed read the EDID info within user-space once I'm in linux.

  ---

  Finally I wanted to implement the backlight driver. This took a lot more effort than I was expecting, as the circuit turned out to be very unstable, and my poor selection in components caused excessive overheating. It took me a bit of trial and error to find an appropriate MOSFET, diode, and inductor that would work at the high frequencies that it was operating at (~500kHz). I did manage to get it working in the end, with an unholy amount of bodge-wires:

  I might have a look at some more LCD panels and driving methods in the future, but it looks like I'll be focusing on the Hackaday prize for now!

  If you'd like more information about anything here, I'm happy to share.
  

• Breaking it out

  Jared Sanson • 02/05/2015 at 07:25 • 2 comments

  The next big problem I have with the Portege LCD is that the connector is tiny and it's not possible to solder wires to it. So I started making a breakout board for it:

  It was very very tedious work, and in the end it didn't even work :( Somehow the wires inside the connector shorted through to the case.

  So I decided I should do it properly and make a breakout board, complete with backlight driver. To reduce the risk of things going wrong I decided to use the same backlight driver chip as the laptop (MAX8790 6 channel LED driver)

  Because I was feeling impatient I decided I would try to etch it at home instead of ordering online, so I designed the PCB to be single-layer with only SMD components. The LVDS signals are routed through to larger pads to make it possible to solder, and there's also some breakout pads for the EDID I2C lines as well.

  I wasn't actually sure if it was possible to etch a PCB with traces that fine (the SMD connector pitch is 0.4mm, and the LVDS traces are 0.254mm wide!!), but I wanted to give it a shot anyway!

  It took me 4 attempts to actually get the iron-on toner transfer to stick properly, since the first few times I overheated it and melted the plastic sheeting, but in the end it paid off!

  I then etched it in an ammonium persulfate solution:

  Although it looks perfect, the etchant had gone way too far and had eaten all the LVDS traces, which you can see in the next photo (the PCB on the right):
  

  Fortunately my second attempt was almost perfect! (Apart from some microscopic shorts which I managed to remove with a little bit more etching)

  An interesting note I found about using ammonium persulfate: You must have the solution (water and ammonium persulfate crystals) in the right proportions! Too weak or too saturated and it won't etch properly! This caught me off guard because I naively thought a stronger solution would just etch it faster, but there must be some chemistry happening when the solution becomes completely saturated preventing it from doing anything at all.
  

  After some quick soldering I powered it up and connected it to my RIoTBoard, and much to my surprise it powered up and worked first try! The only flaw being I had two of the LVDS data pairs swapped, so the colours came out a bit funny.

  Project success!

  Now I definitely have plans for this LCD, since it is sunlight viewable! The contrast isn't quite as good as e-ink or the Pixel-Qi display, but it retains colour even in full sunlight, and is definitely usable unless the sun is directly reflecting on the display.
  

  Still to come:

  • The backlight driver
  • Getting the RIoT board to output the right resolution (note in the first image that there's some empty black area to the right)

• Reverse Engineering an LCD Panel

  Jared Sanson • 02/04/2015 at 08:44 • 0 comments

  The next step in this project is attempting to interface a special sunlight-readable "transflective" LCD panel, out of an old Portege R500 laptop. I couldn't find a datasheet at first, so I embarked on a huge task to reverse engineer the pinout by probing the signals in a working laptop:

  By carefully probing each pin on that (tiny!) connector, I was able to roughly work out the pinout. The LVDS pairs were fairly obvious as I could clearly see them routed on the PCB, so it was easy enough to trace them back to the connector. I was also able to figure out which LVDS pair was which (Clock and Data) by shorting a pair out to see what effect it had on the display:

  The clock LVDS pair was the easiest to find, as the display simply freezes or goes black when it loses the clock. RX2 was the next easiest, as it contains the HSYNC/VSYNC control signals, so when that line is corrupted the screen loses sync. RX1 and RX0 can be determined by looking at what happens to the colours on the LCD: Shorting RX0 will either cause black to become red, or white to become cyan. Shorting RX1 will either cause black to become green with some corruption of blue gradients, or white to become purple. This all becomes obvious once you look at the layout of colour data within the LVDS signals.

  And then I had one last try at finding a datasheet and finally found one using the serial number on an older model! It turns out I had correctly guessed the power lines and LVDS pairs, but I missed the EDID I2C signals and had the LVDS polarity inverted. Not bad for some fairly simple probing! Having EDID signals also means I can make the display plug'n'play with pretty much any system, so the system will automatically figure out the correct timings and resolution to use.

  My next step is to create a breakout board for the connector, since my first attempt at soldering to the wires failed (the connector shorted out internally due to excessive flexing of the wires. Luckily I have spares!
  

• My, What a lot of laptops!

  Jared Sanson • 02/01/2015 at 04:57 • 0 comments

  So my Dad has a big collection of old laptops gathering dust, most of them running XP or older. I wondered whether it would be possible to extract the LCD out of one and perhaps use it with something like a Raspberry Pi? I remember seeing people wonder this on old forum posts in the past and the common answer was "it's not possible, they use LVDS".

  Times have changed since then, and it is indeed possible, and a lot easier than I thought it would be! To start off easy I decided to get a RIoT Board, based on an iMX6 Solo ARM A9 processor, which has a native LVDS interface!

  To start off my experiment, I extracted an LCD panel out of a suitably broken laptop:
  

  It was fairly obvious which pins were power and LVDS pairs (LVDS signals are ALWAYS routed in close pairs, and may or may not be separated by a ground pin), but I didn't know which pairs were which. Luckily I managed to find a datasheet easily enough, which instantly revealed the exact pinout.

  The backlight driver wasn't quite so easy, but after a bit of probing around I got it to power up the fluorescent tube. Interestingly it only required 5V to power up.

  The RIoT board provides its LVDS signals through a micro-HDMI connector (It is not actually HDMI!), so I chopped an old cable and soldered it directly to the panel (since the laptop was broken anyway):
  

  The other wires are for backlight dimming and a touch screen display, none of which are required to display an image.

  And after reconfiguring the RIoTBoard to output video on the LVDS connector, success!

  It just so happened that the LCD panel matched the RIoTBoard's default output resolution, but it worked right out of the box first try!

  My next experiment is a lot more complex: I have a newer "transflective" LED-backlit LCD display out of an old Portege R500. These screens are special in that they are sunlight readable! But their connector is very very fine and the backlight requires +30V to drive, which makes things difficult. My post on this will be coming soon!
  

View all 4 project logs