Eagle parts!

I finally got around to putting my personal Eagle parts library on Github. There's not much else to it, find it here. The most noteworthy thing in there is the SOT223-5 footprint, which I couldn't find anywhere online or in the default libraries. Enjoy! Complete listing below.This is certainly subject to (rapid) change, see the commit messages on github, but for now the library includes:

• Analog Devices AD7685
• ADC121C021
• TI INA125 (the default libs already have it, but for some reason that wasn't good enough, don't remember why)
• Linear Technology LTC1063
• Maxim MAX7414
• Maxim MAX31855
• ON Semi MC74VHC1GT126
• TI REF3333
• Burr-Brown REG103
• SN754410
• Omega PCB-Mount Thermocouple Receptacle
• Bournes 25-turn trim pot
• Amphenol USB3.0A Receptacle
• Amphenol USB3.0B Receptacle

The packages are all standard from the default libraries except:

• Sot223-5

USB IR Toy v3

I got the USB IR Toy v3 as a free PCB from Dangerous Prototypes a few weeks back, but until recently I haven't had much time to track down all the parts for it. Given that this is a v3 and not a v2, there isn't a simple shopping cart of parts at Mouser kicking around. So, I decided to make one! Here is the link to the project on Mouser. I have some notes from assembling it, though, that someone with more knowledge of the project should hopefully be able to respond to.

1. I didn't specify an inductor for L1, my plan is to simply short the pads together. My logic is that I have no idea where to find an 0805 footprint inductor, and the bypass caps on all the ICs should be plenty. Yes? No?
2. I decided to use one of the already-required 1µF ceramic caps for the regulator, rather than a polarized cap as none was specified. The bigger footprint suggests a tantalum was intended, but the datasheet for the regulator makes no specification as to WHAT kind of bypass cap should be used, only that it should be >=1µF. And the 0805 cap used elsewhere in the project will physically fit those pads.
3. VUSB of the PIC is shorted to 3v3 = VDD, is that right? It seems to me like it's not, but then maybe it's a typo in the schematic symbol for the IC.
4. PIC18F24J50, is that right? The specified part number doesn't exist, and looks like it's an incorrectly formed version of this part (same part, with some digits/characters transposed).
5. I used the existing Infrared demodulator, TSOP38238 rather than TSOP34838, which is not in at mouser and won't be for another two or three weeks. Is there a special reason why the latter was specified?
6. On the board I have (same as in the picture on the project page), there is no reset switch placed. I don't know if the switch is obsoleted by software or some such, but if it's not, it'll have to be jerry-rigged anyway, so there's no sense in buying a part that we can't solder.
7. I used the BC81840MTF as T1, rated in the parts listing as 800mA+ when the project calls for 1A+, is that a problem? It seems to me like 1A for an LED is insane, but then that's what the BOM on the project page calls for. Is there a problem here?

Assuming these points all check out, the project cart should be good to go! HOWEVER! An astute reader will note that the quantities are all higher than required. I like to order extras of EVERYTHING, especially the little parts, since I ALWAYS seem to lose parts to the carpet (last project, it was a $15 MSOP-10 ADC. Thank goodness the project budget paid for one or two extra). This is obviously more critical with the small, cheap parts (0805 resistors and caps) than it is with the big parts (PICs, LEDs). You could probably shave a fair few dollars off the project cost by making these quantities closer to what's actually required. And in fact, when I order, I probably will. Something to consider.

The new copper tape in place

I've been getting great use out of my modded Evil Mad Scientist Laboratories Bulbdial clock (you might remember, I modded it with a touch sensitive strip to turn the display on and off), but it's been having some problems lately. Because I couldn't solder to the aluminum tape I previously used, the contacts taped in place were getting loose, causing the clock to flicker on and off. The loose contacts also made functionality very sporadic. The solution was to swap the aluminum strips out with the copper foil I bought a while back from Sparkfun for a whopping $3. 

While I was working, I decided to revisit the mod. Here is the module I had previously made:

Top view of circuitry

And from the bottom:

Bottom view of circuitry

And finally, everything put together:

Assembled

I also decided to actually add the schematic into the original, just for clarity. Before:

Original switch schematic

And the modded version, as it stands now:

Schematic with mod

However, I'm curious as to what would happen if I scrapped the center pin on the header I added to the switch, which is jumpered to VDD elsewhere on the board. I could instead connect the touch strips to the pin of the µC itself, in effect creating a diode-connected transistor. The main problem I can see is that this would only allow for the transistor to pull the input pin (which must be internally pulled up) to GND+Vf of the transistor's base-emitter diode. I haven't checked what the 'low' voltage of the pin is now with the current design, but I'd bet that the input is unstable at 'low' = .7V. Still, it'd be cool to eliminate the one part and the one extra assembly step. (Update: I did check what the current 'low' voltage is, around 0.07-0.08V, quite stably 'low' indeed).

Perhaps some more experimentation next time. But in the mean time, the problem has been fixed.

STM32F4-Discovery

ST Micro in the last few weeks was the first to market with the brand new ARM Cortex-M4 32-bit microcontroller core. The really interesting new feature is the 'F' in the name - this is the first low-cost, low-ish-power light duty microcontroller to include a built in, single cycle per instruction 32-bit floating point unit. In typical ST fashion, the development board is awesome - it's got a built in ST-LINK/V2 programmer and in-circuit debugger on the top half. The bottom half contains the M4 and a host of fun peripherals to play with, including a 3-axis MEMS accelerometer, an audio DAC with class D output driver, a bunch of LEDs, and all GPIOs broken out to .1" headers.

But alas, the software stinks. In fact, it doesn't come with software. There are 4 proprietary (and EXPENSIVE) toolchains supported, Altium TASKING, Atollic TrueStudio, IAR Embedded Workbench for ARM, and Keil MDK-ARMT. Of those, only Atollic and IAR have free versions, where IAR is 32 KB limited (the M4 has 1MB flash), and where Atollic is neither time nor size limited, but doesn't support C++. For some that will be fine, but I'm certain I'll find that annoying.

So what do we do?! Luckily, the single most developed compiler out there is open source, GCC! We're going to use a commercially-developed open source compiler, Mentor Graphics' Sourcery CodeBench Lite edition. We'll pair that with the open source IDE Eclipse (standard for most open source and commercial development toolchains alike), and then weave in ST's tools like ST-LINK/V2 to fill in the gaps. I'm going to mash up a few different existing tutorials to do this, starting with this excellent tutorial for setting up this same toolchain, but for the original STM32VL Discovery and on Windows.

Prerequesites: you'll need Apple's developer tools (Xcode), a package manager for *nix programs (instructions given are for homebrew, you could probably use macports if you really want), and git.

Here's what we'll be using:

Indigo R Eclipse IDE for C/C++ Developers (Mac Cocoa 64-bit)
http://www.eclipse.org/downloads/packages/release/indigo/r

STM32F4 DSP and standard peripherals library
STM32F4 Discovery board firmware package
http://www.st.com/internet/mcu/product/252149.jsp#SOFTWARE_AND_DEVELOPMENT_TOOLSStart downloading these now, they can take a long time.

Sourcery G++ Lite 2011.03-42 for ARM EABI Source TAR - jsnyder package
https://github.com/jsnyder/arm-eabi-toolchain

1. Download and install Eclipse. From here, download the Mac Cocoa 64-bit version of Eclipse for C/C++ developers. Extract the .tar.gz, and copy the 'eclipse' folder to /Applications, as you would with any other Mac app. Launch Eclipse.app from that folder. When prompted for a workspace directory, add 'stm32f4-discovery-projects' to the path just before '/workspace', as below:

Set your path

2. Install Sourcery G++ lite. We're going to use the arm-eabi-toolchain builder from James Snyder. Launch Terminal from /Applications/Terminal or spotlight and enter the following commands, preferably one at a time. Note that the compile commands (CC=clang make... and make cross-gdb take a LONG time, go grab coffee).

cd
git clone https://github.com/jsnyder/arm-eabi-toolchain.git
cd arm-eabi-toolchain
brew install mpfr gmp libmpc texinfo
mkdir -p $HOME/arm-cs-tools/bin
export PATH=$HOME/arm-cs-tools/bin:$PATH
CC=clang make cross-binutils cross-gcc cross-g++ cross-newlib
make cross-gdb
export PATH=$HOME/arm-cs-tools/bin:$PATH
make clean


3. Configure Eclipse. Launch Eclipse that you started earlier. In the menu, go to 'Help>Install New Software...' then click on the 'Available Software Sties' link. Search for 'cdt' and select the one checkbox that pops up. Hit OK.

Search for 'cdt'

In the 'Available Software' window, select the last entry in the 'Work with:' dropdown. Expand 'CDT Optional Features' and select 'GCC Cross Compiler Support'. Click 'Next' until the wizard successfully installs and/or updates everything (in my case, all the software was already installed, so it just updated). Restart Eclipse when prompted.

Select Cross Compiler Support

4. Create a custom template. In Eclipse, go to 'File>New C++ Project'. Name the project 'Template', and for 'project type', select 'Cross-Compile Project' under 'Executable'. Click 'Next', NOT FINISH.

Template project settings

On the next screen, set the tool command prefix to 'arm-none-eabi-' and the tool command path to '~/arm-cs-tools/bin'

Enter these values for tool prefix and path.

Click 'Next' then 'Finish'. Click on the 'Go to workbench' icon. In the project explorer, right click 'Template' and click 'Properties'. In the 'Project Properties' window, select 'C/C++ Build>Settings'. Under 'Cross GCC Assembler>General' add -mthumb -mcpu=cortex-m4to 'Assembler Flags'.

Add -mthumb -mcpu=cortex-m4 to assembler flags.

In the 'Miscellaneous' sections of both 'Cross GCC Compiler' and 'Cross G++ Compiler' set the 'Other flags' to -c -mthumb -mcpu=cortex-m4. Finally, go to 'Cross G++ Linker>Miscellanoues' and set the 'Linker flags' to -T "${ProjDirPath}\startup_src\stm32_flash.ld" -mthumb -mcpu=cortex-m4 -Wl,-Map=linker.map -Wl,-cref -Wl,--gc-sections. Click OK.

In the Project Explorer, right click 'Template' and select 'New>Folder' to create 'src' and 'startup-src'

Create these folders

5. Extract the earlier downloaded stm32f4_dsp_stdperiph_lib.zip inside the ~/Documents/stm32f4-discovery-projects/ directory.

Make sure your project directory looks like this

Copy the file ~/Documents/stm32f4-discovery-projects/STM32F4xx_DSP_StdPeriph_Lib_V1.0.0/Libraries/CMSIS/Device/ST/STM32F4xx/Source/Templates/TrueSTUDIO/startup_stm32f4xx.s to the startup_src directory you created in Eclipse above, then change the extension from .s to .S, capitalized. Note that you must drag/drop or copy/paste directly into the Eclipse interface or the file won't show up in Eclipse.

This is as far as I've gotten. I'm currently hung up on how to replace 'stm32_flash.ld' since the M4 isn't nearly the same flash layout as the value line board used in that tutorial and I can't seem to find a proper linker script. If you know where to go from here, PLEASE comment!

Technically, in order to obey the USB spec, if it didn't negotiate for > 100mA, it can't have >100mA If it tries to draw more than 100mA and it's attached to a USB port with a power supply line that legitimately can't provide it, the result is a drop in voltage on the line, and bad things happen. Maybe it's connected to a 5V supply that can handle 40930485 amps, it doesn't matter. It's just not allowed.

Of course, most things can supply at least 500mA, and to be sure, lots do regardless of negotiation. If I plug a dumb little USB fan or whatever else into my computer, it may use more than 100mA. Technically it's not within the USB spec in this case, but whatever. So basically, you're safe drawing up to 500mA from a USB port without asking, although you probably won't get USB certification.

But of course, with a dumb charger, if you want to be within spec, you can't just *go* and draw what you like. There has to be some other methodology. iDevices for a long time have employed resistors on the data(+) and data(-) lines of the USB port to handle this. LadyAda tore apart a few chargers to figure this out, and she found something like this: if you want the iDevice to take 500mA, hold data+ at ~2.8v and data- at ~2.0v . edit: sorry, I didn't read the LadyAda page well enough, 2.8/2.0 is 1A, and 2.0/2.0 is 500mA. If you want it to charge at 1A, do something similar but with different values.

Finally, there's the more recent USB Charging spec. The pertinant part here is that on modern devices, you're within the letter of the USB spec if you short data+ and data- together as a message to the device, "you can draw any current you like, from 500mA to 1.5A."

And something like that is going on here. It could be one of two different things. It's definitely safe to say that on the male USB plug, only V+ and GND are attached. That way there's no data negotiation at all. On the female side, it's possible that resistors are in place as in the paragraph above to tell the iDevice "I'm a dumb charger, draw 500mA." Although I lean away from that conclusion, since I BET that in such a case, the iDevice would still warn about too little current to charge. The other option is that, as per the Charging spec, the lines are shorted together. That'd technically tell the device "draw whatever," but I THINK that iDevices only draw 500mA in this case, which like I said is generally safe. And it could be that the iPad draws an amp, and the dongle just hopes that most users' computers will be able to handle it.

The bottom line is this:

The dongle is not magic! It doesn't make power out of nowhere. It doesn't matter that it's small and light, or that the iPad is big and not. The takeaway here is that the dongle skirts the letter of USB law to say "computer, give me all you've got, whether you like it or not" and to tell the iPad "here's all the power you desire!" Maybe it works across the board, maybe not, but I'll definitely tell you I won't buy one. I'm 100% positive that if I stick that thing in my late 2008 MBP (with its 500mA max of usb current, yes, I tested the hard way), I'm DEFINITELY getting an overcurrent USB warning. And if I don't, the thing's not helping anyway.

EDIT: I forgot to mention, but it's worth doing so, you can't simply tell the device "you have an amp" if you don't, in fact, have an amp to back it up. It won't just fall back to 500mA, that's not how Ohm's Law (v=ir) works. If the device tries to draw an amp, one of two things NECESSARILY happens. Either the computer CAN support the draw, but doesn't SAY so (in which case, there's certainly good reason it doesn't say so, and good reason you shouldn't be drawing an amp), or the computer CAN'T support the draw, and the USB bus fires an overcurrent warning and the power rail is shut down. And no charging at all takes place. In no case is it a good plan.

UPDATE: For shiggles, I did some quick testing with my USB breakout cable. As per LadyAda's findings, my iPhone 4 with a nearly-full battery draws around 575mA from it's in-package wall charger, stock configuration. Stock configuration has data+ at 2.8 and data- at 2.0, which is what you'd expect from a charger UL rated for 1A supply. Similarly, when I disconnect the charger's data lines entirely, and instead show the phone 2.0v/2.0v, I measure a draw of around 510mA. Again, that's what I'd expect. I'd also expect to see that, charging full swing, it draws more connected to 2.8/2.0, but I'll have to wait until I have a low battery to test.

My custom board

A few people asked about this. I've seen breadboards with binding posts before, but usually they're nothing special, just some banana plugs near the board that you can screw a jumper wire into. I wanted something a little more full featured, so I whipped this up.

View from the back, you can kind of see the power distribution block wiring.

It's 3 interlocking cheap $5 breadboards, linked together, that have had the sticky backing peeled off and that have been stuck to a clipboard. There are 8 banana terminals/binding posts mounted on the clip which are hardwired to the power rails of each individual board by a configureable jumper block. The advantage is that it keeps power management easy and clean, and any spare power rails can be used as easy interconnects to a meter(s) so that you don't have to have extra leads coming in. Basically, any off-board connections that can be made by banana plug can be moved away from the prototyping area, which means things stay more organized and there's less opportunity for heavy wires to yank out of the design by accident.

Also, mounting everything on a big clipboard means there's leftover room, in which I added (fake) laminated white paper as a whiteboard area. This way, notes can be made and labels added to clearly indicate current configuration.

Here's a quick video walkthrough:

Custom Breadboard from Alex Whittemore on Vimeo.

Let's make it touch sensitive!

UPDATE: People keep asking about the breadboard setup. Fair enough. I'll throw together a quick overview when I get home today.
UPDATE: here it is: http://www.alexwhittemore.com/?p=462

The Bulbdial clock from Evil Mad Scientist is probably the coolest clock idea I've ever seen. Even cooler are my parents, who got the kit for my birthday.  The basic idea is that three rings of LEDs cast shadows onto a clock face to form H/M/S hands, somewhat like a sundial, with the hands slowly animating around. A lot of thought clearly went into making this kit, and it's very nicely done, but there's a major drawback: I want to use it on my bed side table, where I usually keep a clock, but it's too bright for me to fall asleep! Of course, that's been thought of too: in the normal view mode, the three buttons at the bottom of the clock are brightness up, down, and "mute," which turns off the LEDs entirely. But they're hard to get to buried underneath the frame of the clock, and it makes muting the display cumbersome in the dark. Let's fix that!

My general solution to the problem at hand is pretty simple: I want some kind of strip running across the top edge of the front plate of the case that, when touched, toggles the display on or off. My first thought jumped to a capacitive sensor: I know that I can find one or two parts on http://www.sparkfun.com/ to handle the heavy lifting, and I know they're pretty reliable. Problems with this plan sprang up pretty quickly, though. First, the two parts available on sparkfun are pretty expensive. One SMD bare part is ~$12, and a different broken-out part is $24. Both are a bit more than I want to spend on this project. Second, looking at the schematic from the bottom of the first link above, there are no spare GPIO pins left on the ATMega on the clock! That's sort of a deal breaker; I could use the hardware serial tx/rx lines, but then I lose the built-in serial functionality which I might want, and I want to be as unobtrusive as possible. Also, comments on those two parts mention that they can be difficult to set up with Arduino anyway, and I'm not especially good at programming micros, so even if there were GPIO pins left to use for software serial, that'd probably be a headache.

So sensor type option two is a resistive setup, which is not only substantially easier, it can even be made with all passive components bolted on to the existing design, as I'll do first (although the drawbacks will become apparent quickly). So resistive sensor, method one:

You use this to fasten pieces of stained glass into a pane by soldering.

In both cases, there need to be two conductive strips running along the top case edge in question to sense a finger's resistance. Ideally I'd have used the kind of copper foil tape used in stained glass, like this stuff. It's cheap, conductive, sticky-backed, and it'll hold solder to fasten leads to: it's INTENDED to fasten pieces of glass together by soldering. But I haven't done stained glass in years, and I don't happen to have any lying around. And I didn't feel like waiting a day (I did this on a weekend) then driving 20 minutes to a supply store and back just to get a $5 roll of copper foil. Instead, I dropped by the hardware store and went with option two:

Option two.

This is the stuff you repair muffler leaks and such with. It's conductive, which, for my purposes, is pretty much the only hard requirement. It doesn't hold solder at ALL, so fastening wires to it was a pain, but oh well. Maybe some day that I have time I'll go get some copper foil, but not right now. I carefully cut two strips of it each about 3mm thick and 35cm long. That itself was a pain, but conveniently, at 5ft you have plenty to practice on. Once I cut those strips, I carefully laid them on the front and back edges of the top case edge such that there was a 1-2mm gap between them. They folded over the edges by a ways, but as uneven as they are, they still look fine.

Conductive strips running along the top edge of the case

I don't have a great picture of the connections on the other side, but you can probably imagine. I peeled two wires off the side of some ribbon I had laying around and stripped the ends. I just electrical-taped those to the strips on one side near the bottom such that each wire contacts one side. Then I stripped the other ends, which are now our "sensor terminals." The only other parts to worry about are headers soldered to the main clock board and a little detachable board soldered to the sensor which plugs into them.

And that does it for the "sensor" part - with no finger present, the wires have an open circuit between them, and when a finger is present, there's some resistance, the value of which depends on an annoying number of variables.

Now, I had to pick a method to READ this sensor, so here's what I did FIRST.

I looked first at the schematic surrounding the relevant switch, it's simple enough.

We're looking at that bottom switch, Z.

The three switches are all connected between GPIO pins in "read" mode and ground. That is, internally there's a pull-up resistor to VDD and the micro is reading the voltage below it. I can use that. The way the digital "read" mode works is that, if the voltage at the pin is above some threshold, the microcontroller reads a "1" and if it's below the threshold, it reads a "0". In this case, since the switch is NO (normally open), a "1" corresponds to "not pressed," meaning I need to momentarily "close" the switch, shorting the pin to ground to "press" it and get a "0."

I used this threshold behavior to my advantage to reduce the part count to a single resistor. I selected a resistor to put in parallel with the switch such that the voltage at the microcontroller pin was just ove the threshold around 2.7v. In my case, that was somewhere between 35kΩ and 45kΩ. Then, the touch sensor is wired in parallel to that. When it's touched, the resistance across it serves to decrease the resistance of the 35k-45k resistor, since the two are in parallel. Assuming you tuned the 35-45k resistor right (I used a 100k pot for testing), the resulting resistance drop will decrease the voltage at the pin until it's just below the threshold to register a "0" and a button press.

The finished product of method one

In practice this works, but it's what you'd generously refer to as ghetto hackery. It doesn't work all that well, and it's a bad design for many reasons: First, the resistance presented by your hand on the sense strips is HIGHLY variable. I eventually settled on this method because, at the time that I was in my basement testing, it was a pretty hot and humid day out and my hands were a bit clammy. The salt on them from sweating on and off at an elevated rate all day combined with the moisture meant that the resistance at the sense strips was abnormally low, resulting in fairly accurate microcontroller response. I found over the course of the next few days that normal dry and clean hands had far too much resistance, even over such a short distance, to get a good response. I had to either press hard, or use my full hand (more surface area). The only reliable way to get a good press was to lick my finger before pressing: the saliva is much more conductive. That's alright, but it doesn't effectively solve the original problem, which is easily and quickly shutting the light off at night. Having to lick my finger is just about as cumbersome as picking up the clock, and much grosser.

Method one schematic: V1 is the ~2.7v value with no finger present

Besides not functioning either well or predictably, another problem with the design is that you have a constant current flowing through both the fixed resister and the internal pull-up. By V=IR, with V= ~2.7v and R = ~39k, you get I = ~.000069A, or
~69µA constantly flowing from the internal supply to ground. Now, that's not all that much, and it's not as if I'm going to burn a resistor (even the little tiny one in the micro), but that's still just wasting power. That much current could provide enough juice for 69 MSP430 microcontrollers in standby. In addition, holding the micro's sense pin around the threshold voltage is probably just bad practice. The Arduino software seems to handle this nicely, but the micro is probably reading horrible noise on that pin from its internal comparator. All in all, it's just bad.

So I decided to scrap the passive plan and try method two. I could have done something like get another microcontroller (I have a few MSP430 value line parts lying around now) and make essentially an ohm meter, using a GPIO pin to output 1 or 0 to the Arduino's input (switch) pin. But that'd be unnecessarily complex. What I really wish is that I could somehow amplify the resistance of my finger. Wait, did somebody say "amplify"? Transistor time!

Everybody's friend, the quad-2

Idea two is to not exactly to amplify the RESISTANCE of my finger, but at least to amplify the CURRENT that flows through it. Touching the sense strips means a small current flows through my finger as per V=IR. If I pipe that current into the base of a standard NPN transistor, I can amplify it. And I can make the amplified current flow between the internal IC pull-up resistor and ground. BINGO! This has the advantage, thanks to the huge current gain (β=200 for the spare 2n2222 I had), even with a really big resistance  on the sense strips (dry hands), that tiny current results in a relatively large current from collector to emitter of the transistor. A relatively high I flowing through a resistor of relatively high R (that is, the internal pull-up) is a relatively high voltage drop. If this current is high ENOUGH (.151mA, according to I = V/R = 5/33k), then the transistor is effectively a dead short to ground, which is exactly what the Arduino wants to register a "0" on that pin. And if it's not .151mA, the voltage at the pin will probably at LEAST go below the threshold by an amount greater than in method 1.

Now it looks like this. I also added headers for the sensor such that it's totally modular. You know, in case I decide to change my mind again.

So the part count is now up to a single transistor instead of a single resistor, and it's already much more reliable. The only thing is that it's usually pretty bad to put the full VDD directly onto a BJT's (Bipolar Junction Transistor's) base, because then you can get nasty side effects and it's not good for the transistor. The finger will always be a great enough base resistance, but in the case that the sensor is shorted with some kind of metal, I added a real base resistor of 1kΩ in series with the sensor. It won't decrease the small current substantially, and we have plenty of headroom. You can't really see it in the image to the right, but the board is now about the same size and includes female headers to plug into the clock, as well as headers to plug into the sensor. I didn't do that originally, but now I can take the board out totally. I also had to add VDD to the mix, since there are now active components. That's the little red jumper that goes from the wall plug jack to the center pin on my header which was previously unused.

The new schematic on bottom and the old one on top.

So there you have it. A simple little one-or-two part mod to make darkening my clock easier, and a whole boatload of ideas about how to implement a resistive touch sensor. Here's a video, for fun (it was made with design one, but you probably won't notice a difference since my hands were sweaty at the time and it worked fine .

Bulbdial touch mod from Alex Whittemore on Vimeo.

Crappy Buds

Say what you will, but iPhones are pretty awesome, and so are the headsets that come with them. At least up until you put them in your ears. The inline controls are awesome, but the speakers are uncomfortable, lacking in low end punch, and do nothing for sound isolation. Other, much better headphones exist, but for under a gajillion dollars, none come with the same kind of inline controls. Here's how to have the best of both worlds.

The solution is pretty simple:

1. Find an iPhone headset and a set of earbuds that don't suck.
2. Cut the earbuds off of each cord.
3. Splice the good buds onto the good (iPhone) cord.

Of course, it's a little harder than that (but not much, don't worry). Here's what I did. I won't tell you how to find good earbuds: it's your call what you like. I selected a pair of Sennheiser CX150s. I bought them cheap (€20) in Germany, so I had them when I bought my iPhone, and they are solid quality - much much better than the iPhone headset, anyway. A good candidate for surgery. The next step is to make your cuts. This is tricky: you don't want to cut the iPhone headset too close to the microphone, because if you mess up and have to move back on the wire, you'll quickly run out of space. But then if you cut too close to the buds, you'll have to do the same on your donor headphones in order to keep roughly the same length from finished earbud to mic. My strategy was to cut ~1.5" from the iPhone buds, and around 2.5" to 3" from the Sennheisers. At best, you only increase the length by 1" on both sides, and at worst, you have as much space to mess up. Once you've cut, you need to strip and tin. The outer insulation is a pain. Sometimes you can cut it with wire strippers without damaging the conductors (Sennheisers), sometimes it just squishes and stretches when you pull it (iPhone set). If the latter happens, try working the insulation gently with flush cutters. I can't say much more besides "be careful" since it depends on what headphones you're using how finicky the insulation is. Tinning is a different story. With a lower-temp iron, I find that burning the acrylic insulation off of the conductors is necessary. But sometimes this leaves soot that makes tinning the conductors a pain. If you can manage it, save trouble by using a really high temp iron and melt the insulation off with a blob of solder on your tip. This will tin them at the same time. IMPORTANT: PUT HEATSHRINK ON! I can't count on both hands and feet how many times I've neatly soldered up a project only to remember that I never put heatshrink tubing on.Do it now. Tip: if you can, slide two pieces on for the outermost layer. Shrink one, then slide over the other and shrink that. It doesn't insulate any better, but it adds structure to what will otherwise be a somewhat fragile joint. Solder up the connections. The trickiest thing here is to know which is which. The iPhone headset follows the scheme red: right+ green: left+ copper color: common ground red/green twist: mic/controls (right side only). The donor headset should share a similar wiring. In general, its safe to say that, if you see the same color on both sides, that's ground. Shrink the tubing. I use my pencil torch from a judicious distance. It's way too hot up close, but it  heats a nice plume of air and from a good 6", it'll shrink tubing right up. And there you have it. But if you're bored, and want to kill 17 minutes, I have a video for you too. I promise future guides won't be so long. I just don't want to edit the video down anymore since I've spent enough time on it.

Headphone Build from Alex Whittemore on Vimeo.

Epilog: After using the headphones for a few minutes, I noticed that the audio image felt like it was pulling a hard right in my head: normally stereo sound feels centered in the middle of your head, but these headphones felt like they were centered on my right ear. The problem is that one of the channels has the incorrect polarity, that is the audio is inverted. Even though it's only off by a few microseconds, this has the effect of offsetting balance drastically. The solution is to simply reverse the polarity of one channel, it doesn't matter which. I reversed the left channel since it's got far more wiggle room to mess up than the right, in this case.

This also gave me the opportunity to do somthing I didn't previously: For added strength, slide TWO pieces of heatshrink on the headphone line before soldering. Shrink one over the joint, then slide the other over and shrink that too. The outer piece serves to tighten the inner piece on the wire (it previously didn't hold the insulation well, and any tension in the headphones was supported by the solder joint) as well as to prevent flex in the joint.

This is what happens when you Build and Go with Backgrounder running.

Here's a quick note on how Backgrounder, from the wonderful http://twitter.com/ashikase interacts with Xcode's Build and Run functionality.

First, Backgrounder: The MobileSubstrate extension manages background persistance for apps both supporting iOS4's native switching as well as apps that require additional assistance. One of the options in Backgrounder is to "enable at launch," which means exactly what you'd think: apps get backgrounding enabled as soon as they're launched, and one must explicitly disable the function if desired. That's the setup I have: If it's got Native functionality built in, let it background, and tell it so when it launches.

But now we need to discuss how that happens. Backgrounder is implemented in-app as a .dylib extension. That extension constitutes code loaded into the app at runtime, in this case code which handles persistence after minimize. In order for that code to activate, something needs to tell it it should, and Backgrounder handles that message by sending a SIGUSR1 signal to the running app process whenever backgrounding is to be enabled. Keep in mind that could be by an activator gesture or some such. In my case, the problem is that the SIGUSR1 signal gets sent to the app as soon as it loads, and GDB catches it. Maybe you caught on, and maybe you're a dolt like me and it took you some hand holding, but you can get over this hump by simply clicking "continue" in the top right of the console window. This will dismiss the SIGUSR1 and the app will continue to execute as normal.

Your other option, if you're getting annoyed by always clicking continue, is to add an override for your app to disable Backgrounder. That will prevent SIGUSR1 from ever being sent and hiccuping your debugging. Though it's probably only worth the annoyance if you're recompiling constantly. And in addition, you'll have to re-override the project any time the name changes.

At any rate, hopefully that clears up any problems you might run into with this.

Jailbreak Development for iOS4!

Vital Stats:
iOS 4.0.1
Xcode 3.2.3
Mac OSX 10.6.4 Snow Leopard
iPhones 3G, 3GS, 4 (I finally have the whole lineup!)

PROBLEM: I still can't get iPhone 4 working. If you have one, please try it and help me out! UPDATE: Found the cause of the problem to be certain status bar libraries installed alongside other apps. I'm not sure why they cause the problem, but see full notes at the bottom of the post.

The Goal: As usual, we want to be able to click "build and go" in Xcode and get the app we're working on to load to the phone and start up. Also, we want to be able to debug from within Xcode itself. After all, Xcode is cool, and terminal+makefiles+gcc+gdb is lame.

Abstract: The plan remains unchanged from the 3.x method. In fact, you commenters practically wrote this one for me. This time we're going to tell Xcode that it doesn't need to codesign for iPhoneOS targets, then we're going to tell it don'tcodesign for iPhoneOS targets, then we're going to tell it, well, actually, codesign but do it using our script, not your built in method.

The Process: With Xcode closed and your device unplugged from the computer,

1. If you've done this step before for previous guides, you may ignore it. You'll need a code signing identity in order to sign code to run on the device. Normally, this would be issued by Apple, but later on we'll break the signature check so you can make a "Self-Signing Identity" using this guide from apple (coral). Note that you should name the identity “iPhone Developer” EXACTLY to avoid having to change a bunch of the steps below.
2. On your jailbroken iPhone, install the app AppSync. Add the source http://cydia.hackulo.us to cydia. You'll get a warning about pirating software: this patch, by virtue of breaking Apple's DRM so that we can install our own app, also enables us to install cracked App Store apps. Don't do that. It's immoral, fails to support legitimate developers who should be rewarded for their effort, and perhaps above all, pirating $2 cell phone apps is just ultra lame. But since our purposes are not nefarious, dismiss the warning. From this repo, install the package AppSync for OS 4.0, and for good measure, reboot the device.
3. Make some Plist adjustments, starting with SDKSettings.plist:

   cd /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.0.sdk
   sudo cp SDKSettings.plist SDKSettings.plist.orig
   sudo vi SDKSettings.plist

   Find

   <key>CODE_SIGNING_REQUIRED</key>
   <string>YES</string>

   and change YES to NO
   then find

   <key>ENTITLEMENTS_REQUIRED</key>
   <string>YES</string>

   and change YES to NO again. HINT: in vi, you can type the '/' key in order to "Cmd-F"

4. Now, move on to the platform Info.plist

   cd /Developer/Platforms/iPhoneOS.platform/
   sudo cp Info.plist Info.plist.orig
   sudo vi Info.plist

   Two times, the following appears:

   <key>CODE_SIGN_CONTEXT_CLASS</key>
   <string>XCiPhoneOSCodeSignContext</string>

   Find each occurrence and replace the block

   <string>XCiPhoneOSCodeSignContext</string>

   with

   <string>XCCodeSignContext</string>

5. And now the real bad boy, some binary patching of Xcode:

   cd ~/Desktop
   vi script

   hit the "i" key and copy/paste:

   #!/bin/bash
   cd /Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneOS\ Build\ System\ Support.xcplugin/Contents/MacOS/
   dd if=iPhoneOS\ Build\ System\ Support of=working bs=500 count=255
   printf "\xc3\x26\x00\x00" >> working
   /bin/mv -n iPhoneOS\ Build\ System\ Support iPhoneOS\ Build\ System\ Support.original
   /bin/mv working iPhoneOS\ Build\ System\ Support
   chmod a+x iPhoneOS\ Build\ System\ Support

   type the keys, in order: ":" "x" "enter"

   chmod 777 script
   ./script

   If it works right, you should see something like

   $ ./script
   223+1 records in
   223+1 records out
   111648 bytes transferred in 0.002678 secs (41692099 bytes/sec)

At this point, you're done telling Xcode it doesn't need to codesign. Now, we tell it don't codesign:

6. With a new project open and ready to go (presumably you want to debug this one, though once you change these settings once, they'll persist from project to project) open Project>Edit Project Settings (from the menu). Click on the "Build" tab.
   Find "Code Signing Identity" and its child "Any iPhoneOS Device" in the list, and set both to the entry "don't code sign"
   

   Should look like this

   Now you've told Xcode "don't codesign."








7. Almost done: time to tell Xcode "well, actually you should codesign."

   mkdir /Developer/iphoneentitlements401
   cd /Developer/iphoneentitlements401
   curl -O http://www.alexwhittemore.com/iphone/gen_entitlements.txt
   mv gen_entitlements.txt gen_entitlements.py
   chmod 777 gen_entitlements.py

8. 

   Just hit cancel.

   And finally, to link the device and computer. Plug your iPhone in and open Xcode. Open Window>Organizer. Select the device from the list on the left hand side, and click "Use for development." You'll be prompted for a provisioning website login, click cancel. It's there to make legitimate provisioning easier, but doesn't make illegitimate not-provisioning more difficult.

Now you're good to go! But there's just one last thing. You have to do this last part for every new project you make. Go to the menu Project > New Build Phase > New Run Script Build Phase. In the window, copy/paste this:

export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate
if [ "${PLATFORM_NAME}" == "iphoneos" ]; then
/Developer/iphoneentitlements401/gen_entitlements.py "my.company.${PROJECT_NAME}" "${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/${PROJECT_NAME}.xcent";
codesign -f -s "iPhone Developer" --entitlements "${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/${PROJECT_NAME}.xcent" "${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/"
fi

That will call the script you just downloaded in step 5 to sign our app with a fake signature. This is important only for debugging. If you do build and go otherwise, the app will load to the phone, but the app will fail to launch and you'll get:

Error from debugger: The program being debugged is not being run

That should do it. Take all those steps and you should be home free for JBDev without paying $99.

CREDITS: Once again, credit for this process goes to various posters in this forum thread at iphonedevsdk.com. All of these steps are there somewhere, it just took a while to re piece them together in the right combination.

iPhone 4 Issue (UPDATE see below): So the method above has been tested working for my 3G and my 3GS. I don't have my 2G right with me, but I expect it's no different from the previous method, given that it can't run iOS4.

The problem that I run into is this:

[Session started at 2010-08-04 20:35:02 -0400.]
//GDB stuff
Program loaded.
target remote-mobile /tmp/.XcodeGDBRemote-93925-69
Switching to remote-macosx protocol
mem 0x1000 0x3fffffff cache
mem 0x40000000 0xffffffff none
mem 0x00000000 0x0fff none
run
Running…
[Switching to thread 11523]
[Switching to thread 11523]
continue
warning: Unable to read symbols for "/Library/MobileSubstrate/MobileSubstrate.dylib" (file not found).
// A bunch of other lib load warnings like this here...
warning: Unable to read symbols for "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0.1/Symbols/usr/lib/libcrypto.0.9.8.dylib" (file not found).

Debugger stopped.
Program exited with status value:45.

The killer is that the app installs, launches, crashes, and then launches fine manually. But I also can't connect GDB to the running process after the fact either, GDB claims the process isn't running. I have no idea what's going on. Anyone?

What gives?!

UPDATE (8/3/10): Totally by chance I happened to read this article on TUAW today about FaceTime. I didn't pay much attention until about half way down something caught my eye:

...rather significant My3G bug -- when installed, you cannot use your iPhone for native software development....

I had initially thought that maybe third party software was to blame but I meticulously disabled each MobileSubstrate extension I had one at a time and ruled them all out. Turns out that wasn't good enough. The (since fixed) My3G bug was exactly the source of this issue, but I had actually uninstalled My3G and the problem persisted. The issue, it turns out, is with the status bar library Intelliborn uses in their products, IntelliStatusBarIcons. BUT, it doesn't stop there. By individually uninstalling apps, I've found that Backgrounder (and NOT libstatusbar) also cause a dealbreaking bug. Instead of the program exiting with status:45, the new error is "Program received signal: "SIGUSR1". at which point the application hangs. Conveniently, the workaround is easy, if annoying: For your particular project title, add an Override in Backgrounder. Hopefully this IS a bug in Backgrounder and not a byproduct of its function. But at least now you can debug again!

So partly I'm dumb and partly this is just a bummer. Full story in this post, but the general idea is that gdb catches a SIGUSR1 from Backgrounder and you have to 'continue' through it. And obviously, disabling Backgrounder for your app prevents the signal from getting sent.