In the previous post I laid out some of my plans for implementing the interface board for the iPad 3 LCD.  In the meantime, I have done some (or rather, quite a lot of) research on the subject, and have gained some additional insight into what may be involved.  I have also begun to choose components based on what I know about the (still en route) panel.

Basic physical attributes

As a panel designed for assembly in a greater structure rather than being self-supporting, there appears to be little in the way of mounting provisions.  I vastly prefer screw-based mounting to any other method for ease of manufacture and the ability to remove pieces to work on them without damage, but in this case the only way that would be feasible would be if the board were some seven or eight inches wide (enough to span one entire edge of the display), and I don’t plan to build enough into the board to need that much space.  Furthermore, this would still only be two mount points, leaving the board unsupported toward the center of the panel.

For now, the ideal mounting method appears to be double-sided foam tape.  It’s cheap, it holds reasonably well but not TOO well, and it’s thick enough to hold through-hole component leads just a little bit off of the rear metal surface of the display panel.  The board will be affixed to the upper left corner of the rear, such that the eDP tail mates up with the connector without too much fuss.  I know this kind of clashes with my “must be elegant” mantra, but it will have to do until I have the opportunity to do up a “proper” back casing (which will have to wait until my budget allows me to buy a mini-mill).

At the moment, I am envisioning a board of dimensions no larger than 2×3.5 inches.  That should be plenty of space to work with without being too cramped.  Using OSH Park, that’s $70 for three boards.  Not exactly free, but not terrible for four-layer one-off prototypes.  Two-layer is more reasonable yet, but the boards will need the extra layers as it’s near impossible to produce a board with decent signal integrity in the 2GHz range in two layers.

Electromechanicals

As I noted in the previous post on this topic, I would prefer not to solder a hacked-off wire to the board.  To that end, I will be connectorizing everything possible.  My choices in connectors are largely driven by what is available in onesies from the normal distributors – I don’t want to rely on samples of obscure parts, and I don’t have the buying power to request anything extravagant.

To bring signals into the control board, I will be using a miniDisplayPort connector.  They’re compact and electrically correct for this application.  They are also surprisingly hard to find, but Mouser currently has a healthy stock of Molex 105081-0001 so that seems like the winner.  It’s a through-hole part with fairly tight spacing so fanout might be interesting, but I’ll deal with that when I get there – there really aren’t many other options.

To get from the board to the panel, I have opted to forgo additional research and use the already-identified Molex 502250-5191 as documented on [Andrzej]’s original writeup.  I suspect there are plenty of other options out there, but I’ve always found Molex to be more readily available in the United States than any of the Japanese vendors’ parts (e.g. JAE) and I don’t think it’s worth bothering to find compatible connectors which I can’t buy.  These are also in stock at Mouser at time of writing.

I will be feeding my board with a 12V 1A adapter, similar to http://www.ebay.com/itm/360545176232.  These are provided with every small networking appliance and external hard drive, and I’ve got a billion of them.  I brought in some CUI PJ-047BH 2.5mmx6mm barrel jacks for a related project at work, and plan to use one of these to accept the 2.5×5.5mm barrel plug on the adapter.  (In-stock at Digikey)

Backlight driver

You’ve waded through the boring stuff, now on to the fun bits.  The panel has two banks of six common-anode LED strings for its backlight.  Per the panel datasheet, the strings are rated at 18.5mA, 4.4W.  This works out to a string voltage of 19.8V, higher than the voltage I am providing to the board.  I could have used a higher-voltage adapter, but I have plenty of 12V ones already.  So my requirements for the backlight driver are 12V in, 12 channels out at >= 18.5mA, max output voltage >=19.8V.

Many solutions call for a two-chip set – a boost switchmode supply to produce V+ for the LEDs, followed by a low-side-switch array to handle the PWM dimming.  I have instead opted to use a combined boost regulator and PWM controller, to save board real estate and complexity.

There are several options available in this arena – Atmel has a couple, Maxim has at least one – but I ultimately chose the Linear Technology LT3754.  I have used a lot of Linear parts over the years, and I think they have some of the best datasheets and application notes of any manufacturers.  Plus they have good field reps (Hi Bryan and Rynk!).

The LT3754 is a 16-channel boost-mode driver with 50mA string drive current and up to 45V string drive voltage from 4.5V input.  It can take a PWM dimming signal, or an analog voltage if you’re crafty.  Additionally, it’s not too expensive, there are less than 20 external components, and it comes in a compact 32-QFN package  All in all, a really neat device.  I made up a spreadsheet to calculate the parameters for the driver.  I may post it later once I clean it up a bit.

Backlight considerations

The identification of a feasible backlight driver brings up some thoughts from the previous post.  I now have a DisplayPort input and a PWM-controllable backlight driver, but nothing in the middle.  Where can we get backlight control information from?

DisplayPort consists of four high speed data links and a low-speed control channel (“AUX”).  This AUX port has a number of interesting features.  In its simplest form, the AUX channel acts like the Display Data Channel of competing technologies (e.g. DVI, HDMI), informing the host of the resolutions and refresh rates and other key capabilities of attached devices (EDID).  However, it may also perform additional tasks – providing, for example, a channel for host-to-device control and configuration.  It is this function which is most interesting for this application.

DisplayPort supports the VESA Monitor Control Command Set over the AUX channel.  According to Wikipedia, a subpart of this standard supports backlight control.  If the data is sent to the panel, and we can decrypt and act upon that data, the operation of the monitor will be greatly improved beyond the otherwise sole option of manual backlight control.

But how do we get at the data, if it even exists?  There exist DisplayPort to LVDS receivers which break out this data (for instance, NXP’s PTN3460), but then we’re left with LVDS for a eDP panel.  Maybe we could buffer and split the DP signal to both our panel and the receiver IC, or convert from DP to LVDS and back to DP, but this starts to become expensive and space-consumptive and complicated.

Ideally we’d want to get at the backlight control data without bothering to retransmit the DP links.  In its basic form the AUX channel is a bidirectional half-duplex 1Mbps I2C-esque bus, which we can potentially read with a microcontroller.  The data is Manchester-encoded to be transmitted over twisted pair cabling though, so we need to decode the data, then interpret it.  It will be difficult to find a device that can do the interpretation in hardware as it has a nonstandard packet structure, which means we’d need either a decently-fast processor (to bit-bang it) or some sort of programmable logic.  So we’re in it for some semi-serious hardware and/or software to solve a simple problem.  Not exactly elegant, as per my design guidelines.

It is desirable to find an alternative source of this data, but so far other options have eluded me.  The search continues, but that’s enough for one day.

<< Previous post in this series … Next post in this series >>