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