Ones and Zeros

The FAA and various aviation-related companies (ITT and others) are pushing a system called “NextGen” that will use GPS-reported locations from aircraft instead of RADAR in enroute areas. The argument goes that this will enable Air Traffic Control (ATC) to reduce spacing between aircraft and improve on-time flights.

There are a few problems with that though, namely it won’t work to hit that goal of reducing delays. Vannevar at “What Would Vannevar Do?” writes up the issues and problems very well, I’m going to point you to him after my summary.

Here’s the thing: the limitation is not the airspace between airports, the limitation is the runways at the airports. Due to the wake that larget aircraft leave in the air, a runway can only support up to 60 takeoffs or landings per hour in excellent weather in optimum conditions. That’s with small jets that are all the same size. Larger jets make larger wakes and reduce that number.

Changing the airspace doesn’t change the runways. While NextGen is pretty cool and can be useful in several ways, RADAR can’t go away. There can be interference problems with GPS when a position can’t be determined.

In short, NextGen is good and useful, but not for what it is being sold for. So, we do have to wonder why we’re being sold it so hard.

Vannevar’s posts are:

An Operational Critique of NextGen: While this is actually his second post on the subject, it’s the meat of the matter where he discusses what NextGen is and why it won’t work in the way it is being sold to us.

Robert Poole, Kathryn Wylde, NextGen ATC and the Overton Window: Vannevar’s first post on NextGen and the people who are pushing it. And how they are pushing it. More political, less technical.

Runways and the Theory of Constraints (TOC): More of an explanation as to why runways are the issue and airspace is not. Gets into how to analyze and think about this sort of a system.

A New York NextGen Metaphor: another approach to covering the operation critique for those less familiar with the aviation world. A metaphor using bridges and New York City.

Solving the ATC Delay Problem: Ok, so if NextGen won’t do the trick, how do we solve the delay problem for flights? This is one sensible approach. Frankly this is more rational and reasonable that anything I’ve heard so far as it fits with the political economics of the situation.

NextGen ATC / Next Gen Air Traffic Control: Summary and wrap up. Why Flow Control is not the answer. And what NextGen is really good at doing.

So, the solar-charged camper works well and the 65 AH battery is sufficient. Even on cloudy days we were getting some charge. We were able to charge brother-in-law’s rechargeable blender charged too.

The solar panel was supported by a piece of wood cut to a good length and with a notch at the top. I set it at an angle roughly equal to the latitude. Through the day, I also moved it - rotated it - this kept it pointing directly at the sun. One night during a windstorm I laid it flat on the ground so it wouldn’t blow over. This “maintenance” was a trivial effort.

Some lessons were:

• I probably overestimated our load. No problem there as I didn’t drastically overestimate. And, I’d rather overestimate than underestimate.
• It would have been good to see some measure of charging current and load current and of battery voltage. I have no easy way to see what my battery level is right now.
• Wiring in a popup camper is hard. The up-and-down of the camper is difficult on wires. Nothing broke, but my wire mounts did not hold.

All it all it was a good idea and much quieter and more pleasant-smelling than the generator at the other end of the campground too. My setup probably cost about the same too. And I have no ongoing expenses for fuel or engine maintenance either. Ours wasn’t the only solar system in the campground, it’s an idea catching on.

Later at some point, as requested, I’ll put up my wiring diagram and a component list for anyone interested in doing something similar.

Note: The issues here only affect iPhone developers and only those developers that upgraded from 2.2.1 to 3.0 after they’d provisioned their iPhone.

After WWDC, I setup my iPhone for development use as described earlier. I was running iPhone OS 2.2.1 at the time. Later, I upgraded through iTunes to iPhone OS 3.0 when it came out. I continued the process of teaching my self how to program the iPhone. When it came time to upload a new app, I couldn’t.

After much hunting around, some reading of documents, checking of hex identifier codes, and the requisite gnashing of teeth, etc. I figured out by using the XCode Organizer window that my iPhone wasn’t provisioned anymore. Well as the last real change was the upgrade to 3.0 that was probably it.

I used XCode’s Organizer to “Restore iPhone” (via a popup on the Summary tab) using the iPhone OS 3.0. This wiped the phone’s data and apps and restored it’s provisioning. It didn’t affect the OS version installed. The popup only allowed the 3.0 version to be restored.

This left the phone in a minimal mode only able to make an emergency phone call and with a graphic on the screen that it wanted to be plugged into my USB. So I did that. I used iTunes to re-restore the system to my last backup. Which, fortuitously was five minutes before I started this mess.

In the end, after the few non-productive hours I spend figuring this out, restoring, and re-restoring, I’m back to having my iPhone with all my data, and I can download new apps to it from XCode as well.

The Root Cause

I surmise from past experience in working with keys, certificates, and public key encryption that there is a tie between the certificate and the OS version. This is a pain for developers and breaks Apple’s user experience principle of allowing upgrades without pain. Granted, only developers are affected and perhaps it’s my failing as a new iPhone developer but I had found no warning of this effect of the OS upgrade.

I understand why Apple is using key signing for applications and that’s good. But as a coworker (hi Randy) once said: The point of security is to create a failure point. I would hope Apple tries to smooth this process in the future. An undocumented failure point is more typical of a Microsoft feature than the usual Apple experience.

I thought I’d put a few notes together on my experiences so far too. These are the ten steps to get started with iPhone programming. There are several sources of useful information that you can Google for. And developer.apple.com/iphone is the canonical source for information.

If you don’t want to do all this, well, you can just hire me or someone like me to write your iPhone app for you. That works too!  Email me at contact@tangozulu.biz.

First things first, you don’t actually need an iPhone to get started, although you’ll want one soon enough. You can program with the iPhone simulator in the development environment, but somethings (accelerometers for example) are not simulated. But you to need a Mac, Windows won’t do. (That’s ok, you need a UNIX box anyhow and that’s what MacOSX is after all. The iPhone is UNIX too. Get over the Windows thing; Microsoft doesn’t let you develop MacOS software on Windows Vista do they?)

1. Get a Mac.

So, get a Mac, any of the laptop pros are good for this. I like the 17 inch, but each to their own. If you have some bucks, get a 3 GHz, 8 GByte memory laptop. Amazing capacity, but you don’t need that level machine to write code for the iPhone.

You’ll need XCode, this is the development environment for the Mac and for iPhone. No worries, this is free. This is listed on the apple site as the iPhone SDK. But, it’s XCode with the iPhone SDK bundled. This is free. But, you’ll have to become an iPhone Dev Center member to download this. You can do a free option, but you won’t be able to download your app onto an actual iPhone with that, you’ll only be able to use the sim. If you buy the membership for $100, then you can later get the cryptographic keys to sign your app and download to an iPhone device.

2. Get an ADC (Apple Developer Center) membership. Spend the $100 for this either now or later.

3. Download and install the iPhone SDK (containing XCode as well) on your Mac and install it. If you have a new Mac, use the Snow Leopard version. Else (assuming you’re not upgraded yet) use the Leopard version. If you’re not running Leopard yet, then upgrade already. You’ll have to.

Ok, you’ve got a working dev environment now. So, “hello world” is next of course. Use this link from Apple to make your first app and try out the dev environment. Run it on the sim, getting it on the iPhone is another issue.
And, if you’ve not done this yet, get an iPhone and use it. Try out some apps and get a feel for what works and what doesn’t. Buy some more apps and try those non-apple apps out too. The point of this is to get a feel for the UI and user experience. Without this you’ll make bad decisions in your designs.

4. Write and run “Hello World” on the sim.

5. Get and use an iPhone if you haven’t yet.

Now, you’ve gotta get your keys. All iPhone apps are signed, and the ones on the iTunes store are countersigned by Apple. You have to 1) get your key to sign your app, and 2) set up your iPhone to accept that for developer purposes.

To get your keys, follow the precise instructions in the iPhone Developer Portal with the Provisioning Assistant there. If you have the free account, you won’t see this. You’ll only see this link when you have your paid account. So shell out the $100 and upgrade already.

You first make a certificate request to the Apple certificate authority, this is the standard public-private asymetric key. The certificate is signed by Apple to make it good. You also have to make a device profile for your iPhone. If you’re a solitary developer the “team” aspect of this is a no-op. If you’re part of a development team, then there’s a hierarchy of controls that can be put into place.

The the second part, you provision your device with your profile and certificate. Beware, XCode 2.x and 3.x are a bit different here. Their directions were 2.x based, and we’re running 3.x. Look under “Code Signing” in the target properties for your application to find the settings they’ll talk about.

Also, note that all this in your profile and provisioning is case sensitive! This created problems for me, either I missed where Apple said it was case sensitive or they didn’t say.

6. Pay your $100 to upgrade your account

7. Request a key

8. Make a profile for your device

9. Provision your device

At this point, you can now put your hello world app on your iPhone and walk around and show it to your family and significant other(s).

Then, learn. Time to exercise your brain and read. The iPhone OS and software development works with ObjectiveC. (Yup, get used to it. I actually like it better than C++.) You’ve also got some massive amount of APIs in the SDK to get familiar with too. Then there’s the human interface stuff and design philosophy. It’s important as this is how Apple does their polished apps. This is a learning curve, but it will help as there’s tremendous amounts of stuff already written for you. You can stride along in seven-league boots making new apps and use all the stuff Apple made for you.

There are plenty of reference materials in the usual well-written Apple style about all this, and about the UI too. But one way to get started is to use the Stanford iPhone class on iTunes U to learn the basics, then expand from that. It was taught by Apple engineers, so that helps.

10. Learn, with online resources or perhaps with the Stanford class.

Or, if you don’t want to do all this, hire me and I’ll write your app for you. So, happy hacking!