As I alluded to in previous comments and update posts, I have received and built up the boards for the simple breakout.  I used a sharpened toothpick to apply solder paste to the board, and reflowed the board in my toaster oven.  I have noted a couple of issues with the first revision of the boards:

• The backlight power pads are through-hole.  Care must be taken to keep the backlight leads flush with the board or they interfere with the panel FFC.
• The connector for the panel has contacts on both top and bottom.  This makes it possible to electrically connect the panel backwards.  The DisplayPort connector is on the other side of the board, which makes it reasonable to expect the panel to be plugged in backward.
• With the DP connector on the back, it makes the board awkwardly arranged – it can’t be affixed flat to the back of the panel.  It was designed to be free-hanging on the cable since it is meant as an interface for those using the panel in a projector, but it would be nice to have an alternate mounting method for those who want to use the panel as is.
• FInally, and most seriously, I accidentally used the source-side pinout for the DisplayPort connector.  In the source connector, from pin 1 the lanes are numbered 0, 1, 2, 3; in the sink connector they are mirrored.  This results in Link Failure errors on the host system.  This was an important lesson, and one which I’m actually glad to have discovered after only $50 worth of boards, instead of at work where I am also working with a DisplayPort design but where the cost would be closer to $3000.

The first three issues were workable, but the last one meant the board was inoperable.  But with an Xacto knife and some 36AWG magnet wire, I was able to make the required changes.  The finished board looks like this:

Front view. Note the magnet wire modifications in the center.

Rear of board. Ignore the flux mess.

If you happened to order the Rev A boards, you too can make the changes.  You will need to cut the DP traces at the rear of the connector, and again at each of the vias where they are transported to the bottom side.  You could conceivably leave one or the other of them connected, but it is improper to leave such a long stub on a high-speed data line as it distorts the signal and causes reflections.  Then connect the vias back to the connector in reverse order.  The modifications are as follows:

Cut at the red marks, install wires across the green and blue lines.

I would suggest soldering the wires to the back of the DP first, then threading the wires through the vias and soldering them in place.  I think this will produce a more robust and neater end product.  I soldered the wires in the vias first, and finishing the other end was a tremendous pain.

After making these changes, the board works great!  I am very pleased with the project so far.  The panel looks great – plenty of brightness, and super high resolution.  Regarding brightness, I installed 100-ohm resistors and ran the panel at about 19.5V.

First panel test. At top is a 1080P HD movie at full scale.  Plenty of screen real-estate!

I have made the necessary changes to the board.  As it works out, when the pinout is corrected it makes more sense to have the FFC and the DP connector on the same side of the board.  This has the side effect of making the connection orientation more obvious, and allowing the board to be rear-mounted to the panel.  I have also increased the size of the backlight pads, so the wires can be more easily surface-soldered and not stick through and interfere with the FFC.

I also had the opportunity to correct the trace size for the proper dielectric constant of the laminate.  The OSH Park stackup is as follows:

• 1 oz copper (1.4 mil)
• 6.7 mil prepreg
• 0.5 oz copper (0.7 mil)
• 47 mil core
• 0.5 oz copper (0.7 mil)
• 6.7 mil prepreg
• 1 oz copper (1.4 mil)

For 1 oz copper with a 6.7 mil height over plane, using dielectric constant of 3.66 for FR408, and assuming minimum 6-mil spacing, to maintain 100 ohm differential impedance, Saturn PCB Toolkit calculates necessary trace width of 8.1 mils.  I used the Saturn built-in value for FR408 when I originally designed the board, which is a little different and called for slightly smaller traces.  Using the new trace sizing and the new board layout, I was easily able to make the traces all very near to equal length (506 +/- 2 mils).  This is closer than they usually come out without a large amount of effort – in this case the board modifications only took an hour or two.

Simple interface adapter, Rev B.

The new boards are on order and should be in house in two weeks or so.  I’m pretty confident now that I’ve tested the hand-wired version, but I was also confident when I originally released this board so it’s at your own risk if you want to order these boards yourself.  Here are the board documents (now with pad masters, in case you want to order stencils):

• PCB10002 REV B GERBERS (22K ZIP)
• PCB10002 REV B LAYERS (253K PDF)
• PCB10002 REV B STENCILS (1.1K ZIP)
• SCH10002 REV B (201K PDF)

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

The digitizer breakout boards arrived, signalling a new round of experimentation with the iPad 3 touch panel.  The design of the board seems mostly solid but for a couple of issues.  First, as predicted, the edges of the digitizer FFCs need to be trimmed off for them to fit in the connector.  This is easily done by pressing down on the FFC on a hard surface with a sturdy sharp knife; the semi-brittle stiffener separates cleanly and without bending the contact portion of the cable.

The connectors used on the breakout need the FFC trimmed just shy of the contacts, but this is easy to do.

I reflow soldered the board by manually controlling the guts of my toaster-turned-reflow-oven, which worked quite well.  I would be cautious to try hand-soldering the tiny connectors as alignment is extremely important, but it might not be a terrible idea, particularly if you don’t have infinite time and patience – I did not have a stencil and individually applying the proper amount of solder paste to each of the 78 miniscule pads took nearly two hours.  But the result works beautifully, so I consider it worth the time – plus I got to experiment with a method I’ll need to use a lot when I start building the other boards.  Tip: Sharpen a wooden toothpick to use as an applicator.  I tried metal points and had a lot of trouble.

The completed breakout. This one has the pins set up for breadboard use.

The other issue with the board is that it overhangs four breadboard rows beyond the connection row, so it’s not impossible but certainly difficult to connect to the row of pins toward the FFC connectors.  Again though, this is not meant to be an end-all solution, just something to facilitate probing the digitizer until a real board is built, so I’m not too upset about it.  Plus the board could not be made much narrower without disrupting the currently-zenlike layout of traces.

As I now have a way to get into the connectors, I’ve done some more experimentation with the panel and have come to realize that much of what I thought I knew about the driving of this panel is wrong.  I have stared at the pictorial diagram of the concept of mutual pcap for many tens of minutes, but it never clicked until I started playing with the digitizer.  The key is this: the capacitance of the display isn’t directly sensed!  No relaxation oscillators here, the pictorial says it all – mutual pcap uses your body capacitance to prevent some of the electric field from coupling from the driven lines to the sense lines!

It took me an embarrassingly long time to register what is happening here.

Using the breakout, it is easy to see how this works.  Using a function generator, I drove an 18V square wave into FORCE0 through a resistor (value dependent on frequency used) and connected generator common to the GND pins.  Take note, Apple drives the digitizer with approximately 18V in the iPad also.  I then connected an oscilloscope to SENSE28 referenced to GND, and grounded SHLD.  The result was a mirror of the input signal at an amplitude of approximately 330mV coupled onto the sense line.  Then, when the bottom right corner of the digitizer is touched (this is the cross point of FORCE0 and SENSE28), a visible 30mV drop in amplitude shows up on the sensed waveform.

Initial breadboard setup of the digitizer test board.

Waveform capture of a 72KHz signal driven through a 10K resistor into FORCE0, coupling into SENSE28. Yellow is source, white is sense without touch, cyan is sense with touch. A clear difference can be seen between touch and no touch.

Now, 30mV may not seem like a lot, but against 330mV that’s just over 9%, which should certainly be detectable.  In fact, if we fed this signal directly to a 3.3V-referenced 12-bit ADC, this would be around 40 steps of difference, which may be detectable with ample averaging.  But we can do better than that.  By using op amps to amplify the signal to the 3.3V range (and to DC bias it up above ground for better compatibility with ADCs), we should have plenty of dynamic range to sense touches.

This is where I hit a snag.  I figure that for 40 force lines and 30 sense lines, and desiring a refresh rate equal to the LCD itself (60Hz) to prevent sluggishness, a touch scan rate of 40*30*60=72KHz is the minimum necessary.  If averaging is desired for better accuracy, then scan rate will need to be a multiple of this.  However, I only had general purpose op amps on hand, with slew rates in the 0.5V/us range.  In the 70+KHz range, square wave edges over a 0.5V/us slew rate device are just too slow compared to the small differences we are looking for.  I will need to source some higher-speed op amps before I can really try this out.

But until that happens, here is my plan for interfacing the digitizer.  I will use some programmable logic or a few 4:16 decoders to drive an array of transistors connected to the force lines, which will generate a pulse on each line in turn.  An analog mux will pipe all 30 sense channels into a high-speed op amp and then into a megafast ADC which will continuously scan until a certain voltage level has been reached.  If the pulse generation time and the minimum level received time are a known distance apart, it should be trivial to determine whether the screen is being touched in this area – the longer it takes to reach the desired voltage, the more charge is being diverted into the attached capacitive body (e.g. finger).  An array of op amps and a couple of multichannel ADCs could be used in place of the multiplexer as well if that ends up being less expensive or more accurate.

Now awaits another trip to Digikey and some more research, but this is starting to look more and more feasible.

<< Previous post in this series

I would say I’m pretty good at hand soldering.  I can solder TSSOP and QFP pin by pin, and I work with 0603 size parts on a very regular basis.  Unfortunately, industry has decided that 0603 parts and exposed pins are wasteful in space, and many really neat parts come only in QFN or BGA, and next to these, 0603 parts are absolutely gigantic.  I thus find myself wanting a way to process boards with no-lead and micro-scale parts.  At this size it’s pretty much reflow soldering or the highway.  The company where I work has a nice six-stage production reflow oven, but I can hardly go asking them to fire that up whenever I need something made, so I would like to have a solution at home to do quick-turn work on my own.

There are plenty of projects on the Internet that document homebrew reflow systems.  Some are built on electric skillets, some in toaster ovens, some in custom made boxes, with varying amounts of complexity.  But I have found that most homebrew designs lack the advanced features found on “real” reflow setups.  Proper profiling is desirable – that is, not only getting it hot enough to melt, but actually following the manufacturers’ specified ramps, which should lead to more reliable boards.  The ability to sense temperature at the board or high-mass board components and provide provisions to optimize the ramp thereafter would also be nice.  Semi-automatic cycling would be good, to press one button and come back in ten minutes to a finished board.  And all of this should be possible without the unit needing to be tethered to an external computer, thereby keeping the footprint small.

Here is the (un?)willing victim, an el-cheapo Wal-Mart toaster oven.

Similar to many designs, my plan is to base the unit on a basic toaster oven – in this case, a 1000W unit with two quartz heating elements, model TO-88, originally from Wal-Mart but in my posession via a dumpster.  There is nothing particularly special about this toaster oven, and any similar design could also be used.

Inside the toaster oven. Not much to it.

The inside of this unit illustrates exactly how cheap it probably was.  It makes no effort to insulate the cooking chamber from the outside world, which must make it very inefficient as well as hot to the touch.  The innards are all 28 gauge sheet steel, which has gaps where it was bent to shape.  The control system uses the (high) ambient temperature directly outside of the cooking chamber to regulate cook temperature in the box; how it achieves any sort of temperature accuracy is boggling (it might not be remotely accurate; I really haven’t tested it).  It’s electrically pretty simple – hot lead in series with the timer, in series with the thermostat/element selector switch, in series with the two elements (in parallel through the selector switch), and out to the neutral lead.  I have picked up a couple of other toaster ovens and there are more elaborate control systems than this, but I plan to rip all of this out so it’s not important how complex it is.

I will need to do a little testing to determine the characteristics of the unit – primarily, maximum heat rate, and maximum cool rate when elements are disabled.  I suspect that 1000W is enough to heat the board quickly enough to conform to proper reflow curves, but that despite its lack of insulation the unit will not be able to cool off fast enough to meet the profile.  I am therefore tentatively planning to circulate air through the box with a small blower at one end, and vent it out the other.  By controlling fan speed and heating element duty cycle, I should be able to very quickly and accurately control chamber temperature.  I will also leverage the blower to make sure heat is evenly dispersed throughout the chamber to prevent hotspots.  To reduce the power required to run a board and the heat at the exterior of the box, I will insulate the chamber where convenient to do so (likely inside the outer casing, at top, left and right) with fiberglass mat.

The existing controls will be removed.  The top control (thermostat) will be replaced with a main power switch, and the bottom control (timer) will be replaced with a neon indicator of heating element power.  The blower will be housed in the plenum where the controls were, and will be ducted into the chamber.  Hopefully this will allow it to be far enough away to prevent the (plastic) blower from being damaged by heat.  So long as the fan keeps sucking cool air, I think it should be OK.

The main control circuitry will be housed in a new control panel affixed to the side of the unit, which will be built in a plastic project box (Hammond RP1065).  The box will contain a Crydom D1225 solid-state relay (I already purchased this on eBay for this purpose), heatsunk out the back.  It will also contain a custom board which will serve as the brains of the unit.  I am planning to use the same 32-pin Freescale Kinetis L2 processor as the iPad screen controller.  This will talk to two Maxim MAX31855 thermocouple-to-SPI converters and in turn to two K-type thermocouples which can be affixed to a board in the unit.  Front panel control will be achieved via a 1.8″ SPI LCD and a few tactile switches.  The unit will be able to take input from USB, front panel and/or SD card (not sure which combination will be implemented).

First concept for the controller for the reflow oven. The PCB isn’t shown as it hasn’t yet been designed.

The oven, SSR, fiberglass mat, scrap sheet metal, blower, and hardware are all in house already; the LCD and thermocouples are on order.  Most of the remaining components will come from Digikey as soon as one of them comes back in stock.  I am feeling good about this – it’s about time I got around to building it.  More later.

After discussion with commenter Eva in the last part of this series, i was motivated to make some progress on the investigation of the iPad 3 digitizer.  Based on leaked schematics for the iPad mainboard assembly and on the physical digitizer itself, I have mapped the physical pins on the digitizer FFC to functions.  There are 40 excitation pins, 30 sense pins, three grounds and a SHLD pin of which I have not yet determined a function.  Normally SHLD means shield, but it’s being fed into a processor input so that doesn’t make sense.  I will continue to investigate.

Layout of the pins on the iPad 3 digitizer.

The leaked documents also indicate that the proper mate to these are Molex 502250 series connectors, the same series as the one used on my DisplayPort boards for the eDP tail.  But contrary to the 51-pin version, this one is not so easy to get ahold of.  As I noted in the previous post on the digitizer, the 503566-3700 is a close alternative, but it looks as if these FFCs are just too wide (11.7mm) to fit in them (11.4 +/-0.05mm max).  There are not a lot of alternatives though, so if worse comes to worst I may end up trimming the FFC to fit – as you can make out in the above photo, there is a small amount of tab with no contact at each edge, and without this the connector easily comes in at under 11.4mm.  Also of note, the distance from the edge of one connector to the edge of the other is 13.5mm.

I have done all I can do with the digitizer by inspection alone, and at this point can only advance with it electrically.  To aid in this I have drawn up a simple breakout for the digitizer.  As I was not sure what my end application would be, I included provisions for connection either to a breadboard directly or to another board via inexpensive 40-pin IDE cables.  The FFC connectors are on the bottom of the board, since the contacts of the digitizer face up when the tail is unfolded and the connector chosen has only bottom contacts (the 502250 series has contacts on both top and bottom).  Not ideal, but workable for the short-term use that this board is designed for.

A simple breakout for the iPad 3 digitizer.

Each position is labelled on both sides with its function to the best of my knowledge.  Dimensions of the board are 0.9″ by 4.1″.  Production of this (2-layer) board at OSH Park costs $18.50 for three pieces.  Populate J3 thru J8 with 0.1″ snappable header strips – omit J4 and J7 for breadboard use, and omit J5 and J8 for IDE cable use.  The mount pads are sized for 2-56 screws.

I have ordered a set of these boards and plan to experiment with them a bit, so you may want to wait until I troubleshoot everything.  If you are impatient, documents for the digitizer breakout are below:

• PCB10004 REV A GERBERS (34K ZIP)
• PCB10004 REV A LAYERS (51K PDF)
• SCH10004 REV A (107K PDF)

So then, now that we can connect to the panel, how do we read touches?  That part isn’t quite so simple. If the documentation from the iPad mainboard is to be trusted, 40 independent outputs are generated and sent to the panel in sequence to 40 horizontal electrodes, and 30 vertical electrodes pick up the signal when coupled into them by a conductive mass (e.g. finger) on the surface.  In the first part of this series I counted 41 squiggly horizontal lines and presumed these to be the electrodes, but it turns out that the sensitive area is between the squiggles, resulting in 40 driven rows.

The methods for driving and sensing touch position are a hot area of development in industry at the moment, and the big companies are all hush-hush on their analog frontend design.  But we know generically how Pcap touch should work, and we can take a guess from this and by examining how Pcap is implemented in devices.  For instance, we know that Apple uses three main ICs to drive the touchscreen – a driver to generate the output to the panel, a receiver of the signals produced by the panel which incorporates an analog-to-digital converter, and a processor to interpret the ADC data.  One popular method of Pcap sensing is to use the changing capacitance to shift the frequency of a relaxation oscillator, then use a frequency to voltage converter and finally an ADC to sense this capacitance.  Given the structure of the panel and supporting circuitry, it seems reasonable for the panel to be read in this way.  A couple of links that provide information on mutual Pcap: http://ww1.microchip.com/downloads/en/DeviceDoc/93064A.pdf, http://www.walkermobile.com/SID_2012_Short_Course_S3.pdf.

I believe it is unlikely that a hobbyist would be able to get ahold of the particular solution used in the iPad – in fact, as at least the receive and processing ICs are made by Broadcom, I’m positive it is impossible – and it is almost as unlikely that there will be an off-the-shelf controller with the proper number of channels that a hobbyist can buy in reasonable quantities.  I therefore plan to implement a solution using generic hardware – simple programmable logic and/or MCUs.  This way cost and minimum buys aren’t problematic.  But that architecture is a topic for a later post, this one has gone on long enough.

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

Now that the main board has been put on order, my focus can shift to the ancillary parts of the project.  In particular, it is time to consider the human-interaction part of this build.  I think it is important to be able to control the brightness, as well as overall system power, of the panel.  Some designs handle brightness via the USB HID monitor class, and I may well go this way eventually, but for the short term I would rather have simple up/down/off button control, so I can have immediate gratification before I spend the time to write the HID software.

Most monitors have some controls in the lower righthand corner – power, up/down, menu, etc – as well as a status LED.  As I will not be inserting video data and thus will not have an OSD, some of these buttons are not important.  But I think the lower-righthand corner is natural for monitor controls, so my plans call for a simple board adhered to the back of the panel at this point, with basic controls and a status indicator LED.  This will connect to J8 on the main board, which has been wired for this purpose (three active-low button inputs pulled high, and three resistor-limited PWM outputs).  I have chosen to use a RGB LED because I have not yet decided on indicator colors.  Perhaps white would have been ideal for this application as it is an Apple panel, but I couldn’t find a white + orange (for standby) LED.  I chose a 0604-size 6-pin LED (Rohm SMLP36RGB1W3), so I could fit discrete white and orange 0402 LEDs if I wanted to change to that.

For buttons, I was really torn.  On one hand, it would have been nice to have the whole board hidden from view, and use right-angle buttons just exposed beyond the edge.  I couldn’t think of a good way to show the LED though.  I thought about capacitive touch buttons, which would be neat and fit with the Apple theme of the unit, and I actually wired the button inputs to capacitive touch inputs just in case, but I didn’t want to bother with the software and debugging right off the bat.  So I went with regular SMD microminiature tactile switches (C&K KMR421G LFS).  These are seriously, seriously small buttons.  They should end up no taller than the panel is thick (and if you have a panel, you know how crazy thin it is), and allow my exposed board area to shrink to 0.14″.  So enough talking about it, let’s have a look, eh?

First go at the iPad LCD controller interface board. It’s smaller than it looks.

You’ll notice a couple of things about the design.  First, note that there are no traces or copper features on the left section of the top of the board.  I plan to adhere this board directly to the back of the panel, so I made sure there was no copper (even under soldermask) that could be rubbed through and short on the back of the panel.  Mind you, this circuit was designed with short circuits in mind, and nothing will be damaged, but if it shorts it won’t work right and I’ll be peeved.  I think I will use contact cement to adhere this board rather than the foam tape of the other one, as it is designed for flat contact  and has no components or pins like the other board does.

You’ll also note that the bottom side traces extend straight for a quarter inch from where they are routed to the connector.  I actually made this board larger than it had to be, because I didn’t think I could get good adhesion in only a quarter-inch of mating surface.  I kept the traces straight in this area so I could easily make the board wider or narrower as needed.  The total board dimensions are now 0.65 by 0.76 inches, driven in X by adhesion area and in Y by the components themselves.  This board is 2-layer and should be very inexpensive (at $5 per square inch, my math works out to $2.47 per 3 – I wonder if OSH Park has a minimum order?), so I plan to order it and just see how it works without putting too much more thought into it.

I spent a little bit of time deciding whether this will end up too small, and in doing so drew up a quick model of the boards in place on the LCD.  Decide for yourself if I’m crazy.

Assembly concept 1, top

Assembly concept 1, bottom

I don’t have the FFC modeled in yet, but assume it would naturally plug into the connector in its current position.  I also haven’t bothered to model any structural components, which I also haven’t mentioned yet.  In lieu of a full case, I think I’ll do a minimal support structure out of 1/8″ aluminum bar stock – a strip down each side to catch the mount pads, one across the back and a hinge with a foot so it sits upright on a desk.  I’ll talk more on that when I get that far.

Documents for the button board are available for download:

• PCB10003 REV A GERBERS (ZIP 5.4K)
• PCB10003 REV A LAYERS (PDF 7.86K)
• SCH10003 REV A (PDF 52.5K)

In the process of generating these prints I did a little more measurement and I think these will be way, way too small.  But what the hell, they’re cheap, so I ordered them anyway.  You may want to wait for Rev B.

<< Previous post in this series

Much has happened since the last update.  I have received a panel, as well as the balance of the components that I ordered.  The panel has a half-inch scratch on the front, so hopefully it is still functional.

The design has been steadily progressing.  The architecture of the board is now a bit more complex – a Freescale Kinetis-L2 (ARM Cortex-M0+) processor is onboard, primarily because it was cheaper than the competing TI MSP430 that I had planned on using, go figure.  To accompany this, a Mini-USB header has been added.  This will not power the system as per other folks’ designs because I refuse to violate the USB spec (and my motherboard) that badly, but it will allow for connectivity to the host in order to (hopefully) enable control of the panel from keyboard hotkeys.  A Linear Technology LT3502 switching regulator has been added to provide 3.3V for the panel and the processor, and a Skyworks AAT4618 high-side switch was put in place to allow power to the panel to be disabled when the system is inactive for greater power efficiency.  The board should operate from something like 8 to 40V DC, for whatever power adapter you happen to have around that fits.

First run of the full-function interface board, revision A.  I was too lazy to add some of the 3D models.  For a sense of scale, the corner pads are sized for a 2-56 screw.

So there it is.  The board is now fully routed and has been sent out for manufacture.  Naturally this means I’ve started noticing errors in it, but I’ve not found anything that means it altogether won’t work.  Getting matched trace lengths on the mDP lines took a couple hours, and was probably the one most time consuming part of the design, but now all 8 lines are matched to within 10 mils.  This is probably excessively close, but what the hell – as long as we’re doing it, may as well do it right.  The final dimensions of the board ended up at 2.525 by 1.5 inches – quite a bit smaller than I originally planned on.  And it is dense.  We’ll see how well everything works.

(2013-05-07) I will not be releasing documents for this board for a while as I have noted a serious flaw in the processor section.  I will use these for debugging the power system then respin the board when I am satisfied.

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

In the comments for Part 2 of the main series, the desire for a comparatively simple interface board was noted.  From the comments in the original thread and from the Hackaday writeup, a number of people have expressed interest in using the panel as a projector, ala the now defunct LumenLab plans.

Compared to my plans for the full-fledged panel interface, this application is a whole lot simpler.  A large external light source serves as the backlight, so no backlight driver is necessary.  With no backlight, there is no need for generation of voltage rails onboard as the whole unit can be run off a 3.3V input.  And presumably power and brightness control can be handled externally, so no processor is needed onboard.

I had a couple hours free, so I took a swing at generating a board for the DIY projector crowd.  At the suggestion of commenter Joe (and as an exercise to see whether it made the routing any simpler), I this time used a full size DisplayPort connector.  This made the fanout a lot simpler than the mDP I am using on the full-function board, at the expense of some real estate.  But the design remains fairly compact.  It is worth noting that DisplayPort’s pin ordering is different from the iPad FFC.  This means that they cannot be simply wired straight through, and must be routed between layers.  The least troublesome way to do this was to place the FFC on the opposite side of the board to the DP connector – this wouldn’t be ideal for my main controller board, but works here as the tail of the LCD will be held away from the back of the panel anyway.

Top and bottom of a simple DP to iPad FFC adapter.  This image does not show the final silkscreen.

Not much magic going on here.  The data lines are straight passthrough from DP to FFC.  The twelve backlight cathodes are connected in two banks of six and brought out to pads, on the off chance that this board might be used with the backlight intact.  To facilitate proper backlight driving, individual 0402 resistors are placed on each of the twelve strings.  Power is diode-ORed between the DisplayPort connector and pads for an external 3.3V adapter, to allow powering from either source without backfeeding to the other; 0603 bypass pads are provided in the event that the diode is not desired or required.  A 5mm electrolytic capacitor is on the output of the diode to stiffen the sources during current peaks.  Finally, a LED indicates the presence of power from either source.  The whole unit comes in at 0.810″x1.175″, barely larger than the DP in width.

So there you have it.  A design for a simple breakout.  You can go ahead and grab the board documents here:

[2013-06-13 UPDATE: The Rev A documents for this board contain an incorrect pinout for the DisplayPort connector, and have been removed.  The Rev B documents which fix this issue are posted in the next part of this series.]

I plan to order one set of these to test and debug in the short term, but beyond that would be more than happy to work with anyone else who might want one.

Next post in this series >>

I mentioned in the initial post of the iPad 3 LCD project log that I purchased an iPad 3 digitizer in addition to the LCD.  I don’t want to call this article “Hacking” the iPad 3 Touch Panel, because I’m not sure how far I’ll get with it.  But I want to at least make a page for this in case my findings may be useful for anyone attempting a similar project.

The full digitizer, as seen from the back.

This is a digitizer for the 9.7″ iPad 3 display panel.  It is, per Apple’s website, “capacitive multitouch”, although the particular type of capacitive is undocumented.  It is likely to be projected capacitive or some derivative thereof.  The connector at the center is a 2×37 pin, 0.3mm pitch FFC.  The contacts are on only one side of the flex cable, so a connector such as Molex 503566-3700 should be compatible.

2×37 pin, 0.3mm FFC. Quite small.

The cable does not appear to have any embedded electronics.  It is connected to the digitizer for about three tenths of an inch at bottom left and right in the above photo (top left and bottom left in the assembled iPad), and is glued down and appears to be occasionally connected along the remainder of the length.  Looking closely at the connection points, we can see how the contacts are structured:

One contact interface. This would be at the upper left corner of the assembled iPad.  Comes complete with dust under protective plastic film, and has been customized with black fibers.

The contact structure of the transparent section of the panel is typical of a mutual type projected capacitance design.  Forty-one very fine wiggly lines travel unbroken from left to right across the iPad display, while thirty rectangular contacts along top and bottom (as seen above) frame four short wiggly horizontal line segments between each unbroken horizontal line.  All horizontal lines terminate at a single contact on the right side of the iPad display and are individually connected at the left; all columns of line segments are bounded at both top and bottom by rectangular contacts (but are not in physical contact with them).  I have tried to photograph the pattern with a microscope, but it is very difficult, so I have illustrated the basic idea below.

Pattern of sense lines on the iPad digitizer. Note that the digitizer is shown here on its side.  Ignore the poor MSPaint rendering.

The effective resolution of this touch panel is then 41×30, but of course by interpolating between points a position can be calculated to much greater accuracy.  It also explains the number of pins on the connectors – with 74 available contacts and 41 row + 1 row common + 30 column, only 2 pins are yet to be identified – although much work remains to map the functions to the pins.

Things are already looking quite good for getting this panel to do something.  With a waveform generating MCU and a little math, this may well be workable.

That’s enough on that topic for today.  See you next time.

Next post in this series >>

Wherein the trouble begins.

The mDP and FFC connectors arrived yesterday.  I have some mDP sources and peripherals so I’ve seen the connector plenty before, but when you look at it on its own in your palm, it just looks so small.  And then compared to that, the 0.3mm pitch FFC looks perfectly miniscule.

Teeny tiny.

As I mentioned in a previous post, I plan to manufacture these boards through OSH Park.  They have somewhat stricter design rules than my usual board supplier, but they’re also less than 10% of the cost.  The rules at time of this writing stipulate 6 mil trace, 6 mil space, with 13-mil min drill and 7-mil annular ring, and no plated slots.

Here’s the problem.  The pins on a mDP connector are so tightly spaced that it’s hard to route with 6-mil traces, and because plated slots aren’t allowed, an even more roundabout path must be taken for Link 3 to avoid the now necessarily round shielding pads.  I then spent a couple hours figuring out the optimal way to route the signals through the transient suppression diode array, got everything lined up and happily routed on one layer, and went to verify the orientation of the connector to the FFC, and…

Damn.  The pin numbering of the FFC is opposite that of Molex’s numbering for the connector!  Ugh!  Now all of the signals are backward.  And to maintain the desired relative orientation of the board to the FFC to the mDP, I cannot route it on a single layer anymore.  I knew it was too good to be true.

So be it.  The board is still routeable.  Just now there are vias in the high-speed lines, which is generally a no-no.  Well, you do what you gotta do.  Here’s my plan of attack:

Veeery preliminary.

I always start a design this way, by planning out the routes with regular (non-diff-paired, non-length-matched) traces and rough part placement.  Then I start a brand-new PCB and add in the parts and traces for real.  That way I don’t waste so much time with tiny tweaks and shifts, which is easily the most time-consuming and least satisfying part of a design for me.  So nobody write angry comments about mismatched trace lengths or pair separation, okay?

Every step of this process makes me more and more nervous about this design.  The capacitors in the above layout are 0402 size.  The occupied space is about one square inch.  The board will of course be much larger than this once I add the backlight driver, but still… I always have a hard time visualizing just how small a design is until it’s actually in my hand.  And this is easily the most intricate design I’ve yet done (most of what I do is big power stuff), so it should be even more surprising.

The work continues.  Hopefully I will receive the panel within the next couple days and I can get some proper measurements.

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

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 >>