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.

Jailbreaking

You probably don't even care about any of this. If that's true, ignore it. Testing results for http://www.jailbreakme.com/:

3G/4.0 - Untested, jailbroken with Pwnage Tool
3G/4.0.1 (UPDATED from above) - Failure, Safari crash to SpringBoard. Reboot spawns reboot loop.
Entered DFU mode to restore to fresh stock 4.0.1.
3G/4.0.1 (stock restored) - Great success! High five!
3GS/4.0.1 (fresh restore) - Great success! High five!
4/4.0.1 - Haven't tried yet, waiting for MMS/FaceTime fix (since I actually use this phone) Great success! High five!  And MMS/FaceTime both work now too.

3G/3gS also unlocked with Ultrasn0w, 4 not yet (and I have no sim to test with anyway).

Meet the LaunchPad

I've been playing with the TI LaunchPad the last day or two since I've been home in the US. I ordered two when they launched, but I was abroad and only just started playing with them, and I have some first impressions to share.

If you haven't heard about the LaunchPad, it's essentially Texas Instruments' unofficial attempt at breaking into the hobbyist market currently dominated by the Arduino platform and Microchip's PIC line. TI naturally has an extensive microcontroller product line as well (the MSP430 series), but typically these chips have found use in industrial designs since they fall into the "extremely low power" category of controllers. (Likely) looking to change that, and at least looking to get young developers and students hooked on the MSP430 line, TI recently developed and launched the LaunchPad development platform as what appears to be an MSP430 based direct competitor for Arduino. Perhaps most importantly, they are selling it for $4.30, almost certainly at cost or loss. You can read more at the link above.

The first thing I notice trying to get the thing up and running is that the packaging and general product is very nice. The board is small but not skimping on functionality for this type of purpose. The box which is attractive and protective) includes a MiniUSB cord, some stickers (a nice touch), some headers and a crystal, and maybe coolest, a second IC. Two ICs AND a dev board for $4.30! That alone is worth it. The board is nicely solder masked (red) and silkscreened (labels for all components and board functions, logo). All in all, it's a nice package, especially for the cost.

The included demo is cool and reasonable: the IC prepopulated to the board (the MSP430 G2231) includes an onboard temperature sensor (or maybe the ADC samples an input diode or something, details on the temp sensor are unclear after a few minutes of research). By just powering on the board, the LaunchPad compares the current temp to the temp at startup and lights a green (greater) or red (lower) LED accordingly. The LaunchPad also reports the temperature over UART to the virtual com port, so a simple serial reading application on the computer can monitor it (demo implementation in Processing available for download from the wiki above).

But here's where the headaches start. For comparison, I'm going to start by describing the Arduino experience: on Windows, Mac, or Linux alike, download the Arduino IDE (you can't really call it that, but it does integrate an editor, a debugger, and a serial terminal). On Windows, you then install it. On Mac, you copy the download to /Apps. On linux, you either double-click the downloaded package or you used a package manager anyway and you're already done. And keep in mind, this is by hobbyists for hobbyists.

In contrast, there are two software packages for the LaunchPad, IAR and Code Composer Studio. I'm still unclear which does what. They are both Windows-only, Mac and Linux are both officially unsupported, though if you're adventurous you can compile and debug on the command line. Moreover, the installation on Windows 7 is anything but smooth. My first attempt to install IAR failed and, as I write this, I haven't yet tried again since I'm still trying to install CCS (for which I'm on attempt two, attempt one stopped responding). While the CCS install has finished, it experienced so many errors that I can only cross my fingers that things will work.

That's pretty unfortunate since the device looks promising on the hardware side. For now all I can hope is that the software does work and I don't run into too many issues with USB support in my virtual machine. With any luck, Installation will be the end of my major problems, since the LaunchPad is pretty hard to refuse at $4.30 and 220µA/.5µA/.1µA current draw in active/standby/off.

Debugging on device. Freaking finally.

UPDATE: There's a new method for iOS4 but they're pretty similar anyway.

So it's been a while, but now that I'm on break again and have some time, I'm doing a bit of iPhone development again. That means I'm going to need to debug on-device (or at least load my app to it to have fun in the real world with my handiwork). This time, the procedure's a little different though.

Vital stats:
iPhone OS 3.1.2
Xcode version 3.2.1, 64 bit
Mac OSX 10.6.2 Snow Leopard

Let's do it.

UPDATE: Corrected a problem with the run script build phase: corrected the directory names for the new version and copied the new phase that doesn't include "resource_rules.plist."

UPDATE 2: Somehow I forgot the add an identity step. It's now #1 below. Sorry guys. Also, while this whole thing should apply to iPhoneOS 4, I'm going to officially text it/repost with 4.01 soon.

The Goal: The goal is the same as the last time and the time before that: 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. More than that, we want to be able to DEBUG on the thing!

Abstract: Our methodology is slightly different this time around. 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't codesign 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:

1. UPDATE: You actually have to do this first. Most of you didn't have a problem, since you had to do it in previous guides, but some people have gotten stuck here because I somehow managed to leave this out entirely. Sorry: You will need a signing identity. We’ll break the check such that it doesn’t have to be an official ADC one, so you can make your own using this guide from apple (coral). What you are doing in this step is creating a “Self-Signing Identity.” Note that you should name the identity “iPhone Developer” EXACTLY to avoid having to change a bunch of the steps below.
2. Make some Plist adjustments, starting with SDKSettings.plist:
   cd /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.1.2.sdk
cp SDKSettings.plist SDKSettings.plist.orig
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.
3. Now, move on to the platform Info.plist
   cd /Developer/Platforms/iPhoneOS.platform/
cp Info.plist Info.plist.orig
vi Info.plist
   Three times, the following appears:
   <key>CODE_SIGN_CONTEXT_CLASS</key>
<string>XCiPhoneOSCodeSignContext</string>
   Find each occurrence by, in vi, typing the "/" key and CODE_SIGN_CONTEXT (typing / will open a "find" box at the bottom of the window)
   Replace the
   <string>XCiPhoneOSCodeSignContext</string> with
   <string>XCCodeSignContext</string>
4. 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
dd if=iPhoneOS\ Build\ System\ Support of=working bs=1 skip=127504 seek=127504
/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
   255+0 records in
255+0 records out
127500 bytes transferred in 0.020355 secs (6263821 bytes/sec)
189216+0 records in
189216+0 records out
189216 bytes transferred in 1.200354 secs (157633 bytes/sec)

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

5. 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).
   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"

6. The final step is to tell Xcode "well, actually you should codesign."
   mkdir /Developer/iphoneentitlements312
cd /Developer/iphoneentitlements312
curl -O http://www.alexwhittemore.com/iphone/gen_entitlements.txt
mv gen_entitlements.txt gen_entitlements.py
chmod 777 gen_entitlements.py

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
export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate
if [ "${PLATFORM_NAME}" == "iphoneos" ]; then
/Developer/iphoneentitlements312/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 (in debug build mode) the app will load onto the phone, and will launch and run manually just fine. However, if the debugger tries to launch it then attach to the process (as when build and go is clicked), the app will segfault and die, causing the error
Error from debugger: The program being debugged is not being run

Perhaps the most confusing part about this error is that build and go works fine up until that point WITHOUT disabling regular code signature! If you sign with a fake identity like we used to in the previous tutorials, everything installs fine, but the legit CODESIGN generated signatures cause the segfault, whereas the gen_entitlements.py ones don't. To further confuse, the regular CODESIGN in this version of Xcode happens last in the build process, wheras it used to be that the custom run script phase happened last before. Meaning we have to kill legit codesigning or it wipes out our fake codesigning. All one monster headache.

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

Oh right, except the one last (critical) part. You have to have a jailbroken iPhone, and it has to have Installd Patch installed! That part's critical. You can find Installd Patch in the iphone.org.hk repo at http://iphone.org.hk/apt, if you don't have it installed.

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.

I've said before on this blog that I'm an electrical engineering student right now. Specifically I really enjoy designing power systems: things that require lots of volts but even more amps. I've also sort of been an environment enthusiast for a long time and being a techie in general, things like veggie oil buses and renewable energy systems come as natural interests to me. The nexus of all these things is very convenient for someone in my situation: I like electronics, and all of these things require electrical design.

More specifically, though, let's talk about renewable energy. The principal problem right now with things like wind power and solar energy is that they're unpredictable. Hydro power doesn't so much have this problem because most hydro dams have a man-made reservoir behind them and locks can be opened and closed as needed, but most other renewable resources with enough capacity for mass production are, in terms of availability, at the mercy of the weather.

The reason this is a problem is that our current grid is dumb. It delivers power from one spot to another, more or less instantly, with no wiggle room. In other words, the input (power generated) has to be slightly greater than the mass usage on the grid at any given time. If it's less, obviously there isn't enough power and you get brownouts or grid shutoffs. If it's too much more, you're just wasting energy, and if it's not enough more, you run the risk of brown or blackouts caused by momentary spikes.

Sidebar for a moment: What is a brown out and what is a black out? First, imagine your cordless drill. When the battery is dying, the drill doesn't stop all of a sudden, it gets slower and slower. If you let it go long enough, it eventually it stops, but mostly it just goes too slow to be useful, and loses all power against whatever you're screwing or drilling. This is because of how a voltage source (like a battery or a power plant) works. A voltage source tries to keep the potential across its terminals constant. Think of it like a bath tub full of water, with a guy sitting there turning the faucet on and off as necessary to keep the water level constant (to go into depth, the faucet is like the chemical source of energy - the coal being burned, the nuclear fuel being fizzed, or in a battery, the chemical reaction going on). The motor of the drill, though, is eating this power ravenously, but it can only eat so fast. Usually, the chemical reaction in the battery can outstrip the motor's demand, keeping the voltage level all the time. When that reaction starts to use up all its reactants, though, and it starts going more slowly, it can't convert energy fast enough to keep up with the motor's demand. As a result, the voltage across the battery drops, and puts less power into the motor, which slows down and loses torque.

The same thing happens on the electrical grid that serves your house. If the grid tries to pull energy out too fast, faster than power plants can supply it, the voltage on the whole grid drops accordingly, just like the tub draining faster than the guy working the faucet can fill it. Usually, when a situation like this is encountered, the grid fails before the power plants (that is, the grid's wires would melt or burn or be otherwise damaged by so much transmission, and to keep everything safe, automatic shutoff switches kick in and some supply line is cut. Sometimes supply duty fails over to adjacent grids, keeping the lights on, but sometimes adjacent grids can't supply enough so it doesn't, or worse, it does fail over and the adjacent grid BECOMES overloaded and shuts off. In either case, the grid automatically shutting off results in zero voltage at your house, and it's called a blackout (the lights turn off).

Sometimes, especially in California (they're famous for brownouts), the grid doesn't shut off. Instead, it stays on, and power plants simply can't keep up. As a result of the tub draining faster than it fills, the mains voltage for affected areas drops outside of acceptable limits (in the US, mains voltage is 120v, but that is intended to safely vary within +-10% or so). This is called a brownout because the lights just dim instead of turning off (though other appliances may actually behave erratically or be damaged). There, now you know what a brownout is and why it might happen.

Since the output of both Wind and Solar plants depend intrinsically on the weather, this system isn't very practical. That is, if supply=demand needs to stay true, and if demand varies with lots of factors, supply can't also vary. We have to be able to control it. With wind and solar, we generally can't. Basically, there are two options to achieve a grid powered entirely by abundant renewable resources. Either find a way to make those power sources variable (key aspect: increasable. We can always throw more coal on the fire, we need to be able to blow more wind on the turbine if we're to replace the coal. We can always stop the turbine entirely, that's not the problem), or instead, design some sort of grid where supply=demand doesn't have to always hold true, only over the average across some period of time.

Seeing as how it's generally impossible to conjure wind or move the clouds (not that either would be a good idea anyway), the only real option is to design a flexible power grid.

Enter the "Smart Grid"

The idea behind the smart grid is to build in storage and intelligent sensing such that the grid itself always knows how much power is needed and how much it has available to it in both original generation and storage. Designing components of such a system is one of my primary areas of interest as an electrical engineer. By converting to an electrical distribution system as intelligent as the internet, we stand to gain a LOT of leeway in the kinds of consumers and producers of energy available to us going forward. Just like a Prius reclaims lost energy by braking and saves energy by not using the motor when it doesn't need all the energy it can provide, our new smart grid can sip energy over the long term from the ocean or earth below us (wave generation and geothermal heat exchange, respectively) for us to use when we really need it, maximizing our ability to generate energy and optimizing our usage of it, while acknowledging the fact that the general populous isn't going to self-regulate demand on the whole.

And of course, it goes without saying that all of this is necessary if we are to do anything as a society about reversing or at least stopping our extremely unsustainable energy policies. It's generally acknowledged that the atmosphere simply can't support sinking any more carbon, which is the largest byproduct of our current energy generation techniques. Even assuming that we're OK at this very moment, which we're likely not, we'd have to basically shut off operations worldwide in order to reduce our carbon output to a level that the earth is naturally capable of dealing with. But that's only the bad news. The good news is that if we pursue the strategy above, and if we do so quickly and successfully, we have much less to fear both immediately and going forward. The beauty of sustainability is that it's sustainable, and that peace of mind doesn't disappear after you've established sustainability the first time.

This post was written for Blog Action Day 2009, http://www.blogactionday.org/. The issue this year, climate change, happens to be both important and eminently relevant to me, so I chose to break my traditional content mold. Also, I'll probably try to follow this up a bit later as there are some topics I feel I glanced over or didn't cover deep enough.