As planned, the beta testing of CloudAhoy app version 2.0 had started on June 5th. There are over 20 testers right now, and most are rather active. The majority own an iPhone and an iPad, and run the app on both. I have received tons of good advice and problem reports. THANK YOU VERY MUCH, DEAR TESTERS ! ! !
At this point most of the planned features have been implemented. They include: a universal app with native iPad support; In-app debriefing (2D) of the recent flights, and a special CFI tab.
The app is mostly done, but there are still some odds and ends that need addressing.
I can almost hear you asking: hey, that’s great, but what about 3D briefing on the iPad?
The answer: iPad-based 3D will be available as well. Initially more limited than what’s currently available on Windows or Macs, but hopefully the gap will be narrowed over time.
I expect the CloudAhoy 2.0 app to be in Apple’s app store towards the end of this month or in early August. Again, many thanks for all the excellent feedback!
I am looking for volunteers to beta-test CloudeAhoy 2.0 on iPhone and/or iPad.
CloudAhoy 2.0 is a significantly improved app. It works natively on iPads, and the iPad version includes several interesting additions. I am looking for feedback on the user interface, shake any bugs, and perhaps most important, any unsolicited feedback from you.
I plan to start beta testing in about a week. If you would volunteer, it would be fabulous.
Get the Unique Device ID (UDID) of your iPhone and/or iPad devices. I found clear instructions on getting the UDID from iTunes here.
Email these UDIDs to me, or to support@CloudAhoy.com
The symptoms: sometimes Auto Stop is not triggered at the end of a given flight, and/or the next flight gets concatenated to the previous.
The first CloudAhoy user to report the flight concatenation bug was Abram Dancy, back in March 2012 (the name is used with his permission). Abram’s bug reports, and other users’ reports, resulted in app version 1.8. But it turned out that another fix was needed. Hence app version 1.9, in the iTunes store as of today. Thanks to every user who reported a problem!
Frank Yellin, a CloudAhoy user, sent yesterday an email with a problem report. He landed on KRDD runway 16, and CloudAhoy identified it correctly. On his next flight he departed from the very same runway, but that time CloudAhoy identified the airport he departed from as 2CL4, nicknamed American Display, and could not figure out a runway. What gives?
In the FAA airport database each airport is represented by one point, typically at around the center of the runways. Turns out that about 2500’ from the approach end of runway 16, outside of the airport, there’s a heliport called American Display. When Frank landed, the touchdown point was closer to KRDD, but when he later took off, the rotation point was closer to 2CL4. CloudAhoy got confused. In other words, a bug.
I added an entry to CloudAhoy’s bug database, and planned to investigate it at a later day. Then an hour later another CloudAhoy user, Luke Hayes, sent an email with a similar problem but in a different airport (BTW, both users permitted their names to appear in this post). I figured that my initial assessment, that it’s a rare case, is probably wrong. And so I fixed the bug.
If you had a similar problem in a past flight, debrief it again. This will fix the airport name, and will identify the runway too.
I was curious what is American Display. I could not find information about the company, but Googling I found two private heliports in CA, both called American Display and owned by the same individual. See this and this.
And back to CloudAhoy – report of what’s cooking in the R&D dept: A much improved app (working natively on iPads), and a better helicopter and hot-air balloon debrief including 360° point of view rotation.
Today the ceiling at my home airport was 600’, and I thought that I should shake out some IFR rust, go SPIFR (single-pilot IFR) and shoot a few local approaches in a Warrior.
I ended up flying only one approach. So in that respect the mission was not fully accomplished. But since I had my first real partial-panel in IMC, a bigger training mission had been accomplished. Obviously, I landed after the failure.
I’ve done my instrument checks while taxiing. When released, they had me turn to 040 after takeoff. I turned a standard-rate turn as I was entering the soup, and noticed that the attitude indicator was showing a 35° bank.
That triggered a concern. My next vector was 360. By that time, a standard-rate turn according to the turn coordinator was 45° on the attitude indicator. I checked the circuit breakers, then declared the turn coordinator broken. Several minutes later it stopped responding.
Looking at the CloudAhoy track, my localizer intercept and tracking were not so good, although I did a fairly good job on the glide slope. I attribute my performance on the localizer to mostly rust but also to partial-panel. Also, I think that it could have helped if ATC gave me a better intercept vector.
My takeaway for future flights: carry with me yellow stickies to cover failed instruments, to reduce the confusion.
All in all I flew only 0.25 hour air time. The Hobbs was 0.85, because there was a line of airplanes waiting for release. Actually Ground had me do my runup in a side taxiway (picture on the right), then told me to turn 180 and join the line.
0.6 hours overhead for just one approach was well worth it, though.
Today I put in beta a pre-release version of iPad-based CloudAhoy debriefing. Give it a try by logging in to beta from your Safari on your iPad. Let me know how useful it is for you.
No, Apple/Google did not implement a Google Earth plugin in iOS. That would be too easy. Instead, when logging in on the iPad’s Safari, CloudAhoy debriefs the flight on Google Maps. As the screenshot below shows, both Satellite and Terrain views are supported.
Because of the iPad’s small screen size, I added a button for closing the left panel, leaving only the Timeline shown. The same button is also available on all the desktop browsers, except Internet Explorer.
Obviously, the iPad’s implementation lacks the cool 3D features which you are used to in the Mac/Windows desktop version. No cockpit view, no published 3D instrument approaches, and for now, no sectionals.
On the plus side, the iPad’s version can display the flight path on a terrain map.
BTW, the flight I chose for showing off the iPad’s debriefing was flown by me and a friend last Friday from P-town (that’s how the locals call Provincetown, MA). P-town is a terrific destination, even this early in the season.
This blog entry is about the weirdest aerial accident I have ever read about. I give below the abbreviated version, many details omitted for brevity. But first, background.
In the last 100 years Argentina was blessed with a large number of enormously gifted musicians, people who touched the soul of an entire nation. Many were admired both in Argentina and worldwide, but none were admired and loved more than Carlos Gardel. Gardel died in a plane accident on 24 June 1935 at the age of 44, but is still admired today, 77 years later. Some say he actually sings better every passing day. I agree.
Last week my Spanish teacher Mariela and I visited the Gardel museum in Buenos Aires. A corner of the museum was dedicated to the fatal accident. The text (left) gave the official account of the tragedy, as follows.
Gardel’s plane, a three-engine F-31 flying from Bogotá to Cali, made a fueling stop at Medellín, where many admirers have been waiting for hours to see Gardel. After fueling and a photo-op, the plane taxied to the south end of the runway, was cleared for takeoff by a waving of a white flag, and started a takeoff roll into the north (great footage at the bottom). After 250m it suddenly turned right, got off the runway, continued 260m and collided with another plane which was preparing for takeoff, its engines running. The two planes burst into flames, and 16 people including Gardel and the pilots of the two planes have died in the inferno.
The official account attributes this to an act of God: a sudden southwest gust of “6-7 Beaufort” (21-33 knots) pushed the F-31 off of the runway, and there was nothing that the pilot could have done to prevent the collision. This account makes sense, plus it takes care of liability issues.
Back in the apartment, I googled the accident, and I bring below the alternative explanations.
The first evidence that the official account was incorrect is that the F-31’s landing gear tracks indicate that once it turned right it continued in a perfect curve of 30 degrees. Had the pilot tried to correct for the wind, the track would zigzag. Furthermore, some of the tracks disappear several hundred feet before the collision, and then reappear shortly before, indicating that the F-31 pilot had attempted to rotate. The runway elevation in Medellín is 5000’.
There are also indications that the F-31 was too heavy even when it landed in Medellín, and probably off of the load-and-balance envelop after fueling and loading additional heavy cargo. There are indications that the F-31 pilot was not proficient in the type of plane and perhaps rotated in ground effect and then stalled.
Why would the F-31 pilot turn in the direction of the other plane during takeoff? Aha! There was a huge rivalry and animosity between the two companies operating the two planes, and specifically between the two pilots: Ernesto Samper Mendoza who flew the F-31 Gardel was on, and Hans Ulrich Thom who was the PIC of the other plane, getting ready for departure. Several days before the accident Hans Ulrich Thom humiliated Ernesto Samper Mendoza by buzzing him – flying a few feet over his plane. Perhaps Ernesto Samper Mendoza’s wanted to buzz his nemesis, which would be doubly humiliating because Ernesto Samper Mendoza was also flying a super-celebrity.
But wait, it gets even more interesting. In an autopsy of Ernesto Samper Mendoza’s body, a bullet was found in his skull. Where did the bullet come from? Three theories: one is that after the crash Ernesto Samper Mendoza was still alive and shot himself to shorten his suffering. Two is that there was a dispute onboard the F-31 during taking off, and a shot was fired which hit the pilot by mistake causing him to lose control. The third theory is that the shot was fired by the other plane’s pilot, Hans Ulrich Thom, or by his copilot whose body was found with a pistol.
We find it laughable that something like this could happen today between, say, Citation and Learjet pilots. Aviation has become safer, if less romantic.
A week ago my wife and I started a one-month vacation in Buenos Aires. Flying there, we missed our connection in Dulles by 5 minutes.
Our United flight from Dulles left 24 hours later, on a stormy night. The good news: our status was upgraded from “you’re on standby” to “passengers squeezed in row 35”. The other good news: United has ATC audio in channel 9. For a GA pilot this is pure joy, plus educational. Here’s what I learned.
As we were taxing for takeoff, a thunderstorm with heavy rain passed over the airport. ATC warned of microbursts. It then cleared a plane for takeoff but the pilot refused to go. Lots of planes were waiting in line, one of the parallel runways was closed, and there was a pressure to get everybody airborne, yet the pilot refused to roll. ATC asked what his intentions are, and the pilot said that he wants to wait two minutes. He requested ATC for more PIREPs. The controller called both landing traffic and planes that have recently taken off, and relayed their data. After 5 minutes the pilot of the number one plane agreed to go. I learned a lesson in assertiveness, which was conducted in a very professional way.
After takeoff they switched us to Potomac departure. Here again, there was a lot of give-and-take between pilots and ATC. Since the Heavy guys have radar, they kept providing PIREPs and requested vectors and altitudes to go around the storm system. I was impressed by the close coop between the pilots and ATC, and by the level of professionalism.
The flight map in the plane’s seat had odd information. My wife asked me what do they mean by “-50 knots headwind”: if the speed is negative, does it mean that it’s tailwind? I did not know. Later when we landed we had “-10 knots tailwind” (more on that below) and so it seems that the minus sign was for decoration only. Actually, maybe the speed was in miles/hour, not sure.
Over Argentina, I was surprised to find out that most of the comm was in Spanish. I thought that if one pilot speaks English, everybody needs to switch to English. Not so. I speak a little Spanish and I could understand most of the dialogs. The ATC, a female, was very courteous with the Spanish pilots, sometimes joking and laughing with them, but not so with the American pilots of several American planes on the frequency. There were exchanges when the American pilots did not understand her, or she did not understand them. I also thought that most of the American pilots were a bit rude to the controller, and talked fast as if they are still on US soil. They did not make any noticeable effort to adopt their accent and speed to the situation. I am assuming that the Spanish-speaking pilots did not understand much of the Americans’ exchanges either.
On our descent to Buenos Aires, flying south, ATC vectored us to land on runway 36. The pilot came on the PR system and informed the passengers that we were instructed to land into the north, which he said is “unusual”, and therefore we will land later than planned. His comment on the PR system cleared the confusion about the sign of the wind speed: ATC were vectoring him to land with tail wind. Why? Don’t know, maybe the ILS did not work on runway 18.
I was also surprised that they did not switch us to the tower frequency: the same controller kept talking to our pilot until after landing, when she switched him to ground.
It’s in the app store as of today. This is a maintenance release, fixing three things:
– Better upload of data especially for iOS devices that are in Airplane Mode. If you ever had a situation where flight was held in your iOS device for too long, it is now fixed. Well, it’s fixed even if you never had the problem : )
– A recognition of Dual XGPS150 devices. This is for display only, because even in pre-1.7 the data from Dual was used correctly.
– Devices left running for days. This could happen in pre-1.7 when users started logging, and CloudAhoy waited patiently for them to takeoff, sometimes days. Or it could happen if users have actually landed, but turned off auto-stop and never turned off the logging manually.
I plan to have the next app release in late April or early May. It will have several new features, plus run in native mode on iPads.
A couple of weeks ago Google released their Google Earth version 6.2. Unless you opted out, they upgraded your plug-in software automatically.
The previous version had several bugs that affected CloudAhoy users (and I, among many others, have reported and urged them to fix these bugs). The bugs have been fixed, so 6.2 is good news. But with the good news came some bad ones: the new version crashes a lot while running cockpit view animation.
I have received reports from several users, all running on Macs. Hey, are there Windows users out there who get this problem too?
When the problem happens, do like Google says: reload the page. It helps… until the next crash.
I verified: this problem affects all the other camera movement applications that I tried, including Google’s own. That’s bad news, because if the bug were in CloudAhoy, I would have been able to fix it myself.
I found that if you get frequent crashes in one browser, switching to another is likely to help. Today I failed to get the screenshot above while running in Safari – it worked beautifully for 15 minutes. I switched to Firefox, and it crashed immediately. Other days, it crashes a lot in Safari but not much in Firefox or Chrome.
I could not get the plugin to crash on Windows XP (both IE and Firefox). Maybe because it runs a 32-bit plugin.