Another year and I still have not made the requisite trek to Aviation’s Mecca. But I’ve spent a little time this morning burning internet bandwidth with two webcam streams and two KOSH Tower frequencies.

For anyone who has seen parallel sequenced landings at a major airport like Boston Logan or Los Angeles, those are nothing compared to what takes place at Oshkosh’s Wittman Airport during AirVenture. In 2009, there were 3,000 flights handled by the tower in just 10 hours – that is a take-off or landing every 12 seconds !

They manage this feat by dividing up the runway length with a series of large colored dots (more like targets) and landing planes at different points along the runways. They also must reduce radio communications time by using one-way communications with airplanes giving visual confirmation either by flight path or rocking wings.

It’s orchestrated chaos

The aircraft Weight & Balance App for smartphones is done. It’s been done for about a week but needed to do some usability testing and then create the video tutorial. I’ve had other hints on my mind so is had to wait. The wait is over.

The mobile web app is really just a specialized calculator so there is no reason it needs an Internet connection. Thus, even though the app is written with HTML, CSS, and JavaScript, it works in airplane mode on iPhones and iPod Touches (and probably android devices but I don’t have any for testing).

A few changes from the first release …

• Helper feature to remind new users to add the app to their home screen
• Dynamic UI to support a wider range of aircraft configurations from single seat to four occupants and up to three baggage areas.
• CG results are displayed graphically as well as numerically.
• Warning messages for missing configuration, over gross, and out of CG
• This version of the app uses the jqMobi framework in place of jqTouch

You can install the application at: 53VG.com/wb. I hope pilots find the app useful. Leave feedback if there are features you’d like to see in the next release!

Addendum: a post to an aviation related forum reminded me of a small assumption I made in the app. While the data entry of the settings and the flight data are all meant to work with either English or metric units, the fuel load is in US Gallons and converts to US pounds during the calculation. Thus, the app does not really support metric. Sorry about that.

For a number of reasons which will become evident over the next several weeks, I have started to do performance testing on the airplane.

My initial plan was to fly a performance test flight then make a change and then fly the performance test flight again and compare. It turns out there are just too many variables for that simple method.

Fortunately, there are non-profesional racers in the world who do this type of stuff all the time. They have been invaluable. The above image and description is based on their years of experience.

What is important to note is that the procedure strives to eliminate some variables, adjust for others, and mitigate still others.

The actual application of the procedure is a bit less precise than the description of the procedure. Here is an example:

I ran the above procedure three consecutive times in a single flight and yet the NTPS spreadsheet (National Test Pilots School) calculations yielded 157.8kts, 158.9kts and 160.1kts respectively. My hypothesis is that ground terrain was one factor I had not considered. The combination of trees, reflective poly covered tomato fields, and muddy inlets results in varrying amounts of thermal activity. The last of those three tests was performed completely over water and thereby significantly reducing the variability.

I plan to fly the test procedure over a couple more days in hopes to see the results stabilize. Once I have a trusted baseline, I can make the first change to the airplane.

It may all sound a bit boring but I'm actually finding the process to be enjoyable.

Don't expect to see me out on the race circuit as a result of this work. The airplane is an economy flier, not a speed daemon.

Almost a year ago I wrote a mobile web application for my iPhone. It was a simple aircraft weight-and-balance calculator. The nice part was it would work without an Internet connection and it remembered all the settings from the last time it was used.

I wrote it for my airplane. It worked for any pilots long as they were flying an RV-8.

Over the past week of evenings, I rewrote the application to support a wide range of airplanes. I also took the opportunity to try a new mobile web application framework – jqMobi

The author(s) of jqMobi claim they have built a leaner faster replacement for the widely used jQuery Mobile. I'm not sure they hit their mark.

My gut tells me they have good intentions but insufficient resources to get the job done. I know jQuery is getting fat and slow on older iOS devices. JqMobi is smaller but for my project, it was still slow on older hardware. More worrisome is that is it very unpredictable and buggy. Something as simple as running their own “kitchensink” test application and switching themes (a part of their test) shows spacing and layout bugs. Worse still, they have made code paths that are totally unpredictable for tough events and form input. The lack of documentation and examples means you are debugging their code more often than your own.

Update 1: I was able to change my application's CSS and HTML to behave with the jqMobi parsing of the input fields withing the fieldset. The original markup worked fine for jqTouch and Dojo.

A google search shown low adoption for jqMobi and a fair amount of friction between jqMobi and the jQuery Mobile team. My guess is jqMobi was built by a team for their own use and the public release is secondary.

Update 2: The lack of online public usage and commentary means that most searches for “jqMobi” and a “question” will show jQuery results. There may be adoption going on but it is not public.

What does all of this mean ?

Simple – I don't trust jqMobi to get better and I don't trust it to be around and supported a year from now. There's no good reason to risk it.

Sadly, I have finished the weight-and-balance re-write using jqMobi. I finally have everything working. It took about 30 hours. But, I'm not going to release it. Instead, I will rip out jqMobi and re-write everything to either Dojox Mobile or jQuery Mobile.

Update 3: I did e re-write using Dojo. It was pretty quick. I attribute mush of that to the fact I've re-written the application three times now and the CSS, HTML, and JavaScript is very modular now. The Dojo documentation is also extensive. The Dojo implementation was the fastest of all the different frameworks – even on my old 1st generation iPod Touch. Sadly, I could not find a single working example of Dojo in full off-line mode. I posted to internal and external sites but no success. The off-line requirement was the show-stopper. Since I had the jqMobi version working, and I needed to release the update, I went ahead and cleaned up the final code and posted the app.

Chalk this one up to a “character building exercise”