Bulldog wash and blow-dry...

The best thing about washing my Bulldog is having an excuse to blow-dry it...

Video clips from sortie over Isle of Man last Sunday afternoon:

Takeoff 

Cruise

Landing

Shutdown

iNavCalc now includes NAVCOM frequencies

I'm delighted to announce that iNavCalc now includes en route frequencies for airports and navaids. You don't need to do anything to enable this functionality. The FREQS will automatically appear in a PDF attachment (alongside the others) in your PLOG email generated via the iNavCalc mobile app, email app, or web app.

The frequencies included in the PDF report for your specified route are summarised as follows:

• COM frequencies for all airfields along your route. Only airfields within 15nm of your desired (great circle) track are included, on the basis that these are close enough that you would likely enter their control zones (and therefore have to call them), or even if you remain outside their zone, you would likely make a traffic info call as you pass them on a typical VFR flight. The airfields are listed in the order in which you first encounter them.
• NAV frequencies for all navaids along your route. Only navaids within 65nm of your desired (great circle) track are included on the basis that this is the approximate upper range of a VOR navaid you would use on typical  VFR flight at 3,000 ft. The navaids are listed in the order in which you first encounter them.

Acknowledgements

Let me take the opportunity to say a big "thank you" to the free internet resource ourairports.com from where I obtained the source database of airports and navaids.

Updates and Corrections

In order for this iNavCalc FREQS feature to be truly useful, it needs to be kept current. Since (at least as far as I can tell) there is no global, central database of official NAVCOM data available for free via the internet, and since iNavCalc is a free service (and therefore cannot incur the costs of licensing data from commercial sources), it relies on you (the users) to keep it fresh. This potential for staleness has been the reason why I've so far held-off from including the FREQS functionality. However, by popular demand, I've now relented, and put it in. I therefore encourage you to submit change-requests for any inaccuracies you discover (e.g., incorrect COM or NAV frequencies, missing airports or navaids, or airports or navaids which are now disused and should therefore be deleted from the database). I've created a web-form where you may submit your corrections. Here it is:   

 FlyLogical Data Correction Submission form (click here)

I will undertake to verify and implement any amendments submitted via this form. For convenience, the corrections form URL is also included in the SYSTEM MESSAGES section of each PLOG email you receive from FlyLogical. 

[Note: although ourairports.com has a facility for users to provide corrections to airfield data, it does not (at the time of writing) have a similar facility for navaids. Therefore I've provided this single form for both.]

I hope you enjoy this new addition to the FREE iNavCalc toolkit.

Isle of Man: get off your bike and take a hike !

I'm no photographer, but thought I'd share a few pics from a hike last weekend on the Isle of Man (where my aircraft is based at EGNS). All photos taken in the hills above the village of Laxey, on the Snaefell Mines trail. Though most famous with petrol-heads (and justifiably so!), the Isle of Man has some less well-known qualities, as evident in the pics below. So if you happen to be visiting for the TT, why not take the opportunity to get off your bike, and take a hike (even for a few hours, you will love it) !

My Bulldog earns its dog-tags...

With thousands of visitors to this blog, growing every month, plus thousands of iNavCalc users, growing every day, and given that my Scottish Aviation Bulldog aircraft is the central inspiration for my development of both, I thought it was only fitting to now put the FlyLogical dog-tags on the aircraft. See pictures below....

Port-side...(I wonder how many aircraft have their own twitter account ?)

Starboard-side...(....or their own blog ?)

The work in progress...(my pal Joe being the master craftsman at this sort of thing)

Greetings, goVFR !

I recently came across the free web-based VFR planning site goVFR  ( goVFR.com) . It has a nice GoogleMaps-based interface, and will therefore appeal to pilots who like using GoogleMaps for flight/nav planning --especially in Switzerland and neighbouring countries where the site includes airspace overlays.

I've now got around to testing the inter-operability between iNavCalc and goVFR. Here is a summary of my findings.

Note: rather than focusing on the GoogleMap functionality (both iNavCalc and goVFR have some similarities in that regard --- and I would expect that users will stick with what they know/like), I wanted to explore the portability of data between the two platforms.

I'm pleased to be able to report the following:

1. the gpx and fpl files exported from iNavCalc can be successfully imported to goVFR 
2. the gpx and fpl files exported from goVFR can be successfully imported to iNavCalc 
3. the gpx and fpl files exported from goVFR can be successfully processed via the iNavCalc email interface (i.e., simply attach the gpx or fpl file to an email and send to plogs@flylogical.com ). This enables the goVFR users to easily obtain NAVCM frequenvies, NOTAMs, TAF/METARs, plus the iNavCalc PLOG (as an alternative or as a complement to the goVFR PLOG).

These positive findings are a testament to the benefits of software publishers adopting standard formats such as gpx for sharing information across systems. It is your data and you should be able to exploit it on any manner of systems you choose to use.

My Flying Tribute to The Dambusters

With all the #Dambusters70 coverage the past couple of days, I couldn't resist putting together a flying tribute of my own today.

"Target"

Based on the Isle of Man (home base EGNS), I first had to find a dam to "bust". The natural choice was SULBY RESERVOIR DAM which lies inside the motorcycle TT race circuit, in the northern half of the island, but outside of controlled airspace (handy).

Aircraft

My ex-RAF Scottish Aviation Bulldog, tail number xx667. Here are a few pictures taken before departure this morning. Note the blue skies, very rare in these parts.

Route

With an easterly wind, runway in use at EGNS this morning was 08. That suggested tracking up the east coast of the island, then cutting across to the west to the target zone. Here's my planned route in GoogleMaps: http://bit.ly/111zB1B

Departure

Uneventful. Here's the video footage (from cockpit-mounted GoPro Hero 2) of the take-off and initial climb-out.

"Raid" on SULBY RESERVOIR DAM

...and here's the video footage of the "raid" itself.  Respecting local livestock and farm buildings, I flew the "raid" at approx 1000 ft AGL.  There are lots of sheep in the vicinity: I didn't want to scare them into slipping down the hill into the reservoir...

Recovery

Uneventful. Here's the video footage of the landing on runway 08. Got radar vectors to the ILS (bit of practice...)

Debrief

Could not imagine having to do such a thing for real: no modern navigation equipment, ultra-low-level (60 ft!) raid at night over hostile territory with people shooting at you. Here are the (approximate) Dambuster routes in GoogleMaps: Waves 1 & 3  http://bit.ly/10AtWzz , Wave 2 http://bit.ly/10Dk9Jb . Imagine flying those routes under those extreme conditions...

Hats off to those chaps.

iNavCalc now includes NOTAMs

I'm delighted to announce that iNavCalc now includes NOTAMs. You don't need to do anything to enable this functionality. The NOTAMs will automatically appear in a PDF attachment (alongside the others) in your PLOG email generated via the iNavCalc mobile app, email app, or web app.

The NOTAMs included in the PDF report for your specified route are summarised as follows:

• Airfield NOTAMs for each waypoint in your route. If a given waypoint is not an ICAO airfield, then the nearest ICAO airfield is used instead.
• FIR (Flight Information Region) NOTAMs along your route. The FlyLogical database includes all current ICAO FIR regions (more than 400). When preparing the FIR NOTAMs report, iNavCalc searches for the relevant FIR regions along the route.

Acknowledgements

Let me take the opportunity to say a big "thank you" to the US FAA for providing free access to their global NOTAMs web-service. Moreover, their support team has been second-to-none when it comes to providing timely feedback to my technical questions...evenings and weekends, no barrier !

Enjoy this FREE service (and let me know of any issues...)

Bulldog Fatigue Meter, a Suitable System of Levers, and Einstein's General Theory of Relativity

Bulldog Fatigue Meter

I recently had to remove the Fatigue Meter from my Scottish Aviation Bulldog aircraft and send it off for its tri-annual overhaul. I find it to be a rather interesting device, so I gathered my thoughts together in this post, whilst flying transatlantic with a fine view of the wing root on the Boeing 777, pondering its structural strength…

Here’s a couple of  photographs of my Bulldog Fatigue Meter. The first is front-on, showing the “g” (pronounced “gee”) readouts, spanning  a range of “bins” (or “buckets”) from -1.5 g  to +6.0 g.  The device is about half the size of a shoe-box, and was built by Negretti & Zambra (Aviation) Ltd (in the 1960's, as far as I can determine). The readouts are all zero since they were reset during the overhaul. The second image shows the instrument mounted on its bracket located between the aircraft front seats (the “glovebox”/pedestal assembly which normally covers the device has been removed for access).

...is not actually a "Fatigue Meter"

Now, calling it a “Fatigue Meter” is a bit of a misnomer since it doesn’t actually measure “fatigue”. It measures “airframe-vertical” acceleration i.e., in the direction “through the seat” (as opposed to “airframe-horizontal” acceleration “along the nose”). More specifically, it counts the number of times the (“airframe-vertical”) acceleration (at the location on the airframe where the instrument is mounted) exceeds various threshold values, defined by the respective “bin” readings.  The key point is that in order for the airframe to achieve a given (“airframe-vertical”) acceleration, the wings must have provided the required force, and moreover, this force must have been transferred through the mechanical structure which connects the wings to the fuselage. This mechanical connection between the wing and the fuselage is the most (structurally) critical area of an (non-rotary) aircraft, and is typically the strongest part of the entire structure.

"Pulling the wings off ?" ...not quite...

If you pull truly excessive “g”, you can exceed the mechanical strength of the structure, and the (proverbial) “wings will fall off” (just as you can bend any piece of metal to its breaking point by applying sufficient force). That is kind of obvious. But a more interesting and subtle failure mode is that of “metal fatigue ” where the application of many repetitive cycles of loading can cause cracks to form in regions of high stress concentration, ultimately leading to sudden and catastrophic failure. Moreover, each loading cycle can be well within the limits of the structural strength, yet the cumulative effect over many cycles can lead to failure (the reason is due to the physics of crack formation associated with the microscopic material behaviour common to all metals under stress).  

De Havilland Comet

I can't mention aircraft metal fatigue without a nod to the most notorious example of metal fatigue in aviation history: the infamous De Havilland Comet where repeated loading of the fuselage structure due to (routine) cabin pressurisation/de-pressurisation cycles led to crack formation in the corners of the square windows  (the square corners – a serious design flaw -- concentrated the stress, leading to the catastrophic failure after less than 400 cycles (i.e., 400 flights). A tragically expensive lesson: rectified by simply using rounded windows, as on all airliners since!).

Bulldog Airframe "Fatigue Index (FI)"

...But back to the Bulldog, where the most important structural element is the attachment between each wing and the fuselage. During the original certification of the aircraft, an assessment was made by the manufacturer (based on cyclical load tests on a ground test rig) of the maximum allowable number of load cycles across the range of load values (larger loads will lead to fatigue failure sooner than smaller loads). Specifically, in the case of the Bulldog, the failure (on the test rig) corresponded to crack formation in the vicinity of the outer bolt hole in the metal straps connecting the main wing spar to the fuselage structure (the wings did not “fall off” the test rig, but the initiation of cracking in that specific sensitive location was considered critical as it could eventually lead to catastrophic failure).

It is a convenient mathematical consequence of the physical nature of metal fatigue, that this can all be expressed in terms of a single (non-dimensional) number, known as the “Fatigue Index” (or “FI”). When the “FI” reaches the maximum allowable value (the “Fatigue Life”), the aircraft must be grounded until the structure can be modified (strengthened) in accordance with an (approved) design, such that the life is thereby extended. In the case of the Bulldog, the “Fatigue Life” happens to correspond to an “FI” of 114. Once reached, the aircraft requires a strengthening (the “Bulldog spar mod”) of the attachment between the wing spar and the fuselage, and the life can be extended to an FI of 200. Specifically, this “mod” involves replacing the existing metal straps (which connect the wings to the fuselage) with larger ones (which consequently requires the drilling of new bolt holes through the main spar – so it is not a trivial undertaking).

[If you operate a Bulldog with a Fatigue Meter, check out my Bulldog FI web-app  for calculating the (change in) FI due to (a change in) the bin readings from the Fatigue Meter]

How does the Fatigue Meter work ?

To re-cap, the Fatigue Meter counts acceleration cycles across multiple distinct bands (“bins”) which are then used to assess the FI and remaining life.

How exactly does the Fatigue Meter measure these accelerations ? In essence, it is a glorified (and expensive) set of bathroom scales. Or put another way, “a mass-on-a-spring” (or most likely, a set of masses-on-springs, one per “bin” – but that’s a detail), as shown in the following schematic:

It may surprise you to discover that fundamentally, the internals of the Fatigue Meter comprise a “distance sensor” (i.e., rather than a direct measurement of acceleration), as described in the caption to the schematic above. As the airframe accelerates, the acceleration is transmitted to the “test-mass” via a spring – the compression (or extension) of which is measurable by a sensor. Then, a Suitable System of Levers (“SSL”), converts this sensor output to the numerical counters, displayed in the readout panel.  

A Suitable System of Levers (SSL)

I first came across the “SSL” in the Royal Air Force (University Air Squadron) ground-school, whereby the “SSL” was invoked to explain away the complexities of any aircraft system considered too complex for (mere) trainee pilots (or dare I say, flying instructors) to understand. All we needed to know about were the fundamental physical principles (e.g., Bernoulli’s law for pitot tubes etc), and the “SSL” would take care of all the details.

To re-cap, we’ve got as far as understanding that a glorified mass-on-a-spring gives us a measure of acceleration, which (via an "SSL") can be used to assess the airframe fatigue life. All quite simple, in principle.

Free-fall, Weightlessness, Acceleration, and General Relativity

We now get to the last – and perhaps most interesting – part of this story. Recall what happens when you push the nose forward just the right amount (or relax the back-pressure at the top of a loop, just enough) to establish “zero g”. It’s a distinctly odd sensation even for those fleeting moments (and I can’t imagine what it must be like for astronauts subjected to sustained zero-g for weeks, months or years!). But here’s the thing: we call it “zero g” (or “free-fall” or “weightlessness”), and indeed our mass-on-a-spring would read “zero” i.e., the spring would be in its relaxed state, neither compressed nor extended.

But is the acceleration zero ? Just ask Felix Baumgartner – or any skydiver for that matter! Of course the acceleration’s not zero! They are accelerating (rapidly) towards the earth: in fact, at precisely “one g” – certainly not “zero g”. If they weren’t, they wouldn’t need a parachute!

So how can we be accelerating at “one g” when our accelerometer (Fatigue Meter) at the same time reads “zero g” (and we feel as if we are floating, “weightless”)?

The answer to this riddle is deep. So deep, in fact, that Albert Einstein (essentially) posed the same question when framing his General Theory of Relativity. In a nutshell, Einstein’s answer was to postulate (as a fundamental property of the Universe) that the gravitational field of a massive body (say, the Earth) is fundamentally equivalent to an accelerating reference frame. Or, spoken more loosely, the inertial acceleration is exactly “balanced” by the gravitational field in free-fall: so we feel nothing (and our accelerometer measures nothing), even though the acceleration is real (the skydivers get faster and faster as they fall!)

[Exercise: any idea how this pertains to astronauts in orbit around the Earth ? Clearly they are not moving faster and faster like the skydiver, but if the gravitational field is "balanced" by the accelerating reference frame, then where is the acceleration ? Hint: the answer is simple, and can be derived from high-school (Newtonian) physics --  but has similarly deep significance in the Einsteinian view.]

Equivalence Principle

This “Equivalence Principle” is mystifying. So mystifying, that physicists are still trying to verify if it is ultimately and exactly true, or only approximately true (and breaks down if you look closely enough). The answer matters: if it turns out to be false, then Einstein’s theories are approximate, not fundamentally true descriptions of nature. This is important -- and many scientists actually hope this to be the case -- because General Relativity does not fit neatly (in a mathematical sense) with the rest of physics (Quantum mechanics): something must give, and most physicists expect that General Relativity is the one that will have to give. Then again, General Relativity is a towering intellectual achievement that has survived all experimental tests to date. For example, Einstein's theories predict that space and time are all affected by gravity. Not least, your GPS receiver, which relies on Earth-oribiting atomic clocks and radio waves, is influenced by gravity and motion in ways unimagined by Isaac Newton (who three hundred years earlier discovered the pre-Einsteinian approximate mechanical laws describing the dynamics of bodies in the Universe). If we ignored relativistic effects, and didn't compensate for the Einsteinian corrections in the GPS system, the navigational errors would be significant, on the order of 10 kilometres per day !

Testing Einstein

In a previous career, I worked with a team of engineers and scientists at Stanford University, NASA and ESA (European Space Agency) to devise ever more accurate (space-based) experimental tests of General Relativity. Such experiments are extremely difficult (and expensive). As such, the jury is still out.

If it turns out that General Relativity, and by definition the Equivalence Principle, are fundamental universal truths, then it would be distinctly more satisfying if the Equivalence Principle could be proven from first principles, rather than merely postulated (assumed) as the basis of General Relativity. Indeed there is a theoretical framework emerging that does just that: only trouble is, it requires that our Universe is a holograph 

But maybe that’s OK!

Parting thought

The next time you push the nose forward, relax at the top of a loop, or merely jot down the readings from your humble Fatigue Meter, take a moment to acknowledge that by doing so you are in a sense probing one of the deepest, as-yet-unexplained mysteries of the Universe. 

...all that from a glorified set of bathroom scales (plus an SSL, of course)!

[...the 777 wing root looks OK, by the way, even if the tip is bending up and down by a metre or more in the North Atlantic turbulence...]

Seeing is Believing: announcing a FREE and open GoogleMaps route viewer

Update: as well as from iNavCalc emails and the iNavCalc web-app (described below), you can now access this #ROUTEVIEW functionality directly from the Route Share feature within the iNavCalc mobile app (Version 3.0 onwards). Click here for details (in the iNavCalc Mobile App Users' Guide)

You will notice that your iNavCalc PLOG emails now include a link to "view the route in GoogleMaps and share with anyone via browser, email, and Twitter".

This very simple but powerful feature enables you to view your route from any mobile or desktop browser. Moreover, by sharing the link with anyone (whether a registered FlyLogical user or not), they may also view your route. Additionally,  the viewer provides options for tweeting and emailing the route to your friends and followers. The email option automatically attaches the route exported in ".gpx" and ".fpl" file formats, providing extreme portability across people, applications, and devices.

As well as via the embedded links in the PLOG email explained above, you can open the viewer directly from the iNavCalc web-app route editor by clicking the (new) share buutton, as highlighted (yellow circle) in the screenshot below.

Last but not least, you can use the viewer to share routes created via any other software or device which supports the  ".gpx" or".fpl" formats (i.e., not just those generated by iNavCalc). Simply send the given ".gpx" and ".fpl" file as an email attachment to plogs@flylogical.com  . A few moments later you will receive an email with the route URL, which you can then share with anybody, as described above. You do not need to be a registered FlyLogical user to a access these features. They are open to everyone.

Give it a go !

Convert a Garmin fpl file to a gpx file

Update 18 April 2017: completely re-written iNavCalc mobile apps with streamlined command-line interface for iOS, Android, and Windows 10

Update: the desktop browser version of the iNavCalc web-app now supports import & export of gpx and fpl files, making it simple to transform between the two formats in any either direction.

Convert a gpx file to a Garmin fpl file

Update: the desktop browser version of the iNavCalc web-app now supports import & export of gpx and fpl files, making it simple to transform between the two formats in any either direction.

Update: with Version 3.0 of the iNavCalc mobile app on Android, you can now import a gpx file by clicking on the file (within the Android file-system, e.g., on the SDCARD), and then convert it to fpl via the iNavCalc email functionality, described below.

I'm often asked:

"How can I use iNavCalc to convert a gpx file to a Garmin-compatible fpl file ?"

The process is simple:

• Using any email program, send a message to plogs@flylogical.com with the source gpx file as an attachment (the subject and body of the email can be blank)
• A few moments later you will receive an email response with the desired fpl file attached (amongst a bunch of other useful things, which you can choose to ignore !). The fpl file format from this conversion has been successfully imported to Garmin 795 and 695 devices. Other Garmins might also be fine, but untested (at least to my knowledge).

Going the other way is equally simple....

[Requires that you have registered your email address with FlyLogical. You only need to do this once. Click here to register. It is FREE] 

Where's Daddy ?

...Just updated the TLB/SQWEEK functionality to include an embedded link in the location Tweet which takes you to a simple GoogleMap page showing the location, date/time-stamp, and accompanying note.

So, when they ask "Where's Daddy ?", just say "not sure....check if he has #SQWEEKed recently !"

"...there he is !"

[I know there are loads of apps which offer similar mobile location services  but I simply find it handy to have this feature "under-one-roof" with the rest of  the iNavCalc functionality...so I put it in ! You -- and yours -- may find it useful, too !:)]

TLB and SQWEEK

With the release of the iNavCalc mobile app v2.0, I've included a new feature called TLB which stands for "Twitter Locator Beacon", a play on "PLB" -- "Personal Locator Beacon".

As the name suggests, this allows you to broadcast your location (leveraging your mobile device's location function) to the @FlyLogical Twitter feed. Anyone who wishes to know your whereabouts, simply follows @FlyLogical (and searches for your FlyLogical user-name with the optional hashtag #SQWEEK to de-clutter the results).

I call this "SQWEEKING" (a play on "tweeting" and "squawking"). Typical usage would be, for example, to announce to the world that you have landed safely, etc.

It is simple to use, and free.  All you need to do is carry out the following steps:

• Create a FlyLogical user account (if you don't already have one)
• Download the iNavCalc mobile app to your device
• Activate iNavCalc on your mobile app. The first time you do this, you will need to verify the credentials of your FlyLogical user account (first point, above)
• Click the Coffee Cup icon top-centre of app main screen (highlighted in yellow in screenshot below)

• This will take you to the main menu.
• Click on the Bullhorn icon to navigate to the TLB (sqweek) screen

• Click the SQWEEK button (adding an optional note before doing so). Assuming your location services are enabled on your device, you will receive a confirmation that your location has been verified, and you will be asked to confirm the SQWEEK.

•  On confirmation, your user-name & location (latitude, longitude), date/timestamp plus (optional) note will be tweeted via the @FlyLogical Twitter account.

• Clicking on the embedded link within the Tweet takes you to a simple GoogleMap page showing the SQWEEK location, date/timestamp, plus note:

• Anyone interested in knowing your location may retrieve it by following @FlyLogical on Twitter. 

iNavCalc "Version Two Point Oh"

Update: iNavCalc now includes NOTAMs

Update: see recently-added Route Viewer which further extends the route-sharing capabilities of iNavCalc...

I'm pleased to announce the release of  iNavCalc v2.0 for iOS and Android (including Kindle Fire).  If you already have v1.0 installed on your mobile device, the upgrade will be available automatically via the respective app store. If you're one of those people who prefer to wait for "Version 2.0" before trying new app, then here it is.

Main features

Enhancements to Routes and PLOG generation (compared with v1.0):

• Google Maps page for entering & editing routes -- despite what the experts say about small digital maps being bad for your brain, I do admit they are handy, so I've gone ahead and leveraged the power of the Google Maps API v3.x in the iNavCalc mobile app. Also included touch-screen conveniences such as "double-click-to-delete-waypoint" and "click-leg-to-insert-waypoint with rubber-banding", etc.

• Waypoint search/lookup against FlyLogical database of more than 43,400 airports and 11,100 navaids across 242 countries -- bringing to the iNavCalc mobile app the same database and search facility as available via the iNavCalc web-app. You can extend the database with your own custom waypoints (via the iNavCalc web-app) which then become available to the iNavCalc mobile app
• Automated Geosearch (if FlyLogical database lookup unsuccessful) -- bringing to the iNavCalc mobile app the power and convenience of geosearch 
• Route-Editor page for convenient Waypoint list manipulation -- let's you quickly edit and re-order your waypoints in your route, a handy companion to the Map page

• Generate PLOG directly from Map or Route-Editor screens -- complementing the command-string (email subject-line) interface for rapid PLOG generation and GPX / FPL file creation/export
• Comprehensive suite of Parameter-Edit screens (for applying PLOG generation control parameters without having to type them in) -- leverages the power of the entire set of iNavCalc command-line parameters via an easy-to-use UI

• Assorted UI improvements and minor bug fixes

Brand new feature in this release:

• TLB and SQUEEK ("TLB" stands for "Twitter Locator Beacon", a play on "PLB" -- "Personal Locator Beacon")
• Broadcast your location to whoever may be listening (via Twitter). I call this "SQWEEKING" (a play on "tweeting" and "squawking") 
• Typical usage would be, for example, to announce to the world that you have landed safely, etc.

iNavCalc now available in Amazon AppStore

The iNavCalc mobile app (v3.0) is now available (for free) in the Amazon App Store. Click on the icon (on the left) to go to the iNavCalc listing on the Amazon App Store and install on your Amazon Kindle Fire (or any other Android device)...or simply search for iNavCalc within the App Store on your device, and install from there...

Compatibility with Garmin 695 verified !

Many thanks to peterlondon posting on the UK Flyer Forum for successfully "field testing" the iNavCalc-generated ".fpl" formatted files on the Garmin 695. This complements my own testing on my Garmin 795 device.

[If anyone is able to test on the Garmin 796 or 1000 series, please share your experience. I'm confident -- though not certain -- that those should work, too. But successful "field tests" by someone with access to those devices would prove it once and for all...]

GoPro Bulldog flying videos

Videos made with a GoPro (HERO 2) mounted in the cockpit of my Scottish Aviation Bulldog

(...apologies for lack of editing finesse -- no time at present for anything beyond simple cropping !...)

Taking off from EGNS (Ronaldsway, Isle of Man), 13 January 2013

Laxey (Isle of Man) outbound,  13 January 2013

North Barrule (Isle of Man),  13 January 2013

Maps on the brain...

I was interested and not surprised to find that psychologists and cartographers have recently discovered that using small digital maps (of the type found on smartphones, tablets, navigation avionics devices, etc) actually impairs our spatial awareness. This ties-in with my own experience of navigating by "following the pink line" (on my Garmin, or iPad GPS etc), happily and accurately reaching my destination airport, "...good, airfield in sight (tell the tower, etc)", but then suddenly faced with the mental gymnastics of "****, how do I line-up in the right direction for my overhead join".

Of course, being prepared in advance for the correct arrival is the appropriate response (I hear you shout), but on occasion I admit I've been caught-out in the slightly bizarre situation of having 100% location-awareness (from the GPS), and almost zero spatial awareness. Yes, the "OBS" functionality (if your device has it) helps a *great* deal in this scenario...but only if you remember how to activate it in the heat of the moment... ("what switch or knob on the Garmin 430 does that again?") etc.

I'm relieved to hear the experts telling me its not entirely my fault. Their findings are summarised in last week's (19 January 2013, p45) New Scientist article  "Where in the World...?" .  Well worth a read.

Here are some highlights:

Toru Ishikawa from the University of Tokyo, Japan, found that:

"...those referring to their phones traveled more slowly, walked longer distances and were worse at working out their orientation than those using a paper map ".

The full paper can be found at Wayfinding with a GPS-based mobile navigation system: A comparison with maps and direct experience, in Journal of Environmental Psychology, vol 28, p. 74.

...and Georg Gartner, a cartographer at the Vienna University of Technology in Austria argues from similar experimental evidence that reading maps on cellphones can affect our spatial cognition. Specifically:

"A map on a mobile device or in a navigation system leads to less accurate mental maps and a lower ability to act in the real world". 


...Yikes, just as I was contemplating adding GoogleMaps to my new iNavCalc mobile app...which, on balance, I will probably do for the convenience of finding waypoints in pre-flight planning, but not for navigation.

[Anyway, just like everyone else, I always fly with complete, up-to-date, paper charts folded in the correct manner for my given route, and easliy accessible in the cockpit. Right ?]

Goin' mobile...

<<< choose your platform >>>

Version 2.0 now released

(Also available for Kindle Fire via the Amazon AppStore)

I'm delighted to announce that iNavCalc is now available for the iPhone, iPad, iPod Touch, or any Android device (click the appropriate link above, or search for iNavCalc on the App Store or the Google Play Store, respectively). This powerful (yet *FREE*) app makes it even easier to generate your PLOG by email. Follow three simple steps (requires only one hand / one thumb !):

1. Enter desired route as list of waypoints separated by spaces e.g.:  EGNS EGNH
2. Click "Get PLOG..."
3. A few moments later, retrieve your PLOG, MET, GPX, and FPL files as email attachments

Finally free of my PC (!)

In a recent post I extolled the virtues of the Garmin AERA 795, and its synergies with my free email-based flight nav planning app, iNavCalc which now supports importing and exporting of Garmin-format routes  (".fpl" files).

So far, so good. But I was still left with the nagging problem of having to

1. only program the Garmin SD card when at home (using my desktop PC with its built-in SD card reader); or 
2. lug my laptop around just to be able to program the Garmin on-the-go (at the airfield, in the cockpit before departing, etc) via the laptop's SD card-reader.

THOSE DAYS ARE HAPPILY BEHIND ME, and I just thought I'd share with you my excitement at being finally free of my PC (at least when it comes to flight planning). For no more than a few pounds/dollars/euros, here's how I have freed myself:

First, here's a reminder of  my essential  kit for flight nav planning and navigation:

1. Garmin AERA 795 for in-flight navigation (in my humble opinion, blows away my iPad in terms of usability, robustness, stability, and performance in the busy cockpit environment -- pricey, yes, but you get what you pay for).
2. Samsung Galaxy S2 Android smartphone for planning my routes via iNavCalc and nothing more than a 3G connection (to receive email on the phone).

Next, I recently purchased the following pieces of kit to complement the above:

1. A simple portable USB SD card reader (from Kingston)
2. A USB OTG (On -The-Go) cable for connecting the USB SD card reader to the Galaxy S2. Quite possibly the best £1.69 I've ever spent. 
3. The Gmail Attachment Download app for Android
4. The ES File Explorer app for Android

...and here's how all that kit hangs together, completely freeing me from my PC:

1. I use the Galaxy S2 smartphone with  iNavCalc to plan my route (literally using only one hand / one thumb) via email. When done, I automatically receive an email with an attached ".fpl" file containing my desired route.
2. I open the ".fpl" attachment on the smartphone, and save it to the local micro SD card ('permanently' installed in the phone). This is where the  Gmail Attachment Download app does its thing: it enables files of any format -- such as the relatively obscure ".fpl" format --  to be downloaded and saved (without this app, the Galaxy S2 would not allow me to download an unrecognized file format such as ".fpl").
3. I plug the OTG cable into the Galaxy S2, and connect the portable USB Card reader to the other end of the cable. I then insert the SD card from my Garmin AERA 795.
4.  Using the ES File Explorer app, I copy the ".fpl" file from the phone's internal micro SD card to the Garmin SD card in the external reader [note: I did, of course, try copying directly from the email attachment on to the mounted Garmin SD card. The file-copy worked fine: but then the Garmin somehow couldn't import the file. Odd. I will take a closer look if/when I have time. Meanwhile, 'bouncing' via the internal micro SD card works fine, adding only  a few seconds to the task].
5. I then slot the SD card back in to the Garmin, and "import" the ".fpl" file to create a route (aka a Flight Plan) in the AERA 795.

The whole process takes a matter of minutes. Also, I can just as easily go the other way: export route(s) from the Garmin into my phone and then on to wherever...e.g., Google Drive (for my own later re-use), or iNavCalc's routes database (for sharing with anyone)...

Of course, all of the above would be unnecessary if I could communicate between the Galaxy and the  Garmin via Bluetooth and utilise some file-sharing protocol....maybe that will come in time, but for now, I am happy (and free).

Final note: all of the above is avoidable if I simply use my iPad for everything. That has certain appeal: I can use iNavCalc  to generate/share routes via email, and seamlessly import them to SkyDemon or AirNavPro etc., on the iPad for navigating. In fact, this is what I used to do -- until the iPad let me down once too often in the cockpit, and I went the Garmin 795 route (and haven't looked back since).

Related: this experience exemplifies one enormous advantage of Android over iOS: the ability to configure your devices to do what you want to do with them, not being restricted to do only what Apple allows you to do with them. Try reading an ".fpl" file via the iPad camera kit's SD card-reader, for example. Impossible. Forbidden by the Apple software (unless you jailbreak your iPad, which is not an ideal scenario -- especially on a device you may then go on to use for navigation !)